Agile Architecture
Lean Architecture Principle #7: Architecture Initiated by Business Goals
Gero Vermaas 21 Jun, 2010
Share 
That was the question on my mind while walking out of an hour and a half meeting which was attended by 6 people. The problem wasn’t that complicated, we went into the meeting with 3 alternative solutions: so why did it take so long to pick one? It kept nagging me a bit and then I recalled the “Simple Architectures for Complex Enterprises” book by Roger Sessions. By applying his approach I was able to determine if we made the right choice and I’ll describe the results below.
For details on the calculation, refer to the book. It’s well worth the read and if you’d like to start off with a shorter version, there’s a whitepaper available here. The short summary is that simplicity trumps all other quality aspects of a system. Simple systems are easier to maintain, perform better, scale better, etc. Simple is the opposite of complex and using his approach you can calculate the relative complexity of different alternatives. Number of business functions and number of connections per system are the main input for the calculation. The one with the lowest complexity is the best alternative.
Start situation
Enough theory, what is the problem at hand? The picture on the right is the system landscape that is already in place. In reality there are more systems surrounding it, but I limited it to the systems that are considered in the alternatives. Systems A/B/C/D are all part of a fulfillment chain and as you can see they are all decoupled by EAI adapters. The datawarehouse (DWH) is fed with product details that are delivered by the fulfillment chain systems.
The functionality used down the chain from system A till D is now limited to order processing. However, system A now needs an information service that enables it to decide on certain properties for the order submitted to system B. This information service needs:
- Details of delivered products that are present in system B and C (and also fed to the DWH)
- Business rules that are only known in system C
- Business rules that are only known in system D
To calculate the complexity of the existing situation I used the spreadsheet provided with the whitepaper. Putting the number of business functions and connections per subsystem into the spreadsheet adds up to 157 SCUs (Standard Complexity Units, see whitepaper for details). This does not mean much yet, but once we have done the calculations for the alternatives, we’ll be able to see the relative increase in complexity. The calculations for the existing situation and the three 3 alternatives can be found in this spreadsheet.
How are we going to realize this information service? As said, three alternatives had been put on the table. I’ll describe each of them and their relative complexity according to the calculations of Roger Sessions.
EAI coordination, no DWH
Alternative 1: EAI Coordination without DWH
In this alternative a composite EAI service is created that is invoked by system A and subsequently gets the required details from system B, then asks system C to enrich it and apply its business rules and finally asks system D to apply its business rules. After that it’s able to send the response back to system A.
Putting the number of business functions and connections per subsystem into the spreadsheet adds up to 422 SCUs. So adding one new component and 4 new connections almost tripled the complexity!
EAI Coordination with DWH
Alternative 2: EAI Coordination with DWH
In this alternative a composite EAI service is created that is invoked by system A and subsequently gets the required details from the DWH (instead of from system B), then asks system C to enrich it and apply its business rules and finally asks system D to apply its business rules. After that it’s able to sent the response back to system A.
Putting the number of business functions and connections per subsystem into the spreadsheet adds up to 408 SCUs. So that’s better than alternative 1 and the lower complexity is mostly caused by the fact that system B now only has 2 business functions.
Down the chain
Alternative 3: Down the chain
In this alternative there is no composite EAI service that does the orchestration, but the request is pushed down the fulfillment chain (incl. EAI adapters) just like the normal orders. Each system and EAI adapter exposes a new service and once system D produces the result, it traverses up the chain though all systems again before it’s handed over to system A. At first glimpse this may seem a nice solution because a similar pattern is used as for the order processing, but each system/EAI adapter now has one extra business function and has extra connections.
When doing the math with the spreadsheet, it adds up to 715 SCUs. So this is actually the most complex alternative of the three.
Conclusion
What alternative did we choose before doing the math? We selected alternative 2 and since this one has the lowest complexity we made the right choice. However, we could have reached the conclusion much faster if one of us would have done the math before we went into the meeting. And in addition we would have some ‘formal’ argumentation why this alternative was the best one. I use this approach more often now. If you have used this, what are your experiences?
by Gero Vermaas
