BT

Debate: Is SOA Dead?

by Dilip Krishnan & Boris Lublinksy on Jan 07, 2009 |

Anne Thomas Manes wrote an obituary for SOA, claiming that

SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession. SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural approaches that depend on “services”

She continues:

Once thought to be the savior of IT, SOA instead turned into a great failed experiment—at least for most organizations. SOA was supposed to reduce costs and increase agility on a massive scale. Except in rare situations, SOA has failed to deliver its promised benefits. After investing millions, IT systems are no better than before. In many organizations, things are worse: costs are higher, projects take longer, and systems are more fragile than ever. The people holding the purse strings have had enough. With the tight budgets of 2009, most organizations have cut funding for their SOA initiatives.

Although SOA was initially adopted mostly by technicians, at its root it is more business then technical problem. But as it was introduced (and often executed) by technical people and product vendors, which were more interested in SOA technologies (software sales) then its business impact:

People forgot what SOA stands for. They were too wrapped up in silly technology debates (e.g., “what’s the best ESB?” or “WS-* vs. REST”), and they missed the important stuff: architecture.

An inability to show a quick ROI turned many business decision makers away from SOA:

SOA fatigue has turned into SOA disillusionment. Business people no longer believe that SOA will deliver spectacular benefits. “SOA” has become a bad word. It must be removed from our vocabulary.

This means a huge setback for IT industry:

The demise of SOA is tragic for the IT industry. Organizations desperately need to make architectural improvements to their application portfolios. Service-orientation is a prerequisite for rapid integration of data and business processes; it enables situational development models, such as mashups; and it’s the foundational architecture for SaaS and cloud computing.

So what is next? According to Anne:

Although the word “SOA” is dead, the requirement for service-oriented architecture is stronger than ever.

