Application Platform Strategies Blog

Measuring SOA Success/Failure

Blogger: Anne Thomas Manes

Eric Roch recently asked, "What Constitutes a SOA Failure?" The debate regarding SOA's demise still reigns, and quite a few people have posted numerous SOA success stories as evidence that SOA is still alive and thriving. For the most part, these success stories refer to individual integration projects implemented using an ESB or something similar. And while these individual projects may be successful, I still question whether the SOA initiative is successful. As Eric states in his post,

"I recently talked to a company that spend millions of dollars on SOA software and are now spending the next 18 months on their architecture frameworks and governance model. I have to wonder, given the time value of money, how that company will ever get to positive ROI. Especially since no one is actually talking about business related projects yet or even in the near future! All of this money was spent on toys for architects."

Joe McKendrick recently compiled some relatively positive information about SOA adoption trends, and Michael Poulin returned from QCon reporting a generally positive attitude toward SOA success. My response to Michael on the SOA discussion list was as follows:

How do they measure success/failure? Individual projects might be successful, but does that mean that the initiative as a whole is a success?

Most organizations that I've spoken with are using service-oriented middleware to do integration (SOI rather than SOA). Very few companies are actually rearchitecting their systems, i.e., simplifying their applications and data architectures in order to increase agility. Instead they are using WS-* or something similar to implement open interfaces to their existing applications (i.e., JABOWS). Over time, JABOWS typically results in increased architectural complexity and systems that are more fragile and more expensive than ever before. Although initially the initiative appears to be successful, the long term effect is actually a failure.

The best way to measure success is to measure it from the bottom line.

If an organization invests $15 million in infrastructure, education, new hires, consultants, project costs, etc, over the course of 5 years, how long will it take the organization to recoup that investment and start realizing benefits that can be quantitatively measured? Can they now actually deliver new solutions in less time and for less money than they could 5 years ago? Are their savings sufficient to offset the 5 year investment? If so, then I would agree that the initiative has been successful. If not, then you need to reassess the initiative and figure out why it has not delivered its promised benefits.

I have seen a small number of spectacular success stories. These companies have realized huge savings, they are able to deliver new solutions in significantly less time than before. All these companies adopted SOA as part of a much larger IT transformation effort, and they really focused on the architectural aspects of SOA.

I have also seen a number of companies that are starting to realize small cost savings and increased agility, but it's taken them 6+ years to get there, and they have not yet recouped their initial $15 million investment. It will probably take them another 3-4 years to break even. These companies will eventually be successful, but I suspect the business would think twice before making this type of long-term investment again.

And just in case you miss my point, I still strongly encourage organizations to invest in SOA. But my primary recommendation is to focus on architecture rather than technology. The goal of the program should focus on reducing the complexity and redundancy of the applications and data architecture.

REST Principle: Separation of Representation and Resource

Blogger: Anne Thomas Manes

A recent thread on the OASIS XML discussion brings to light an important but often misunderstood REST principle. The subject line of the discussion thread was, "RESTful XML for updates", and the following question was posed: "I would like to update a representation without having to PUT the entire resource representation back to the server." i.e., the representation of the resource is an XML document, and the user wants to update one element within the XML document, and wants to transfer just the changed element rather than the entire document.

Scott (the person asking the question) provided an example: the resource is a "widget", and it has various attributes, including "status" and "color". The representation of this resource is an XML document with a root element called "widget" which has child elements called "status" and "color". So how do you update "status" without uploading the entire XML document?

Quite a few people responded, and the prevailing recommendation was to create separate URIs/resources for every "thing" that you want to access or update independently. One person recommended reading Joe Gregorio's treastise on How To Do  RESTful Partial Updates. The discussion is informative, but I think Joe's suggestions impose too much burden on the user to understand the mechanics of his system. Which brings me back to the core topic of this post.

Look back at the original question, and you'll notice the source of the common misunderstanding: "I would like to update a representation without having to PUT the entire resource representation back to the server."

Scott should have said that he wants to update the resource, or more precisely, he wants to update the resource's state. The thing to remember is that a web resource is an abstract thing. It has a URI that names it, and through that URI and its uniform interface, a user can access and/or update its state. Users interact with the resource through representations of its state. But here's the kicker: The means by which you maintain the state of the resource should be invisible to users of the resource.

