What To Do When your SOA Initiative Gets Cancelled

We at ZapThink are an idealistic and optimistic bunch. We tend to see the positive side of well thought-out IT initiatives and believe that when rational planning meets incremental expenditure that provides short-term returns, all is well and companies can sail smoothly ahead. However, we realize that is not the reality for most companies. In the current economic climate, companies are giving the axe to those half-planned efforts that spent tremendous sums up front to show little to no returns well past their promised milestones. Even well-planned, rational initiatives that met distinct business pain-points and used iterative approaches and incremental expenditures justified only when short-term business goals are met also got their proverbial plugs pulled.

 

While we spent almost a decade trying to help you avoid this outcome by ingraining the Service-oriented style of enterprise architecture as a core tenet of dealing with continuous change, we know that for some of you, it’s too late. The wounds are fresh, but the damage is done: the powers-that-be have killed your SOA project and now you need to know what to do. Fortunately, being optimistic sorts, we’d like to give you a few potential solutions to this problem of having the SOA rug pulled out from beneath your feet.

 

Do SOA Anyways… without the Vendor Expense
If you’ve been reading ZapThink’s research for a while, you already know that SOA is not something you buy, it’s something you do. So, just because the boss isn’t paying for it anymore, who says you need to stop doing it? Usually, the primary reason why so-called “SOA” efforts get the can is because they resulted in an inordinate amount of early spending without any of the promised reward. Starting in 2001, the vendors jumped on the SOA bandwagon, proclaiming their existing middleware infrastructure as SOA middleware (aka “Enterprise Service Bus”). They saw the architectural promise of SOA and communicated it as a technology solution, resulting in billions of dollars spent with questionable value to show for it. Those who kept their eyes on the prize and focused on the architectural benefit of SOA saw greater return than their investment, but then again, these are not the folks who would be pulling the plug on their SOA efforts, would they?

 

No, those who are now pulling the plug on SOA because it got too expensive simply overinvested in the wrong area: technology over architecture. So, now these companies have already taken SOA off the project plan, those on the receiving end of the cut can get SOA back on the docket by implementing it without products. Can it be done? You bet. If you don’t believe it, it’s because you never tried it, and therefore, perhaps you simply don’t understand what SOA is all about. SOA is Dead (according to the boss). Long Live SOA (according to the architects).

 

Find a Problem Worth Solving. Do it with SOA. Tell no one.
Another oft repeated refrain from ZapThink is that SOA is not a hammer in search of a nail. That is to say, don’t start first with SOA and then look for a problem to solve. But then again, if you followed this advice, then you wouldn’t now be facing the result that the plug was pulled on your SOA project because no one could figure out why they were doing it. Companies that cancel their SOA efforts because they’ve “lost traction”, or “met with political resistance”, or some other similar reason are indicators that whoever successfully sold the SOA initiative in the first place never tied it to a short-term, compelling, and important problem that the company needed solved. After all, why would the business stop a solution to an important problem they are having? No, it’s only those companies with bogus SOA initiatives started because some exec read about it in a magazine on an airplane or got sold into it at a conference or by a smooth-talking salesman without finding a suitable problem worth solving.

 

The easiest way to keep a former solve-no-problem SOA effort a float is to quickly pivot, find a major problem to solve, salvage as much of your enterprise architecture (but not necessarily your Services) as possible and leverage your best practices, methodologies, and expertise (after all, that’s what architecture is) for the sake of the new problem. Don’t tell anyone you’re doing it with SOA. To others, it seems as if you are a magician. But you know the secret behind the trick: it’s simply good architecture applied to the right problems.

 

Convert it to a Cloud Initiative
So, your company has tossed SOA by the wayside because it simply is “not cool anymore”. SOA was the talk of the B-school elite set just a half decade ago, but now they just scoff at you when you say you’re still toiling away at it. Cloud is the new thing, haven’t you heard? All the SOA vendors have gotten acquired or put out of business by IBM and Oracle anyways, so go where the field’s ripe, or so they say. This analyst / market / lemming-driven purchasing behavior has now taken a project that had C-level visibility and doomed it to the dustbin, since it is now out of favor, and now you no longer are working on a SOA effort.

 

Can you still resurrect it? Sure, by giving them what they want. They think Cloud is cool and SOA is not, but fail to realize that you can’t really do the sort of Cloud they want without first building Services. And to build those Services, you first need to design and model them, govern, secure… wait, sounds like SOA again, doesn’t it. Of course it is. Sell them Cloud. Give them Cloud. And all along, do SOA. They want Public Clouds? No problem, focus on Service consumption, governance, and cross-network issues (security, availability, composition, etc.) They want so-called Private Clouds? Just implement SOA in a location-independent, dynamically scalable, and truly heterogeneous way. Just don’t buy an ESB. Or a Cloud Service Bus. Or whatever the marketing geniuses will turn up to convince you that what you can’t be turned into what you need, even if it can.

 

Start Tallying the Cost of Inflexibility
But what if the company pulled the plug on the SOA initiative because they simply lost faith in the whole concept? What if they wanted to go back to tightly coupled systems with hard-coded integration logic, non-composable business processes, no governance, or ability to deal with continuous change? Let’s set the clock back to 1998 and try to deal with the realities of the IT environment today with social networks changing the way companies interact with each other and people, mobile applications on new devices launched monthly, government regulations that can change tomorrow and impact your business in a critical manner, increasing security challenges, compliance requirements, and penalties for failure. Yes, let’s assume that your company chopped SOA off the block because the management simply did not believe that you can solve provide agility and flexibility through architecture. How can you convince your bosses that SOA is indeed worth the investment?

 

The answer: by measuring just how expensive it is to do what you’re doing now. They say a SOA effort will cost $20 million dollars (to which we say “phooey” anyways). Your response: the company’s inflexibility is already costing the company $40 million dollars per year, and here’s how. Quantify every process change. Every policy change. How long does it take to do a point-to-point integration? To change it? How much do you have to incrementally and continuously spend to simply keep everything afloat, let alone deal with significant changes? Does the logic “I don’t have time to do it right, but I have time to do it over” actually make sense here, or is it a colossal waste of time and money?

 

If you truly believe in what SOA has to offer and its promise, then you have to become the thorn in the side of the business that shows them the cost of doing business now. Any practical, reasonable financially-minded business executive will choose an approach that lowers the cost of change over time, if presented with significant enough evidence. So, what are you waiting for? Get to it!

 

The ZapThink Take
We often treat SOA as if it was some sort of point-in-time acquisition or implementation that a company does in its lifetime. However, as a form of enterprise architecture, it’s nothing of the sort. When we hear companies canceling, pulling back, reducing, or otherwise restructuring their SOA efforts, we wonder if they understand that they’re canceling and pulling back from their architecture. “Let’s do less SOA” means “let’s do less architecture”, and we can’t see how this benefits anyone. It might certainly be true that SOA is not appropriate for every problem and simply has been misapplied, but then the argument shouldn’t be about canceling ongoing SOA projects, but instead about refocusing SOA efforts. The problem primarily is that companies, still to this day, lack a strong, resilient, and authoritative enterprise architecture team. The architecture team is mysteriously relegated too far into the depths of the organization and therefore at the whims of those who lead by analyst report, latest media coverage, and vendor marketing pitches. Enterprise architecture is the very beating heart of the IT organization and can’t be subject to such arbitrary and fickle whims. Therefore, if you are the victim of, or even more so, the perpetrator of, a SOA cancellation effort, dig deep and see what is really being canceled — the company’s long-term viability.