We can easily get swept up with recommending and using a particular architectural style — such as SOA, or object-oriented, or event-driven, or cloud-based — because they are in vogue. It is important to emphasize that using a specific architectural style is not necessarily a bad thing. If an architectural style accurately reflects the architectural needs and requirements, then it is an appropriate option. However, sometimes that simply isn’t the case. Here are a couple of examples to illustrate.
Company A wanted to standardize many business functions across several different lines of business. As part of the rationalization process, it replaced a large number of standalone applications with a set of integrated services, using the SOA recipe (or “style”). The new architecture was produced and worked very well for several months, providing the same functionality as originally supplied by the replaced applications. However, the business then decided it would like to allow business managers to change business rules, without any developer intervention. This proved difficult with the pure SOA implementation. The company had to backtrack and produce a hybrid style that combined service and an ‘event-driven business rules’ approach.
Company B adopted a cloud-based, on-demand platform that provided most of the business functionality. Again, this worked very well until the company expanded into a new, emerging market that didn’t have the same, secure network access. The EA team struggled to provide the required functionality in this new environmental context.
It’s not that the service-oriented or cloud-based recipe architectures were “wrong.” The problem was more that the EA team hadn’t fully explored the architectural needs. In particular, the team overlooked the potential limitations in adopting a particular solution architecture style.
If they rather had focused on getting the architectural thinking right — before they selected a particular solution architecture style — then things might have been different. In the first case, the desire for business users to have a high degree of control over business rules and events was clear from the outset, but it was ignored because it wasn’t a necessary part of the initial phase; when the second phase was started, this oversight resulted in expense and delays. In the second case, there was always an expected expansion into emerging markets. Recipes are all very well if that is the exact shape you are looking for.
Many years ago I was involved in a highly innovative architectural project. In many ways, it pioneered concepts and ideas that are now mainstream EA. The recipe at the time was mainframe-based, standalone Java applications. If the architecture team had started with the currently popular recipe, then the project would have been traditional and similar to most other architectural undertakings at the time. Moreover, it would have failed to address the concerns of its stakeholders or their ambitious strategy. However, the architecture team didn’t start with the recipe, and instead produced a blueprint that would still apply to many EA projects today.
Implementing these grand architectural designs was an immense challenge given the technologies of the time. The rock solid architectural thinking provided a sound framework to develop an inspired solution design: a highly modular, frame-based foundation that generated Java code; parameterized business rules and product conditions that supported product and process templates and a high degree of inheritance; and a knowledge-based rules engine that resolved business rules at run time.