In this case, we're talking about a widget. As the provider of this widget resource, you need to maintain its state. But a user of the widget resource should not need to know whether the state is being maintained in an XML document, relational table, spreadsheet, or whatever. When the user performs a GET on the resource, you return a representation of the state of the resource--in this case, an XML document. But keep in mind that the XML document is not the actual resource. Even if you do use XML to maintain the server-side state, you shouldn't let the physical storage media constrain or restrict the means by which a user interacts with the resource.

If you want to enable users to update the status of the widget, then give them a URI that represent's the widget's status. When they update the status, your backend process must make the appropriate changes to the server-side state of the resource. From a developer's perspective, it's much easier to directly expose the physical state (e.g., the XML document). But as a resource provider, it's your responsibility to hide the limitations of your physical media from your users. 

REST in Action: recovery.gov

Blogger: Anne Thomas Manes

I'm sorry that I missed Transparency Camp this weekend. Based on the TwitterVerse, it sounds like it has been a phenomenal experience.

Transparency Camp is a BarCamp style unconference taking place this weekend at The Institute for Politics Democracy & the Internet at George Washington University. The conference is described as follows in the unconference FAQs:

"This un-conference is about convening a trans-partisan tribe of open government advocates from all walks — government representatives, technologists, developers, NGOs, wonks and activists — to share knowledge on how to use new technologies to make our government transparent and meaningfully accessible to the public."

The geek-fest session I was most sorry to miss was presented by George Thomas, the chief architecture of the recovery.gov web site. Per the FAQs on the recovery.gov web site:

"Recovery.gov is a website that lets you, the taxpayer, figure out where the money from the American Recovery and Reinvestment Act is going. There are going to be a few different ways to search for information. Within days after the signing of the legislation, Federal agencies will start distributing funds, and you will be able to see which states, Congressional districts, and even Federal contractors are receiving them. As soon as we are able to, we'll display that information visually, through maps, charts, and graphics."

George Thomas was kind enough to post his slides describing the architecture of the recovery.org web site. The site is built using Drupal, and relies on REST, Atom, XForms, XHTML, RDFa, and SPARQL. Essentially, it aggregates feeds from all the agencies that are spending Recovery Act funds. According to the implementation guidelines associated with the Recovery Act, agencies receiving funds MUST make information available to recovery.gov via Atom or RSS feeds.

Podcast on the death of SOA with Anne and Phil Windley

Blogger: Anne Thomas Manes

I recorded a podcast with Phil Windley last week, which he published on ITConversations. Not surprisingly, the topic was the death of SOA.

Also, we recorded the "wake" telebriefing, and it's available for streamed viewing on the Burton Group Channel on BrightTALK.

It's not what you do, it's what you call it ... huh?

Blogger: JP Morgenthal

Staying out of this "SOA is dead debate" is like trying to stay out of the circle at at Greek wedding.

It seems there's a good amount of traffic focused at commenting on Anne's blog entry stating that the principles of SOA are sound, but you don't want to call it SOA.  This has led to very satirical representations, such as the one by Miko Matsumura, calling it the "Artist formally known as SOA".  However, this notion makes the hair on the back of my neck stand up.

In response to David Chappell's thoughtful blog piece, I responded, "the whole sordid process has brought me full circle and I don't know that SOA was ever really born".  My basis for this statement is that there has never been broad spectrum agreement on what SOA means.  There's the OASIS Reference Model definition, the software engineering definition--I built a web service, therefore, I SOA, the Enterprise Architecture perspective--save the architecture, save the world, just to identify a few.

Moreover, the examples of successful SOA that have been put forth, primarily by the vendors, all look like re-hashed former architectures.  I see many examples of EAI, OOD, component architecture, BPM, workflow, etc. and mashups of these architectures used to form a solution, but I don't see anything uniquely SOA, unless you buy into the definition of SOA as having used an interface to expose these efforts as reusable chunks.  As I also pointed out in my comment on David Chappell's blog, "if you use a term that is amorphous and identify success by that term, then the success is circumspect."

The reason why we cannot summarily dismiss this notion of lambasting the term 'SOA' without throwing away the whole notion, is because at the core 'SOA' represented semantics--the semantics of business.  Its like the fact that no one talks about Iraq and the weapons of mass destruction anymore; the original premise has gotten lost.  The underlying principles of what is now known as the 'Artist formerly known as SOA' were the relationships between services and their semantic representations of the business' faculties.  It was a way to look holistically at the organically grown rats-nest of applications and their awkward "intertwingling" (Chris Haddad's superb description) and apply a methodical reorganization of those assets against a template representing the core business.

