I tend to agree with Todd, and it's hard to argue with a phrase like "at some point, development must occur."
=) The writeup in searchwebservices was a series of snippets transcribed from a long and varied conversation I had with Rich Seeley. But the goal of clarification is being met as various members of the community step up in this environment to propose amendments and make legitimate points. The fact that a service lifecycle ends when a service dies is a very good one. In lots of places we have seen services live on for longer than they probably "should" which brings up versioning. Anyhow, this is good debate... Miko --- In [email protected], Todd Biske <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
