> Archive > Issue XVII: April 2008 > A Program Management Methodology for SOA
James P. Lawler

James P. Lawler


James P. Lawler is associate professor of information systems in the Ivan G. Seidenberg School of Computer Science and Information Systems at Pace University in New York City.

He has extensive experience of 30+ years in business information strategies at Merrill Lynch and AXA-Equitable in the financial services industry.

Dr. Lawler is a published author on customer relationship management (CRM), e-Business, and Web services, including principal authorship of the current title Service-Oriented Architecture (SOA): Strategy, Methodology, and Technology (Copyright © Taylor & Francis Group, January 2008).

He can be reached at:


rss  subscribe to this author


A Program Management Methodology for SOA

Published: April 15, 2008 • SOA Magazine Issue XVII

Abstract: Program management is a key part of any successful IT project. With SOA, the management of a "program of related projects" is often required when carrying out larger adoption initiatives. But even when your SOA project revolves around just a single solution, the management of the delivery of that solution should be part of a formal program.

In this article we describe a disciplined program management methodology [REF-1] for organizations attempting SOA projects. The approaches discussed are complementary to and build upon many established project management methodologies.

As part of the research carried out for this article, we analyzed 15 Fortune 10-1000 firms, with a focus on service deployment, integration of process and services architecture, and required organizational restructuring. Our findings confirm that organizations leading SOA projects with procedural and business requirements have more success than those leading their projects with technical functionality. (The results of this study are provided at the end of this article.)

Introduction: A Methodology of Frameworks

The need for an SOA-specific program management methodology emerged from the challenges and complexities of delivering a fully deployed SOA within a service-oriented enterprise (SOE). To attain the goals of SOA within an SOE, an organization has to consider its objectives not just from a project perspective, but from the perspective of a number of continuing projects evolving in iterations and incremental department, business unit, internal firm and external firm solutions. This is simply a reflection of the enterprise-centric nature of SOA. Today's SOA projects tend to evolve, as follows:

  1. department and business unit expansion of Web services to deployment of services, based on a low maturity of SOA; to
  2. integration of process and services architecture and restructuring of organizations and staff; and to
  3. deployment and exploitation of enterprise services, based on a high maturity of SOE.

The methodology we are about to describe - formally known as the "Methodology for Enabling Service-Oriented Architecture (MESOA)" - essentially proposes an approach for attaining an evolutionary SOE. It is comprised of a series of frameworks of best practices for participating corporate, business, governance and technical staff.

The frameworks are summarized Figure 1 and will be briefly explained shortly.

Figure 1: An overview of the individual "frameworks of best practices" that comprise the program management methodology.

These frameworks all support the application of service-orientation principles and SOA, and can be further customized, as required. Furthermore, by creating these frameworks, you can establish an overarching methodology capable of evolving as its underlying projects are carried out in iterative phasing and in incremental steps. The frameworks and the projects gradually work toward establishing a true SOE.

Let's take a closer look at each framework:

Governance Framework

Governance enables the alignment of processes and services with business strategy, and oversees the evolution of a service-oriented enterprise. SOA project governance ensures that utility and business services conform to design standards part of an overarching IT strategy that is subordinate to the business strategy of the organization.

To successfully establish an SOA governance framework, both business and technical staff are often required to learn new project management methods - and - possibly unlearn old methods.

Furthermore, governance is generally centralized in that it is owned by a group of business and technical staff. This group controls the service inventory, the service catalog, and the service registry. Although the governance group may not be formally known as such, it is, in fact, recommended that they are given this status as part of the IT departmental structure. Regardless of their title, this group will usually report to senior management.

Communications Framework

Effective communications is critical to running a successful SOA program. A formal communications framework often needs to be defined by an executive, such as the chief information officer (CIO), if not the chief executive officer (CEO).

Communication fosters the harmonious collaboration of business and technical staff on an on-going basis, across multiple projects, and in support of attaining the target SOE. A key ingredient in ensuring smooth communication between various project team members is establishing a common vocabulary (or glossary) of technical and business terms.

Communications may be enabled in a dashboard designed as a balanced scorecard and displayed on a Web-based portal devoted to the SOA program. This type of dashboard may help in informing project staff and senior management staff of the status of a given project and the progress of the SOA program as a whole. The dissemination of timely information can be further accommodated by investing in a knowledge management system that allows access to practices and metrics from past SOA projects.

Product Realization Framework

