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
Hi,
Thanks for the nice article and good analysis.
After reading your article I got few queries regarding use cases of above theory.
1. Can this be applied to any kind of architecture-SOA, MVC, Broker etc?
2. Can this be applied to layered architecture? Consider a case where I have n nos of layers in my architecture and at each layer I have m functions to be invoked which finally increases the complexity and the cost. Reducing n layers to n-k would reduce total fns to (n-k)*m. However it might arise multiple design issues like coupling, maintainability and performance etc. What could be reasonable approach while selecting and analyzing arch designs?
Thanks,
Jayant
Hi Javant,
Thanks for the questions. I’d expect that you can use this approach with different kinds of architecture, and actually, when applying the approach it might guide you towards a certain architectural style (depending on the business functions [ABCs in Rogers terminology: Autonomous Business Capabilities] and dependencies between them). In the example I only used the calculations to compare 3 alternatives. The book describes a process (SIP) that guides you in partitioning the functionality over systems. I’ve not applied the SIP process for the example in the blog. (Just noticed that there is also a whitepaper on SIP in case you don’t have access to the book: http://objectwatch.com/white_papers.htm#SIP)
The book is focussed on Enterprise Architecture and I’m not sure if you could also you the same approach when doing the architecture of for example 1 system, or a framework. I do not see any obvious reasons why it would not work, but maybe there are some dynamics on these levels of architecture that do increase/decrease the applicability.
Hi Gero, nice! Did you try what happens if you get rid of the EAI components? What exactly increases complexity? My impression is that arrows are evil, therefore reducing arrows would reduce complexity. Removing the EAI components would remove 3 arrows (or even 6 for alternative 3) so EAI-less solutions should get a lower score right?
Jan.
Hi Jan,
Agree, if you’d drop the EAI adapters, the the scores would be lower. But even then there are still the questions
– of using the DWH or not
– pushing the request through the chain vs. having some sort of coordinator that contacts the relevant systems.
So Although dropping the EAI adapters would reduce total complexity, there are still alternatives to be considered and you can use this approach to compare them.
In this particular case we also had to existing production situation (with EAI adapters in place) and some policies (no direct communication between systems) that we would not be able to change as part of this small project. Might not always agree with these policies, but in this context we could redo the whole landscape.
Gero
Gero.. It does look like you choose the best solutions out of the 3 alternatives. But what did you consider alternative 4: Not implementing this solution at all because it isn’t worth they trade-off in added complexity?
Erwin,
Sure that would keep complexity at the current level, but would also prevent the commercial side of the company (they use system A) to submit orders that are valid.
The information retrieved from this new service enables them to submit valid orders and increase the # of first time right orders and with that have more happy customers (since they get the services they ordered on a predictable date).
They can of course do trial&error, but since orders are not processed in real time, causes days of delay.
So there is business value that outweighs the added complexity.
Gero