SOA marketing and expenses. On the misleading promise on SOAs and what is dying?

Continuing thinking over the “SOA and the real Service Integration issue”, I fall on a tone of new-years posts concerning the ‘2009s SOA death’. Once again, I believe that the whole thing is about conceiving SOAs. I post a draft thought concerning the way that SOA need to be conceptualise both from Architects, Developers and Business owners perspectives. In most cases, the ‘philosophy’ of analysing requirements, services and environments for SOA, didn’t had the appropriate ‘holistic’ nature. So, lots of problems raised,  both in financial aspects but also in designing principles. All the above, and more were stated by Mike Kavis in his post  Top 10 Reasons Why People Make SOA Fail.

[

1. They fail to explain SOA's business value.
2. They underestimate the impact of organizational change.
3. They fail to secure strong executive sponsorship.
4. They attempt to do SOA "on the cheap."
5. They lack the required skills to deliver SOA.
6. They have poor project management.
7. They think of SOA as a project instead of an architecture.
8. They underestimate the complexity of SOA.
9. They fail to implement and adhere to SOA governance.
10. They let the vendors drive the architecture.

]

Dave Linthicum summed it up in his post when he stated:

[

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.

]

Anne Thomas Manes blogged the SOA is Dead;Long Live Services, and stated that “SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural approaches that depend on “services”.” The logic that follows her thoughts is more or less :“Successful SOA (i.e., application re-architecture) requires disruption to the status quo. SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates. The small select group of organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. In each of these success stories, SOA was just one aspect of the transformation effort. And here’s the secret to success: SOA needs to be part of something bigger.”

And I fully agree with this last statement. Actually, don’t forget that SOA = Service Oriented Architecture.

The illusions of the above SOAs concepts, become when considered the SOA as option, tool, software platform or some product under the SOA – name umbrella that will magically solve all problems. More or less, was a marketing oriented illusion from some (actually the biggest) vendors  on the street. And all this illusions, combined with the financial aspects (more and more and expensive new software, service from vendors and external co-operators, consulting etc ) gave a avoiding aroma in the real S.O.A. approach. Ok, if you mean SOA (the above marketing term) and S.O.A. (the Service Oriented Architecture) i agree, that if its not dead it soon will.

As stated in this blog in a numerous posts, SOA actually is not expensive. Both the open source community and some vendors, have release tools and frameworks that can do the job, or parts of the job. The only consideration is the correct definition of the job, aka the A on S.O.A.s . Actually, all posts under the SOA and ESB labels are toward this concept.

Anne Tomas Manes, blogged on ‘SOA doesn’t need to be expensive’ the main in-expensiveness that S.O.A. could have (and not SOA):

[

It's a common misconception that SOA is expensive. Many organizations believe that they need to acquire a boat-load of new products and technologies to get started with SOA. First on the list of product acquisitions is an ESB, followed by registries, repositories, and security appliances. In these belt-tightening times, many SOA initiatives will be challenged to raise the funding required to acquire these products. So what's a team to do? Pack up and wait for better times? Or make do with what you have?

In truth (and much to the vendors' dismay), you don't need a bunch of new products to do SOA. SOA is about the way you design your solutions -- not about the technology you use to build them. An ESB is a "nice to have", but it's not a prerequisite. Pretty much all programming environments (Java, .NET, Ruby, Groovy, PHP, JavaScript, COBOL, CICS, etc) now include native support for building services -- both method- or document-oriented services built with SOAP and WSDL and RESTful services built with HTTP. You can also build document-oriented services using your favorite message-oriented middleware product (although MOM protocols will limit your reach and interoperability options). (I described the differences among the three types of services here. And see here and here for some great references on RESTful services.)

The only new product that an organization should really budget for is a management solution -- one that supports administration, monitoring, security, and mediation of service interactions (e.g., AmberPoint, Progress Actional, SOA Software Service Manager. Many platform vendors also provide management solutions--sometimes reselling AmberPoint [Oracle and Tibco]).

For organizations that need an ESB, consider open source solutions. Mike Kavis posted a nice summary of open source SOA stacks here. David Linthicum has also been extolling the benefits of an open source SOA product strategy here. Both Mike and Dave point out that the open source solutions tend to be easier to use and more cohesively integrated than the big vendor alternatives. Unfortunately, none of the open source solutions provides a comprehensive management solution yet.

]

the reason that i am using this part of Ms Manes post, is that i feel that describes the best my overall thesis on this subject and hope yours to.

If you need more applied, real world arguments on this, or how can be applied into your case, please drop me a notice.