ZapThink Acquires Linthicum Group / ZapFlash: Architecture-Driven Infrastructure
Let’s imagine the following scenario: John is a married man with a large family. He has a job just outside the city that requires a half-hour commute. His wife has a job in the city that, with traffic factored in, requires a 45 minute commute. They have six kids ranging from one barely in kindergarten to a 14-year old just entering high school that will eventually be driving on his own as well. Add to the mix the collection of soccer games, grocery runs, family outings, and daily chores and you have a fairly complex set of requirements for driving in, around, and out of town. And to make things more complex, John’s car has just died. He needs a new car. So, he buys a Mini Cooper. Wait, a second. A Mini Cooper? Something’s wrong. The car meets none of the above requirements. Well, maybe it helps John commute to work, but getting all the family together in the car for outings or meeting even the daily chore and driving needs will be a significant challenge at best.
So, what happened in the above scenario? Despite all the clear indications of specific requirements, John’s need for a car focused on the singular, and vague, need for driving somewhere. He bought the car first and then decided how to apply it (if at all) to his current and future needs. This example sounds ridiculous right? Well, as it turns out most companies who are buying, or have bought, SOA infrastructure are making the exact mistake John’s making. Despite all the clear requirements and indications for specific SOA needs, or even without trying to figure out what those requirements are, companies are making simplistic (and often inappropriate) infrastructure purchasing decisions. Many simply are saying “I need SOA, therefore I need an Enterprise Service Bus (ESB). I’ll buy it first and then determine later how I will meet my SOA requirements.” There’s nothing wrong with buying an ESB, but doing it without considering the requirements first is a recipe for failure.
If you have made your decision to buy infrastructure before you have figured out your architecture, you’re making John’s mistake. You’re trying to pile a family of 8 into a Mini Cooper, a semi-truck, a lawn tractor, a school bus, or a van. Given the above choices, it’s clear that the van would be optimal, but you’ve gone ahead and bought the Mini Cooper first anyways. What’s a family man to do?
The Role of the Assessment and Gap Analysis
A decision that needs to take into account many complex variables can’t be made by fiat or by simply calling in vendors and doing a feature-function comparison and bake-off. It is important for companies to know the features, benefits, and capabilities of a given technology offering for sure, but only after knowing what their needs are first! Indeed, in considering your architectural needs first, you might realize that you probably already have some elements of the infrastructure already in place that can be applied in a different manner, or that a specific aspect of a vendor’s offering might be the most important while others are either irrelevant or simply convenient additional capabilities. You would never know that without knowing what you need first.
In order to maximize the impact, efficiency, and effectiveness that SOA infrastructure plays in a SOA implementation, companies should start first with a careful assessment of their architectural needs and capabilities. If you’ve read the SOA Pilot Pitfall and Quantity is No Measure of Maturity ZapFlashes, you know that organizations can’t assess their SOA efforts by simply counting the number of Services they have or even by identifying the functional requirements of their Services. Indeed, the specific Services you have matters very little to the state and nature of your SOA. For example, one of the best practices of Service-oriented development is to assume change. This means that the quantity, functional nature, composition, policies, and other aspects of Services are highly variable. As such, an organization’s infrastructure might need to support not just exposure and running of Services, but also continuous management, quality, testing, security, composition, and exposure of Services at a wide range of granularity.
However, another organization’s SOA efforts might only focus on a particular set of business processes used within a specific context. There might be only a few Services used in a tightly controlled environment that might never see broad consumption. That context might have a more controllable environment of change or limited policy enforcement requirements. In this environment, the SOA infrastructure choices might look very much different from the organization mentioned in the above paragraph. Furthermore, that organization might be facing stiff resistance to SOA , in which case buying an expensive piece of technology before you’ve figured out if it’s relevant or appropriate is a highly risky endeavor. In order to reduce overall risk, increase likelihood of success, and optimize spending, starting from a set of adequately-defined requirements is a good starting point.
So, where do companies start? Well, first you have to start by understanding if SOA is even the answer to your problems. The correct starting point is a needs analysis, in other words, a business requirements assessment. Only if that analysis indicates that SOA might address the problems would a SOA assessment be warranted. Rather than starting with the assumption that SOA is what you need, you have to first understand what problems SOA solves, and then, how to apply to SOA to solve them. We outline this necessary business justification in our Business Modeling and Outside-In SOA and The Third Conversation ZapFlashes. Once that necessary step is out of the way, the next step is a SOA assessment of some kind. A good architectural assessment considers both current requirements and capabilities, and does so by factoring in at least five different aspects of the business and IT organization: process and function requirements, methodology and architectural approach, organizational structure, runtime, design-time, and change-time needs, and the security, policy, and governance environment. Many good assessments consider an even greater assortment of environmental considerations.
But the assessment is just a starting point for determining needs. It tells you where you are, but it doesn’t tell you where to go. When John is considering his car purchasing needs, he can’t just assume his requirements will stay the same. Indeed, his oldest son will soon be driving, and his youngest will grow up. His job or that of his wife’s might change. It’s only by knowing where you are heading that you can adequately know your needs. Similarly, companies must follow-up a SOA assessment with some sort of gap analysis to determine where the company’s SOA efforts are heading. Pairing SOA assessments with a SOA roadmap exercise as well as a means to measure a company’s progress down that roadmap is critical.
While it seems that almost every consulting firm now has a SOA assessment of some kind in their offerings, many of them are assessments in name only, and poor excuses at that. If your own internal organization or a third-party consulting firm is doing a SOA assessment simply by trying to figure out which Services to build or which processes to consider, then you know you’re heading down the wrong path. If they are doing an assessment by helping you first figure out which ESB to buy, then you know you’re already on the wrong path.
Architecture is a function of design and organization, not of technology. And this is especially the case with regards to SOA. The whole idea of SOA is to be able to meet the continuously changing needs of the business using abstracted Services that loosely couple the simultaneously changing capabilities of IT. Indeed, both business and IT are part of the continuously changing environment. If a SOA effort is tied to a particular infrastructure, and that infrastructure was selected prior to evaluating the architectural needs, the odds of success are close to zero. In fact, those who have tried and failed with SOA, and have since labeled SOA itself as a failure, should careful evaluate whether they even were doing SOA, and if there efforts were indeed Service-oriented, whether they considered the architectural needs before they went ahead and bought the tools.
Resisting the Pressure to Purchase
There’s good reason why many companies go down the path of buying products without considering their specific needs. In part, this has to do with the significant marketing and sales pressure that vendor companies use to pitch their products. The message coming out of most vendor firms is: “Need SOA? Buy our product.” As we detailed in our The SOA Marketing Paradox and the Wizard of Oz ZapFlash, vendors can at best provide capabilities to meet your needs, but they can’t figure out your needs for you.
But the vendors aren’t entirely to blame. In fact, it takes two to make a purchase: the seller and the buyer. IT buyers are too accustomed to making purchasing decisions quickly through a Request-for-Proposal (RFP) process that lumps many disparate vendors together in a single category for the sake of expediency. We discussed this in our Pitfalls of SOA RFPs ZapFlash. During this process, many companies don’t consider specific needs that make decision-making difficult or complicated. Furthermore, many companies tend to default their decisions to their current technology providers, whether or not these vendors meet their new needs. While there’s nothing wrong with vendor loyalty or expedient decision-making, an effective decision can only happen after the proper assessment of requirements. After all, if you’ve done the hard work of figuring out what you need, and then an evaluation determines that an existing vendor’s offerings will indeed work best, then you can assure yourself that a you made the correct decision and didn’t simply cave in to marketing and sales pressure.
The ZapThink Take
By writing this ZapFlash, it’s evident that ZapThink believes that there is a problem with the way that many firms are going about their SOA initiatives. Lest you believe that we’re anti-vendor or anti-ESB, let me assure you that ZapThink has no such bias. In fact, we believe that many of the best SOA implementations are dependent on vendor products that meet their customer’s requirements well. But the key to those SOA successes wasn’t the vendor choice — it was the fact that the Service-oriented capabilities met the Service-oriented requirements, and the enterprise spent the right time to make sure that their needs were factored in to the technology choices they made. Yet, too many companies come to the incorrect conclusion that successful SOA is simply a matter of vendor choice.
ZapThink wants you to be successful with SOA. We want vendors to be successful with their SOA products. We want consulting firms to be successful with their SOA solutions. The best way to guarantee success for all these critical pieces of the SOA puzzle is to make sure that those holding the purse-strings know what they want, get what they need, and do so with as little risk as possible.