<<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/
