Middleware Matters

Steve - If I'm hearing you correctly... one just needs to implement your product and "presto" - instant SOA! No pains, no worries!

No need for SOA education!
No need for SOA governance best practices!
No need to concern yourself over how to implement SOA based ERP, CRM and SFA systems!

I'll download a copy right away. :-)

Hi Jeff, yes, it's all positively magic! :-)

Seriously, there's always a need for SOA education, best practices, etc. And there is no magic, as we all know.

My point is that SOA isn't really to blame in many, if not most, failure cases. Many vendors push the idea of "Hey, just buy into my SOA infrastructure, get rid of that other stuff in your enterprise, and life will be grand!" I call this the "Same On All" or "Scrap Old Applications" variants of SOA (note the acronyms). People fall victim to the notion that you can't get to SOA one small step at a time, that it all has to be done in a big jump, and then they fail, and they wrongly blame SOA.

Artix is specifically designed to let you keep your existing systems in place and running while you build your SOA Network around them. Sometimes it actually seems too good to be true, and yet Artix is real. Among other things, it eliminates the tedious and error-prone hand-coding that people engage in when trying to "service enable" their existing applications, which invariably leads to the failures you alluded to in your blog.

Yes, this blog entry is making the rounds. And because it certainly does resonate with folks.

But I think focusing on the implicit rip-and-replace message is not what Mr. Schneider was primarily writing about.

Schneider was making a point about SOAs and critical mass. It's hard to weave together systems and business processes if the integration points (services) aren't there. Once you've created a large enough service landscape, SOAs begin to take off. But it's slow going until then and ROI doesn't accumulate much until that point.

Getting there means focusing on identifying the right functionality to service-enable early on, specifically things that people will need to build iniital composite services and apps to leverage their SOA.

I've been on enough SOA implementations to know it's very hard to get folks to agree on what services implement first, second, and so on. People in large organizations tend to have wildly different priorities.

I think means we have to encourage folks to do more bottom up SOA work at departmental and division levels with some minimal central architecture work to make the SOA emerge, be consistent, and interoperable across the board.

But the problem of critical mass is going to be a real, ongoing issue as folks pour money into SOA projects and then try to extract value.

Best Regards,

Dion Hinchcliffe
Tier-I Architect
Sphere of Influence

Hi Dion, all very good points. Critical mass is indeed important, but I think it's also why people tend to think they have to take a "big bang" approach. They think they shouldn't bother service-enabling anything unless they service-enable everything.

We've seen that attitude in other areas, too. For example, when OOP arrived on the scene years ago, everyone started turning everything they could into an object. If everything wasn't an object, after all, how could you really claim to be doing OOP? And if you weren't doing OOP, then your systems couldn't possibly be any good, of course.

I think SOA success can often require a top-down approach from an organizational perspective, but a bottom-up approach from a technical perspective. If the CIO says "we need services, and I am going to be involved in seeing that we obtain measurable ROI from deploying and reusing services," the technologists will figure out how to do it. If OTOH the technologists just service-enable this app and that app, then you're right, the likelihood of seeing a successful SOA-enabled enterprise is low.

I led a SOA panel at the ICSOC conference last November in New York where Tom Kozempel talked about SOA in Verizon. His CIO Shaygan Kheradpir basically has a dashboard where he can monitor services and see how they affect the business. Various articles have been written about it, such as this one:

http://www.cio.com/archive/110104/hs_verizon.html

When a CIO is involved to that degree, SOA works. When OTOH a CIO thinks that just training his employees on SOA and putting a magical methodology in place will lead to having an enterprise SOA, as Jeff told me he's seen, then they are bound to fail.

Just FWIW, my comment wasn't against CORBA per se, it was against those who promoted it in this way (including, funnily enough, myself 8-).