BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News SOA Is Alive And Well?

SOA Is Alive And Well?

This item in japanese

Bookmarks
Over the past few months we've been hearing more and more about the death of SOA. From what we've heard so far, maybe this is just what Gartner calls the Trough of Disillusionment. However, as InfoWorld mentions:
"... the model is potentially in danger of misdirection and ignorance rendering it a worn-out moniker that represents mere product features. That's more or less what happened to EAI, after all. Forces that might be assassinating SOA include: integration platform vendors, enterprise architects, certain industry analysts, CIOs."
It's with this in mind that the latest article from ZapThink tries to put things into perspective.
"Any trend that demands such a significant portion of executives’ and practitioners’ time and budget demands to be critically examined so that the good of all parties are being met. After all, very few people benefit from trends that are all hype and no substance."
According to the analysts, the most frequent cause of failure of SOA is inappropriate use. The "one size does not fit all" argument would appear to be an accurate summary of this pitfall, where companies try to use SOA across the enterprise when the business case would not be justified.
"The rationale goes that SOA is an aspect of Enterprise Architecture and therefore its scope is enterprisewide, or because it is so important and strategic, it must be implemented at an enterprisewide level. Other IT practitioners are simply used to implementing all of their major initiatives enterprisewide, so why should SOA be different? Because SOA is not a project or a technology – it is an approach, that’s why."
SOA is simply not appropriate for all problems and determining when and where (and if) to apply SOA principles should always be the first step in any attempt to use SOA. The inappropriate use (or overuse) of a technology, methodology etc. has often resulted in its downfall in our industry:
"When companies seek to implement hundreds of unproven Services against a business case that is not justified using millions of dollars of untested technologies, they risk significant failure. And when those SOA projects fail to deliver as promised, do they blame their own efforts, the products they used, or their methods? Of course not. They rest the blame on SOA itself."
As far as the authors are concerned:

"On the flip side, well-scoped SOA projects are often remarkably successful. Most case studies of SOA success relate to organizations fixating on a particular business problem, perhaps at even the departmental level, and solving that in a Service-oriented way. The champions of SOA know full well that success comes from focusing the solution on a particular problem and solving it well."

The article goes on to make the case for Enterprise Architecture Teams as the best way to apply SOA principles, because very few individuals have the skills to understand the business combined with the technical acumen necessary to understand how SOA best practices can drive business solutions. Building cross-functional teams that include, for example, line of business representatives, application development, data modeling, process modeling, security, and network operations roles, can be a key element in the success of SOA deployments.

There's also a strong educational requirement needed throughout organizations:

"Where business can see a solution, sometimes IT is blind. Too many times IT departments try to use the SOA hammer to approach every problem as a nail. Indeed, the symptom of ill-scoped SOA projects is partially caused by this inability (or inexperience) to utilize SOA properly. ... Technologists often get stuck in defensive positions regarding particular technological approaches (REST vs. Web Services anyone?). These arguments relate little, if at all, to the business problem at hand and tend to devolve into pedantic arguments of semantics. The truth of the matter is that any technology approach that can solve a business problem is valid, and probably will be displaced in favor of a better one in a few years anyways."

However, the article finishes with some sound advice for those looking to deploy applications based on SOA principles or wondering whether they have the right skills in place to continue with existing deployments:

"Smart architects and business managers who seek to apply SOA to solve their problems should have a firm grasp as to when SOA will provide success and when it is being inappropriately shoe-horned. Such a grasp includes realistic assessments of the people, technologies, processes, and methods of the existing environment and proposed solution, and the drawbacks of any potential solution. Having such a balanced approach serves to further the likelihood of success with SOA, and doesn’t by any means kill the value of SOA itself."

Rate this Article

Adoption
Style

BT