« Web of Services for the Enterprise | Main | The Last Face to Face for WS-TX? »

Incremental Approach to SOA Infrastructure

Steve Craggs picked up on IONA's recent announcement, in which we reiterated our incremental adoption approach, asking whether this is a good thing. Neal Keneally has already commented that if you know you need orchestration, you can always buy it at the same time as the Artix ESB microkernal, and Steve apparently ended up agreeing with this, but still wondering how the final tally would come out. Would it really be less expensive than buying another ESB the "traditional" way, all at once?

This is a good question, of course, and one that's very difficult to answer because in the world of enterprise software, sales are typically a long discussion, including price negotiation. It's not like buying Word or Flight Simulator.

But I would add that SOA is fundamentally different than previous generation products because SOA is an approach, not a technology. (As Steve V. has pointed out at the end of this post it actually would make more sense to call it Service Oriented Approach so it isn't confused with more precise software architectures such as hub and spoke, three tier, or REST.)

The comparison of the "traditional" vs the "incremental" approaches is difficult since everyone's SOA requirements are different, and everyone's budgets are very tight. It just seems more reasonable to offer a smaller priced offering for companies getting started with SOA, especially those sensitive to demonstrating ROI.

The point is that to do SOA you may not need a lot of software in the first place. You probably don't need another application server, an EAI broker, or a message queuing system. The point of an SOA is to join these and other types of existing software systems together using a standard interface and some (possibly combination of) data formats and communications protocols.

So the incremental approach makes more sense for SOA infrastructure than it would for application servers, database management systems, message queuing software, packaged applications etc. since by definition what SOA is trying to do is put these kinds of things together, not replace them.

TrackBack

TrackBack URL for this entry:
http://blogs.iona.com/cgi-bin/mt/mt-tb.cgi/396

Listed below are links to weblogs that reference Incremental Approach to SOA Infrastructure:

» New and Notable 118 from Sam Gentile
We have a new addition to our house - a 60 pound 2-year old English Bulldog! Agile/TDD The big news of [Read More]

Comments (3)

Good point on incremental changes to an infrastructure to introduce SOA. The name change wouldn't be a bad idea as well since it is more of an approach that spans across organizations, where architecture limits it to the technology running the environment versus the organization shifting gears to support incremental changes to their IT environment. This may include making some of their IT functions a commodity.

Dan - good point yourself on the impact of existing technology on any proposed new architecture. Absolutely the more general purpose functions that commoditize the better, IMHO.

Eric

Jacques Cayuela:

I agree with these two good points.
A better name could be SOO (Service Oriented Organization). When you have an organization, you use an approach and then you build an architecture.
Making correctly incremental changes is a matter of organization, delivering services with business meaning is a matter of organization.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

About

This page contains a single entry from the blog posted on October 27, 2006 5:34 PM.

The previous post in this blog was Web of Services for the Enterprise.

The next post in this blog is The Last Face to Face for WS-TX?.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.31