ServiceTechMag.com > Archive > Issue XXIII: October/November 2008 > Optimizing the Enterprise for SOA: From Project Management to Program Management to the Network Organization
William Perlowitz

William Perlowitz

Biography

William Perlowitz is Vice President of Advanced Technology at Apptis and is chartered to provide technology and process leadership throughout the enterprise.

He has over 20 years of dynamic technical and management leadership fielding complex, global systems including work for the Alyeska Pipeline Service Company, Department of Defense, Federal Aviation Administration, and Federal Emergency Management Agency.

Prior to joining Apptis, he was CTO of Reliable Integration Services, and had worked for United Technologies Sikorsky Aircraft and IBM's Federal Sector Division.

He has a Bachelor's Degree in Electrical Engineering, Administration & Management Science, and Economics from Carnegie-Mellon University. His current interests include the processes and measurements for delivering business strategy through technical programs and the hierarchical application of the Federal Enterprise Architecture to public sector enterprises.

He can be reached at William.Perlowitz@Apptis.com

Contributions

rss  subscribe to this author

Bookmarks



Optimizing the Enterprise for SOA:
From Project Management to Program Management to the "Network Organization"

Published: November 17, 2008 • SOA Magazine Issue XXIII
 

Abstract: SOA addresses enterprise requirements to rapidly respond to changes in business requirements, processes and policies, and continual changes to commercial technologies and implementations. SOA accomplishes this by adoption across heterogeneous enterprises and environments, enabling information sharing, rapid evolution and change to applications, increased investment reuse, and the elimination of duplicative effort. The price for attaining these advantages is that the enterprise, no matter how large or complex, must be unified and uncover, define, and persistently evolve governance (including management, security, and quality) across intricate, often politically charged, environments.

To achieve the benefits of SOA, enterprises must realize that traditional approaches to IT project management (where a project is considered in isolation, requirements are defined, and budgets are allocated) can no longer work. This article explores why the shift to treating IT as a continually evolving asset must occur. We describe why a radical change from traditional IT project management to program management and organization must be made and we conclude by introducing the concept of the "Network Organization".


Introduction

Anyone working in IT has moments when they are convinced that business people have limited cranial capacity and no appreciation whatsoever for the vast complexity of an enterprise's systems and interfaces, the difficulty of translating vague requirements into functional systems, and the comprehensive disruption caused by "minor" tweaks to specifications. Conversely, business people routinely view IT as a cost vacuum, where endless resources for hardware, software, telecommunications, and training seem to disappear only to be replaced by systems that are inflexible and only marginal incarnations of what IT "was told" was needed.

When promoting SOA, we commonly argue that the fundamental business advantages over past architectures are an emphasis on long-term strategic benefits and high return on investment (ROI). Past this marketing literature, practitioners understanding and experience have shown that benefits and high ROI are only achievable when a common vision is achieved between business and IT, and the resulting alignment is continually updated so that high quality, reusable services responsive to rapidly changing business needs are produced.

Unfortunately, enterprises continue to specify SOA requirements and create budgets as if each project required dedicated resources and interaction between projects occurred only at project boundaries. This is the natural outcome of vertically integrated enterprises whose very structure disables the ability to align strategy, projects, and benefits. The resulting contradiction between the expectation that SOA deliver enterprise resources and SOA implementation management as a series of isolated projects limits the enterprise's overall evolution and impedes the ability to respond to continuous change, increase reuse, and decrease redundancy. The first step towards resolving this contradiction is to create alignment between the business and IT.


The Insight of Alignment

Business people work in a world of uncertainty and ambiguity and most enterprises have developed using an emergent strategy; a series of unplanned responses to stimuli from within and outside of an enterprise. IT conversely requires a deliberate strategy; a formal process of analysis, design, and planning whose implementation is subject to formal baseline and control.

When an enterprise itself is a metaphor for the countless activities that people within it perform, and processes within that enterprise are abstractions of the sequencing of those activities, how can emergent and deliberate strategies be reconciled so that an enterprise can rapidly respond to unplanned changes in regulations, stakeholder demands, and market forces? SOA condenses the solution into the word "alignment."

