Burton Group Analyst Anne Thomas Manes wrote a great article yesterday called SOA is Dead, Long Live Services. If you just read headlines, you might think that she is denouncing SOA as a failed architecture. But if you read the entire article you will find that what Anne is really denouncing is the term SOA and the failed approaches that most organizations have used to try to implement it.
Although the word “SOA” is dead, the requirement for service-oriented architecture is stronger than ever.
I wrote a post on CIO.com several months ago called the Top 10 Reasons Why People Make SOA Fail. My message was that SOA is disruptive and transformational. It requires vision, leadership, organizational change management, and exceptionally talented architects and engineers. Dave Linthicum summed it up in his post when he stated:
So what went wrong?
First, there are not enough qualified architects to go around, and you’ll find that most of the core mistakes were made by people calling themselves “architects,” who lack the key skills for moving an enterprise towards SOA. They did not engage consultants or get the training they needed, and ran around in circles for a few years until somebody pulled their budgets.
Second, the big consulting firms drove many SOA projects into the ground by focusing more on tactics and billable hours than results and short- and long-term value.
Third, the vendors focused too much on selling and not enough on the solution. They put forth the notion that SOA is something they have to sell, not something you do.
Finally, the hype was just too much for those charged with SOA to resist. Projects selected the technology first, then the approach and architecture. That’s completely backwards.
As much as I agree with Anne’s article, I fear that the attention will now shift towards the next exciting technologies like mashups, cloud computing, Saas, and others and we will repeat our mistakes. Two years from now we will be blogging about the death of cloud computing and mashups if we don’t take a step back and review our lessons learned. When you bowl it down, what is the real problem here?
In my opinion, we suck at architecture! Why do we suck at architecture? Let me count the ways.
- We think process is a bad thing and it slows us down. Well bad processes are bad, but good processes can guide us through the proper steps that lead us to successful implementations. But there is a balance between process and agility.
- We are impatient. Many executives, especially in publicly traded companies don’t have the stomach to wait a year or two or more to reap the long term benefits of a service-oriented approach. They want results and they want them now. So we skip steps like identifying the organizational impacts, implementing governance, and acquiring the proper talent and wind up with a hodge podge of services that are built wrong and are unmanaged.
- We don’t understand what an architect really is. How many people do you know that have the title of architect? How many of these same people have a clue on how to architect an enterprise system. I laugh when I see job openings for a .Net architect. What does that mean? Is this person capable of architecting a .Net framework to be used by the .Net community? No, this person knows .Net real well. That’s not an architect, that’s a “senior, sr. developer”.
- We don’t understand what architecture really is. I am a member of many LinkedIn groups that focus on architecture. There is so much discussion on what the value of EA is and hundreds of different answers. If we can’t agree on the value of EA amongst ourselves, how in the world is the CEO or CFO going to support an EA initiative? There are so many good frameworks out there (Zachman, TOGAF, E2AF, etc.) yet it seems that we are trying to reinvent the wheel. Pick one, tweak it to your organization’s needs, and follow it. It is not rocket science.
- We lose sight of the value and argue semantics. I am also in many yahoo groups (SOA, Cloud computing, etc.) and the discussions are so discouraging that I don’t even participate. There are so many religious wars like Rest vs. Web Services, this vendor vs that vendor, and myths being discussed as facts. What we really need is to discuss what has worked an what has not. What are the best practices, the gotchas, the case studies, etc. We should be helping each other succeed instead of fighting over semantics. No wonder the business often takes matters into their own hands. How did we become a Dilbert cartoon anyways?
- We lack leadership skills and emotional intelligence. When was the last time you saw IT leadership who excelled in Technology, Business, and People Skills? You are lucky if they are good at two of these but to deliver transformational technology based initiatives they need to be skilled in all three (see The Missing Link in IT).
But these are not SOA specific issues. IT has historically struggled with enterprise wide initiatives because they require more than just technology to implement. Look at IT’s track record delivering ERP, CRM, new software development lifecycles (SDLC), agile, six sigma initiatives, etc. All of these require an organization, not just IT, to change behavior, standardize, and work in harmony to achieve a common set of goals. To make matters harder, we still need to keep the business running in the mean time.
The Cop Out
So now that we have declared SOA dead, we can forge ahead and start creating all kinds of ungoverned services, mashups, and cloud applications. But guess what, like SOA we will wind up spending more money on solutions that don’t solve our problems unless we invest in architecture. It reminds me of day trading and the the housing bubble. People fall for the get rich quick scams and think they are winning the game until it all comes crumbling down. Like a good long term mutual fund, SOA is a long term investment that lays the foundation for long term success. The day traders and house buyers where living high on the hog early on but when the market corrected itself many where left broke. The day trading bars disappeared, the real estate agents closed shop, and the hype died. That’s what I see in IT. SOA was the stock that went up 150 points in one day or the condo that you could flip for $50K in 3 months. So we bought ESBs, hired consultants, and wrote a ton of web services. There were some quick wins. But then we needed to make changes to these services and things broke. Worse yet, because we didn’t take the time to architect the data layer, a business request caused us to make changes to 35 services instead of making a configuration change in the data services layer. Even worse, we lost track of which version of the service we changed and who it impacted. We made the change and broke other applications. You get the picture. We day traded instead of architected. Guess what? We failed. But we blamed SOA, the vendors, the analysts. It couldn’t have been our fault could it?
So my question to the industry is when are we going to admit that we will continue to fail until we invest in enterprise architecture? EA frameworks do not only address technology. EA starts with the business and ultimately defines which people, processes, and technologies that are required to help the business meet its goals. Included in any good EA framework is the transition plan (I call it organization change management plan) required to successfully implement the appropriate solutions.
So the choice is ours. We can invest in EA or we can have the analysts declare our next strategy dead two years from now. I choose EA. What do you choose?