Her suggestion is to stop talking about SOA and start talking about services (although she isn't clear about her definition of this term, thus leaving room for interpretation and misinterpretation).

The post has quite obviously stirred up reactions among some of the thought leaders in this space.

David Linthicum analyzed what when wrong, to paraphrase

  • Lack of skilled architects who understand SOA.
  • Big consulting firms focusing more on tactics and billable hours than results
  • The vendors focused too much on selling and not enough on the solution.
  • Hype that SOA is a panacea to all IT woes

Joe McKendrick observes that SOA is a style of architecture and not a product:

Successful SOA is part of a transformative process that changes the way organizations are managed and do business. And some organizations just seem to “get it” right away. For many companies, however, what they may see as SOA is more JBOWS (Just a Bunch of Web Services) architecture. SOA is a methodology and philosophy. The mix of technologies and approaches employed to work toward SOA will shift. A few years ago, Web services was seen as the way, yesterday it was REST and Web or Enterprise 2.0, and now it’s cloud computing. The beauty of SOA is that it is meant to be independent of the underlying technologies or protocols.

Miko Matsumura supports Anne’s suggestion to change terminology, but stresses the fact that the notion of SOA, and especially business dimension of SOA will certainly survive:

I believe that use of SOA as a term will certainly decline, but the strategies to address the fundamental problems will have to continue to evolve out of the SOA “stream”. At the same time SOA is dead, SOA is also inevitable–but it may come under a different name. The DNA of large organizations will require interfaces to appropriately segment the what of requirements from the how of implementation, and the design patterns of SOA will be the ones that will realize the long term vision of an Enterprise, Multi-Enterprise, and indeed “cloud” platform. Any term like SOA has to experience the hype cycle and goes through linguistic mystique, implementation, experimentation, and eventually a degree of nomenclature fatigue. SOA had a particularly “big tent” agenda and so a lot of folks latched on to it in the hopes that SOA would be their savior. Frankly I see the same kind of pattern in “cloud”, which is to say that it’s not an easily defined technical term, rather a set of political interested tied to a set of insights and realizations.

He also cautions against over reaction, which is so common in IT recent history:

Fear about the economy should take a back seat to the project of becoming the change we need. The era of knee-jerk emotional reaction can hopefully be relegated to 2008 (or perhaps the first half of 2009) and we can move forward together to both re-envision and rebuild our infrastructure. And to realize the big vision we need each and every person to become the change we need.

Steve Jones interprets Anne’s statement as:

Vendors are moving away from SOA as they've flogged you enough stuff and now they want to flog you its offspring: mashups, BPM, SaaS, Cloud Computing… The reality is that it is in fact the services that matter more at this stage than at any other. This doesn't mean that SOA is dead, it means that the marketing fury of T-SOA has moved on as their just aren't that many more ESBs and Web Service tools that you can be sold. What remains is in fact what SOA was all along its Services are the starting point for SOA its not those pretty technologies…If you adopt the new technologies without having a services mentality then you will create a degree of mess that will make the one that consultants and vendors got fat on with EAI look like a trivial problem. Doing Spaghetti inside your firewall in big applications is one thing, doing it over the internet and with thousands of small ones is a completely different scale of problem.

Steve then elaborates on definition of service, promoting “business first” approach and defining them as a functionality that can be exposed for use by others:

…you need to Identify your services, understand the business value that they deliver, understand the cost model to deliver that value and then decide on the right technology approach.

Nick Gall, on another hand, disagrees with Anne’s way forward ("long live services"):

It is services thinking, as conventionally understood, that led to the mess in which we find ourselves: fragmentation caused by entity-specific (service) interfaces. I'd say instead, "long live the web." I'm shocked that Anne's blog post does not even mention the web!

He cites successes of Google, Amazon, and even Salesforce and attribute them, for the most part to the leveraging of web architecture, web community, and web business models: "Web-orientation is a prerequisite for rapid integration of data and business processes; it enables situational development models, such as mashups; and it's the foundational architecture for SaaS and cloud computing.

And finally in a similar view, a blast from the past 2005 prediction from Don Box, which though not related to this discussion, seems to suggest the same:

The term SOA will have been beaten to death and the software industry will invent or recycle some equally vague term to replace it.

Be sure to check out Annes original post.

It seems quite obvious that changing a name will probably not fix current SOA problems, but one can argue that refocusing on the architecture and business aspects of SOA will. What do you think? Is SOA dead, or alive and kicking?

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Interesting article. by Byungwook Cho

This is very interesting article.
Meaning of term "SOA" looks like getting worse. I don't want to argue about the issue.
But nowdays most of solutions from vendors are based on SOA.
REST and Cloud computing are drived by Service company like amazone,google etc.
Enterprise usually wants to use vendor oriented solution. Because of some maintenance issue, belief and fashion from vendors...??

I think SOA can be also popular too this year.
Vendor will try to sell their product as well this year with very powerful marketing message and sales activities. And they convince their customer.
If there are no alternative solution that support another architecture from vendor, SOA will only answer for Enterprise.

What a great way to start 2009 ! by Jean-Jacques Dubray

It had been such a long time that Ann et al. had not tried to launch a self-prophetic campaign to "kill" something related to SOA and Web Services (no need to mention the "Web" anymore, we get it, REST is "winning").

It is of course entirely clear that what every IT organization wants is to deploy and operate silos and keep duplicating, replicating and synchronizing data and business logic.

It is of course entirely clear that people are no longer using XML because of the financial crisis nor they want to reuse information and information management elements across their IT organization. Reuse is no longer a desirable outcome moving forward.

If it of course entirely clear that all Lean Six Sigma initiatives have been canceled due to economic hardship and therefore we no longer need a combination of BPM and Services to support process improvement.

If is of course entirely clear that master data or decisions services have shown absolutely no value and people no longer want to use BREs, MDM or CDI solutions.

It is of course entirely true that there are absolutely no value to deliver services over B2B channels and everyone is going back to faxes, emails and god forbids snail mails for B2B data exchanges.

Imagine if one day, analysts could actually come up with something of value on their own?

Re: What a great way to start 2009 ! by Stefan Tilkov

In all fairness, Anne seems to object to the word SOA, not necessarily the concept, because it seems to have lost its meaning for many people.

Re: What a great way to start 2009 ! by Jean-Jacques Dubray

Are we really talking about "meaning" when someone writes:

>> SOA instead turned into a great failed experiment—at least for
>> most organizations.

Is that a subliminal message?

Maybe Anne could spend more time thinking how SaaS and Cloud Computing are "off-springs" of "SOA". Does she really think that Software-as-a-Service means Software-as-a-Web Service? Does she consider EC2 a "web service"? Yes they both expose "web services" but I am not sure elasticity/virtualization or "pay-per-use-enterprise-solutions" were part of the SOA blueprints at any point in time.

So I am not sure about what Anne is talking about nor her motivations, and in all fairness, your comment does not make it clearer. Service Orientation has well defined principles and technologies that seem to be still in use as of 1/7/2009. You might want to discuss whether people will use more, less or as much of these principles and technologies, you want to discuss if these principles and technologies solve problems and what kind of problems, how they can be improved, but I don't see people pulling the plug on their ESB or converting all their XML data interchanges into JASON.

All I have seen over the last few years is wishful thinking and more and more people trying to confuse the space to sell their cheap advice, products and services. It seems that some people in our industry think that they are dealing with complete idiots that can swallow anything and everything. This post from Anne is probably not her greatest one -by far.

Where are we? in 2009 it is still hard to reuse information and information management elements. Computer Scientists don't get that you can't reuse information the way you reuse a subroutine. It is not as easy, it is not even as simple as making a "call" be it RPC, message oriented or RESTful. I can assure you that there would be a lot of people that would want to kill any ability to reuse information and information management elements. There is simply too much revenue depending on it.

So I find it quite revolting to read posts like the one Anne wrote. Does she mean that the principles and technologies that were painfully developed and somewhat standardized over the past few years don't work? we should trash all of them? It is just the principles? Is it the understanding (or lack thereof) of these principles the usage of these technologies that we should revisit?

No, Anne's post is about setting us back in the past, in an era where reuse and composition did not exist. It is about shutting down research and efforts to improve. Who is she to come up with this kind of statements? Does she even have a clue anymore about what she is talking about? Or is it just about "killing".

Re: What a great way to start 2009 ! by Oisin Hurley

It's a nice start to the new year to have a traffic spike on your blog. And it's easy to say things that get people stirred up. It would be a pleasant change to see people being passionate about results, rather than being passionate about techniques.

If I can paraphrase the paraphrase of Linthicum:

* Lack of skilled architects who understand FOO
* Big consulting firms focusing more on tactics and billable hours than results
* The vendors focused too much on selling and not enough on the solution.
* Hype that FOO is a panacea to all IT woes

Perhaps we have hit upon a good generic epitaph for any technology that
has reached the end of its hype phase.

Re: What a great way to start 2009 ! by Pierre de Leusse

Exactly my thought.

So maybe changes in the way it’s sold and evolution of its structure (let’s face it we’ll never stop arguing over the pros and cons of architectural models or technologies), but death of an IT domain is a bit stretched… for the death of a buzz, only time will tell us.

Burn SOA and pick what's useful by Hermann Schmidt

I agree,

SOA is a burned term. It shares its fate with other terms, which contain too much and are never fully understood by 3/4 of the people (take object orientation for instance).

Ask 10 people and you get 10 different answers what it means. Therefore, who is able to define "success" at all?

It's neither 100% (hooray, success!) nor 0% (total failure) with SOA. When planned "SOA projects" get cancelled, this doesn't mean that all SOA concepts die with them. Once you got your head around SOA in general, you will use at least some of it in future projects, no matter if the SOA label sticks to them or not.

Re: Burn SOA and pick what's useful by Hermann Schmidt

eek, it's burnt, not burned, of course.

Re: What a great way to start 2009 ! by Shane Johnson

I have to disagree.

EC2 is not SOA. It happens to be great, but it is not SOA. They provide a service in the same way my building's laundry cleaners do. That doesn't mean the cleaners have implemented SOA either. I can do my taxes online. It doesn't mean that the company has implemented SOA. It is just a web application that generates my tax returns for me. Cloud Computing is not necessarily SOA either. Just because you use a web service (or otherwise) as your entry point does not mean that you have implemented SOA. The real architecture in Cloud Computer is what goes on behind the service. Period.

Why do you need an ESB? What is it really doing? I don't believe in centralizing all of your services and then creating a single point of failure. An advanced routing and mediation capabilities can be found elsewhere such as in Camel. And yes, most people are moving to JSON instead of XML. It is pretty easy. Why not do it?

I don't think it is hard to reuse information at all. And I certainly can't imagine anyone wanting to kill that ability.

SOA did not lead to new principles and technologies. Why do people keep saying that? Loose coupling was around before SOA. JMS, it was around before SOA. Obviously REST was around before SOA. So what exactly new principal or technology did the idea behind SOA bring us? I'll admit it brought those damned ESBs.

Going back to the past in an era where reuse and composition did not exist? Honestly. Reuse and composition existed long before SOA. Everyone should know that. Shutting down research? In what way? In not spending ridiculous amounts of money to buy SOA platforms and re-architect processes as services even though they were fine the way they were? The abandonment of SOA is exactly what leads to research and improvement. It means we need to find a better way of doing this and it won't happen in our sleep. We'll need research.

The problem with SOA was not the borrowed principles and technologies, the use of web services, or other technical issues. It was this notion that it wasn't about technology. That it was about the organization. It was a philosophy. That was just a load of crap. Drop the architecture and you are left with services. That is fine. I like services. I continue to use them. However, there is a time and place for them. Yes, Amazon and Google offer services. They are service oriented. I don't see any architecture present in the pure fact that they choose to provide services though. Also, most companies are not like Amazon and Google. Most companies do not need to be service oriented. It doesn't mean that should provide and consume services. In certain cases they should. Let's face it, not everyone company needs to be service oriented.

Re: What a great way to start 2009 ! by Jean-Jacques Dubray

Shane:

>> EC2 is not SOA
I think this is what I am saying. I can't see how Anne can argue that Cloud Computing, SaaS or BPM for that matter are offsprings of SOA.

>> Why do you need an ESB?
You don't, for me what people call an ESB is a "Service Container", sometimes I need one, sometimes I don't, sometimes I need more than one. BTW, a "service container" is not "central".

>> JSON instead of XML
This is quite a bit of an issue. If you read the article that Kjell and I wrote recently, you might understand why: www.infoq.com/articles/contract-versioning-comp2

>> SOA did not lead to new principles and technologies
You might want to read the mini-book I wrote. You can download it for free: www.infoq.com/minibooks/composite-software-cons...

some "new" things that did not exist before SOA:
- bidirectional interfaces
- orchestration languages
- assemblies (SCA)
- compatibility (see versioning article).
- ...
Please note that none of these concepts are available in REST.

>> Reuse and composition existed long before SOA
really? so why did we need integration to start with? why did we have silos that kept replicating all kinds of data if we could have reused it wherever it was?

>> The problem with SOA was not... It was this notion that it
>> wasn't about technology. That it was about the
>> organization. It was a philosophy. That was just a load of
>> crap. Drop the architecture and you are left with
>> services.
What is a load of crap is precisely to drop the "architecture". The insidious -and frankly outrageous- argument that Anne is making is that all you need is services and mashups. Oh... and magically, REST fits that picture wonderfully. This is what she is talking about. She wants us to drop the architecture, because the Web is the architecture.

The RESTafarians have never proven they could deliver a significant enterprise solution (the caliber of SAP or SalesForce) using an entirely RESTful model. Yet, we are urged to "drop the architecture", the principles and technologies that failed so miserably.

The architecture is unfortunately critical to create "composite software". Mashups are just one-third of the equation, in addition to the presentation layer you also need process and information composition capabilities which don't seem to fit REST quite well.

>> Let's face it, not everyone company needs to be service
>> oriented.
Sadly, every company needs to leverage "composite software", i.e. solutions that leverage existing systems of record instead of always rebuilding their own and integrating with all the other applications of the enterprise.

Look at any IT organization? How many apps do they have to run their business. I just came across that quote recently:

“We have over 100 IT systems managing HR data, and we share HR data with over 150 partnering firms for payroll, outsourcing, staffing, healthcare, life insurance, and various benefits,”
Systems Consultant for HR Data Governance at a U.S. retailer.

Do you really think that "traditional principles and technologies" have done a great job at delivering information systems? This is what SO-A tackles.

Could we talk seriously about principles and technologies that can tackle this kind of problems? instead of sending dramatic subliminal messages to support corny software construction principles and technologies that got us where we are in the first place. I guess not, that's too hard and boring. Let's talk in depth for a change.

Re: What a great way to start 2009 ! by Bill de hÓra

"* Lack of skilled architects who understand FOO
* Big consulting firms focusing more on tactics and billable hours than results
* The vendors focused too much on selling and not enough on the solution.
* Hype that FOO is a panacea to all IT woes."

I would add two others

* Lack of understanding of technology. Technical v Business SOA is a red-herring. A huge amount of business value is in understanding what technology can do, not treating it as a problem.
* Running projects instead of programs. You can't run build and run services using IT project methods that focus only on the first 10/20%. This is where consultants and vendors need to be adding serious value.

But I think this topic says far more about the analyst industry than SOA (for any definition of SOA). What needs to happen is for the hype cycle itself to die.

Re: What a great way to start 2009 ! by Shane Johnson

I can see some of what you are saying.

ESB: I can agree that it is simply a container. However, it contains services. If that container is unavailable, so are all of the services within it. That is what I was getting at. Perhaps there is more than one container. That is fine, but if one of them goes down all of the services within that particular container do too.

XML/JSON: I am not against XML or a service contract. I'm merely stating that there are times when JSON will suffice. Especially for consumers such as AJAX clients or RIAs. If we are not dealing with RPC then I think JSON is just fine. I still use SOAP web services too.

Principles: I'm going to take a look at your articles when I have a chance. I'll accept that some new principles may have been born from SOA, but my issue is with people using traditional OO principles such as loose coupling and saying that they are why SOA is needed.

Reuse/Composition/Integration: This may not be everyones favorite technology but think about EJBs. We had reuse and composition right there. Consider libraries. Again this is an example of reuse. Even some application servers supported shared libraries. In the end it comes down to the code. It was certainly possible to reuse code before SOA. Integration has always been needed, and we could certainly accomplish this without SOA. It could be as simple as sharing data. It could be with messaging.

Data Replication: I have no idea what you are talking about here. I've never seen data replicated with or without SOA. Many applications can talk to the same database. Many clients can read from the same queue.

RESTafarian: I'm no RESTafarian, but I can certainly appreciate their views. I use both web services and RESTful services.

Composition: I'm a fan of composite software when it makes sense. It simply isn't always required though. A dot com can get away with a simple web application using a common web stack. While larger enterprises may be able to take advantage of behind the scenes processes to create composite applications. I just have a hard time considering that architecture. It is really about messaging. We're just connecting the dots and that is all. And the idea of taking business logic and separating is certainly not new with SOA. All we are doing is creating a sort of physical separation. In a traditional OO application you have your business logic separated into classes and or methods. Now all we are doing is taking those classes and or methods and separating them physically.

Re: What a great way to start 2009 ! by Anne Manes

Jean-Jacques -- I get the impression that you only read the first couple of paragraphs of my blog post. In any case, you certainly did not understand my intention. Forgive me for being subtle. Your interpretation of my meaning is completely off the mark:
The insidious -and frankly outrageous- argument that Anne is making is that all you need is services and mashups. Oh... and magically, REST fits that picture wonderfully. This is what she is talking about. She wants us to drop the architecture, because the Web is the architecture.

If I had made such an argument, then I would agree with you that my recommendation is completely outrageous. But I did not make such an argument. As Stefan said, the essence of the article is that projects labeled "SOA" will not receive funding this year. "SOA" has become a bad word, and people must remove it from their vocabulary. But I also say, "Although the word “SOA” is dead, the requirement for service-oriented architecture is stronger than ever." So I am absolutely NOT recommending that people abandon architecture. The point is that you won't be able to sell architectural concepts to business people in 2009. If you want to get funding for your projects, you'd better focus the business case around the *services* that you intend to deliver to the business. Oh yeah -- and I didn't say anything about WS-* or REST -- other than to say it was a silly debate. If you do architecture well, then your services should be able to support interactions using either HTTP operations on resources or SOAP method calls.

Re: What a great way to start 2009 ! by Jean-Jacques Dubray

>> This may not be everyones favorite technology but think about EJBs.
that's why Spring has taken over the J2EE, precisely because EJBs are quite hard to reuse outside the context for which they were designed. But's let's assume POJO are reusable enough. The problem is that reusable POJOs is not quite useful.

What people need to reuse is information and information management (I include well defined business process tasks inside information). Again, in a typical enterprise (medium to large) data is duplicated across different application boundaries simply because enterprise application architecture has never allowed that level of reuse. Reusing just POJOs will be of no help if you have to duplicate the data in your system.

>> Integration has always been needed
This is the point of SOA, eliminate integration. By integration, I do not mean the integration technologies, connectors and adopters. What I mean by integration is the need to replicate and synchronize data across different systems because information and information could not be reused. If you can bring reuse at that level, then you need integration, lots of it.

If you read the first chapter of my book I explain how traditional application architectures make it more cost effective to systematically build new applications with data duplicates. Typically, IT grows until all the budget is gobbled up by operations and maintenance of these apps. You reach a point where you can't innovate, retire or even improve without breaking your business.

>> Composition simply isn't always required though.
Well, if you are in a "reuse" logic, then composition becomes mandatory, they go hand in hand. This is where the "architecture" is really important.

>> We're just connecting the dots and that is all.
well, not quite, that would be quite easy, this is where technologies such as bidirectional interfaces, orchestration languages and assemblies become essential (and federated security, ... ). Composition is not easy. Negating the "A" of SOA is negating the major advances that SOA principles and technologies brought to our industry. It is not easy, if there is a failure, it is a failure of explaining how critical these concepts are. Oracle for instance with Fusion has a full understanding of this, IMHO, a tiny bit better than IBM, but they come late in the game, but they are coming.

>> In a traditional OO application you have your business logic separated into classes
>> and or methods.
For a difference between OO and SO, please see WSPER, and abstract SOA framework I have designed. (www.wsper.org - I also talk about it in the book).

Re: What a great way to start 2009 ! by Jean-Jacques Dubray

Anne:

you would allow me to doubt that the Burton Group -and yourself- has any other agenda than pushing REST. Shall I remind you that not so long ago you went as far as pushing the idea of a "RESTful" data store capable of replacing relational databases. Just as if nobody had contemplated the idea of not using relational databases before.

Claiming that BPM (which predates SOA and frankly does not go very well), Cloud Computing or SaaS are off springs of SOA is quite a leap of faith and I think in the opinion of many people plain inaccurate.

"SOA is dead" (followed by "SOA is a failed experiment") echos very well another famous RESTafarian, Tim Bray, who prophetically announced "the end of SOA" in 2007, with again very doubtful arguments. Won't you think that's quite a stretch? How many thing "die" in software? Mainframes? Thick clients? VB? Windows XP...

Continuing by saying "SOA will not receive funding this year". What does that mean again? What are your sources? Where is the research? Shall we just "trust" you? Are you saying that no one is going to build services anywhere this coming year? We are going to unplug these expensive ESBs, turn off the appliances? empty the SOA registries? What are we really talking about? Repurpose the servers for Cloud Computing?

Won't you think that these innocuous statements have actually a high probability to self-prophetically "kill SOA". It is of course not your goal. Don't you think that emails are going to fly across companies to derail perfectly legitimate SOA budgets, quoting the "first part" of your post. Do you think people will read and quote the second part? Aren't you suggesting to "fund" mashups, Cloud Computing...

If it was supposed to bring the agility... by Richard Richter

...then companies should allow the agility in the first place. I'm not in the big IS market, but the way I see it on our customers is: They like SOA (because companies often hears to buzzwords) but they like it via all those show cases. "Create service here and here and join it like here. No coding..." Luckily I never had to do anything in SOA way and I hope I will not. Unluckily - I will not do it agile way either - I mean the whole project with customer involved in the agile part. When customer is conservative to adopt more flexible way of doing software than I hope he is conservative enough to refuse SOA too. I also hope that easy stuff will still be made with easy and simple solutions and not via overkills like some big-gun SOA architect/designer SW where I can do 80% of the result in 5% of time and the rest 95% of time I have to hack limiting framework/product.

On the brighter side - SOA is probably not only false promises about loose coupling, less coding, more drawing and SW closer to (non-IT) managers/buisness ppl. There are many ideas (especially loose coupling stuff) that has its justification and I hope we will take the right stuff on and let the idealistic/nonrealistic stuff behind.

Re: If it was supposed to bring the agility... by Jean-Jacques Dubray

Richard:

you are touching on an important point, SOA could have been made really simple. When you look at SCA (especially Tuscany) you may get a sense for what I am talking about. I'd be the first one to agree that some people have made SOA standards and products unnecessarily complex. But is it a reason to throw everything away? SOA should somewhat be eventually as easy as you claim it should be.

The question is why it hasn't been that way? All I have seen in the last 10 years is little (and not so subtle) games to "kill this", "kill that" for whatever reason. How often do we really have a discussion on the substance, on the "architecture" as Anne would put it? You can blame it on a number of factors, analysts for sure, who always have to come with something new, some even feel that drama is part of the analyst job. Vendors too. The losers of wave X want to be the winners of wave X+1. People for sure, when "facts" no longer matter. Anyone can make a claim: "XXX is dead", "YYY is alive"... trust me.

I frankly think that we will reach what you are talking about, not because we uncovered a "new" and "marvelous" technology that can do that, we will reach it, the day the culture will change, the day analysts will talk about (and sell) substance and not effect, the day people will question their own belief, the day people will finally understand that you don't build "connected systems" the way you build monolithic systems. There are indeed principles and technologies that differ. It will take a few egos to shut down, it will take a new system of values, it will require a dialog, a real dialog. Until then, we will keep getting the kind of factless discussion that we are seeing today.

Re: What a great way to start 2009 ! by Anne Manes

Jean-Jacques -- I find it very amusing that you are accusing me of being a RESTafarian, and I doubt the other RESTafarians would agree with you. I've been pretty adament in recommending caution when it comes to REST adoption. (I don't think very many mainstream developers are prepared to adopt such a fundamentally different architectural style.) Also, I have not pushed the idea of a "RESTful data store" replacing relational databases. What I have proposed is the idea of developing a data model based on hypermedia which might replace--but would more likely extend--the relational data model.

