One of the unheralded innovations of SOA governance is that the operational life of a service was made an explicit part of the lifecycle. That is in sharp contrast to the typical scenario with the traditional application lifecycle, where the software development group usually washes its hands of responsibility once software is migrated to production. For SOA, the inclusion of formal service contracts has mandated that developers and owners of a service must pay attention to service levels once the service enterprise production. Such contracts not only identify which consumers are entitled to the services and under what conditions, but also include promises to meet specific service levels.
The challenge, however, is figuring out who is responsible for the service as it transitions to production; in most IT organizations, accountability for the service isn't always clear, and often changes based on the stage of the service lifecycle. Here, IT organizations could take a cue from their counterparts in the durable goods manufacturing world: designate a product manager for the service.
A cast of many
For SOA governance, the problem is that there are too many cooks spoiling the broth. In most organizations, a revolving cast of players has some skin in the game when it comes to taking responsibility for creation and delivery of a service. Based on where the service is in its lifecycle, the characters that are accountable for a service include:
Requires Free Membership to View
- The Service Owner, who is typically the lead stakeholder from the line of business, secures the funding, but does not own the physical implementation (the SOA architecture) of the service;
- The software development and/or enterprise architectural team, which owns the physical software implementation (e.g., the SOA architecture);
- The SOA team project manager, who is responsible for ushering the creation of the service, but typically does not manage the service once it has entered production; and
- IT Operations, which is responsible for running the service and fielding infrastructure-related problems with meeting SLAs.
While managing handoffs among a cast of several might be perfectly acceptable if organizations are only managing a handful of services, as service registries expand to dozens or hundreds of services, this arrangement hits the wall. Once a service enters production, governance involves far more than simply monitoring performance levels. For instance, if another group is interested in repurposing the service, that triggers a new series of events requiring complete visibility back to development (see Figure 1). It requires working with new stakeholders who have discovered the service, and ensuring that:
- The service will meet their requirements
- Adding new consumers of the service will not jeopardize promises to service owners, contracts with existing consumers (e.g., those who may have a vested stake if other entities wish to use services that they have already paid for), or violate corporate policies
- IT Operations are able to accommodate the proposed new use of the service, especially if it results in higher or sharply different consumption patterns that could tax the IT infrastructure.
Enter the Product Manager
This is where IT organizations that have become active with SOA could learn a few lessons from their durable goods manufacturing counterparts: appoint a product manager who acts as steward through each phase of its lifecycle. In this case, the "product" is the automation or composition of a business process or set of processes, and the consumers are business stakeholders, and in some cases, business partners and/or end customers.
So what does the SOA Service Manager actually do? We believe that the role would begin at the service strategy stage of the SOA lifecycle, where the requirement for a service is validated. At that point, the service manager should then ensure that the SOA project gains the requisite approvals and does not duplicate services that are already in the software portfolio. Then the service manager would mobilize resources for moving the service through design, construction, and release (as mentioned earlier, in some cases he or she may also be the project manager).
Then the service manager takes on responsibility for release management, determining when the service is ready for production, when the business is ready to start providing or consuming the service, and when IT Operations is ready to host the service. Once the service enters production, the service manager should monitor or get reports on service performance, ensuring that the service is meeting SLAs and coordinating with the ITIL Service Desk when problems emerge. Additionally, the service manager should be the chief marketer and advocate for the service while in production, assuming responsibility for outreach to potential new classes of service consumers; if successful, the service manager is then responsible for overseeing onboarding new consumers of the service. And once the service meets its midlife or end of life, the service manager again would be responsible for the chain of evaluations as to whether the service still meets the business need, whether new versions should be implemented side-by-side or in replacement, or whether the service should be withdrawn.
The SOA Product Manager: who should step up the late? The last thing that any IT organization needs today is another layer of management. Therefore, it makes sense that the service product manager be recruited from one of the actors that is already involved with oversight at different stages of the lifecycle. Who should it be? That will depend on the organization's structure and culture, and most importantly, on the leadership qualities of the candidate.
Make no bones about it, the SOA product manager must be capable of acting as field marshal, motivating and moving people who have already agreed verbally or in writing that change is needed. The most logical candidates could be a service owner or business analyst who has leadership capabilities, or a project manager who also has some domain expertise.
About the author
Tony Baer leads Ovum's research on the software lifecycle. Working in concert with other members of Ovum's software group, Tony's research covers the full lifecycle from design and development to deployment and management. Areas of focus include application lifecycle management, software development methodologies (including agile), SOA, IT service management/ITIL, and IT management/governance.
Join the conversationComment
Share
Comments
Results
Contribute to the conversation