BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

SOA: Where Do We Go From Here?

by Jean-Jacques Dubray on Mar 14, 2009 |
Okay, enough wrangling over whether SOA is dead, or is thriving, or never even existed, or crashed somewhere near Roswell, New Mexico. The indisputable fact is many organizations are now working toward service orientation for at least part of their business application offerings, and this will only grow.

claims Joe McKendrick.

For Joe, the way forward can be found in an article written by Bob Violino a couple of years ago, who argued at the time:

There is no doubt about it: service-oriented architecture, or SOA, has gained acceptance as a way to exchange data previously trapped in legacy systems and isolated databases.

In the mean time, lat week, Ted Neward tempered:

In the rush to embrace new technologies and demonstrate “cutting-edge awareness”, companies (and individuals) sometimes create mountains out of molehills. Such was the case with XML a few years ago, relational databases before that, object- orientation, Java, graphical user interfaces…. in fact, it’s hard to name a recent technology trend that hasn’t spawned this kind of “rush to embrace” that leads to nonsensical claims, bizarre architectural suggestions, or blatant bald-faced attempts at capturing clueless consumer dollars. One of those more recent trends has been the SOA bandwagon.

He asks if we remember:

Originally, though it’s hard to remember in the frenzy around SOA, the whole point of services, ... was about designing distributed systems to be loosely-coupled and thus easier to interoperate with.

Yet, he notes that:

Nowhere in here do we find reference to SOA governance, SOA enablement, or any of the other elements that have been attached to the SOA name. In fact, it’s gotten to the point where CTOs and CEOs are talking about SOA as a general strategy for running their entire IT department.

This is in sharp contrast with what Joe think will take SOA Forward:

1) Increased visibility as SOA moves from theory to practice

2) New types of jobs

3) The rise of best practices and competency centers

4) More governance and reuse

5) More measurement

Ted justifies his argument by asking why is it really the role of the CTOs and CIOs to worry about SOA? In the meantime he explains:

Too many CEOs and CTOs just assume that their back-end IT systems are capable of talking to anything at any time–in fact, one CTO once told me, to my face, “The only reason you’re saying it’s hard is so that you can charge me more money as a consultant. Well, I’m not buying it, and I’m not buying you.”

Ted continues:

So what are we to make of all the “service-oriented” bells and whistles currently being hung on every product, language, or release?

In his view,

There is a point in the IT implementation, where the technology simply can’t help.

Eric Roch seems to agree, one of the problem he sees is ROI:

many companies have spent millions of dollars on SOA software, infrastructure and consulting dollars with no idea how to justify the costs. That's bound to get noticed.

Ted concludes:

Moral of the story? We learned that objects are a useful way of structuring the way programmers think. Nothing more.

Another look at the “four tenets” makes it pretty clear that services aren’t much more than that, either–it’s a way of structuring the way programmers think, and has nothing to do with “governance” or “enablement”.

Where does SOA go from here? Do we have enough middleware between Web Services, HTTP/APP, SCA or distributed-OSGI? What is the role of Resource Orientation or Event Orientation in Service Orientation? Is it time to let developers loose with these technologies? or Do we still need competency centers? Can you build connected systems without governance? Should you rush to explain your CEO how successful your project was because of OSGI? Are to current programming and integration models enough to build complex connected systems? Is it just an interoperability problem? A cost problem? What is your opinion?

Hello stranger!

You need to Register an InfoQ account or or login 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

Technology doesn't matter by Anne Manes

As Ted says, what matters is changing the way developers think about solving the problem. Technology can provide useful tools that facilitate that change in thought patterns, but the specific technology used today will almost certainly not still be used 10 years from now. I'm sure that creative people will continue to design new technologies that will improve the facilitation of the thought patterns. And I have no doubt that they'll also design new ways to think about the problem.

So no -- I don't think we have enough middleware, because all the middleware we currently have is flawed. And meanwhile, project decision makers need to spend a lot more time thinking about ROI.

- Anne

Re: Technology doesn't matter by Jean-Jacques Dubray

Anne:

could you elaborate on your point: "all the middleware we currently have is flawed" or maybe give us a link to where you explained that point.

JJ-

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

2 Discuss

Educational Content

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