In any case, you are still misinterpreting my intention. When I say "SOA is Dead", I am not talking about technology. As I've said many times, SOA is not about technology. The second part of my blog post talks about how vitally important it is to continue re-architecting the organization's application portfolio and to replace redundant applications with well-crafted services. (My definition of SOA.) The debate as to whether you build services using ESBs or lightweight frameworks, using WS-* or HTTP, or designing service interfaces as methods or resources is irrelevant to the discussion.

SOA is an architectural concept -- and, as a general rule, it's a really bad idea to try to sell architectural concepts to business people. At a minimum, you must correlate the concept to a value proposition. In the minds of business people, the "SOA" meme correlates to "reduced costs and increased agility", but very few organizations have realized these benefits. In 2009, business people will demand hard evidence to support the value proposition. There's plenty of evidence out there that organizations plan to cut their IT budgets this year. You're kidding yourself if you think that "SOA" won't get hit by those cuts. If you can't produce a business case that directly ties real business benefits with hard short-term ROI, you should expect the project to get cut. Hence I recommend that organizations focus on the things that deliver value to the business. Services deliver value; "SOA" as an architectural concept does not.

Re: What a great way to start 2009 ! by Jean-Jacques Dubray

Anne:

I am not sure if we are playing with words or having an intelligent discussion. But when you say

