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.


4 responses to “Incremental Approach to SOA Infrastructure

  1. 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.

  2. 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.

  3. 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.

  4. New and Notable 118

    We have a new addition to our house – a 60 pound 2-year old English Bulldog! Agile/TDD The big news of

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s