It's that time of year again. Everyone is writing their predictions for 2008. Some are bullish, some bearish, some worth reading, some not. Of the myriad predictions out there, I like the ones written by Dave Chappell and Dion Hinchcliffe the best. I almost completely agree with everything they have to say. However because I don't completely agree, it gives me an excuse to write.
I suggest you read both posts in full. They are definitely in the 'worth reading' category. but I want to comment on two points made by both gentlemen. First is about the demise of Big SOA. The second is about the need for mashup governance. Unfortunately, there is too much to write for a single post, so I'll break it up into a two-part series for your reading pleasure.
2008 – The Year Big SOA Died
Chappell and Hinchcliffe are as one in their predictions for the demise of Big SOA. “That’s nice,” you say, “but what is Big SOA and what does it have to do with business mashups?” Good questions, both, so let me address them one at a time.
I’m not sure we have a good definition of Big SOA. Like porn, however, we know it when we see it. Does the initiative span the entire organization? Does it incorporate a lot of planning? Does it have a multi-year rollout schedule independent of any mission critical project? Does the SOA plan stress measures of effort, such as the number of services to be built, rather than results?
Most tellingly, when you ask the project owner to describe the business problem they are solving with their SOA initiative, do they say something like, “SOA enables developers to build applications more quickly, reducing costs through service reuse.” Hint: this isn’t a description of a business problem; it is a description of a technology solution in search of a business problem.
Big SOA is all about the big picture, which can be a very good thing. It’s good to have an understanding of what the organization’s SOA will look like in five years. Of course, in six months the five year plan will be out of date, but that’s beside the point. Thinking about the big picture can help tactical implementations fit into an overall strategy of growth, security and scalability. Big SOA becomes a problem, however, when the objectives are technical rather than business focused, when the measures of success describe effort rather than results, and when the initiative itself is not tied to the success of specific business initiatives.
Can Big SOA be done right?
Certainly. Let’s consider an example. Let’s say your sales organization has decided that adding social networking to your eCommerce site, currently a Web 1.0 app, will increase sales by 15% in the first year. The project gets funded, and the eCommerce product team makes an architectural decision to build the features using SOA. They consult the Enterprise Architecture group to see how the eCommerce initiative should fit into the enterprise SOA master plan. EA and App Dev work together to modify the enterprise SOA master plan, and to plan for the eCommerce upgrade. At implementation time the eCommerce team leverages work done elsewhere in the organization by re-using and re-factoring services and infrastructure.
In other words, Big SOA is the keeper of SOA strategy and an enabler of enterprise reuse strategy. Little SOA implements the strategy on a tactical level and makes use of the shared assets built in other projects.
Now consider Big SOA run amok. This is a story told to me by someone I met at a conference last year where I was giving a talk on consumption-side SOA governance. During the Q&A period, one of the attendees said her SOA project didn’t include any consumption-side considerations. This puzzled me since the consuming applications are where all the ROI will be realized. She said her company’s SOA initiative included a plan to roll out 500 services in the first year, and then make those services available to App Dev, who would be responsible for using the SOA infrastructure in any new initiative. When I asked her “Why 500 services?” she said it was the number they decided was right for an organization of their size.
Run away, far away. That’s what I told her, at least.
Big SOA has been fueled by middleware vendors trying to sell bloated app server stacks, by SOA governance and management vendors and by analyst firms. This next statement will likely generate hate mail, but I believe their efforts were cheered on by Enterprise Architects searching for a way to become more operational and less purely advisory. As a result, businesses have spent a lot of money and significant effort to plan and implement Big SOA initiatives. Every application, every server, every database had to be pulled into the SOA fold. After huge outlays for consultants and software, and after spending lots of time and effort planning for the brave new world of SOA, these same organizations ended up with a five year rollout plan, a huge proposed budget, and no well-understood way to calculate their SOA's ROI.
That’s a problem. If I’m about to spend $30M developing an enterprise-wide SOA, I’m going to want to see a return sooner rather than later. It’s not just the amount of money, it’s the politics. IT doesn’t control its own budget anymore. Not since the dot-com bust. Something as strategic as Big SOA now requires business buy-in and business approval. When it comes time to approve the Big Budget that goes along with Big SOA, business will want to know how soon and how much ROI to expect. If IT can’t answer, then the business won’t fund.
Hence the demise of Big SOA in 2008.
So let’s move on to the next question. What does this have to do with business mashups? Business mashups need services. They need widgets. They need workflow. Mashups behind the firewall need SOA to get access to the myriad enterprise data currently locked in siloed applications. Mashups outside the firewall need WOA to pull data and display elements from the web at large. For business mashers to take on the task of drawing down the application development backlog, SOA is a necessary backdrop. So if Big SOA is doomed, and I completely agree with Hinchcliffe and Chappell that it is, what’s going to take its place?
Smaller, directed SOA initiatives, called Guerrilla SOA by ThoughtWorks practice lead Jim Webber, have a much better chance of succeeding. Rather than taking an enterprise-wide approach, Guerrilla SOA initiatives are funded by specific projects. Because they are part of a larger project, they don't have the visibility, nor the political liabilities that come with big ticket IT infrastructure projects. Also because they are funded by specific projects, it isn’t necessary to calculate the ROI for the SOA work itself. If the project is a success, that’s enough.
2005 was supposed to be the year of SOA and wasn’t. Then 2006 was supposed to be the year of SOA and wasn’t. Then 2007 was supposed to be the year of SOA and wasn’t. If we toss out Big SOA and go with guerrilla SOA, 2008 actually has the chance to be the year of SOA, only nobody will know it. The ROI won’t come from the SOA initiative itself, but rather from IT finally getting to those pesky integrations, and from subject matter experts in the business building mashups.
The demise of Big SOA may be just what’s needed to get SOA off the drawing board and into production. And that’s what mashers need to start cranking out those mashups.
Next post: Mashup governance. Will IT help or will IT hinder?
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment