InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

SOA Is Alive And Well?

Posted by Mark Little on Oct 18, 2007

Sections
Architecture & Design,
Enterprise Architecture
Topics
SOA ,
Technology
Tags
Trends
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."
  • This article is part of a featured topic series on SOA

No comments

Watch Thread Reply

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.