- Common Pitfalls Limiting the Value of SOA and BPM
- How Other Industries Approach Varying Conditions
- A Streamlined Enterprise Architecture for BPM and SOA
- Basic Principles for Enterprise Dynamicity
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
How Other Industries Approach Varying Conditions
The IT industry is not the first industry to face varying conditions. Even though computing technology itself has had some approaches to variability in the past, such as overloading or rules engines, here we expose some solutions for which we can find an implementation analogy in the IT industry.
Whether it is in the automotive industry with shock absorbers and suspension, or the building industry with expansion joints, or the mechanical industry with washers, a mediation layer always absorbs the variations of one part without affecting the other part. In these industries, the integrated elements may not need to vary or move internally, but at the end, a dynamic assembly is realized with tightly coupled parts flexibly linked with other parts. Components can be subassemblies with their own internal variability using similar technologies, but the higher level assembler only cares about the external characteristics of the components. Similarly, in the IT approach, there must be a notion of the levels of assembly and the granularity of components.
In all industries, the final assembly is designed based on a global architecture that looks at requirements, operating conditions, and desired capabilities. Dynamicity is not a goal by itself; it has to respond to a specific context and desired states. Take for instance, buildings in Tokyo, which require more flexibility to withstand earthquakes than buildings in Paris. A 4x4 car has to absorb more landscape variations than a limo. Similarly, the enterprise and business architects must look at how the enterprise business model needs to evolve and what market conditions it will face to understand the variability necessary.
A bank we worked with had to implement higher controls on its loan origination processes because of the Sarbanes-Oxley requirements. However, this bank operates in four different countries with four different legislations and four different IT systems. In addition, this bank plans to expand to Eastern Europe in the future. This specific case led to a common process trunk with variable subprocesses handling specific legislative constraints and a common top-down but variable services definition for account, products, customer information, and so on.