SOA = SOS

SOA is supposed to finally align business with technology - as William Mougayar of Aberdeen Group counsels.

Daryl Plummer, one of the smartest Gartner analysts, continues the business tone and summarizes in an Optimize article the state of SOA as follows

" Web services, in the context of the evolving Web, may well provide the next revolution in how businesses and people use technology. I see a shift away from installation and products, as seen in enterprise-SOA efforts. Instead, I see the focus on people and processes—how customers or employees use the technology—becoming more important. And this emphasis is where the real value of Web services will lie."

But there is caution there - and when Daryl pauses many CIOs do too.

Then I read this James Governor post about Daryl's comments - WSDL, ebXML.....not the kind of language which makes business executives align with their CIOs. A few weeks ago James posted feedback from one of his readers about the "SOA acronym soup"

And I read Randy Heffner of Forrester, in probably the understatement of the year, calling IBM's SOA "rich, but complex" as it packages 13 (not a typo) WebSphere and Tivoli products.

And I see Consulting Magazine reporting "SOA promises to bring back the demand for IT professional services just like the good ole days, like client/server computing, like the e-Business frenzy"

And I read Chris Koch of CIO magazine ask about Oracle's Fusion application strategy: "But if SOA really takes over, how anxious will those CIOs (at Oracle's customers) be for upgraded versions of software they already own? SOA bodes for keeping old software infrastructure around longer."

And I hear SAP's Shai Agassi, who has been aggressively pitching SAP's own SOA, acknowledge that less than half its customer base will be on its SOA even by 2010.

Daryl, James, Randy, Chris, Shai are some of the sharpest minds in the industry but I am still hearing lots of fundamental questions - and hearing about multi-year projects, lots of external consulting services, more technology jargon.

In the meantime, in the Valley, young (and old) kids, oblivious to all these weighty questions are writing their own SOA in very small letters - in mashup camps.

So here are my questions to big, enterprise-wide SOA. Where's the revolution? And the alignment?

We may need canoes to link our islands of applications and data. Instead we are building a big boat. The Titanic.

Update: Charles Zedlweski has a nice response on enterprise SOA where he explains that SOA becomes more interesting as services - like Lego pieces - proliferate. I respond with my questions on his blog.

Comments

[Dennis Howlett]

Don't you think it's about time 'we' stopped talking about SOA and started talking about Service Delivery Architecture or Service Based Architecture as Loek Bakker suggests? I sure as heck do. For the simple reason I can't think of a CIO who is anything other than thoroughly confused by the whole thing.

Go one step further. Does it really have to be an architectural approach? It scares the crap out of many I speak with and while I may not agree with the approach you've got to hand it to the ESB boys who have done a handy job side stepping the argument.

[Dan Creswell]

"And I read Randy Heffner of Forrester, in probably the understatement of the year, calling IBM's SOA "rich, but complex" as it packages 13 (not a typo) WebSphere and Tivoli products."

And here's part of the problem. If SOA is a radical new thing and it'll bring about all these benefits, how come we have all these old technologies/platforms being touted as the way to achieve it? Is it rational for software that is blatantly three tier architecture (client/server if you prefer) oriented to be pushed into this new vertical?

From a customer perspective it makes no sense at all. You might want to integrate with these old paradigms (and an app server should have that integration thing down by now) but you're going to need some new stuff.

From a vendor perspective, SOA threatened to render your app server legacy and you don't want that do you? So all the vendors and everyone else facing the same rendered legacy issue and all the analysts that don't know enough conspire to turn SOA back into what we already have and do.

The result? SOA becomes useless - it's new but it's based on all old concepts and tech. Every vendor fights to ensure that their legacy tech is _the_ SOA platform of choice.

This won't stop happening whilst we appoint vendors and/or analysts to be the high priests of knowledge. The vendors might be smart enough but they are _biased_ whilst the analysts typically don't have knowledge in the appropriate areas. And why are these people proclaimed the experts? Because we've forced commidization of architecting and implementing systems so as to keep it cheap to do. Cheap engineers, cheap results.