>> There's plenty of evidence out there that organizations plan to cut their IT budgets
>> this year. You're kidding yourself if you think that "SOA" won't get hit by those
>> cuts.

There is quite a difference,at least in my mind with "With the tight budgets of 2009, most organizations have cut funding for their SOA initiatives".

When you surround this unsubstantiated argument with "people holding the purse strings have had enough. SOA fatigue has turned into SOA disillusionment Business people no longer believe that SOA will deliver spectacular benefits. “SOA” has become a bad word. It must be removed from our vocabulary." Let's look at the message conveyed by your picture? Meteorite, Dinosaurs... extinction. Again, what subliminal message do you want us to get?

To be more price, are you talking about "decreasing budgets" or "cutting funding altogether"? An extinction is quite different from a decrease.

So what's your point? where is the evidence for what you are talking about?

>> In 2009, business people will demand hard evidence to support the value
>> proposition.
Do you know any IT department who are not doing that across the board? Do you know many IT department where people could "play" with stuff and engage in projects without measuring some value? Sure I have seen people who fudge the benefits, but they can't do it for very long. I actually even seen a company who found a business case for replacing an ESB by another -even more expensive- ESB. You know how this experience ended up. Is that a failure of SOA? not sure about that.

I also know IT organizations who actually are discussing not implementing a new packaged solution and instead use SOA to create a composite application that will suit their needs with the current systems of record. I can assure you that in that case the business case is a slam dunk by a large margin. This is just a few data points, I don't claim I can make any general conclusions out of it about whether SOA is dead or alive. Of course if someone is putting an expensive ESB in production, create a service with no consumer and claims it done. That won't fly very much further. I think most organization I see are passed this, way passed this. SOA is an option amongst others. Again, gave us your facts. Dramatic statements don't cut it anymore.