So, IMHO, to say "do SOA", but don't call it "SOA", is at the core of why so many have reacted so strongly to this message.  We hate the unknown.  It's better to have a bad name, then no name at all.  But, even better, would be to have a name that describes the task at hand.  I also believe that if you go management with a message of, "we should clean up our intertwingled application mess," you should probably be prepared to join the unemployment line, regardless of the fact that you would be acting in the best interest of the organization and undertaking an effort that could result in millions of dollars of savings amortized over a number of years.

In conclusion, I would like to leave readers with something they can replace SOA with as they are getting called on the mat about their support:

1. SOA is a bad word because it doesn't tell us anything
2. Think about applying a pattern of organization to your information technology infrastructure that closely mimics your business' core focus, along the way reducing redundancy and building out a common reliable business service infrastructure
3. As a result of developing out the business service infrastructure, you will need to respond to practicalities associated with security, reliability and change management
4. Extra credit: take the opportunity to build out a strong software development life cycle methodology and develop out metrics and expected ROI

SOA vs SOI

Blogger: Anne Thomas Manes

According to this report by Jack Vaughn at SearchSOA | TechTarget, Yefim Natis asserted "SOA is integration" at last week's Gartner AADI Summit. The assertion produced the usual firestorm of commentary on the Yahoo! SOA discussion list. Michael Poulin started the discussion with this comment:

"What can we do to slow down spreading such Integration SOA madness?" 

My response followed suit:

"While I agree with the last line ["SOA is less a technology than a way to dependably extract business value from technology."], I disagree with the leading one: "SOA is integration". Many organizations mistakenly perceive SOA as an integration strategy. But it is not. SOA is about architecture. To achieve SOA, you must rearchitect your systems. You must remove the deadwood. Every organization has too much stuff -- too many redundant applications and data sources. SOA is about cleaning house. You will not simplify your environment, reduce costs, and gain agility until you reduce that redundancy."

We have 17 messages in the thread so far, and our debate was picked up yesterday by Loraine Lawson at ITBusinessEdge. Loraine admonished us for our "boil the ocean" perspective of SOA. As many SOA case studies indicate, "SOA" works well for integration. I put "SOA" into quotes, though, because I assert that these integration case studies are not examples of service oriented architecture (SOA). The are examples of service oriented integration (SOI). i.e., they are examples of projects that used service oriented protocols (e.g., WS-*) and middleware (e.g., ESB) to integrate two or more application systems. But from an architectural perspective, you still have monolithic systems bridged by integration middleware.

Maybe I'm just being pedantic, but I think it's important to distinguish between integration and architectural activities. It's fine to use service oriented middleware to implement integration projects, but then you need to readjust your expectations. Most organizations that I speak with say that the goals of their SOA initiative are to reduce costs and increase agility. Unfortunately, these organizations aren't likely to achieve these goals if their projects only focus on integration. (Also see Chris Haddad's perspective on these success stories.)

In the research that Chris and I conducted last year, we found only four companies that had achieved real success in their SOA initiatives -- i.e., they met their goals to reduce costs and increase agility. Their successes were astounding, and they delivered positive returns on investment in less than 12 months. In all cases these companies focused on architecture -- not integration.

Service oriented architecture is hard work. It's disruptive. It's a political minefield. It involves going through the application portfolio and identifying redundant applications that can be decommissioned and replaced by a single service. But no one ever wants to open that can of worms. Many folks live by the adage, "If it ain't broke, don't fix it." There's way too much other stuff to do. But each additional application increases the annual maintenance and operations budget. And for many of those applications, the cost of maintaining the application exceeds the value it brings to the business. It's just good business sense to eliminant some of that redundancy. And by the way, the CFO is going to be looking to reduce the IT M&O budget this year. There is no better time to start an application rationalization effort.

Subscribers only -- check out the following two documents:

Application Portfolio Management and Application Rationalization: Burning Fat and Building Muscle.

SOA doesn't need to be expensive

Blogger: Anne Thomas Manes

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 leading open source projects have commercial backers that provide support, education, and consulting services. For more information about open source (subscribers only), see the following documents:

• Open Source Management: Who Owns That Software?
• Open Source Software: Risks and Rewards
• Assessing Open Source Software Projects