Posted by Gero Vermaas in the early morning: April 28th, 2010
This is the second of a series of blog posts discussing Lean Architecture principles. Each post will discuss one principle and applying these principles will result in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The first principle that we discuss applies to the architect role and is called “Always Involved“. The architect role is not limited to one project phase or even one project, a good architect takes a much broader perspective. The Lean Architect constantly communicates with all stakeholders (from business till operations), plays an active role in running projects, and ensures that lessons learned in projects are known and where applicable used in other projects.
Posted by Jan Vermeir around lunchtime: April 27th, 2010
Knowledge of the past allows us to predict the future, at least, for certain areas of human enterprise. I’m convinced that software development is one such area. The theme of this blog is ‘to measure = to know and to know = to predict’, so by the transitivity of equals we can state ‘to measure = to predict’.
But what should we measure? I suggest you at least measure the following and will try to explain why below: trends in burn down, trends in bugs, trends in test coverage and trends in complexity.
Posted by Gerard Janssen at around evening time: April 19th, 2010
Architecture can be divided into two categories : simple and complex.
And actually, it is the same with people. I prefer simple, humble and straightforward people. I find complex people hard to relate to, they often make a fuss about things that seem irrelevant to me and make life harder than it should be. In Holland we have a saying: “Such a person should come with a manual”. Only, I hardly ever read a manual. That is why I prefer people with a straightforward and ‘simple’ character that lack pretense and that you can take at face value. And it should be the same with architecture: let’s keep it simple. Simplicity is in fact a systemic quality that must be a driving force in architecture.
(more…)
Posted by Jeroen Borgers at around evening time: January 20th, 2010
Previous time I blogged about the last step of the seven steps, step 7: Share the responsibility for the whole chain, a non-technical but rather a communication and behavior thing which I found crucial for success. We now have reached the end of this series and I’ll sum up the topics we’ve dealt with and draw some conclusions. (more…)
Posted by Mark Bakker in the early morning: December 22nd, 2009
Introduction
Currently I am working at a big Enterprise where they use Tivoli Access Manager as authorization and authentication source for a lot of there applications.
This Enterprise is using JBoss as open source application server platform and is using this more and more. When they began using JBoss they got a TAM plug-in for JBoss from IBM. This plug-in did the complete authorization and authentication by implementing JAAS and registering all the used security roles in TAM. This is done during deployment time.
If you have an application with a lot of roles this is very frustrating because it can take a lot of extra time to start up (think of 30 minutes per application) because TAM is synchronizing all the new roles.
Most applications at this customer are using JAAS but do not have special method level authorizations implemented by using TAM. So only the roles are important.
After realizing this I thought is could be a good idea to create a simpler solution for integration TAM and JBoss. For this I wrote some custom code (only 250 lines).
Posted by Erik Rozendaal in the early morning: December 3rd, 2009
Ever since attending Greg Young’s Unshackle Your Domain talk at QCon ’08 in San Francisco and a later two-day training course given by Greg Young I’ve wanted to build a sample application that made use of the principles of Command-Query Responsibility Separation (CQRS).
However, other interesting things intervened and I never got around to doing this.
But every few months we have a one day internal training course at Xebia Software Development and after Sjors Grijpink and I proposed to give a training on DDD and CQRS we got some time to actually prepare and implement a CQRS example application.
(more…)
Posted by Erik Rozendaal in the early morning: November 18th, 2009
Besides organizing a Scala workshop at the J-Fall meeting we also presented five technical posters to serve as discussion points for anyone interested (or just walking by). Unlike traditional meeting sessions we could interact directly, somewhat similar to open space sessions.
(more…)
Posted by Viktor Grgic mid-afternoon: October 5th, 2009
Many have assumption that IT / software architecture is a thing of logic. So, there are many discussions about ESB and that we should not have those. The fact is that in large companies, we do not often do architecture – we do politecture. The politics drive the architecture. It’s not the way it should be, but that’s the way it is.
Let’s do one more shot…why do we need ESB? This time from politecture perspective:
Preventing a mess
It allows for a greater degree of control on delivered solutions. Before you even think about creating another quick and dirty integration solution; there is that annoying ESB compliancy making sure that integration mess created with each new technology is at least visible.
Disruptive Innovation
An alternative like REST is a “disruptive innovation” and does not fit in the line of old mindsets (CORBA, RMI, EJB, SOAP, WS-*,…). ESB fits in this line. Of course, it is a matter of time before something like REST wins from ESB’s.
Legacy
Quite often the cleanest solution is to change or replace the legacy in case of integration problems. So you still don’t need an ESB. But the real problem is who is going to let you change that legacy that has not been changed and (barely) working in production for a long time.
Posted by Aman Arora around lunchtime: August 27th, 2009
I joined Xebia India as a tester for one of the project. While validating the defects the biggest problem that I faced was regarding the understanding of defect report and trying to reproduce the said problem when there were no steps. Being a new member to the team and joining the application in between the sprints added to it. Every time when I had to validate the defect and steps to reproduce were not there I had to run to the developer for their help. Developers too were tied up with their own tight schedules and sometimes the validation for the defect had to wait for sometime which created a backlog for me and then I thought to come up with the solution to it which I am discussing below. Using the following approach helped us and can help all.
(more…)
Posted by Michaël van Leeuwen around lunchtime: August 3rd, 2009
Rik de Groot wrote a blog entry about a year ago about versioning services as part of the Top 10 SOA Pitfalls. He touched the subject on different versions in deployment and basically offered us the option of rerouting services using an ESB.
It is a common knowledge that consumers will keep on using a service hoping to only upgrade if *they* need additional or changed functionality. Services however are not meant for a single consumer but for a lot of consumers. Even if they want to upgrade they won’t do it simultaneously. So you will have multiple versions of services running.
I see several options to address versions of services:
1. Minimize by using rerouting within the ESB.
2. Keep all versions running while in use.
3. Have a contractual agreement with expiry date.
4. Use content based routing.
5. Construct adapters for conversion
First I would like to look at which versions might appear. A major version increment of a service means we are no longer backward compatible. A consumer wanting to use the next major release therefore needs to start coding to make use of this service. When a minor increment occurs there is backward compatibility and additional functionality offered. This means a consumer can make use of it without much effort (changing the binding would suffice). A patch increment of a service indicates a change without breaking specifications. A new patch release can – and should – therefore replace the older version.
Clearly in all options we should limit the number of versions of a service created. This means services should not be created within projects but (re-)created in a separate track in order to have generic services and optimal reuse. This track should collect all requirements of (potential) customers, take the common denominator and bring a new version into existence. More than often a new version is created because a single customer wants certain functionality not yet offered and without looking around the new version is tailor-made.
(more…)