Did we make the right architectural choice?
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.