The only thing I know is that multiplying the systems of records in an organization is a really bad idea. SOA is tackling this problem. The business can't care less about SOA, we agree, all they care is about results, rightfully so.

Now, Is it easy to move from a Build & Integrate paradigm to a Reuse & Compose? no. It is not trivial, it is actually much less trivial when people keep "killing" this approach instead of pointing at what works and what does not, what can be improved or what should be changed.

>> Services deliver value; "SOA" as an architectural concept does not.
This is where the disagreement is profound and symptomatic of why SOA can't reach the benefits that it is supposed to reach. What does "Services deliver value" means? don't you need an architecture to compose and consume services in meaningful solutions? You are recommending once more, "build services and they will come" or "build services for one and they will be reusable". Unfortunately, no matter how hard I wish this would be that easy, it cannot happen without an architecture, it cannot happen without a deep understanding of how building "connected systems" differs from building monolithic systems.

So I feel sorry that you think you have initiated a healthy and interesting debate. This kind of debate is precisely the reason why we are not making any progress. Pictural and Rhetorical arguments don't make any sense to me and I hope one day our industry will walk away from the "people magazine" approach to software architecture. As I said many times, we are fast approaching the time where the business is going to be disgusted enough by IT to cut all funding except for keeping the light on.

Re: What a great way to start 2009 ! by Stefan Tilkov