Product realization relates to the analysis, design, and development stages (including related integration, testing, deployment, and implementation) of service-oriented programs. This framework can be considered the core of an SOA project management methodology. A primary goal of the product realization framework is to ensure that the emphasis of any SOA project is on the business, not the technology.

The product to be realized is either the service or a service-oriented solution comprised of composed services. The consistent application of key design practices, such as those established by service-orientation design principles and SOA design patterns, are a priority in order for this framework to guarantee that every service and service-oriented solution is delivered consistently and with future reuse and interoperability in mind.

Note that this framework can build upon the communications framework in order to allow project teams to learn from the experiences of past SOA projects.

Project Management Framework

The framework dedicated to project management represents the delivery lifecycle of SOA projects. It ensures that changes in business strategy are applied as appropriate throughout a project and that processes and services are functioning and implemented as originally planned. This framework advocates the interaction of technical staff with business staff and generally requires a "new age" project manager experienced with SOA phases and intricacies.

The project management framework also benefits from the knowledge management and dashboard metric portal systems described previously in the communications framework section. These tools can provide instant access to project and service statistics and can also be used to share critical information between project team members.

Architecture Framework

Architecture supports the conversion of functions into services and the composition of services into service-oriented solutions. Project-specific architectures often need to be managed so that they can be delivered in compliance with and as part of larger, inventory-level architectures that support pools of services. These service inventory architectures can then accumulate to form the basis of the SOE.

This framework provides practices and standards for the seamless communication of services within inventory pools and the infrastructure required to enable cross inventory communication as well. Scalability, performance, and capacity are high on the list of priorities in this framework, as are the technologies, tools and resources required to govern technology architecture implementations as part of the overall SOE platform.

Data Management Framework

Data management supports the delivery of "behaved" data services that abstract and expose legacy data without disrupting underlying legacy applications. Data management is concerned with access, availability, and the breadth and accuracy of data already residing in legacy repositories.

This framework ensures the consistency of data and the control of data redundancy, as well as fractal data replication. The database administrator(s) in charge of the existing data dictionaries and the metadata catalogs, will probably become the owners of this framework, which will entail learning about SOA (and most likely Web services and XML schemas).

The framework also supports the architecture framework's goals in relation to capacity, performance, and scalability. Often a separate data architecture needs to be defined that spans both frameworks.

Note that the data management framework can also be supported by data analysts and database developers.

Service Management Framework

By service management we are referring to the continued conformity and coordination of processes and services to the business strategy defined in the governance framework. In other words, the service management framework supports the governance framework by focusing exclusively on the services.

This framework is usually coupled with the product realization framework to ensure that requirements for new processes and new services (or revisions) are not redundant with existing processes or services. This type of cross-project coordination is critical to achieving Logic Centralization with the goal of maximizing service reusability.

Those generally involved in service management are business analysts, process and project coordinators, and enterprise architects.

Human Resource Management Framework

Human resource management enables the identification of new and revised responsibilities and roles of business and technical staff, as they pertain to SOA projects. Education is therefore a paramount concern, for both business and IT professionals, as is the change in culture brought upon by the adoption of service-orientation. Although human resource management emphasizes organizational transformation, it actually helps carry out a transformation in technology once developers, analysts, and architects apply their training with the proper mindset and an appreciation of the overarching strategic goals of SOA.

Post Implementation Framework

Post implementation enables the service and process lifecycle phases that follow product realization. This framework is focused on service availability and the technologies, tools and utilities related to general quality-of-service (QoS) requirements and service level agreements (SLA).

Factors for Enabling Frameworks

In support of enabling all of these frameworks, the program management methodology defines 57 factors, 15 of which are business, 22 procedural, and 20 technical.

  • Examples of business factors are agility, efficiency and flexibility benefits, client participation, culture of innovation, executive sponsorship and focus on improvement of process.
  • Examples of procedural factors consist of the creation of an SOA center of competency, education and training, common reference, infrastructure architecture, and process and service deployment techniques.
  • Examples of technical factors are the definition of internal SOA project domains, external SOA domains, technology platform, specialty tools, and service description and discovery standards.

These factors provide a helpful checklist for creating an SOA strategy, and are further supplemented by a set of roles and responsibilities that form the foundation of the overall program management methodology.

Methodology Analysis Findings

From January 2005 to March 2007, an analysis of fifteen Fortune 10-1000 firms was conducted, based on available metrics and interviews with key program staff.

