The SOA Project Manager

Jiju is a project manager who takes on projects that need help. He likes a challenge put in front of him to be solved in a fixed amount of time. Because of this trait, he was fortunate enough to be called upon for completing projects in distress. Through detailed analysis and designing mitigation strategies, he is able to turn distressed projects into successful ones.

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.


Trending Articles

An Unidentified Project Risk

by Bartlett Howard

Collaboration among stakeholders who are not able to demonstrate project management standard practices prior to project launch leads to project-as-planned failures. The author outlines 16 unidentified project risk elements, each attributed to the aptitude or the attitude of project participants, along with recommended risk mitigations.

Preparing for the Exam with PMBOK Guide—Fifth Edition (Part 6): Cost Management

by Bruce Garrod

The latest in the ongoing series of articles helping you get “PMP fit” explores the often avoided Project Cost Management knowledge area. To paraphrase a well-known company, just get at it. When you have read this article and completed your studying, you may well be asking yourself why you were so concerned about it…

Topic Teasers Vol. 44: Don't Hire Heroes!

by Barbee Davis, MA, PHR, PMP, PMI-ACP

Question: Finally, we have convinced human resources that our agile team lead and our ScrumMaster need to be involved in hiring new team members. But now that we have the authority, we really don’t know what to look for in a good hire. How do we use this new power to our best advantage in choosing a fresh agile colleague?
A. Be careful what you ask for. Only human resource certified people are qualified to choose new employees for an organization. Revoke your participation rights in this process or you will be blamed when this new hire fails.
B. It’s not only the questions you ask, but what you do with the answers that will empower you to choose the best addition to your team. Create a good list of questions and know how to interpret what you hear.
C. Your product owner is the person on the management team and is more experienced in what makes a good agile team member. Ask him to sit in on candidate interviews and then defer to his superior judgment when making the final choice.
D. The person you hire must fit into the team, so assemble the entire team and have all of them work with you to interview potential candidates. Once they have agreed on a choice, they will be forced to work with the new person successfully since they have been part of the hiring decision.
Pick your answer then Test Your Knowledge!

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.



I agree that a "SOA" PM should have an understanding of the basic terms of the project and the importance of the different areas of the project (WBS, anyone?), but no more so than, say, a "Hospital" PM or a "Banking" PM or a "Cloud" PM. In this case the PM is not designing the SOA architecture nor is he writing the code, these actions are done by SMEs and the PM must trust what they're telling him. It's the PMs job to put tasks to schedule, within budget, while understanding the criticality of each task. Then the PM has to communicate with stakeholders, but most stakeholders won't understand tech-speak, so the PM is now an interpreter. As for pushing SOA through the enterprise, well, sorry, that's the CIO's job to champion the issue; the PM's job is to implement.


"In Italy for thirty years under the Borgias they had warfare, terror, murder, bloodshed - but they produced Michelangelo, Leonardo da Vinci, and the Renaissance. In Switzerland they had brotherly love, 500 years of democracy and peace, and what did that produce? The cuckoo clock."

- Orson Welles, The Third Man