Quoting Anne,

The point is that you won't be able to sell architectural concepts to business people in 2009. If you want to get funding for your projects, you'd better focus the business case around the *services* that you intend to deliver to the business.


I couldn't agree more – in tough times, it's next to impossible to convince the business side to invest in something as abstract as architecture, at least if you're following a top-down, big-bang approach. Then again, it's been my experience that even in good economic times it's tough to get them to do this.

It seems to me that delivering value, i.e. services (which might in turn be only possible because of a good overall architecture) is always the better approach.

In other words: Talk less, do more.

Oh yeah -- and I didn't say anything about WS-* or REST -- other than to say it was a silly debate. If you do architecture well, then your services should be able to support interactions using either HTTP operations on resources or SOAP method calls.

You've lost me here. There may be silly arguments in it, and silly people arguing, but I don't see how that makes the debate silly. While I agree it doesn't matter from a 10,000m perspective, this doesn't mean the technologies are equal.

Re: What a great way to start 2009 ! by Jean-Jacques Dubray

So I am not sure why all this drama around SOAsorus, asteroids, "SOA is dead", "SOA is a failed experiment", "the business had enough" and move all your money to Cloud Computing, Mashups and BPM.... blah, blah, blah

For once, I agree with Stephan, which sounds quite a miracle. I don't know many SOA initiatives that are not anchored in delivering business value. I am not sure there are many people delivering "architectures" which have no purpose whatsoever. Now whether you choose to spend more/less/nothing on infrastructure/architecture, I am not sure everyone will choose nothing, and if they spend nothing, will they spend nothing forever?

