Most people agree that one of the desired outcomes from adopting SOA is increased business and IT agility. What confuses many people is exactly how that agility is achieved. Many enterprises see interoperability as the path to agility. The thought being that they will be able to integrate legacy systems at a more rapid pace or that they can swap package vendors with fewer resources. Certainly there is some truth to that initially; however, as more services are created and more dependencies are established organizations will find that line of business owners will no longer share their services so they can maintain their own agility by not acquiring other line of business applications as dependents. At this point, organizations find themselves facing the same issues they did before, but with newer technology. I guess that is a plus.
Web services are about interoperability. SOA is about removing impediments, and that's it. A strong SOA story is one that provides a cohesive plan on how individual impediments can be mitigated. For example, additional dependents make it more difficult for service providers to version their services. Dependents are not the impediment, and one might argue that a successful service in a successful SOA implementation is one with many dependents. Not knowing who your dependents are and not having a technical strategy for supporting multiple versions are the impediments. As I said SOA is about removing these impediments and not just identifying them. Requiring consumers to register for access to services is the best method for tracking dependents. Once you know who is consuming your services, how often they are consumed, and what version they are consuming you can actively manage them. So, if you want to sunset an older version of a service you can proactively work with its consumers on upgrading to the latest schema. Often, getting all your consumers to upgrade in a timely manner is difficult. This is where having a strong method for supporting multiple versions is critical.
This is the concept behind Service Lifecycle Management (SLM). If you treat individual services like independent projects and manage them through identification, development, provisioning, and consumption you will begin to realize some of SOA's promised agility. Concepts like Application Lifecycle Management and methodologies don't go away and they still play their respective roles in the development phase of a service's lifecycle. The Managed Services Engine (http://www.codeplex.com/servicesengine) is a tool that can help execute some of the activities needed to pull off SLM like consumption monitoring and versioning through Service Virtualization.
[Update: Original posting with Word 2007 didn't work so well, so I updated post from Live Writer]
This is my first post with Windows Live Writer. I've been using BlogJet for years, but this is free and has all the features I need like FTP upload for pictures.
While I am at it, I think I'll give Word 2007 a try as well.
Bri took 4th on Vault, 2nd on Bars, 1st on Beam, 5th on Floor, and 2nd in all-around. Still driving home, so no pics or video yet.
Over the years, I’ve gotten the most use of my 360 when I’ve been ill or my back has been aggrevated. Coincidentally, and unfortunately, my back has me almost unable to move and my 360 is unable to start because it is getting three flashing red lights indicating an unrecoverable hardware failure for the second time.
My son, Mateo, leveled up on Saturday moving from a Taekwondo green belt to a purple belt. Gabi should be testing next month to move from purple to blue.
