Re: [service-orientated-architecture] Miko on SOA Lifecycle Governance

[Todd Biske]

I had to re-read this because at first glance, I thought he was speaking about the service lifecycle, a topic that I recently completed a whitepaper on for my employer.  This is very different than an SOA lifecycle, which is clearly broader in scope.   I think Miko's got some very good points.  I wouldn't have chosen his terminology, but I don't want to turn the discussion into a debate about semantics (although semantics are very important in SOA!). A key similarity between what this article conveys (I haven't read the 50 page document yet) and my own work is the notion that lifecycle doesn't end when something goes into production.  The lifecycle ends when the thing dies.  In the case of a service, it's when all the consumers are gone.  Ron, Jason, and I touched on this a bit in our podcast back in June (http://www.zapthink.com/report.html?id=ZTP-0239) which discussed the difference between product management and project management.  Project management ends when the project is done, product management does not.  Product management is exactly what a service provider needs to practice. Another common point is the need for change management.  Changes to the service and changes to the policies that govern the service.  What happens when a service consumer is going to double or triple the load they place on a service?  This is a change in the governing policies of the service contract, and that change may need to trigger action, such as provisioning more resources for the service, changing the chargeback rate, etc.     The one difference I saw was that my document included the SDLC.  At some point, development must occur to get the services out into production.  Likewise, the composition of services or orchestration as part of a broader solution must also go through some form of development lifecycle.   -tb On Aug 30, 2006, at 12:28 PM, Gervas Douglas wrote: <<Attempting to clarify matters, Matsumura has written a 50-page white paper on SOA Lifecycle Governance, which is available at the Infravio Resource Center. In discussing the SOA lifecycle, he divides it into three parts: * Design time, when the services are put together to form a business application * Runtime, when the SOA implementation goes to work and the business activity begins * Change time, when the inevitable alterations are made as business requirements change to take advantage of the agile promise of SOA However, this SOA lifecycle bears little or no resemblance to what developers traditionally talk about in terms of the Software Development Lifecycle (SDLC), Matsumura argues. "What's ironic about SDLC is it has zero overlap with the SOA lifecycle," he said. "The traditional SDLC begins with some kind of design or blueprint. It essentially ends with the deployment of the service or software. If it's a service as in the case of SOA, in a way the event that suggests that the cycle is complete is the publication event. I know that some people think of SDLC as much more. But I think some of the traditionalists would think of deployment as being the finish line. Okay, we're done. Hurray!" In Matusmura's view, the SDLC ends where the SOA lifecycle begins. His definition of design time, the first stage in his vision of the SOA lifecycle, covers the assembly of the now published Web services into a business application. "I know there's even an earlier stage there where people build architecture and they kind of make plans, and they make a big picture, and they talk about interoperability and standards and security and everything else," he said. "So there's an architectural design stage." But, in his view, that's the preliminary stage before the SOA lifecycle begins with what he calls "SOA design time." "SOA design time actually involves taking lower level services and combining them up into business level services," he said. "So this is a different kind of design." That leads to SOA runtime and change time, which complete the lifecycle. Then, while it requires thinking outside the box, Matsumura argues there are two facets to the SOA lifecycle. The first facet is the more obvious one where the Web services have a lifecycle consisting of design time, runtime and change time. But when he talks about SOA governance, he argues that the policy layer has its own lifecycle, an inside game that is often missed in SOA implementations. "The layer that almost always escapes people is that the policies themselves also have a lifecycle, a design time, runtime and change time," he said. Policies need to be designed, run and changed, and it is in this policy lifecycle that Matsumura believes the promise of SOA agility can be delivered. The ability to maintain a policy lifecycle and quickly make changes can provide a competitive edge, he argues. "You can fundamentally compete as a company on policy, which is ironic way of thinking about it," he admits.>> You can read this in full at: <http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1213362,00.html?track=NL-110&ad=562929&asrc=EM_NLN_498824&uid=5532089> Gervas __._,_.___ SPONSORED LINKS Computer software program Computer software spy Computer job Database software Discount computer software YAHOO! GROUPS LINKS  Visit your group "service-orientated-architecture" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___