Just as the principles of SOA evolved from Enterprise Application Integration, Business-to-Business, and Web services technologies, the principles of business and IT alignment have evolved since the foundations of A Framework for Information Systems Architecture [REF-1] were described in 1987. In the public sector, frameworks have evolved into the Federal Enterprise Architecture [REF-2], and in the private sector to variations and amalgamations of the Zachman Framework for Enterprise Architecture [REF-3], markup languages, System Development Life Cycles, and process improvement approaches.

The challenge posed by SOA is to build services that can be leveraged to manage continuous change without initiating a completely new development project every time a requirement emerges or a process is modified. Yet the concept of aligning the business and IT requirements needed to meet this challenge is difficult precisely because of the mismatch between emergent, abstract business descriptions and explicit, deliberate IT requirements. This will always be the case because the enterprise includes behavioral components of people that can never be explicitly defined; consequently business architectures will always be descriptive. This is the insight into explaining why achieving alignment between business and IT is significantly more difficult than describing the business or technology by themselves; the reconciliation between abstract business descriptions and explicit IT requirements meet at the "alignment."

Why is the strategy for the creation of and methods for maintaining business and IT alignment still debated when basic principles were established when PCs were using Intel 386 processors and the first descriptions of HyperText Markup Language were three years away? The answer is that while SOA, Enterprise Architecture, and enterprise management tools and techniques have evolved, enterprises fail to appreciate the strategic benefits of alignment and continue to fund and manage SOA development as if they were developing stand-alone tactical applications. This is predictable since enterprises are emergent and there is generally no descriptive representation of the enterprise to use as a basis for baseline or change. So how do we align an SOA to something we can not explicitly define?


Projects versus Programs

The Project Management Institute (PMI) tells us: "A project is a temporary endeavor undertaken to create a unique product, service, or result ..." and "Groups of projects sometimes constitute a program, which is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually" [REF-4]. Extrapolating these definitions, consider the resulting characteristics of project and program management:



Table 1: Characteristics of project and program management.

If we change "Project" in Table 1 to "Traditional Architecture" and "Program" to "SOA," it becomes evident that the benefits for deploying SOA in an enterprise and the reasons to select SOA over traditional architectures are exactly the same as the reasons to incorporate a program management methodology across an enterprise's projects. This suggests that in addition to just speaking of technology, we need to examine the evolution of SOA as a program if we are to fully reap SOA's business benefits of flexibility, agility, and cost efficiency.


Program Management is Not Project Management

As the pace of change accelerates and technology becomes more complex, projects will increasingly compete with each other for resources, increasingly conflict in their objectives, and create competition within the enterprise. To deliver value, a strategic organization able to respond to emergent developments is required. This means that strategic objectives must be identified and prioritized, and that each project's contribution to the objectives must be quantified if projects are to be prioritized effectively.

Program management is a discipline rooted in project management, but the concepts and tools used to affect strategic, long-term management are not nearly as mature or as widely distributed as those used to implement tactical, short-term projects. To understand the difference between the two management disciplines, it is necessary to clearly define the terms uncertainty and ambiguity.

Uncertainty is being unsettled or in doubt or dependent on chance [REF-5], that is, it is the amount or percentage by which a value may differ from the anticipated value. Ambiguity is an unclear, indefinite, or equivocal word, expression, or meaning [REF-6]. The distinction is important because uncertainty refers to variations in defined requirements while ambiguity refers to unexpressed or undefined requirements and expectations.

Whereas the primary goal of project management is to reduce the uncertainty of performance-based activities, program management is a learning process whose primary goal is to reduce ambiguity within the enterprise to support implementation of business strategies, improve flexibility, and deliver benefits. This requires a much broader range of stakeholders, skills, processes, and knowledge areas to narrow the number of preferred solutions and reach consensus across the enterprise.

Program management emphasizes the interdependencies of projects to link strategy and programs to individual projects, and it is iterative, so that opportunities are identified and the accompanying benefits to the enterprise are continually quantified and assessed. These are exactly the outcomes required to realize SOA's benefits and for IT to remain continually aligned with business needs.

If the differences between program and project management still appear superficial, consider the difference between a Work Breakdown Structure (WBS) organized to the products of the project and a Benefits Breakdown Structure (BBS) used to define the scope and needs of programs.

