In his recent post “No one wants SOA”, Kevin Orbaker identifies one of the issues with infrastructure in general and Service-Oriented Architecture (SOA) in particular:
SOA is like plumbing in a home/office. No one thinks about plumbing. No one cares about plumbing. They just want water to come out of the faucet when they turn the handle. The faucet is like the UI of your application. It is the final output from which the user interacts with. They see it. They touch it. They interact with it. They don’t know where the water comes from. They don’t really care. They just expect it to work.
To make matters worse, SOA had the misfortune to be one of technology’s silver bullets. Sellers and buyers alike gleefully conflated “can connect” with “will connect”, indulging in an expensive bacchanalia of “build it and they will come”. Broken promises and the Great Recession combined to end the reign of SOA as “the answer”. Yet, as Anne Thomas Manes noted in “SOA is Dead; Long Live Services”, services remain a viable strategy for creating systems of systems.
So, given the negatives of a relatively high start up cost and a history of disappointments, how do you justify a service-oriented solution?
Solutions, ideally, solve problems. This may seem trite, but the “solution in search of a problem” is an all too common occurrence. Letting the problem space justify the solution is key:
- Do you have one or more systems needing to communicate with multiple other systems?
- Do your systems have multiple implementations of the same type of integration (e.g. several flavors of “Submit Order”)?
- Do outages in one system degrade others?
- Do changes in one system break others?
- Do integrations force parallel development efforts and releases across more than one team?
Each “yes” answer above furthers the case for investing in the infrastructure and development needed for a service-oriented architecture, provided you can communicate the benefits. Those benefits should be expressed in business terms – removing duplicate integrations isn’t a business benefit, but saving development time for features instead of plumbing is; implementing an enterprise service bus will likely mean nothing, but being able to add new integrations with little or no delay will mean a lot; “store and forward message-oriented middleware” will yield glassy stares, but the analogy of email versus a phone call should make the scalability and response time benefits clear. Being able to quantify those benefits (for example, providing hours spent on developing and maintaining duplicate integrations) enhances the case.
When making the case for a “plumbing” change, the benefits are a big part of the picture, but not the whole picture. Assessing and communicating the costs is critical to credibility. Although it might seem counter-intuitive, a higher up front price is less a problem than unexpected costs that show up later, particularly when those costs could have been predicted. Accounting for the costs beyond hardware and licenses (e.g. training of developers, training of administrators, etc.) that can be reasonably expected demonstrates thoroughness.
Another common obstacle to infrastructure investments is a variation of the tragedy of the commons. Business owners of individual systems may well balk at the costs involved, even if the benefits are tangible. If multiple systems will benefit, it’s understandable that one owner may be unwilling to subsidize the rest. Joint sponsorship by those multiple owners may be appropriate. If the pool of potential beneficiaries is sufficiently broad, another alternative may be to solicit the sponsorship of a higher level of the organization. Strategic initiatives are generally best championed by stakeholders with a strategic focus.
Once the facts have been marshaled, they must be presented. Alan Inglis, in “What story does your architecture tell?”, provides an excellent template for “selling” a solution (based on Nigel Watt’s “How to Structure A Story: The Eight-Point Arc”):
- Stasis – The As-Is state.
- Trigger – Why now? What is the trigger event that means that we should act now? What is the imperative to change at this point?
- The quest – These are the problems with the current state that need to be addressed. What is our motivation to change?
- Surprise – This is where we determine the goals to be met by the change. We may wish to solve the problems or we may wish to go further.
- Critical choice – The key decisions that need to be made to achieve the goals, or to compromise on the goals. This is where we define our options for change, the change impacts and the decision principles that we will apply in making a decision.
- Climax – This is the big decision where we commit to a way forward with the resources necessary to get there and a change owner to drive the change through.
- Reversal – We reverse the problems and create an improved future state through a roadmap of coherent actions.
- Resolution – The To-Be state.
Alan’s framework provides a very powerful tool to present a solution in a complete, concise, and coherent manner. The narrative of an architecture illustrates it’s value to the stakeholders. They may not want a service-oriented architecture, but they may well want the benefits it brings. Telling the story of that value is the job of an architect.
Re-posted from Form Follows Function
