This was selected as Best Answer

Well, part of this depends on how you define success.

I’ve worked on several large programs that transformed their legacy, COBOL-based, text screens to web/portal-based enterprise functionality powered by web services. We also consolidated many of these services into more enterprise-oriented web services (as opposed to just service-enabling legacy systems).

To me, the biggest problem with really implementing SOA is that it’s generally implemented bottom-up by service enabling existing functionality rather than a business-driven, functional transformation. This alone can be very powerful and useful by providing easy web/XML access to your core business functionality, but it’s not really SOA. And SOA is almost always viewed as an IT or technology-centric solution rather than a business-centric solution.

1. Full blown SOA based implementations
Well, we had pure web service interfaces and SOA infrastructures, although many of the underlying systems were pretty ugly. But that’s SOA in the real world.

2. Thorough and working SOA governance
We had active service monitoring using SOA governance tools, CCBs (change control boards), and ARBs (architecture review boards) to ensure compliance. It strongly supported and aligned with SOA, but a lot bigger than just SOA.

3. Full scale inter-company or inter-organisation type SOA information exchange
Sure - we had web service enabled interfaces to dozens of external agencies, partners, and suppliers.

4. Total efforts to transfer Legacy applications to SOA participants to achieve full scale SOA
I’m not sure what this means. The beauty of SOA is the decoupling of the interfaces with the underlying implementation. We built web service interfaces so the legacy systems could integrate and support an enterprise SOA and, for several systems, we modernized the underlying technology to better support internet apps. But, in general, legacy apps won’t really align so perfectly with a lovely top-down design so you can either rewrite, refactor, or modernize the app or build web services to access the parts that you need with fairly minimal change to the legacy app.

5. Working Middleware / information brokers / enterprise service buses supporting nearly all functionality in a SOA environment
Sure - that’s standard in a SOA-enabled enterprises. Beyond that, you’re also going to get multiple and layered registries and ESBs since many of your services might be implemented using a SOA as well. (For instance, if you integrate with an ERP, the ERP also has its own SOA backbone). And you’ll get public and private services. It’s all good as long as it makes sense.

6. Fully implemented BPM on top of a full SOA implementation.
We did implement fixed enterprise business processes by chaining together a number of services. But none of that dynamic service discovery (except for run-time binding) - I don’t think many companies really use this and I’d question if they ever want to unless you have really strong QoS and service pedigrees controls. Well, we certainly did dynamic service discovery at design time, but that’s quite different. On the whole, I think dynamic service discovery is over-rated for the big-picture enterprise services, although it could be useful in the little-picture services (like the big-picture Inventory service might want to automatically including yet another data source, but you wouldn’t want to dynamically discover the picture).

posted 11 months ago

We have shared our success in this regard publicly on many occasions. Likewise, we are also game to share with employees of other Fortune enterprises. We typically don't share with consulting firms though as we desire more transparency...

posted 11 months ago