The WBS is one of the fundamental tools of project management and is likely familiar to most IT practitioners who have worked on complex programs. According to the PMI, a WBS is "A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables" [REF-7]. A typical WBS (with detail shown for "Activity D") might look like what is depicted in Figure 1.



Figure 1: Representative Work Breakdown Structure

A Benefits Breakdown Structure is the program management equivalent of a project WBS. The BBS is used as a tool to provide a clear understanding and statement of the expected benefits of the work to be performed. The BBS creates a hierarchy of functions from abstract enterprise needs (vision, mission, and goals, the "Why"), through active functions, to defined tasks and activities (the "How?"). The resulting BBS documents stakeholder's expected benefits in ways that they can understand and eventually achieve consensus about a collective view of enterprise objectives. An example of what a portion of a BBS might look is shown in Figure 2.



Figure 2: Representative Benefits Breakdown Structure.

Once the enterprise agrees that the BBS represents the expected benefits, qualitative Critical Success Factors (CSFs) are identified for all elements of one horizontal level for each branch of the BBS. CSFs are the actions that are required to achieve the strategy identified in the BBS. The trick to choosing CSFs is that they should be at a high enough level that they are manageable, a low enough level that they are qualitatively measurable, and the minimum number practicable so that the entire horizontal level of the BBS is covered when all CSFs are satisfied. If there are more than a dozen total CSFs identified for your BBS, then go up a level to a more abstract concept and summarize the CSFs below into a single CSF. The resulting set of CSFs becomes the criteria through which alternatives and changes can be ranked and evaluated.

Once Critical Success Factors are identified, we identify quantitative Key Performance Indicators (KPIs) that are the measures of success and each measure's acceptable levels of performance. In some instances, qualitative KPIs are also used; however, all KPIs must be accurate, feasible, measurable, relevant, sensitive to change, and timely if they are to be of value. Once KPIs are defined, the value of a program (and the projects contained therein) can be quantitatively evaluated in terms of an enterprise's business requirements.

Returning to the BBS example above, a CSF for the function "Satisfy Enterprise Computing Needs" might be "Engage End Users in Decisions." The criteria for the KPI associated with this CSF might be: At least 70% of application decisions are made with end users; at least 50% of application proposals are endorsed by the end users, and at least 20% of application proposals are made by the end users.


Develop Supporting Enterprise Structures and Culture

In addition to managing multiple projects, programs can be used to drive organizational change. Most enterprises are so product focused that even if it were possible to derive and agree upon a BBS, it is difficult to coordinate projects to achieve information sharing, application agility, reuse, and the elimination of duplicative effort. This is not particularly surprising since most enterprises lack the capabilities to evaluate projects in terms of enterprise benefits and are using resources inefficiently, resulting in the implementation of ineffective responses to emergent changes. If we are to take an increasingly strategic and holistic view across an enterprise, the enterprise must prioritize projects differently than they do today. This can only be achieved by integrating program and project management to maximize the delivery of value to the enterprise.

  • Implementation and maintenance of a consistent, objective project selection process,
  • Program Managers learning to communicate with senior management,
  • Senior management openly discussing business issues with Program Managers, and,
  • Training and development to support a program management culture.

Enterprises usually implement some form of a Program or Project Management Office (PMO) that monitors and controls project performance for multiple projects and may also develop methodologies, competencies, and training. If available, leveraging the management processes already in the PMO makes it possible to more easily create linkages between programs and projects. Whether there is an existing PMO or one needs to be established, high-quality program management processes are essential to the PMO's success; without them the PMO will become just another form of overhead or, in the worst case, an obstacle to Project Managers.

Traditional enterprise organizational structures are usually vertically integrated because they require frequent purchases of specialized inventory or services to differentiate their offerings from competitors. These organizations must purchase inventories large enough to buffer their requirements against uncertainties in the market supply of their products and services, and it is unlikely that contracting these to external organizations will occur because of the cost of finding suppliers, inventory maintenance, per-transaction costs, legal fees to establish contracts, and the supplier's ability to add premiums to costs once supply lines have been established drive total costs above what could be obtained by in-house management. The shortcoming of this vertical integration in an enterprise that needs to respond quickly to emergent developments is that inventory is both expensive to maintain and becomes rapidly obsolete.

