InfoQ

News

Enterprise SOA: End Of The Line?

Posted by Mark Little on Nov 03, 2007 07:17 AM

Community
SOA
Topics
Community
Tags
Patterns and Practices
Joe McKendrick has a couple of interesting articles recently that look at whether or not we are seeing the death knell for "big enterprisey" (subjective) SOA. As Joe points out, some people are saying that a more pragmatic approach to SOA is the way forward:
There’s been plenty of discussion across the blogosphere, analystphere, conferencesphere, and mediasphere about how SOA has not been quite making it because it hasn’t been surfacing on the enterprise level. Instead, SOA has been mainly seen in departmental or single business unit settings.
Zapthink has long argued for more targeted approaches to SOA, or Pragmatic SOA as they called it. As we reported in an earlier article:
... success with SOA rarely necessitates comprehensive change; instead, architects who choose their SOA battles carefully can deliver on SOA's promises to the business via projects of limited scope. Architects who miss this point often set the bar for SOA success too high ...
The same argument holds true for most new technologies: with very few exceptions, for many reasons an evolutionary approach to use has a higher chance for success than a revolutionary approach. The larger the organization and the larger the scale of potential deployment opportunities, the smaller the chance that you can get everyone to agree to the necessary changes in the necessary time-frame. Joe goes on to discuss how he hears echoes of "Geurilla SOA" in what Zapthink say:
... well-targeted, lightweight engagements to address specific business problems, versus the Big SOA approach promoted by many vendors
However, Jeff Schneider disagrees with Joe in general:
... [Joe] implies that 'enterprise SOA is failing' which couldn't be farther from the truth. I believe that his bad information comes from people who don't know SOA, don't do SOA and in some cases, caused the mess that SOA cleans up.
And he also disagrees with Joe and others concerning "Geurilla SOA":
... the idiots that are running around yelling "guerrilla SOA" have to be put in their place. Many of these individuals are the ones responsible for silo-oriented thinking in the first place. They proposed small (agile) projects where we captured just enough requirements to begin coding and releasing. Guess what? This style of development doesn't jive with the concept of shared services. It is the cause of the problem, not the solution.
Furthermore, as Miko points out, enterprise SOA is hard (as is enterprise Java, enterprise CORBA, enterprise XYZ), so it should be no wonder that the number of successful examples are limited at this point: but give it time:
So while it may be helpful for us to look at the eventuality of Enterprise (intergalactic) SOA, it’s enough at the moment to establish “Interplanetary” SOA. Lets get the Development Martians talking to the IT Operations Venusians about Service Lifecycle Governance.
Although Joe agrees that both have valid points, he stands by his view that things are not all well in the State of SOA:
The bottom line is that organizations that really need SOA the most to reform and reshape their processes are the ones least likely to adopt SOA. For most of these organizations, service-orientation will be spotty, uneven, without purpose, and often without the full support of the enterprise — or perhaps no support at all. There will be plenty of SOA proponents forced to go it alone, building success one process at a time. Guerrilla tactics may be the only way forward here.
But there does seem to be some agreement. Whether or it's "Geurilla SOA", or Pragmatic SOA, Joe mentions that successful enterprise SOA deployments he's been involved with have involved some partitioning of the deployment space, but with the whole picture still kept in mind:
They don’t do it for the entire enterprise all at once - that isn’t what ‘enterprise SOA’ means. Instead, they partition their enterprise into a set of communities and attack them, often in parallel.
To which Joe responds:
Perhaps we tend to think too small when it comes to SOA. Maybe we need to start ‘thinking big.’ As with anything in life, constrained, limited thinking leads to mediocrity. Dreaming big opens up the universe to new possibilities, new ideas, and new innovation. In the long run, SOA is far more than standardized interfaces or streamlined processes ... SOA has the potential to reorder organizations into confederations of entrepreneurs and brokered services that will open up new opportunities for everyone in the economy.

5 comments

Reply

Idiots? by Steven Devijver Posted Nov 4, 2007 8:45 AM
think globally act locally by Joost de Vries Posted Nov 6, 2007 10:15 AM
Agile is the cause of the problem? by Joshua Graham Posted Nov 6, 2007 3:20 PM
Re: Agile is the cause of the problem? by jeff schneider Posted Dec 14, 2007 10:41 AM
Re: Agile is the cause of the problem? by berkay NiQuiL Posted Jun 30, 2008 2:56 PM
  1. Back to top

    Idiots?

    Nov 4, 2007 8:45 AM by Steven Devijver

    Calling people idiots won't get him anywhere. The people who he calls idiots are merely saying: it's easier to get forgiveness than it is to get permission. It's also easier to get forgiveness before you call people idiots than after.

  2. Back to top

    think globally act locally

    Nov 6, 2007 10:15 AM by Joost de Vries

    The difficulty of getting mired in discussion and slow processes is a universal risk of enterprise wide efforts. Ideally one would start an initiative on a local corporate level keeping the global enterprise needs in mind. Unfortunately "keeping global enterprise needs in mind" isn't always as intuitive as it seems. These issues aren't so much design issues but organisation-change issues. That takes a wholly different tool set.

  3. Back to top

    Agile is the cause of the problem?

    Nov 6, 2007 3:20 PM by Joshua Graham

    To Jeff, The vast majority of the enterprise mess is from legacy systems created pre-Agile. These are the critically deformed progeny of projects with a lack of collaboration, lack of domain-driven design, lack of "think big, act small" (or globally/locally" as Joost points out), all-you-can-eat requirements, and framed with cost-blowouts and anti inter-departmental sharing budgets in mind. That's what I'm thunkin anyways, aherk.

  4. Back to top

    Re: Agile is the cause of the problem?

    Dec 14, 2007 10:41 AM by jeff schneider

    Joshua, You are correct; the vast majority of the mess was pre-agile mostly becuase the vast majority of the systems that exist were created pre-agile. As a proponent of spiral development in 1993, I got a kick out of people getting excited about iterative & agile ten years later. Not all 'pre-agile' systems were waterfall. Most people will agree that a continuum exists between agility/rapid results and long term planning. E-SOA is fundamentally closer to the planning side than the agility side. It's wonderful fun to claim that you can have your cake and eat it too. However, reality is that E-SOA requires more planning than knocking out an agile application. It's extremely dangerous to tell people it isn't. There are lessons to be learned from waterfall, spiral, iterative and agile that should be applied towards SOA. Jeff

  5. Back to top

    Re: Agile is the cause of the problem?

    Jun 30, 2008 2:56 PM by berkay NiQuiL

Exclusive Content

Rationalizing the Presentation Tier

Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.

Agile Project Management: Lessons Learned at Google

In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.

AtomServer – The Power of Publishing for Data Distribution

In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.

An Introduction to Virtualization

It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.

REST Anti-Patterns

In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.

Choosing between Routing and Orchestration in an ESB

In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.

Enterprise Batch Processing with Spring

Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.

User Story Estimation Techniques

Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.