Service-oriented architecture (SOA) is not something you buy, it is something you do, writes Mike Kavis at CIO.com in Top 10 Reasons Why People are Making SOA Fail. Although the article is written to some degree from a manager's viewpoint, developers working their way through SOA projects may find some of the article's conclusions useful.
That's because research shows us that very few companies are doing SOA projects well, and the reasons for so many failures are usually people issues, not technology issues. By acknowledging the top reasons people cause SOA to fail, you can put a game plan together that addresses each issue and greatly improves your chances of success.
Based on interviews and industry research, Kavis argues in the article that the biggest mistake people make with SOA projects is to mistake the technology for the process:
The beauty of SOA and BPM is the simplicity it brings to the end users by integrating various back end systems so they look like one composite application to the user. The downside to SOA is that this greatly increases the complexity of building and managing software. Building SOA is a software engineering exercise. This is not drag-n-drop development effort and many developers will struggle to make the transition. SOA requires adherence to standards and best practices (governance) and needs talented individuals who understand complex concepts to be able to deliver.
People ... approach SOA purely from a technology perspective. They spent a great deal of time and effort on architecture, governance and vendor assessments (which is good), but they forget that SOA needs to solve real business problems. So they spend a huge amount of time and money building out the architecture—only to find that when they are done, nobody in the business understands the benefits and are not interested in the technology.
Organizations also don't often realize that implementing an SOA project also requires changes in the organization itself, and that business won't be as "usual" after the project launch:
SOA brings massive amounts of change to an organization, especially if the organization does not have a well established enterprise architecture in place.
Contrary to the common-sense approach of building things incrementally, Kavis also argues that SOA projects tend to require large budget commitments:
Some companies attempt SOA with limited budgets. In addition to all of the middleware that is required, there are huge investments in governance tools, training, consulting, infrastructure and security...
You need SOA architects, business process modelers, administrators of the tools within the stack, data architects and many other skills. These positions are not cheap. Trying to implement SOA without any SOA experience is a major mistake...
Why do you think SOA projects fail in an enterprise?
Having now blood on it's fingers, SOA is likely to turn from a hyped buzzword into a bugaboo like J2EE. ;-) It's time for the industry to find a new acronym and swipe SOA under the carpet to its fellows DCE, CORBA, DCOM, RMI and the ones I have forgotten...
SOA, like CORBA before it, promises the Fortune X00 CEO/CIO that s/he can "repurpose" 35 year old COBOL batch programs into a slick looking web app that the users will just love because it allows them to continue to execute 35 year old batch business processes with a mouse. Nevermind that such code was intentionally designed to be procedural and not event driven. And not at all OLTP or database friendly.
Those that don't know history are condemned to repeat it. And so it goes.
You need SOA architects, business process modelers, administrators of the tools within the stack, data architects and many other skills. These positions are not cheap.
> SOA, like CORBA before it, promises the Fortune X00 > CEO/CIO that s/he can "repurpose" 35 year old COBOL batch > programs into a slick looking web app that the users will > just love because it allows them to continue to execute 35 > year old batch business processes with a mouse.
Promises of this kind of magical silver bullet are not new. There isn't an essay in "The Mythical Man-Month" about this because the author was clairvoyant. However, this is not something promised by SOA. SOA doesn't promise any easy solutions. And it's not a technology like CORBA. You are confusing SOA and what vendors and consultants are trying to sell as SOA, which is often not SOA at all.
> Having now blood on it's fingers, SOA is likely to turn > from a hyped buzzword into a bugaboo like J2EE. ;-) > It's time for the industry to find a new acronym and swipe > SOA under the carpet to its fellows DCE, CORBA, DCOM, RMI > and the ones I have forgotten...
You say this as if the technologies are the problem. The problem is with an industry that promises that the next big thing will resolve all problems without anyone involved having to (gasp!) understand something moderately complex.
> SOA doesn't > promise any easy solutions. And it's not a technology > like CORBA. You are confusing SOA and what vendors and > consultants are trying to sell as SOA, which is often not > SOA at all.
I'm up to my knees in vendor poo. Make no mistake: SOA, like Web 2.0, is vendor poo. Vendors encourage the CEO/CIO crowd to conclude that all that Legacy Code can be "repurposed" through SOA; no re-engineering required, just wrap it all up in our SOABlanket. CORBA went the same way. The difference in advertised granularity is merely a difference in degree, not of kind.
The result will be the same: boatloads of $$$ to vendors/consultants, and nothing works. Another apropos adage: you can't cheat an honest man.
> I'm up to my knees in vendor poo. Make no mistake: SOA, > like Web 2.0, is vendor poo. Vendors encourage the > CEO/CIO crowd to conclude that all that Legacy Code can be > "repurposed" through SOA; no re-engineering required, just > wrap it all up in our SOABlanket. CORBA went the same > way. The difference in advertised granularity is merely a > difference in degree, not of kind. > > The result will be the same: boatloads of $$$ to > vendors/consultants, and nothing works. Another apropos > adage: you can't cheat an honest man.
If you ignore the vendor BS and focus on the real core of the service oriented strategy, there's something there. You might still disagree but it's not all of this nonsense that you are running into. Let me be clear, I totally agree that there is a lot of this nonsense. This noise is drowning out the signal.
This article is actually a pretty good assessment of the state of SOA although I disagree with a few minor points. The key thing that people get wrong and stated properly in this article is that 'SOA is something you do, not something you buy.' If someone tries to 'sell' SOA, you know they are full of shit right off the bat.
> If you ignore the vendor BS and focus on the real core of > the service oriented strategy, there's something there. > You might still disagree but it's not all of this > s nonsense that you are running into. Let me be clear, I > totally agree that there is a lot of this nonsense. This > noise is drowning out the signal.
James, could you elaborate on this?
I've been having trouble understanding what the signal might be because there really is so much noise. As Robert pointed out, a lot of the hype about SOA involves "repurposing" old investments = saved $$$ but what does SOA do that no one else has done before?
My understanding was that SOA advocates creating self-contained, loosely-coupled services, which can be "orchestrated" (love that word) into applications as desired. The problem of course is, how do you decide what a "self-contained service" is and how do you create loosely-coupled services? The problem seems to reduce itself into that age old problem of functional decomposition, modularity and interface/contract design, except at a coarser level of granularity and now introducing "process modeling experts"/"business analysts" to the mix?.
> I've been having trouble understanding what the signal > might be because there really is so much noise. As Robert > pointed out, a lot of the hype about SOA involves > "repurposing" old investments = saved $$$
In my personal experience, reusing existing resources in ways that they were not designed to support is always costly but often the cost of reimplementing (correctly) is far higher. The technology-agnostic aspect of SOA makes it possible to do this but it's not a core principle that you should. That's a pure cost/benefits question. If you have nicely encapsulated services around your old code, it might ease migration later. We are approaching some batch based programs with this in mind.
> but what does > SOA do that no one else has done before?
One of the misconceptions about SOA is that it's a new idea or pretends to be one. The idea behind SOA is not about creating something new and exotic. It's basically a formalization and documentation of a set of practices that have been proven out in real world systems. That's probably too much of a simplification but I think it's a good place to start and why I first started to consider SOA.
> My understanding was that SOA advocates creating > self-contained, loosely-coupled services, which can be > "orchestrated" (love that word) into applications as > desired. The problem of course is, how do you decide what > a "self-contained service" is and how do you create > loosely-coupled services?
There's a lot of literature on this but IMO self-contained means that it doesn't expose it's dependencies. I don't need to call service A to get the parameters from service B. But for me this is only really important at the public layer of services. Loosely coupling is hard to explain in a sentence but if you have any experience working with say, abstract classes/interfaces and concrete classes the concept is the same.
> The problem seems to reduce > itself into that age old problem of functional > decomposition, modularity and interface/contract design, > except at a coarser level of granularity and now > introducing "process modeling experts"/"business analysts" > to the mix?.
What you have said is accurate. SOA borrows heavily from OOD. There aren't any easy answers to these questions. It takes experience (and don't count on consultants to have it.) Personally, I think any senior programmer is a process modeling expert so we don't need any people who can't write code for this.
Mixing business analysts into the problem may seem problematic at first but in my perspective, it's crucial. Most software failures are the result of vague or flawed requirements. And that's really what SOA is about at the core. It's basically eliminating the 'hand-off' of requirements. The rest of SOA is about being ready for change, IMO.
I bought a book by Thomas Erl and I haven't finished it so I'm a little hesitant to recommend it but it does attempt to answer each of these questions in fine detail:
Thanks for the explanation. The company I used to work for was migrating to an SOA precisely with the intention of building on top of their large, thoroughly-debugged and stable code base. The main issue I saw with the whole process was determining how to break up stuff into services. This turned out to be more art than science. For one thing, there are many little helper methods required by a GUI client (i.e. auto completion, validation). However, these same methods are useless for process integration. Kind of messes up the service interface with both finely-grained and coarsely-grained methods.
I agree that some of the core ideas in SOA that you've highlighted, like its platform-agnostic nature, and emphasis on greater involvement of process experts, are good things. Other things like loose coupling and composability will continue to be determined by a programmer's competence I guess, and SOA will suffer from this just as OOD does.
> You say this as if the technologies are the problem. The > problem is with an industry that promises that the next > big thing will resolve all problems without anyone > involved having to (gasp!) understand something moderately > complex. The technology is part of the problem since it didn't really improve. Issues such as versioning are hardly ever adressed but essential for complex integration projects. I am talking here of the tools that should be used to implement SOA since SOA is some kind of a design philosophy (that isn't particularly new by the way, it just got a new name...).
The promise of the "next big thing" is essential for sales. The whole SOA idea got somewhat sucked up by sales and marketing and mixed with promises SOA can never deliver on.
Robert C. Martin wrote about his experience with SOA some time ago. After him, the whole ESB and BPEL thing is doomed to fail in the real world...
> Get some business process modelers to draw pretty pictures > of all the interconnections between the systems. Feed that > all into the ESB, and shake vigorously with deadlines and > threats. This will cause fuzzy bunnies to hop happily over > the green fields of his IT systems.
> The promise of the "next big thing" is essential for > sales. The whole SOA idea got somewhat sucked up by sales > and marketing and mixed with promises SOA can never > deliver on.
Absolutely. This is the real problem with SOA. And it's a cycle that we seem to repeat again and again. What's unfortunate is that some really good ideas get lost in the process and too many bad ideas get way more attention than they deserve.
Ultimately, I don't think we can blame marketing for this. It's like blaming sharks for attacking surfers. They are just doing what they do and something we care about got in the way. The real problem is that by and large, there are few educated buyers in IT. 'We' fall for the same tricks and gimmicks again and again.
It seems to me when people talk about SOA, they are usually making a series of assumptions. Often, SOA is applied as an integration tool to weave together resources that are locked into organizational silos to gain some corporate level advantage.
That's a good application of SOA but it's pretty ambitious and requires much more than a technical solution. There are many other reasons to apply SOA.
I agree with most of the points Mike Kavis makes. I believe they apply better to the integration problem I describe above.
At Overstock.com, we successfully deployed a SOA and we describe it in our JavaOne 2008 presentation that can be found here:
We built out a SOA as the back end of the check out process on our e-commerce site. Here are a few comments on the 10 reasons as they apply to this type of application.
1. They fail to explain SOA's business value. This is a no-brainer for any significant development effort. Attempting something as costly as a SOA w/o explaining the business value is going to lead to problems regardless of context.
2. They underestimate the impact of organizational change. Even in our case where IT controlled the entire SOA and we weren't crossing thick organizational boundaries, there was organizational pressure. We understood the organizational challenges as part of our 'feasibility study' and had plans on how to address them.
3. They fail to secure strong executive sponsorship. We are a bottom-up organization that pursues top-down buy-in. In that environment, it was easy to get support from our CIO. We arranged for him to demonstrate his support early to send a message about expectations. He rarely needed to be involved from then on.
4. They attempt to do SOA "on the cheap." I can imagine lifecycle management tools being beneficial for coordinating the silo problem above. In our case, most of what the governance tools provide is wasted money.
If an organization feels it must hire consultants to tell it what to do and how to do it, then the organization is probably not capable of executing the task anyway. Technical and organizational leadership must come from within the organization. Spend money on good full-time employees - don't waste a dime on high-end consultants.
5. They lack the required skills to deliver SOA. This is a hard problem that requires talent and leadership. This is the most important success factor. Skill, as in technical skill, is only part of the equation. We hire people who demonstrate technical leadership and behaviors that support a high degree of collaboration. We require people who can take initiative and responsibility (we are a bottom-up organization). These skills are invaluable in delivering a SOA.
6. They have poor project management. SOA puts a much greater demand on collaboration and coordination. One way to skin that cat is through strong project management.
7. They think of SOA as a project instead of an architecture. SOA is many projects built atop an architecture. The projects must work together. Thus #6. Team and members must be well-behaved corporate citizens. People follow the architecture and its principles which implies oversight. Some organizations prefer assurance to enforce compliance. We prefer communication and detection. We communicate expectations and can detect when compliance is loose. It can then be corrected. This has positive social implications.
8. They underestimate the complexity of SOA. I think people misplace the complexity. Service-orientation should focus on stable, high-quality interfaces. These can be quite simple. The complexity is really in coordination and in building and testing distributed applications in general. Most of the complexity is related to these issues and not specifically to SOA. Tool and standard choice introduces unnecessary complexity. WS-*, for example, is a huge and unnecessary source of complexity.
9. They fail to implement and adhere to SOA governance. I echo my comments about #4. SOA governance is very important in certain contexts and a huge waste of money in other contexts. This is one of several danger areas for vendor lock-in.
10. They let the vendors drive the architecture. The term is "Marketecture." SOA and governance are all driven by the vendors. There is absolutely nothing wrong with the concepts behind SOA but the crap the vendors foist on us is mostly useless.
In our presentation, we describe a very different approach to SOA than what you will read about in the press, hear about from your vendors, or even be able to implement with the WS-* standards.
With the right people, you can be successful with most any marginally reasonable processes, and tools. But making considered choices will certainly make life easier.
I see large-scale scale development as having to deal with three areas: Technical, organizational, and sociological. By far, sociological concerns are the most important. The right people with the right behavioral and technical skills, are the key to success.
For some reason, the world of SOA and web services has spiraled out of control. The lack of technical reason is astounding. The marketing people have totally hijacked the discussion. Go this way and you'd better get used to reading articles about why SOA fails. That is about all that is well-understood.
Flat View: This topic has 27 replies
on 2 pages
[
12
|
»
]
Previous Topic