The problems are compounded further by the fact that we drive everything from the technology perspective. If SOA was always about aligning business and tech how come we've spent so much time talking tech and so little time understanding business requirements?

In the meantime, SOA is being better implemented by the REST crew and the mashup guys. They've ignored the hype and tried to deliver value with simple systems whilst everyone else is already gearing up for the next hype curve......

[viinnie mirchandani]

Dan, agree ...but the thought leaders do influence corporate decisions and their lack of consensus is another reason to question SOA with big enterprise letters...

[David Chassels]

SOA is a logical and sensible "concept" in the increasing connected world where use of information can be easily accessed and used BUT it is not the answer to bringing IT to business or solving the pressing issue of connecting people to their processes. Fact is business fundamentals have not changed yet in 21st century we still have hugely costly and complex component applications that subjugate people who actually run the business. We need to fix this before SOA can be fully exploited. We need to focus on decoupling business logic and tasks from delivery technologies - create the ultimate "generic" application by recognising there are less than a dozen task in any business. A Task Orientated Application "TOA" a single development environment where people come first and all you need to know is what do you want them to do - it is actually how business works. This is the paradigm shift that is needed - thereafter tune your architecture in which most companies have already heavily invested and then SOA becomes relevant. At least in this order the CEO/CFO will understand. As for "thought leaders" well some of these guys need to come out their "component" box and take a long hard look at how business really works - until they do confusion remains, which keeps everyone busy!

[William]

Mr. Mirchandani, Please take a moment to stop trending, complaining and filling my Inbox with silly statements. SOA requires that people sit down and discuss the roadmap. Please also stop dropping names, taking statements out of context and join an existing standards devlopment organization and help solve the problem.

If you are not part of the solution, you are just another bloggart.

[rob c]

At the end of the day, SOA has a great many benefits, but these benefits must be decoupled from the vendor hype that says that the ultimate goal of SOA is to provide business process & IT system synergy across the ENTIRE enterprise - its just to grand / scary / expensive / new / untested / risky.

A more moderate approach to SOA is to acknowledge the short term & medium term goals, there is enough comment from the vendors about the long term ( generally overtly ambitious ! ) goals.

So, in simplistic terms, when designing your next enterprise system, acknowledge which parts of your system would potentially be usefull, i.e. 'reusable' to other systems, then design your apps so that they break out these parts into seperate apps, communicate to these apps via 'Web Services', if you think you need business domain seperation for the different clients, go and require a client ID to be passed to the web service as well so it knows how to partition data - the web service will then be able to use different db's etc.. if required.

Tell you what, whilst we're at it, ensure that your web services are WS-I profile complient, that way your consumers can be java / .net etc.. etc..

As long as you don't have high load / performance system requirements you can go a long way towards starting an 'Evolutionary SOA' with this approach, and guess what... it hasn't cost you anything....

and if you do have infrastructure load requirements, go buy an SOA monitoring kit from soa software / amberpoint, this will assist in capacity planning / QOS as well. Here's your first purchase.

I'm oversimplifing here I know, but the point is, we have done this for many clients, it works, you get reusability and dramatic cost reductions... in some business functions i.e. marketing FAR more thanothers.. the SOA CAN be organic with the correct blend of governance, top down and bottom up SO analysis / design and planning. All this without massive up front investment / esb vendor lock in.

Rob Cheyne
Practise Director
Enterprise Solutions

[viinnie mirchandani]

William, happy to help with solutions – if EVERYONE does not come with pre-conceived solutions (some years old), multi-million dollar, multi-year implementation plans.

On joining a standards board – I am much more aligned with other reader Rob’s comments. The small, organic approach - not some group grope.

[Juliao Duartenn]

Vinnie, as an information systems architect, I do believe SOA is - sadly - just still another attempt to reach what we all _really_ want, which is Data Convergence.

