The Artima Developer Community
Sponsored Link

Artima Developer Spotlight Forum
Top 10 Reasons SOA Projects Fail

27 replies on 2 pages. Most recent reply: Aug 6, 2008 10:37 AM by Sean Landis

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 27 replies on 2 pages [ « | 1 2 ]
Carson Gross

Posts: 153
Nickname: cgross
Registered: Oct, 2006

Re: Top 10 Reasons SOA Projects Fail Posted: Jul 24, 2008 7:55 AM
Reply to this message Reply
Advertisement
Here are the top one reasons SOA Projects fail:

Distributed computing that performs well is effin' hard.

No amount of boxes and arrows or marketing hype will change that.

They underestimate the complexity of SOA.

Complexity is the last refuge of a scoundrel.

Cheers,
Carson

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Top 10 Reasons SOA Projects Fail Posted: Jul 24, 2008 9:50 AM
Reply to this message Reply
> Here are the top one reasons SOA Projects fail:
>
> Distributed computing that performs well is effin'
> hard.

>
> Cheers,
> Carson

For the counter argument (not that it's right) give this a read: http://www.amazon.com/Client-Server-Survival-Guide-3rd/dp/0471316156/ref=sr_1_9?ie=UTF8&s=books&qid=1216918033&sr=1-9

IIRC, there never was a fourth edition. Here in the third, distributed nirvana is described. Chapter 22 on is the fairy tale. Substitute SOA for CORBA.

Sebastian Kübeck

Posts: 44
Nickname: sebastiank
Registered: Sep, 2005

Only 1 in 5 SOA Projects Actually Succeed Posted: Jul 27, 2008 5:20 AM
Reply to this message Reply
found at:

http://www.infoq.com/news/2008/07/Only1

"...in-depth studies of 20 companies found a 50% complete failure rate, while another 30% were considered neither successful nor wholly failed... Many of them had deployed multiple successful projects, but most of those projects were focused on just one integration problem. It was just a bunch of Web services... The service is only built for one application and it’s never going to be used again"

Seems that the SOA-Bubble is collapsing.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Only 1 in 5 SOA Projects Actually Succeed Posted: Jul 28, 2008 8:10 AM
Reply to this message Reply
> found at:
>
> http://www.infoq.com/news/2008/07/Only1
>
> "...in-depth studies of 20 companies found a 50% complete
> failure rate, while another 30% were considered neither
> successful nor wholly failed... Many of them had deployed
> multiple successful projects, but most of those projects
> were focused on just one integration problem. It was just
> a bunch of Web services... The service is only built for
> one application and it’s never going to be used again"
>
> Seems that the SOA-Bubble is collapsing.

An 80% failure rate isn't surprising. That's the general project failure rate (actually maybe even lower) for IT.

Personally what I see is a lot of people taking whatever it is that they already know or do and calling it SOA. It's not a shock to me that slapping a new label on the same old crap isn't making it any better.

Carson Gross

Posts: 153
Nickname: cgross
Registered: Oct, 2006

Re: Only 1 in 5 SOA Projects Actually Succeed Posted: Jul 28, 2008 9:07 AM
Reply to this message Reply
Again, distributed computing is hard. Serious computer scientists and people who bother to read what they write have known this for decades.

I'm beginning to wonder if the sum total pain caused by the box-and-arrow crowd has outweighed the occasional usefulness of UML.

Cheers,
Carson

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Only 1 in 5 SOA Projects Actually Succeed Posted: Jul 28, 2008 6:41 PM
Reply to this message Reply
> I'm beginning to wonder if the sum total pain caused by
> the box-and-arrow crowd has outweighed the occasional
> usefulness of UML.

Off-topic but speaking of boxes and arrows, I've been seeing diagrams like this more and more lately:

http://www.w3.org/TR/ws-arch/#gsom

Does anyone think this is a useful type of diagram? I mean, does anyone look at this and think, "oh, that makes it much clearer." When I look at these diagrams, I immediately lose focus, literally and figuratively. I am unable to force myself to parse it. It kind of seems like a style of diagram created by someone who doesn't really 'get' diagrams.

Bringing it back to this discussion, I have to agree that box and arrow tool sets are very much overrated. They make sense at a very high level but beyond that they have little value. Most of the time, they just hide the code in little text boxes inside modal dialog windows anyway. I once used XSLT to print out all the code that was in one of these tools to show a manager that the tool was not eliminating code. The quality and amount of code was appalling.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Only 1 in 5 SOA Projects Actually Succeed Posted: Jul 29, 2008 5:19 AM
Reply to this message Reply
> Off-topic but speaking of boxes and arrows, I've been
> seeing diagrams like this more and more lately:
>
> http://www.w3.org/TR/ws-arch/#gsom
>
> Does anyone think this is a useful type of diagram?

Since this is the/a "reference" diagram of SOA, not at all off topic. That its authors are clearly off their rockers, I guess it about sums up the morass that is SOA.

Sebastian Kübeck

Posts: 44
Nickname: sebastiank
Registered: Sep, 2005

Re: Only 1 in 5 SOA Projects Actually Succeed Posted: Jul 30, 2008 12:03 PM
Reply to this message Reply
Lo

Sebastian Kübeck

Posts: 44
Nickname: sebastiank
Registered: Sep, 2005

Re: Only 1 in 5 SOA Projects Actually Succeed Posted: Jul 30, 2008 12:11 PM
Reply to this message Reply
> > http://www.w3.org/TR/ws-arch/#gsom

Looong time ago, I saw that kind of diagram in a book about object oriented modelling. It was drawn by a child, it showed the sea and animals there and lines with verbs showing relations between those objects. So that's definitively not new and, at lest not exclusively, related to SOA.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Top 10 Reasons SOA Projects Fail Posted: Aug 5, 2008 2:55 PM
Reply to this message Reply
The biggest problem with the term SOA is the fact that it is a valueless term. It doesn't say anything about what matters to those who might implement one.

SOA includes the word "architecture" to make its use independent of technology. However, in the end, it is specific technologies that help make an SOA successful.

You have to understand why idempotent interfaces are key. You have to understand why distributed systems need things like leasing and transactions for effect resource management. You need to include explicit fail over strategies for every remote entity that participates in the system. You need to understand how authentication and authorization are best done as detached, pluggable parts of the system.

Some distributed system technologies include all of these things as integral parts of what they provide. Many products and technologies are but one part of a more complex system architecture.

The team of people implementing an SOA need to understand how each technology interfaces to each other so that the impact of those interfaces can be part of the architecture and design processes.

My typical mantra is that if you are using Java for your SOA services, you should be using Jini for your technology of choice to interface services that talk to each other. I say this because Jini exploits the power of Java's mobile code model to keep versioning issues minimized. Smart proxies can be deployed to work around versioning issues that would typically make your service support multiple interfaces. A single proxy object can be sent out with multiple interfaces supported and it can do conversions that allow a single service interface to be supported with the old clients utilizing the smart proxy as the versioning compatibility entity.

There are transport/communications technologies such as the low level FTP and HTTP kinds. There are higher level technologies for RPC such as Corba and RMI-IIOP (and RMI-JRMP) that are binary oriented transports. Then there is marshalling based normalization such as WS-X that include a plethora of "semantics" tied to the otherwise "neutral" content.

If you look around at all these various technologies, there are lots of partial players. Technologies like J2EE and .Net attempt to broaden the underlying technologies into particular types of markets by having support for very specific types of solutions integrated into the "platform" that they represent.

Frameworks such as Spring, provide a style, but not really a feature set of "technologies" that might make distributed systems work (directly).

My Jini mantra comes from the fact that Jini has support for all the things that I consider integral parts of good SOA as parts of the platform. They all work together, share a common model, similar issues for each service in lifecycle, interface, security etc. So, I think its more likely that you could teach a team of people how to be effective Jini developers then to teach them how to use the plethora of technologies and packages that you need to integrate into a more "heterogeneous" system.

Alas, I know that most people wrote of Jini a long time ago because of the old licensing issues. It's been open source under apache for more than 2 years now, so it is "free" for the taking.

It's interesting to see how people are experiencing SOA. I tend to think the failures are really about poor choices and bad execution rather than about SOA being a problem child.

SOA is possible to do, but you have to understand the 10 fallacies of distributed systems and be able to consider each technology you wish to deploy in light of those, and decide whether that technology is appropriate, and if not how to make the appropriate change in architecture, expectation or technology.

Sean Landis

Posts: 129
Nickname: seanl
Registered: Mar, 2002

Re: Top 10 Reasons SOA Projects Fail Posted: Aug 5, 2008 3:28 PM
Reply to this message Reply
As I mentioned before, we were able to succeed with SOA using RESTful web services. I totally concur with Gregg regarding success factors. I too come from a Jini background and the values I learned in that world drove how we solved our architecture challenges with RESTful web services.

You might ask, "Why didn't you use Jini?" If you've taken the time to listen to our JavaOne presentation, there were several constraints and factors that made Jini the wrong short-term technology choice. It wasn't a technology issue though.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Top 10 Reasons SOA Projects Fail Posted: Aug 6, 2008 7:45 AM
Reply to this message Reply
> As I mentioned before, we were able to succeed with SOA
> using RESTful web services. I totally concur with Gregg
> regarding success factors. I too come from a Jini
> background and the values I learned in that world drove
> how we solved our architecture challenges with RESTful web
> services.

Was this discussed at your presentation? I actually attended it but I don't recall if you got into this.

On a side note, what's your take on whether RESTful web services need some sort of descriptor. I don't want to get specific because it poisons the discussion but let me know if what I am asking is not clear.

thanks,

-James

Sean Landis

Posts: 129
Nickname: seanl
Registered: Mar, 2002

Re: Top 10 Reasons SOA Projects Fail Posted: Aug 6, 2008 10:37 AM
Reply to this message Reply
> Was this discussed at your presentation? I actually
> attended it but I don't recall if you got into this.

We didn't get into how Jini informed our decisions but I think if you take what Gregg said were lessons from Jini and map it onto what we ended up with and what we said, you should see Jini's fingerprints.

> On a side note, what's your take on whether RESTful web
> services need some sort of descriptor. I don't want to
> get specific because it poisons the discussion but let me
> know if what I am asking is not clear.

Like WSDL or WADL? I definitely don't think it is *needed*. Nor do I think the JSR-311 work is necessary. I think the benefits have more to do with style than technical benefits. Some organizations are better positioned and will be more comfortable working at the Java level - like ours. Other organizations will be more comfortable using WSDL and annotations - maybe they are a JavaEE shop for example.

What I like about Restlet is that you can use it either way.

There may be some benefit to providing WADL for public-facing RESTful services but there's not a need to generate clients like there is in the WS-* world. You can but you don't make life much easier by doing so.

Once you go the descriptor route, you have to have the tooling to keep the WADL consistent and that starts to dictate how you develop your services. I think that's wrong thinking: Interface descriptions dictating implementation choices. Interfaces should be independent of implementation to a greater degree.

The other thing to consider is whether your app is just baby-sitting a database - the Ruby on Rails sweet spot. For this sort of thing, the WADL/JSR-311 approach is great.

Flat View: This topic has 27 replies on 2 pages [ « | 1  2 ]
Topic: Sun Releases JavaFX Preview SDK Previous Topic   Next Topic Topic: JetBrains Releases First Beta of IDEA 8

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use