
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.
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
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.
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.
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.
Conclusion

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