Progress has happened, and much of the infrastructure is now defined and available for implementation. The main remaining issue is bringing companies - be it Service Providers or Service Consumers - to converge on true open data formats and data processes.

By data format convergence, I mean ensuring that all service providers and service consumers can present their unique pieces of information in a commonly _understood_ format. Think ebXML - altough someone quickly ought to come up with a decent name for this.

By data process convergence, i mean creating and defining a common framework for applications to adhere to, that would ensure that service providers and service consumers can make good use of the provided services. It is still no good that, in order to consume a service, you have to make your client application stand on its head in order to collect and process information outside your normal sequence, just because the service you are using requires that some information is present.

What I am witnessing is indeed a move towards SOA, in so much as that companies are building new applications using the technology - but not the philosophy. I've seen companies forego ebXML for internal applications, and stick to formats "closer to their data". This just means that they will never be able to publish the service - globally, with partners, with customers, anyone - outside their closed IT sphere of influence.

The technology, believe me, is getting there. It's the people's minds that aren't.

[Kirk M.]

Interesting discussion.

I'm the architect for an ent-wide software implementation, and I've put much of my focus lately on SOA, and what the term really means.

Juliao's post above hits the nail squarely on the head. SOA is not so much an architectural framework, or a set of architectural best practices, or a specific vendor solution, as it is a guiding principal or philosophy. Where is the ROI going to be found? The answer lies in how extensible and ubiquitous you've engineered your solution. For example, if I did everything correct.. everything "by the book" by creating course-grained, stateless interfaces that abstracted the complexity away from the consumer, BUT, decided to use a .NET remoting solution because it offered a higher performing solution, I just broke the central tenet of SOA. That is, my solution may be solid in every way, except I just forced my new partner, or the latest acquisition's IT dept. to move away from their Sun/Java shop, and to instead spend a bunch of cash buying .NET and Windows, in order to consume my perfect solution.

By creating a framework that is consumable by whoever, and whatever technology platform is the preferred flavor-of-the-day, I've now invested in the long term, and signifanctly extended the audience capable of utilizing my service offerings.

[viinnie mirchandani]

Kirk, appreciate the rigor and discipline. It is good to have "master crafstman" like you. But you can be a master crafstmen in a micro-brewery... I just thing a set of vendors (not all) is hyping up SOA and encouraging massive investments, which we all need to be wary of. Also, most SOA projects sound IT driven. We have seen over and over again if there are not enough business sponsors, the results are usually questionable.

[Kirk M.]

Viinnie

Right on both points..

Vendors are trying to cash in. SOA is just the latest buzz word to do it.

A properly executed SOA project should spend considerable time involving the business community, and IT shouldn't come near the engagement until well down the road. If IT is driving the process early on, even a properly executed SOA project will lack business continuity, and the final product will have the smell of the IT dept.

[Kirk M.]

Click the link for more about SOA over at my blog:

http://blogs.consultantsguild.com/index.php/kmiller

[Jeff K.]

As you can see in my latest NetworkWorld column, www.networkworld.com/columnists/2006/050106kaplan.html, I think the technical issues associated w/SOA are only the tip of the iceberg re: the challenges of successful adoption. As with most things IT, the lion's share of the obstacles are politics and process-oriented not bits and bytes-based.

[Charles Rathmann]

I think that you and various other pundits are correct in trying to puncture the hype bubble that surrounds SOA. IFS has been offering enterprise applications in an SOA environment for years, so we are rather amused by some of the statements made by our larger competitors when they promise glistening, new SOA functionality.

SOA, combined with granular, well-structured functionality, can in fact deliver increased agility and cost effectiveness. But the granularity of functionality is the hardest part of this equation to deliver on. If major players simply use SOA to open up their applications to Web services, the market will be disappointed in the results.

[viinnie mirchandani]

Charles, I ain't no pundit - just a humble blogge who ahppens to be wary of large projects with questioanble business payback...