Anne knows what she's talking about by Dorel Vaida

SOA was a term coined primary as a MARKETING term. I am a developer since 8 years and still I cannot tell in a single phrase what SOA is. Because everyone sold their bullshit being SOA. I understand the term of service orientation, I understand the term of architecture but still, SOA is a term invented (or maybe early hijacked) to draw money not to bring benefits. As other useless or shitty technologies like EJB it has it's place to the IT world's trash can.

Re: What a great way to start 2009 ! by Boris Lublinsky

Stefan,
What does it mean to deliver business value through services? Expose existing application as a WEB/REST service? What is the value in that? we tried this before - remember creation of the web front-ends 10 years ago?
I think that the most dounting problem is creation of all encompacing enterprise architecture. Yes business people do not want to hear or fund it, but ... is there any other choice? The siloed IT is killing every company and as a result we spent more time on implementing and supporting ad-hoc integration patches, then it will take to come up with the reasonable architecture. I still think that SOA failures can be largely attributed to a very siloed IT management and funding models

Re: Anne knows what she's talking about by Boris Lublinsky

Dorel,
You are right to say there is a lot of marketing in SOA, but there is plenty of good definitions. On another hand SOA is not a technology - it is an architecture and a way of thinking about system's (not applications) design

Re: Anne knows what she's talking about by Boris Lublinsky

