 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > SOA All-in-One Guides > SOA Lifecycle > Fundamentals > Service lifecycle > SOA lifecycle: What are we talking about? |
| |
|
|
|
||||||
| All-in-One Guides: SOA Lifecycle: |
|
|||||||
|
||||||||
|
||||||||
|
||
|
Fundamentals
 Service lifecycle
|
|
| |
|
|
| |
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The SOA lifecycle is different from the more traditional uses of the term lifecycle in IT and software development, according Miko Matsumura, vice president of technology standards at Infravio Inc. The different meaning of lifecycle can cause confusion in discussions of SOA, especially in his area of interest, which is policy and governance. Yet it is more than a debate over defining terms, as he argues that paying attention to the policy lifecycle within the larger SOA lifecycle can provide a competitive advantage to a business.
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:
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.
Noting that the business activities within an SOA application are constrained by policies governing things such as how they interact with business partners, Matsumura argues that this is not a bad thing since it makes sure that, as he puts it, "the trains not only run on time, but stay on the track." In his view the agility of SOA requires that the Web services activities operate within the constraint of policies. "It's one thing to be agile and flexible and another to go completely amuck," he quips. To push the railroad analogy, by maintaining a policy lifecycle, an organization can quickly switch to another track and take a different route if the business climate changes. "If your constraint model is more adaptable, more flexible than another company's, then you have the possibility of having a sustainable competitive advantage," he said. "As conditions change, policies change, and the flow of activities change. But all in ways that maintain the integrity of your intentions."
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
