« New Podcast: Mark Herring of Sun Microsystems on the Evolution to Simple SOA | Main | SOA Practitioner Podcasts: Measuring Value, Successful EA Program Ties, Lessons Learned »



Feed You can follow this conversation by subscribing to the comment feed for this post.

Aleks Buterman

Brenda -

This is exactly the kind of issue that we've been solving lately. Once SOA-based implementation goes live, the management paradigm - including such thorny points as annual planning and budgeting - must change to account for what CAN be assembled out of all the bricks and patterns that have been delivered. That leads to continuous reprioritization of planned/in-flight bricks and patterns to constantly adjust to external pressures. This challenge applies to other technology approaches, provided they are model based (MDM, BPM, EDA, BI, and UX, just to add a few more acronyms to the post).

So the fundamental idea of a management unit must change from service or process or system to a capability. If IT is a business unit, then just as any other business unit, the full value is not captured in services that IT provides, but rather in capabilities that this unit enables in profit centers - no different from other enabling units like Finance and Human Resources, to name a couple.

This approach resolves the question of cloud-sourced services - whether "true" cloud (external) or internal cloud. The trick is to sufficiently describe all of these services in a way that allows for easy assembly of services into capabilities, and capabilities into capability portfolios. Call it a semantic service bus for organizational interactions. A lot of very interesting work in this area has been done in DoD utilizing RDF/OWL to create these descriptions. While that resolves the management aspect, the actual discovery and translation of processes, services, and organizational structures is still an art.



The comments to this entry are closed.