While there have been some successes implementing program management within traditional organizational structures, enterprise value creation will be maximized if the enterprise itself could be made as flexible and adaptable as a loosely coupled, well-governed SOA. "Network Organizations" are an alternative to vertical enterprise integration that permits the enterprise to retain control and decouple the volatility associated with requirements for specialized inventory and services. Network Organizations are the business analog of SOA and treat an enterprise as a complex system, redefining its structure to optimize information sharing, enable rapid evolution and change, and minimize duplicative effort.

In a Network Organization, team accountability and empowerment are emphasized and program management becomes the natural means of business because policies, procedures and direct supervision are removed from the enterprise. This is generally considered radical because the resulting organization is dynamic and forms around products or projects and enterprise authority and rules are replaced by joint incentives, limited competition with freedom of choice to eliminate poor performers, and a common culture.

We will not attempt to replicate the extensive sociological theory and literature [REF-8] available to describe the cost, benefit, and design of Network Organizations, but the results are always that enterprise, structural, and departmental impediments to the entire enterprise working as a team are removed and replaced with "units" whose sole purpose is to create value and innovate. Units are defined by their function and their relationship to other units and units must maintain accountability, creativity, value creation, empowerment, a stakeholder's perspective, and the enterprise's vision. When this occurs, an enterprise is truly able to implement and exploit its Enterprise Architecture using program management and achieve SOA's promises of information sharing, rapid evolution and change to applications, increased investment reuse, and the elimination of duplicative effort.


Conclusion

A well governed SOA addresses enterprise requirements to more rapidly respond to changes in business requirements, processes, policies, and continual changes to commercial technologies and implementations. To integrate across heterogeneous environments, enable information sharing, enable rapid evolution and change to applications, increase reuse, and eliminate duplicative effort, the enterprise, no matter how large or complex, must act as a unified enterprise.

To achieve unification, alignment between enterprise business and IT requires the development of an Enterprise Architecture to establish communication between the abstract business descriptions and explicit IT implementations and align performance and business approaches to service components, data, and technical implementations.

Creating the alignment between business and IT however does not guarantee that an enterprise will be able to execute against that alignment. To achieve this, a shift in the management of IT from a series of projects producing deliverables to a program producing benefits and value must occur. Program management is a discipline rooted in project management, but the concepts and tools used to effect strategic, long-term management are very different from project management and require a much broader range of stakeholders, skills, processes, and knowledge areas to implement.

The vertically integrated organization of most enterprises is an outgrowth of their emergent development. Unfortunately, the division of labor in vertically integrated organizations fosters compartmentalization and competition, and is inconsistent with enterprise goals to achieve the agility required to maximize the benefits achieved from alignment and program management. By transforming to a Network Organization and prioritizing projects within a program aligned with an Enterprise Architecture, an enterprise is enabled to go beyond delivering capabilities and products and deliver the IT resources and value that fully achieve the benefits of SOA.


References

[REF-1] Zachman, J.A., A Framework for Information Systems Architecture, IBM Systems Journal, Volume 26, No. 3, 1999, download PDF

[REF-2] Federal Enterprise Architecture, http://www.whitehouse.gov/omb/egov/a-1-fea.html

[REF-3] The Zachman Institute for Framework Advancement, http://www.zifa.com

[REF-4] Organizational Project Management Maturity Model (OPM3) Knowledge Foundation, Project Management Institute, Inc., Newton Square, PA, 2003

[REF-5] Dictionary.com. WordNet® 3.0. Princeton University. http://dictionary.reference.com/browse/uncertainty (accessed: September 22, 2008).

[REF-6] Dictionary.com. Dictionary.com Unabridged (v 1.1). Random House, Inc. http://dictionary.reference.com/browse/ambiguity (accessed: September 22, 2008).

[REF-7] Practice Standard for Work Breakdown Structures, Second Edition, Project Management Institute, Inc., Newton Square, PA, 2006

[REF-8] Van Alstyne, Marshall, The State of Network Organization: A Survey in Three Frameworks, MIT Sloan School, 1997, http://ccs.mit.edu/papers/CCSWP192/CCSWP192.html