And by the way,
There is rarely such a thing as bad technology, but there is commonly misunderstanding and misuse of technologies

Re: What a great way to start 2009 ! by Stefan Tilkov

What I meant is that you should try to justify the money spent on SOA through the services you create, not through the creation of the enabling concepts, processes and technology. This means that someone within IT – not on the business side – understands that getting away from the current integration nightmare is necessary, and supports projects that take steps into this direction.


This might be a lot less efficient than a strategic SOA initiative although I have a lot of sympathy for the viewpoint that it's the only way to create something that actually works. Anyway, it's likely to be the only alternative left.

Re: Anne knows what she's talking about by Magnus Wilson

I love when some people kidnap terms and terminology and then when the "hype" is gone they "leave the misused terminology on the ground in a mess...." and declare it for dead.”

SOA is not about technology. In my eyes SOA was (becasue it is now dead:-) a good attempt to bridge the gap between business people and the technical people to make them sit in the same room and talk the same languages and solve the real problems.

Those that have succeeded have shown that properly applied (SOA based) IT is a business enabler and not only a big financial black hole. But it takes a lot knowlegde and committment to make this transition, not only technology!

I disagree by John Harby

Seems like every job description out there now has SOA in it, I don't see SOA as being dead at all. I do see issues with customers trying to implement large green solutions provided by vendors. As happens with any significant technology change, it takes the vendors time to perfect the solution in terms of quality, documentation, etc. As I wrote in an article here awhile ago, I'm not sure the ESB was a great idea but the ESB is not SOA so to pronounce SOA dead is not making sense to me right now. If you want to make statements due to the economy then just pronounce technology dead, no?

What we need is Model-Driven SOA by Johan den Haan

I don't see the solution in 'services' or 'WOA'. I think we need SOA as architectural style, combined with Model-Driven Engineering: Model-Driven SOA.

The Death of SOA - maybe later by The Rasmussen Report .

I think what some see as the "Death of SOA" is just a natural part of the way new technology is adopted. Instead of looking too close, zoom out take the longer view: The time has come for the 'Architecture' part of SOA.

rasmussenreport.wordpress.com/2009/02/16/the-de...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

30 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT