Interdependent Architectures
I’m currently reading The Innovator’s Solution by Clayton Christensen and Michael Raynor. This is a business book from Harvard Business School Press, not an SOA book, at least so I thought.
In Chapter 5, titled “Getting the Scope of the Business Right,” the authors discuss product architecture and interfaces. Keep in mind that this is a business book, so the product they refer to could be consumer electronics, a box of kleenex, I-beams, etc. The authors state:
A product’s architecture determines its constituent components and subsystems and defines how they must interact- fit and work together- in order to achieve the targeted functionality. The place where any two components fit together is called an interface. Interfaces exist within a product, as well as between stages in the value-added chain. For example, there is an interface between design and manufacturing, and another between manufacturing and distribution.
An architecture is interdependentat an interface if one part cannot be created independently of the other part- if the way one is designed and made depends on the way the other is being designed and made. When there is an interface across which there are unpredictable interdependencies, then the same organization must simultaneously develop both of the components if it hopes to develop either component.
The book goes on to discuss the pros and cons of interdependent architectures and how they create a performance versus flexibility tradeoff. Interdependent architectures yield greater performance, modular architectures yield greater flexibility through tight specifications. This is certainly analogous to IT and SOA, as SOA is all about standards-based interfaces and higher flexibility. If you read on, however, you find that there is a perpetual see-saw like motion that consumers take regarding performance over flexibility. In the early days, a market may be built on performance and features using a completely proprietary model. The original Apple Macintosh is a great example of this. Apple controlled it end to end, and as a result, provided performance and features that no one else did at the time. Over time, however, a consumer base built up that was not so interested in performance and features, but was interested in flexibility. This eroded Apple’s market share and made Bill Gates rich. Today, however, the pendulum has swung back. Apple’s success with the iPod is largely due to the proprietary, integrated experience they can provide by owning the solution end-to-end.
So what does this mean for the SOA practitioners out there? It means that we must be judicious in where we apply the principles of SOA. If the business requires flexibility, SOA is where we need to be. If the business does not require flexibility, SOA may be a tough sell. Today, we’re at the apex of the pendulum swing on the side of flexibility. The business is demanding it, and SOA is there to save the day. As you build out your services, however, keep in mind that the pendulum will swing back. There will be a time where performance and features will rule over flexibility, and your IT systems must be prepared to support it. What’s the key? The key is that both interdependent architecture and a modular architecture understand the concept of interfaces. If you know where your interfaces (services) belong, you can choose to make those interfaces more or less proprietary as appropriate. Any large organization will likely find that some services need to be very specific to a single consumer to meet performance needs while other can be designed to support the masses. Those decisions are based on the needs today, however. Over time, that consumer-specific interface may need to be used more broadly as the pendulum shifts. If you never had a service there to begin with, it will be a far more difficult task.