The companies chosen were categorized based on project complexion, as follows:

  • significant deployment of Web services designed in accordance with service-orientation (5 organizations)
  • deployment of services, integration of process and services architecture, and restructuring of organizations and staff (8)
  • deployment of services as part of a service-oriented enterprise initiative (2)

These corporations belonged to the following vertical industries:

  • automobile (1)
  • banking (3)
  • energy (1)
  • health (1)
  • insurance (2)
  • manufacturing (1)
  • technology (2)
  • telecommunications (2)
  • training (1)
  • travel and leisure (1)

Each project was analyzed post facto, including an assessment of each of the aforementioned frameworks. As part of the evaluation, each framework was assigned a grade of "low", "intermediate", or "high", based on their effectiveness. This assessment revealed that business factors (70.7%) in SOA projects were more enabling than technical factors (55.3%) in the methodology frameworks. Procedural factors (68.4%) were also more enabling than technical factors. Note: These percentages are based on the following formula: Business, Procedural and Technical Factors = Number of Business, Procedural or Technical Citations / (15 Business, 22 Procedural or 20 Technical Factors x 15 Firms)

The following factors were cited repeatedly across most evaluated projects:

  • service-orientation
  • agility
  • efficiency
  • flexibility
  • reusability of assets
  • financial benefits
  • executive technology leadership

Strategic planning and focus on improvement of process were cited as drivers on the projects, and business client participation, competitiveness, market and regulatory differentials, customer demand, and culture of innovation were cited frequently as enablers of the projects. Several technology factors were also cited, but there was an overwhelming indication that these were outweighed by business factors.

Other findings, based on supplementary surveys, disclosed that of all the standard project team members, the following were considered most valuable or instrumental in successful SOA project delivery:

  • executive sponsor and/or business sponsor
  • SOA strategist
  • communications coordinator
  • SOA program coordinator
  • technical sponsor
  • infrastructure architect
  • database analyst
  • security technology specialist

Here are some final statistics that we thought were interesting:

  • Some firms (2) were considered to have achieved a high level of maturity in the deployment and exploitation of enterprise-wide, reusable services.
  • About half (8) of the organizations were at an intermediate level, experimenting with integrating process and services architectures and restructuring departments and teams accordingly.
  • Several of the firms (5) were at a low level of maturity where no consideration of service-orientation design principles was being taken into account with the development of Web services.

Almost all of the companies (13) were achieving some noticeable level of competitive equivalency (or competitive continuous improvement), while the two firms at a high maturity level were actually realizing the beginning of competitive differentiation in service solutions.

Key Lessons Learned

Finally, we'd like to share with you some of the key lessons learned from this study:

  • Close collaboration of the information technology department with the business departments and business units on business requirements can contribute to fast deployment of a service-oriented solution.
  • Collaboration and dependence of business units on a technology firm without a definition of business process requirements can contribute to slow deployment if not failure of a project.
  • Collaboration on enterprise architecture requirements can slow deployment of a service-oriented solution and may not be agreeable with business staff.
  • Enterprise governance of services based on strategic planning can ensure effective and economical reusability of services, especially if governance is centralized and funded by senior management. (However, decentralized governance seems to still be the current norm.)
  • Evolution of functionality on incremental projects can provide more visible benefits when compared to "big bang" approaches focused only on long-term benefits.
  • External projects may be more possible than internal projects because of less external political constraints.
  • External projects may be possible merely due to more defined external industry standards (compared to non-defined or immature internal standards).
  • Focus on service-orientation and design standards at the beginning of a project can help establish a proper foundation for service-oriented solutions.
  • Focus on service-orientation training of internal technical and business staff from the beginning of a project, and continuous technical training during the projects, is crucial for carrying out a successful SOA strategy.
  • Culture of innovation in the technology departments may be helpful in initiating training. Internal expertise in an SOA center of competency may also be beneficial.

Future studies can be expected to disclose further lessons, as organizations continue to expand the scope of SOA and experiment with the required restructuring of technical and business departments and staffing.


SOA continues to be a feasible and strong proposition, as evidenced by this study. Organizations need real leadership to see SOA projects through successfully, and to ensure that strategic goals are met. This provides the opportunity for any company to attain a competitive edge by focusing their investment on technology, guided by proven practices and processes. In the end, though, the excitement and hype surrounding SOA must be balanced with the prudence of a sound program management methodology.


[REF-1] "Service-Oriented Architecture (SOA): Strategy, Methodology, and Technology", James P. Lawler, Taylor & Francis Group, January 2008