Print
Close

The SOA Project Manager

August 29, 2011

Does the role of Service Oriented Architecture project manager exist? If there is indeed such a position, would they be more of a technical architect and less of a PM? Is there a rule that mandates that the SOA project manager need to be technically savvy or have been a technical architect early in his or her career? These are all good questions to ponder as we see more and more IT organizations seeking management competency in implementing SOAs to reap its much-touted benefits of interoperability, reusability and business savings.

The SOA paradigm has existed in the IT industry for many years now. The major driving force for SOA adoption is the desire for faster timing to market as well as reducing project costs. Forrester Research reports that a typical savings on an individual project can be as much as 30 percent (based on concrete data gathered from organizations implementing SOA). Organizations and architecture communities have written, discussed and dissected various aspects of SOA; it has now become a very marketable concept. Software companies have released SOA suites and system integration consultants have been proposing the best practices for SOA adoption. In short, SOA as a practical concept has caught the attention of businesses that want to reduce the IT sprawl--and are on the lookout to increase the time to market speed.

In a typical SOA implementation and adoption scenario, technology architecture and its enablement plays an important role. After all, SOA adoption is all about transforming critical business functionalities into technology services that can be reused by other services or applications. In such a technology-heavy scenario where system infrastructure, architecture design and operations optimization plays a prevalent part, project management usually becomes an afterthought. Project managers usually tend to focus on the methodology for executing the technical part of the project. However, a good understanding of a practical SOA landscape and its associated challenges can help a technical PM make the SOA adoption on technology projects run smoother.

Technology Awareness
A project manager in charge of SOA will be called upon to deal with many related technical scenarios. Terminologies like ESB, message queues and schemas will be floating around. The SOA PM should start absorbing these technology elements that will help him or her lead the team successfully. A SOA project comes in many flavors. However, building a SOA infrastructure and maintaining it for existing services will be the most important projects that a SOA PM will have to manage.

As a first step, get familiar with the SOA reference architecture. Even though this sounds very complex, an understanding of the basic technology components can help the PM effectively navigate the project.

• SOA Principles: reusability, loose coupling and autonomy of services. (A good starting point can be Thomas Earl’s SOA principles.)
• Enterprise Service Bus (ESB): The backbone of the SOA framework. ESB connects service providers and consumers. More information can be found from various SOA tools vendor sites.
• Web Services standards: SOAP (Simple Object Access Protocol) and REST (Representational State Transfer)
• Registry and Repository: Enterprises register their SOA services in the registry and repository. A repository hosts more details about the registered services and could manage a service lifecycle from inception to production.
• Other SOA keywords: WSDL (Web Service Definition Language), WSIL (Web Service Inspection Language), BPEL (Business Process Execution Language) and Service Schema. A simple Google search can yield rich results.

Management Challenges
As mentioned in the earlier section, a SOA PM will be either in charge of building a SOA infrastructure or maintaining it. Building an infrastructure also constitutes SOA concept adoption by the enterprise. This is a grueling task and should be undertaken by a SOA CoE (Center Of Excellence) leader. The toughest management issue a SOA PM will tackle is the clear allocation of funds for building a reliable SOA infrastructure. Upper management rarely recognizes the capital cost that is needed to build before any results can be obtained.

• Funding Model: It is highly likely that the PM finds his SOA projects strapped for cash. The usual reason for such a situation is the lack of commitment from the core business groups. In many cases, SOA projects or initiatives are originated by technology groups and presented to lines of businesses for their support. Business groups find it hard to justify long-term investments on technology architecture when other core business operations scream for funds. As a solution, the SOA Center of Excellence should pursue executive sponsorship for any SOA-related initiatives.
• SOA Governance: A SOA PM should influence the creation ofa baseline governance process for identifying, initiating and monitoring SOA-based projects. The SOA CoE group should have plans to develop, test and deploy standard templates and forms for delivering SOA-based projects. The SOA governance processes should be integrated with the overall processes that govern software development projects. Each technology project should be examined carefully to see if potential enterprise service functionality can be harvested.

Lifecycle Integration
Most project managers are well versed in the software development lifecycle and seldom cross over to the territory of service lifecycle. This lifecycle is unique; it is an integral part of the architectural design and governance. Rules need to be enforced at various stages of the service build; they should comply with the basic tenets of SOA as well as the organization-specific ones. The organization’s SDLC process will have to be aligned with this service lifecycle to ensure that SOA projects are successful.

• SDLC Integration: A SOA service implementation lifecycle will be an integral part of an organization’s Software Development Lifecycle (SDLC). However, a service lifecycle will be influenced by SOA governance policies that will be enforced as part of its migration from inception to a production state. Automated tools for service lifecycle governance are available and will immensely benefit if used as part of an organization’s SDLC processes.
• Registry/Repository Model: From a project management perspective, a SOA PM will need a Service Registry/Repository that provides an automated mechanism to locate available services both at design time and at run time. The registry will manage the lifecycle of available services and will have integration points with other change/configuration management tools. The registry/repository provides a central point to perform policy administration for the service assets. The registry repository model is vital to managing the SOA service lifecycle.

SOA adoption, as with any technology or business methodology adoption, is not a straightforward initiative. In the midst of funding uncertainties, executive disinterest and growing project costs, a SOA PM might find it difficult to run SOA projects smoothly. In parallel with pursuing project management best practices in software development, a SOA PM will have to actively incorporate SOA service governance rules so that enterprise projects start aligning with the organization’s SOA framework. It is also important for an SOA PM to recognize the long-term value imparted by a successful SOA framework adoption; he or she should be prepared to act as an evangelist purporting SOA’s benefits. A SOA PM’s true success will be measured in his or her ability to balance and communicate the project management and architectural awareness elements to project stakeholders, thereby enabling organizations to move to a desired enterprise architecture target state.