Table of Contents
Title Page
Copyright Page
Dedication
Preface
Acknowledgements
Chapter 1 - The SOA Governance Imperative
THE INEVITABLE SOA TREND
INTRODUCTION TO GOVERNANCE
INTRODUCTION TO ENTERPRISE SOA GOVERNANCE
GOVERNANCE AND RESOURCE MANAGEMENT AND ALLOCATION
DO NOT CONFUSE GOVERNANCE WITH MANAGEMENT
GOVERNANCE IS ABOUT RESULTS AND APPROPRIATE USE OF RESOURCES
INFORMATION TECHNOLOGY GOVERNANCE
IT PROCESS FRAMEWORKS: ITIL, COBIT, CMMI, AND OTHERS
IT GOVERNANCE APPROACHES
WHO ARE THE SOA STAKEHOLDERS?
ADDRESSING SOA STAKEHOLDER BIASES
SOA GOVERNANCE IMPACTS IT GOVERNANCE AND ENTERPRISE ARCHITECTURE
SOA GOVERNANCE REQUIREMENTS VARY BY SOA MATURITY
SOA BILL OF RIGHTS
PURSUE THE “RIGHT” SOA STRATEGY
APPLY SOA TO THE “RIGHT” CHALLENGES
IDENTIFY AND BUILD THE “RIGHT” SERVICES
BUILD YOUR SERVICES THE “RIGHT” WAY (DESIGN-TIME GOVERNANCE)
GET YOUR SOA TOOLS PLATFORM “RIGHT”
CREATE THE “RIGHT” ORGANIZATIONAL, CULTURAL, AND BEHAVIORAL MODEL
ACHIEVE THE “RIGHT” SOA RESULTS
ESTABLISH THE “RIGHT” SOA GOVERNANCE MODEL AND POLICIES
COMMON SOA GOVERNANCE MISTAKES
RIGHT-SIZED SOA GOVERNANCE: HOW MUCH GOVERNANCE DO WE NEED?
SUMMARY
Chapter 2 - SOA Governance Reference Model
WHY AN SOA GOVERNANCE REFERENCE MODEL?
ELEMENTS OF THE SOA GOVERNANCE REFERENCE MODEL
DECOMPOSING THE SOA GOVERNANCE REFERENCE MODEL
SOA ENVIRONMENTAL DIMENSIONS
APPLYING THE SOA GOVERNANCE REFERENCE MODEL
SUMMARY
Chapter 3 - Four Tiers of SOA Governance
EXPANDED FOUR TIERS OF GOVERNANCE
TIER 1: ENTERPRISE/STRATEGIC GOVERNANCE TIER
TIER 2: SOA OPERATING MODEL GOVERNANCE TIER
TIER 3: SOA AND SERVICES DEVELOPMENT LIFECYCLE TIER
TIER 4: SOA GOVERNANCE ENABLING TECHNOLOGY TIER
SUMMARY
Chapter 4 - Organizing Your SOA Governance Toolkit
SOA GOVERNANCE ASSESSMENT TOOLS
SOA MATURITY ASSESSMENTS
GOVERNANCE MODEL DESIGN TOOLS
POLICY MODEL
GOVERNANCE AND POLICY ENFORCEMENT MODEL
GOVERNANCE EXECUTION MODEL
SUMMARY
Chapter 5 - SOA Governance Model Design Process
GOVERNANCE MODEL DESIGN PREREQUISITES
GOVERNANCE MODEL VALIDATION, REFINEMENT, AND IMPLEMENTATION PLANNING
SOA GOVERNANCE MODEL DESIGN FRAMEWORK CHECKLIST
SUMMARY
Chapter 6 - SOA Governance Goals, Principles, and Policies
OVERVIEW OF THE GOALS-PRINCIPLES-POLICY CYCLE
SOA STRATEGY AND SOA GOALS
SOA GOVERNANCE GOALS
TURNING SOA GOALS INTO SOA PRINCIPLES
DERIVING SOA GOVERNANCE PRINCIPLES
SOA GOVERNANCE POLICIES
INTRODUCTION TO POLICIES
WHAT POLICIES ARE REQUIRED?
SUGGESTED POLICY DEFINITION PROCESS
DECOUPLING POLICIES FROM SERVICES
IDENTIFYING TECHNICAL POLICIES
TOWARD AN INTEGRATED MODEL OF SOA POLICIES
POLICY TAXONOMY AND VOCABULARY
POLICY GRANULARITY
MULTI-LEVEL OR MULTI-TIERED POLICIES
VERTICAL AND HORIZONTAL POLICY ENFORCEMENT
POLICY ENFORCEMENT MODELS: MANUAL, TECHNOLOGY-ASSISTED, AND AUTOMATED
POLICY CATEGORIES DETERMINE POLICY ENFORCEMENT MECHANISMS
GOVERNANCE THREADS AND GOVERNANCE PROCESS ORCHESTRATION
BARRIERS TO A UNIFIED POLICY MODEL
INTEGRATED POLICY ENFORCEMENT MODEL
BARRIERS TO INTEGRATED POLICY ENFORCEMENT MODELS
POLICY PROVISIONING MODEL (AND PROCESS)
SOA GOALS, PRINCIPLE, AND POLICY MANAGEMENT
TRANSFORMING SOA POLICIES INTO BEHAVIORAL NORMS
SUMMARY
Chapter 7 - SOA Governance Organizational Models
FIRST THINGS FIRST: UNDERSTAND YOUR CURRENT ORGANIZATIONAL STRUCTURE
CONWAY’S LAW AND ENTERPRISE SOA GOVERNANCE
MARKS’ LAW? ORGANIZATION REFLECTS FUNDING
ORGANIZATIONAL ANALYSIS STEPS
PURPOSE OF THE SOA GOVERNANCE ORGANIZATION
GOVERNANCE ORGANIZATION PATTERNS AND BEST PRACTICES
OTHER SOA GOVERNANCE BOARD CONSIDERATIONS
SPECIFIC GOVERNANCE ORGANIZATIONAL MODELS TO CONSIDER
FEDERATED ORGANIZATIONAL MODELS
SOA GOVERNANCE FOR FEDERATED IT MODELS
BEST PRACTICE SOA GOVERNANCE ORGANIZATIONAL ROADMAP
SOA GOVERNANCE ORGANIZATIONAL MODELING STEPS
SOA GOVERNANCE ORGANIZATIONAL ROADMAP
SOA GOVERNANCE ORGANIZATIONAL MODEL SUMMARY
SOA GOVERNANCE ORGANIZATIONAL MODEL BY SOA ADOPTION PHASE
SUMMARY
Chapter 8 - SOA and Services Lifecycle Governance
LIFECYCLE GOVERNANCE MATRIX
LIFECYCLE GOVERNANCE TOOLS AND PLATFORMS
PRODUCTION VERSUS CONSUMPTION PERSPECTIVE
SERVICE REUSABILITY
GOVERNANCE GAPS IN A TYPICAL ENTERPRISE
SERVICE LIFECYCLE GOVERNANCE BEST PRACTICES
SUMMARY
Chapter 9 - SOA Governance Enabling Technology and Tools
POLICY MANAGEMENT MODEL (PMM)
POLICY ENFORCEMENT MODEL (PEM)
POLICY PROVISIONING MODEL (PPM)
INTRODUCTION TO THE GOVERNANCE TECHNICAL REFERENCE MODEL
TECHNOLOGY AND STANDARDS OF SOA GOVERNANCE AND POLICIES
DESIGN TIME
QA AND TESTING
PUBLISHING AND DISCOVERY
RUN TIME
BATTLE FOR CONTROL OF SOA TECHNOLOGY GOVERNANCE
SUMMARY
Chapter 10 - SOA Governance and Beyond
GOVERNANCE AS A STRATEGIC COMPETENCY
GOVERNANCE BEYOND POLICIES AND EDICTS
EVOLVING GOVERNANCE: POLICIES TO NORMS TO CULTURE
COMMUNITY MODELS FOR GOVERNANCE: OPEN SOURCE AS A GUIDE
GOVERNANCE OPEN SOURCE STYLE
GOVERNANCE OF THE INTERNET: THE MAC DADDY OF COMMUNITIES
INTEGRATING GOVERNANCE PARADIGMS
GOVERNANCE PERFORMANCE MANAGEMENT: A NECESSARY DISCIPLINE
CREATION OF AN ENTERPRISE GOVERNANCE EXECUTIVE
SEPARATION OF ENTERPRISE AND IT GOVERNANCE FROM THE PMO
PLAN FOR THE STRUCTURAL ACCORDION: CENTRALIZED TO DECENTRALIZED TO CENTRALIZED AGAIN
GOVERNANCE GOING FORWARD: THE WAY AHEAD
DEVELOP A UNIFIED MODEL OF POLICIES
INTEGRATED POLICY ENFORCEMENT MODELS
DEVELOPMENT OF GOVERNANCE COLLABORATION TOOLS
“THAT GOVERNANCE IS BEST THAT GOVERNS BEST WITH LEAST”
SUMMARY
Index
This book is printed on acid-free paper.
Copyright © 2008 by Eric A. Marks. All rights reserved.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey.
Published simultaneously in Canada.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400, fax 978-646-8600, or on the Web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, 201-748-6011, fax 201-748-6008, or online at http://www.wiley.com/go/permissions.
Limit of Liability/Disclaimer of Warranty: While the Publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
For general information on our other products and services, or technical support, please contact our Customer Care Department within the United States at 800-762- 2974, outside the United States at 317-572-3993, or fax 317-572-4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.
For more information about Wiley products, visit our Web site at http://www.wiley.com. Library of Congress Cataloging-in-Publication Data: Marks, Eric A. Service-oriented architecture governance for the services driven enterprise / Eric A. Marks. p. cm. Includes index.
eISBN : 978-0-470-43530-4
1. Business enterprises-Computer networks-Management. 2. Information technology-Management. I. Title. HD30.2.M374 2008 658-dc22 2008017691
Dedication
This book is dedicated to two special Fathers in my life: Nicholas Dardeno and Lyle Thomas Marks.
Preface
I began this book with a lofty goal: to clarify and simplify the concepts of Service-Oriented Architecture (SOA) governance such that organizations could understand the breadth, richness, and scope of SOA governance in the context of their entire enterprise. As SOA interest and adoption has accelerated rapidly despite still being in its infancy as a discipline, the challenges of governance have risen to the fore across the entire industry. Absent a governance model, SOA adoption will be stilted and hampered by a lack of engagement with key enterprise stakeholders in the important decisions and management processes that will help ensure business value through SOA. This exposes one of the Catch 22s of SOA—SOA governance is critical to SOA success, yet SOA governance is very challenging in and of itself, so much so that, to their peril, organizations may choose to avoid confronting the governance issue. This possibility would represent a major lost opportunity for any organization. After all, could it be that the ultimate value of implementing SOA in your enterprise is that you implement an appropriate enterprise governance model as a result? Imagine, we started out doing SOA and ended up fixing our enterprise governance along the way.
I will also confess that this has been the most challenging book project I have undertaken. Governance is a complex topic, fraught with organizational impacts far and wide depending on what you are governing and how you want to govern. And now, add to this volatile mixture the nuances of behavior and corporate culture, sociopolitical issues, incentive and reward dynamics, and funding and budgeting issues, and you can see how governance becomes a very difficult concept to wrap your arms around. For this book, I have explored a variety of governance approaches and concepts from our own federal government, from the community models of the open source community to the self-governance approaches that exemplifies the early days of the Internet. I have researched command and control structures and market-based models of resource allocation, where the dynamics of organizations evolve around the relative scarcity of resources. And I have, of course, explored the rise of IT governance and corporate governance as these disciplines assumed critical roles in the decision-making processes of both public and private corporate enterprises.
Whenever a major challenge such as governance arises, the software and tool vendors are always first responders with claims that their particular tool is the answer, the silver bullet for that particular challenge. However, with all due respect to my colleagues and friends who work for the many excellent software companies out there, the domain of enterprise SOA governance, or any form of governance for that matter, is more of a social sciences discipline—cultural anthropology, sociology, psychology, and social engineering—than it is of software tools and automation. This is most certainly the case, to be sure, in the early phases of governance in most organizations.
SOA governance has been co-opted by technologists to some extent, and this has been a disservice, leading to an over-focus on tools and technology standards and not enough emphasis on the processes and organizational models of governance. This technical emphasis has also falsely led to an overemphasis on either the design-side processes of an SOA and Services Development Lifecycle, or on the runtime aspects of the lifecycle, focusing on management of services once they are operational in a production setting. Of course, this leads to tools and technologies, which are more tangible than the social and behavioral aspects of governance, which play a much more profound and dramatic role in the success of governance.
This SDLC-focused perspective leads to underemphasis on the precursors to the delivery processes of an organization, such as portfolio management disciplines, enterprise architecture, funding and budgeting, and more. Of course, then you must consider the federated enterprise model that is very typical of large enterprises today, and the allocation of corporate roles and responsibilities aligned to and supportive of business unit-specific roles and responsibilities.
This book is also imperfect. There is no way to adequately address the nuances of governance at an operational level that would satisfy all the various approaches and perspectives on governance. While I recognize the stakeholder model for this book is broad, and I have tried to adequately represent them, there are probably another ten chapters I could have written to address all governance perspectives and stakeholders. Governance is a broad subject no matter how you focus it on a particular domain. Data governance has many of the same challenges as IT governance: Who is accountable, who “owns” the resources, who “owns” the data, and Who are the participants—the data providers and data consumers—who are stakeholders? These are fundamentally social and cultural questions, not technical questions. Enterprise governance is indeed a social science. SOA governance adds technology challenges to the social sciences, which forms a simmering brew indeed. SOA adds many technical governance challenges to an already complex task, which is why IT governance approaches are too lightweight and board-centric to address the technical, architectural and interoperability requirements of enterprise SOA governance.
As I delved into the concepts of governance, I developed a greater appreciation of why many organizations either reduce to governance boards at one extreme, or implement governance tools at the other extreme. As I dug deeper, I realized that an integrated approach to governance must find a model to enable the integration of all three governance enforcement mechanisms—boards and tools, integrated with governance processes. An overemphasis on governance boards, which is a common mistake for SOA governance, reduces the effort to an organizational design effort, which often creates overhead, generates more meetings on busy calendars, and usually does not solve the core governance needs of the enterprise. However, reducing governance to a tool, such as a repository or a service registry, or any other governance tool (or tool claiming some partial governance functionality), does a similar disservice to your enterprise. The tool-centric approach falls short because it does not accommodate the broad view of policy models, and enforcement as a combination of boards, processes and of course supporting tools. The key word is “supporting.” Tools cannot do the job in and of themselves.
With this backdrop, I began this project with the following high-level objectives:
• Develop a general model for enterprise governance. In this book, we develop a governance assessment and model design framework that will work for any enterprise governance challenge—corporate governance, IT governance, enterprise architecture governance, portfolio management, or program and project governance across your SDLC. Our definition of SOA governance can be simplified to encompass any form of governance. After all, all forms of governance have at their core ensuring appropriate stakeholder representation in critical decisions around the best use of resources to accomplish organizational goals.
• Address SOA governance from an enterprise governance perspective. Our premise is that SOA governance can only be adequately implemented in the context of other enterprise governance processes and activities. Thus, we use the Four Tiers of Enterprise Governance to establish appropriate enterprise context for your SOA governance model. If you begin SOA governance without having appropriate enterprise context, it will end up as a limited scope, bottom-up governance model without executive support and lacking enterprise alignment.
• Develop a unified approach to enterprise policies. This book explores the lack of unified industry standards for enterprise policies, and offers a conceptual policy framework for developing a unified policy model. Such a unified policy model will integrate technical policy approaches of the WS-Policy genre with corporate policies that are often codified in documents and enforced by oversight boards. Our view of governance and integrated policy enforcement requires a unified policy model.
• Develop a framework for integrated policy enforcement. Another important goal of this book is to debunk the notion that SOA governance can be accomplished using technology alone. As we discuss in Chapters 3 and 4, implementing and enforcing enterprise policies requires a multi-pronged fabric of policy enforcement. SOA governance demands an integrated policy enforcement “fabric” comprised of three types of policy enforcement mechanisms: governance boards, governance processes, and governance technology and tools. None of these is sufficient to realize an effective SOA Governance model based on definition, provisioning, and enforcement of policies. The reality is that enterprise SOA governance requires policy enforcement using governance boards, integrated with governance processes and supported by governance technology and tools.
• Build upon the Weill and Ross foundation. This book explores the complexities and nuances of IT and SOA governance that go far deeper than Peter Weill and Jeanne Ross in their excellent book IT Governance: How Top Performers Manage IT Decision Rights for Superior Results (Harvard Business School Press, 2004). I give tremendous credit to Weill and Ross for their work in establishing the foundation for much of today’s emphasis on IT governance. However, SOA governance and policy-driven governance demand and require the details and moving parts of a complete governance model to be understood. We build on Weill and Ross, and in many respects establish an operational governance model framework that will implement right-sized, tangible governance at all levels of your enterprise.
• Evolve governance from “art” to “science”: In many respects, governance seems like more of an art than a science. I believe that the artistic side of governance derives from its tendency to be viewed as a collection of boards and committees, which are constructed to provide the stakeholder representation and also to assuage political concerns in the enterprise. Often, a governance model is required to overcome inherent weaknesses in the organizational structure of an enterprise and the subsequent sociopolitical structure that evolves from the physical structure. Thus the art of governance is to create governance boards, name them, charter them, and staff them with the “right” members to create the desired sociopolitical alignment and outcomes. The science of governance we attempt to establish is through an enterprise policy model that is deployed to and enforced by an integrated enforcement model comprised of boards, processes, and tools with appropriate feedback. This science explicitly recognizes the merits of blending resource allocation models such as command hierarchies, market economies, and community models into a cohesive framework that provides maximal engagement with the entire enterprise of stakeholders, not just those who have power and authority for decisions in the enterprise.
• Establish a new conversation and language of governance. We felt that we needed to address governance from a holistic and far-reaching perspective, and address some of the industry challenges that have inhibited the progress of governance to date. These include the lack of industry standards for enterprise policies, the lack of integration of various tools and technologies, and the failure to address the concept of integrated policy enforcement using boards, processes, and tools. We hope that this book will create a new generation of thinking around enterprise governance much as Weill and Ross did with their seminal book in IT governance.
These goals are clearly aggressive and far reaching. We clearly viewed the subject of enterprise governance from a perspective that is well beyond current perspectives, and well beyond today’s technologies, tools, and industry standards. However, we feel we have pushed the discipline of governance ahead in ways that are within the grasp of organizations and within the grasp of a new generation of tools and industry standards as well. As you read the book, focus on the chapters or sections that make sense for you. The chapters are sequential in nature, so this is not necessarily a book you can jump around in. We establish the foundation concepts in Chapters 1, 2, and 3, we establish a governance modeling framework in Chapters 4, 5, and 6, and we facilitate implementation in Chapters 8 and 9. Chapter 10 serves as a future-focused chapter on gaps and challenges that need to be addressed. Below are summaries of each of the chapters.
Chapter 1 presents the landscape of governance and some of the common mistakes organizations make as they focus their efforts on governance. This chapter sets the stage by establishing a definition of enterprise SOA governance that is adaptable and applicable to any kind of governance. Remove “SOA” from the definition and you can apply our governance definition to any form of governance. The chapter finishes with common mistakes and best practices to be cognizant of with respect to SOA governance.
Chapter 2 develops an SOA Governance Reference Model to help decompose the concept of governance into bite-sized chunks that are easier to digest. In this SOA Governance Reference Model, we explore various “layers” of governance, explaining what the “moving parts” within each of the layers are. In addition, we establish the foundation for funding and budgeting as a governance activity, and we also develop the concept of “Governance Performance Management,” or the discipline of sustained enterprise governance over time.
In Chapter 3, we transform the SOA Governance Reference Model into the Four Tiers of Enterprise Governance. These tiers are then broken down into more detailed tiers to show the interplay of enterprise governance processes with SOA governance process, all of which impact enterprise architecture and SDLC delivery processes of an enterprise. This chapter also details the many processes that comprise enterprise governance by these various tiers. This enterprise governance process catalog serves as a baseline from which you can develop your own processes for governance.
Chapters 4 and 5 present a governance model assessment and design framework that is based on years of accumulated experience from the trenches of enterprise SOA governance. Chapter 4 develops the SOA governance tools and assessment framework to baseline your current enterprise SOA governance model and capabilities. Chapter 5 develops the elements of a complete enterprise SOA governance model and establishes a process for building your own enterprise SOA governance model.
Chapter 6 is a pioneering chapter focused on establishing a unified view of policies for an enterprise. This chapter exposes some of the challenges with enterprise policy enforcement, especially if you want to establish an enterprise governance framework that incorporates SOA into it. The concept of “policy” is imperfect, and we suggest a policy metamodel to help unify the concept of policies from an enterprise perspective and from an integrated policy enforcement perspective.
Chapter 7 focuses on various governance organizational models for consideration as your governance model adapts and evolves in concert with coevolving your SOA maturity. We establish a range of governance organizational models and concepts, including one we call an SOA Center of Gravity, which we think is a superior governance construct for the early phases of governance and SOA adoption.
Chapter 8 presents some concepts and discussion of SDLC governance. This chapter was contributed by Brent Carlson, a clear industry thought leader on design time and SDLC governance. This chapter develops the provider—and consumer—side aspects of services lifecycle governance, and offers some best practices for refining SDLC governance.
Chapter 9 covers the governance enabling technology and tools landscape as developed by the SOA governance reference model, and as suggested by the policy enforcement model concepts developed in Chapter 6. This chapter was spearheaded by Dennis Nadler, a colleague with tremendous experience with the broad range of SOA tools, technologies, and standards.
Chapter 10 concludes with some concepts and ideas for how we believe governance should evolve going forward. We believe that governance is an enterprise core competency that must continue to be adapted and refined through time. Governance should thus be an organization, headed by an executive position reporting to the chief executive officer or managing director of an organization.
I would like to thank the many friends and colleagues who have helped make this book a reality. I also want to thank you, the reader, in advance. I hope we have created an opportunity to advance the industry and the field of enterprise governance, as well as the discipline of SOA governance in particular. For feedback on this book, I encourage you to email me anytime at
[email protected]. No book is possible without the ideas and thinking of those before us. This book owes much to many, yet I happened to hold the proverbial pen. I hope I have done the industry a service with a book focused entirely on governance, not only on SOA governance, but a book focused on enterprise governance. Enjoy. I know I have.
Acknowledgments
This book would not have been possible without the contributions and support of many colleagues, friends, and supporters. I would like to acknowledge those who have helped make many of the concepts of this book possible. First, to my contributors, whose support for a few key chapters and reviews has been critical to this book’s completion: Brent Carlson, Dennis Nadler, and Vince Snyder.
Next, there have been a few thought leaders in the SOA community who have been critical to moving this industry forward and helping develop some of the concepts contained in this book. Thanks to the following people in alphabetical order: Alan Belisle, Bill Clarke, David Cohn, Ben Morland, Jim Schultz, Mark Stender, Umesh Vemuri, Steve Verba, Adam Vincent, and Rob Vietmeyer. These people have been on the front lines of governance innovation along with me.
Of course, I have to acknowledge Peter Weill and Jeanne Ross, whose book IT Governance: How Top Performers Manage IT Decision Rights for Superior Results established the current foundation for IT governance in the industry such that we could advance our own concepts of Enterprise SOA Governance in this book.
Finally, I have to thank my family for their support and patience as I have gone through yet another writing project. Diane, Jonathan, Jessica, your unyielding support has been my strength!
1
The SOA Governance Imperative
Since my last Service-Oriented Architecture (SOA) book, in which I dedicated an entire chapter to the topic of SOA governance, industry interest in governance has exploded. The challenges of enterprise SOA governance have moved to the foreground across the IT industry as interest in SOA has increased, and as the many SOA practitioners out there have reached the same conclusion: SOA governance is mandatory for any measure of SOA success. Understanding and implementing effective SOA governance has become a corporate imperative, and thus the topic requires the depth of coverage that this book provides. Yet, despite all the interest in the topic, governance is one of the most misunderstood, emotionally charged, and enigmatic concepts in the industry. We will attempt to address these challenges in the chapters of this book.
THE INEVITABLE SOA TREND
SOA is one of the most important trends in Information Technology today. SOA is now a top priority in most organizations. SOA is receiving all this attention because of the great potential value it offers to those who pursue it. If an organization achieves a mere fraction of the total potential value of SOA, it will be significant to that organization’s bottom line, competitive posture, and overall operational effectiveness. That is why SOA is such an important strategic initiative to pursue. SOA makes too much sense technically and financially not to implement.
I like to define SOA as a combination of a Business Model, an IT strategy, an architectural approach, and an implementation pattern, all predicated on the concept of “Services.”
In the SOA business model sense, an organization is essentially an economic engine assembled from a combination of internal and external processes and capabilities, all of which in combination enable the end-to-end execution of business processes that achieve the organization’s objectives. A for-profit corporation is created to make money for its shareholders. Thus, maximum profits are achieved by optimizing execution of business
Exhibit 1.1 Core vs. Context (Make vs. Buy vs. Rent)
transactions. If an organization can accomplish business transactions more efficiently and at a lower cost by performing them internally, it will do so. If, however, overall efficiency and cost optimization is achieved by others outside of the organization performing those transactions, the best model is outsourcing of those functions. These ideas are derived from the work of Ronald Coase, whose work on transaction theory provides a perfect foundation for SOA as a business model.1 (See Marks and Bell 2006 for a discussion of Ronald Coase and transaction theory applied to SOA and services.)2Exhibit 1.1 illustrates the concepts of core and context, and as an extension, the combination of internal and external services to optimize the overall transactional cost and efficiency of an organization.
Per our set-up discussion above, a corporation continually evaluates the relative cost of performing business transactions internally versus externally to best optimize its overall profitability. In fact, Ronald Coase would argue that the relative size of a company, and its interactions with the marketplace, are ultimately based on relative costs of business transactions. Combining the transaction theory of Ronald Coase with the core and context concepts of Geoffrey Moore give us a tremendous foundation to apply SOA concepts to.
Many small businesses outsource human resources, payroll processing, and even their Information Technology (IT) in their early startup days, instead focusing on the innovations that will help the company grow. However, as those functions become more critical to the enterprise, and as the cost of performing them is lower than in an internally-provided service, the organization may eventually insource those functions. In this manner, the service-oriented business model is one of optimizing core and context processes (per Geoffrey Moore’s book Living on the Fault Line3), and leveraging service providers as necessary to achieve the overall optimal structure of internally- and externally-provided transactions in support of the business model. This is SOA as a business model.
SOA as an IT strategy is an extension of the SOA business model. An SOA-enabled IT strategy explicitly embraces concepts of service providers and service consumers, and seeks to optimize IT services provided to the business by leveraging SOA concepts. Thus, the combination of IT services will be optimized through a combination of internally- and externally-provided services, which helps realize the profitability goals of the enterprise. The SOA IT strategy perspective also means that there is an SOA strategy, that the SOA strategy enables the SOA business model, and that it is expressed technically through a clearly defined and articulated enterprise architecture and the resulting portfolio of services that, when exposed and implemented, enable the optimal end-to-end execution of business transactions for maximizing profit. Again, this is from the perspective of a for profit enterprise.
SOA is also an architecture approach or paradigm, along with a supporting implementation pattern that realizes that architectural approach in support of the IT strategy and the SOA business model. SOA extends an organization’s enterprise architecture to include concepts of services, both logical and physical descriptions of services, as well as the required SOA infrastructure and tools, and the SOA platform for service design, quality assurance and testing, and service runtime operations.
The SOA implementation pattern includes the implementation of the SOA platform and enabling technology as well as the SOA-enabled services/ software development lifecycle (SDLC) that accommodates both service provider processes and service consumer processes of the enterprise. The SOA implementation pattern enables business applications or capabilities to be assembled through the consumption of services provided through the SOA architecture and SOA implementation patterns. The assembly of business applications from reusable services is how an organization realizes SOA value through services reuse, integration avoidance, agility through application assembly and rapid time to market, and the many other benefits of SOA.
Although the definition is technically accurate, SOA is far more than an “architecture” comprised of “services.” SOA is an architectural approach and operating model predicated on the concept of reusable “services,” or chunks of business logic or business processes that are shared by enterprise consumers. Services are message-invoked modules of business logic, process activities, chunks of data that offer value to the enterprise through the sharing and reuse of these modular services. In an SOA, services are exposed using a standards-based interface that abstracts or “hides” its technical implementation from the service consumers. When consumers access the functionality of a service, they do so via its exposed interface using message-based communications. The service interface, by virtue of its standards-based construction, offers a simple mechanism for service consumers to find or discover a service, develop a client or access mechanism to the service, and then begin consuming the service in support of a desired business outcome. The technical complexity of the implementation is hidden behind the service interface, which enables a more simplified model for building service-based applications.
SOA offers many business and IT benefits to an organization. From a business perspective, the following SOA benefits are typically expected:
• Business agility
• Reduced time to market
• Easier to do business with
• Reduced technology costs
• Right-sized business model based on core and context—can add or subtract service providers easily
From an IT perspective, the following SOA benefits are often targeted:
• Reduced software development costs
• Reduced software maintenance costs
• Reuse of services accelerates application delivery
• Reuse of services increases software quality
• Allows easier procurement of application software as services
• Allows faster IT response to business change
• Provides for graceful evolution of IT architecture, which leads to lower operating costs and total cost of ownership
SOA as a business or IT initiative presents several challenges with which organizations must contend before they can begin to realize the benefits of SOA. An SOA strategy is a critical requirement. An SOA business case should be established. An SOA reference model and SOA enterprise architecture should be created.
First and foremost of these is an actionable SOA strategy. An SOA strategy is essential to help focus and galvanize organizational efforts, identify the appropriate uses of SOA for business benefits, and to explicitly identify the business or mission outcomes desired from investing in an SOA initiative. SOA governance is mission critical to guide and manage all the “moving parts” of an SOA strategy. An enterprise SOA governance model must be informed by an actionable SOA strategy, since SOA governance helps enable the realization of your SOA strategy.
In our experience, most organizations have skipped the definition of a reasonable SOA strategy, and until recently the same organizations have bypassed developing an enterprise approach to SOA governance. However, as interest in governance intensifies, this should spur a concomitant interest in SOA strategy development as well. To set the stage for the remainder of the book, let’s explore the rise of governance as a discipline, the industry and business drivers for governance, and then translate that into the SOA-SPECIFIC instantiations of governance.
INTRODUCTION TO GOVERNANCE
SOA governance, information technology (IT) governance, and corporate governance are currently hot industry buzzwords. But what is SOA governance really? What is governance in the general sense? Governance is a simple concept to understand, yet it is made complex by vendors, management consultants, and opportunists who see the increasing emphasis on governance as a chance to augment or enhance their power base in an organization. However, governance, be it IT, SOA, or corporate, does not have to be that complicated.
Governance is the process of making correct and appropriate decisions on behalf of the stakeholders of those decisions or choices. In its corporate application, governance is the process of ensuring the best interests of a company’s or organization’s stakeholders are met through all corporate decisions, from strategy through execution. In its IT application, governance focuses on appropriate oversight and stakeholder representation for IT spending and overall IT management.
Corporate governance has become critically important as a result of corporate accounting scandals, stock option backdating and related corporate mismanagement episodes. Corporate governance is essential to apply oversight and balanced stakeholder representation for all corporate decisions relating to hiring and retaining key executives, executive compensation, strategic direction and execution. Corporate governance in publicly traded companies is the process by which firms are managed to ensure stakeholder interests are met by corporate decisions. Stakeholders include shareholders, employees, management, and even customers. The corporate governance process is normally achieved by a board of directors, who are either appointed or elected to provide objective, balanced oversight on such key issues as executive compensation and performance and corporate strategy and decision making. The board of directors normally is comprised of inside and outside directors to ensure all stakeholder interests are represented in a balanced fashion. When corporate governance fails, it is usually because of a lack of objectivity (e.g., board members appointed by the Chief Executive Officer [CEO] of the organization, or board membership weighted too heavily toward inside interests versus external shareholder interests). Most recently, corporate governance has been in the news due to the stock option backdating scandal. Corporate governance failed in this case due to a lack of decision transparency, which enabled a few executives to unilaterally or multilaterally enrich themselves by backdating stock option agreements. In the general sense, any governance will fail if stakeholders of critical decisions are not engaged in the processes of governance. This is why governance is first and foremost about engagement of critical stakeholders in key decisions of an organization.
INTRODUCTION TO ENTERPRISE SOA GOVERNANCE
What is enterprise SOA governance? SOA governance is the process of ensuring all business and IT stakeholders’ interests are served by the planning, funding, and execution of an enterprise SOA initiative. One of the early pioneers of SOA governance is the company WebLayers, located in Cambridge, Massachusetts. WebLayers defines SOA governance as follows:4
SOA governance is the ability to ensure that all of the independent (SOA) efforts (whether in the design, development, deployment, or operations of a service) come together to meet enterprise requirements.
WebLayers developed the concept of a policy-driven SOA governance approach where in effect SOA governance is predicated on developing, formalizing, and enforcing a body of SOA policies that ensure conformance to enterprise SOA business and technology goals. In my opinion, this whitepaper paved the way for the industry to understand the scope, breadth, and criticality of policies in a SOA governance framework.
However, SOA governance must be approached from an enterprise perspective and from a comprehensive and holistic viewpoint. An enterprise approach to SOA governance offers a more robust model than focusing narrowly on SOA governance. While explicitly defined SOA policies are essential to formalize and encode the enterprise requirements for SOA governance, SOA governance must also address the convergence of other forces such as organizational structure, IT and governance processes, organizational culture, behavior and political dynamics, and metrics that help measure governance. Thus, to better address the holistic nature of SOA governance, I defined SOA governance as follows:5
SOA governance refers to the organization, processes, policies, and metrics required to manage an SOA successfully. A successful SOA is one that meets defined business objectives over time. In addition, an SOA governance model establishes the behavioral rules and guidelines of the organization and participants in the SOA, from architects and developers to service consumers, service providers, and even applications and the services themselves. These behavioral rules and guidelines are established via a body of defined SOA policies. SOA policies are specific and cover business, organizational, compliance, security, and technology facets of services operating within an SOA.
SOA governance consists of the organization and processes required to guide the business success of an SOA and Web services. SOA governance defines and enforces the Web services policies that are needed to manage a SOA for business success.
While this definition is sound, I realized that a simpler definition would help clarify governance and SOA governance in particular. Therefore, we will augment the complex and detailed SOA governance definition above with a more simple and elegant definition:
SOA governance is doing the right SOA things the right way for the SOA stakeholders.
Let us break this definition down a bit more. There are three fundamental elements to this definition of SOA governance: (1) Do the right SOA things; (2) Do the right SOA things the right way; and (3) Do the right SOA things the right way for the SOA stakeholders. This definition can thus be expanded as follows:
SOA governance is the definition, implementation and ongoing execution of an SOA stakeholder decision model and accountability framework that ensures an organization is pursing an appropriate SOA strategy aligned with business goals, and is executing that strategy in accordance with guidelines and constraints defined by a body of SOA principles and policies. SOA policies are enforced via a policy enforcement model, which is realized in the form of various policy enforcement mechanisms such as governance boards and committees; governance processes, checkpoints, and reviews; and governance enabling technology and tools.
This SOA governance definition will be used for the remainder of this book.
Weill and Ross emphasize the allocation of decision rights in their book on IT governance, which is really the process of deciding what to do, how to do it, and who has a vote. Relating our definition to theirs, SOA governance is focused on setting priorities and applying SOA to the appropriate universe of business challenges; SOA governance involves implementing SOA according to company processes, architecture, and technology standards, and in alignment with business priorities; and finally, SOA governance explicitly involves the business and IT stakeholders in the decision-making process for input, review, and approval, and enforcement of key decisions relating to SOA.
The challenge is, with SOA, there are many more “right things” to perform the “right way.” SOA governance adds many more architectural and technology dimensions to the governance equation, as well as the horizontal processes of a services/software development lifecycle (SDLC) that span design time activities, quality assurance and testing, and runtime governance and operations. Thus, SOA governance includes fundamental elements of IT governance, while adding many technical issues that require integration into the governance calculus as well. As for the stakeholders, they are the same by and large as the IT stakeholders except for two fundamental differences: First, SOA done right offers a more direct business engagement model via process modeling and analysis than previous IT architecture and development paradigms offered; second, SOA requires more internal coordination across more moving parts in order to for it to deliver on its business and IT promises.
GOVERNANCE AND RESOURCE MANAGEMENT AND ALLOCATION
Many people equate governance with management and allocation of resources and assets, such as financial and budgeting decisions, human resources, and physical assets. Weill and Ross discuss governance of key categories of assets, such as:6
• Human resources and personnel
• Financial assets
• Physical assets, such as buildings, property, equipment, and similar fixed assets
• Intellectual property, such as patents, trademarks, copyrights, trademarks, brands
• Information, data, and IT assets
• Relationship assets, such as customer, supplier, and regulatory relationships
In this sense, then, governance is essential where the allocation and management of critical corporate resources impacts corporate performance. Decisions relating to the management of human resources have a direct bearing on organizational performance, as well as legal and financial implications; and thus human resources can fall under a governance process. Certainly, key executive hiring and firing decisions are made by subcommittees comprised of members of the board of directors, and those decisions often fall under the Securities and Exchange Commission (SEC) reporting requirements for public companies. The same can be said for financial management, physical assets, intellectual property, IT assets, and others.
The irony is that IT governance became important after the Internet hubris of the mid- to late-1990s and the Y2K hype when IT spending seemed to spin out of control without clear accountability to the business and without a direct connection to business performance. In other words, the rise of IT governance is a backlash against the unchecked and seemingly “reckless” IT spending of the go-go 1990s. IT governance was necessary to get control of “those IT guys” and ensure they would not be able so spend corporate funds on IT toys without appropriate checks and balances. Governance was about proper oversight, transparency, and stakeholder involvement in critical decisions, ultimately the appropriate use of IT funds on behalf of the business stakeholders.
Now, with the rise of SOA and enterprise SOA governance, the meaning and emphasis of governance varies dramatically depending on what your interests are. SOA in and of itself can mean the strategic aspects of SOA, such as strategy development, program and initiative selection, and funding and budgeting. Of course, SOA governance also entails the architectural dimensions of SOA, the services aspects of SOA, the software delivery and service development dimensions of SOA, and the operational management dimensions of services in the SOA. The following are major forms of enterprise governance that are common across industry:
• Corporate Governance. Transparency, oversight, and conformance to corporate policies and support for key corporate decisions by the board of directors.
• IT Governance. Transparency and oversight for IT funding, actual IT spending, and input into key IT decisions.
• Architecture Governance. Oversight and conformance to the enterprise architecture (EA) standards and policies of the organization, as well as input into key enterprise architecture (EA) decisions.
• SOA Governance. Definition, execution, and oversight of an SOA business and technology strategy, along with ensuring technical oversight, interoperability, and enforcement of technical policies for the architecture and services that comprise the SOA.
• Services/Software Development Lifecycle (SDLC) Governance. Governance of services from concept to requirements, design, construction, quality assurance and testing, publishing/registration, consumption, composition, orchestration, provisioning, management, maintenance, deprecation, and retirement. Lifecycle governance often is broken into design-time governance and runtime governance, separated by quality assurance and testing, service registration and publishing.
• Program Governance. Oversight of major programs, projects, and initiatives from a cost, schedule, and performance perspective, often performed by a program management office (PMO) process.
We could add data governance, portfolio management, and many other dimensions into this list. What should become clear is that “governance” means slightly different things for each of these areas. While they all generically still mean “doing the right things the right way for the stakeholders,” the right things, right ways and stakeholders are all different for these governance focal points.
However, when does the transition from “management” to “governance” occur, and for what kinds of assets or decisions? Governance is not the same as management, yet they are intrinsically related to one another as we will see below.
DO NOT CONFUSE GOVERNANCE WITH MANAGEMENT
Our definition of governance is critical to bear in mind as you begin developing your SOA governance model. Governance is often confused with management. In one sense, both are management activities. Governance provides management and oversight for critical activities or decisions where stakeholder representation is an imperative. Management is about execution of all business or organizational activities once the decision is made. Management activities usually do not require external stakeholder involvement or representation, whereas governance activities nearly always have stakeholder interests across multiple domains or constituencies involved. Both are related, and both are necessary in an SOA governance model. However, governance is essential where critical decisions require stakeholder involvement, and where those decisions have strategic or serious impact on business, IT or process performance. Do not confuse management processes with governance processes.
Governance is also focused on more critical aspects of the business, where management is focused on all aspects of the business, some of which may be the focus of governance oversight. One of the real challenges in SOA governance is determining what must be governed, and how, versus what must be managed as parts of normal IT or business management. In this book, we will separate out the domain of management from the domain of governance. When in doubt, ask if something is being governed versus managed. Good management processes can reduce the need for governance, but good governance requires good management.
GOVERNANCE IS ABOUT RESULTS AND APPROPRIATE USE OF RESOURCES
Without governance, there will be no results. Governance is focused on ensuring appropriate use of resources in an organization to drive the organizational actions that will bring about the desired results. Resources in a for-profit organization include funding, personnel, organizations, capital assets, and even intellectual property.
Often, a discussion of governance finishes with a statement roughly equivalent to the following: “Funding is the ultimate governance mechanism.” What most practitioners would agree with is that funding is a primary governance enforcement and incentive mechanism, and judicious use of funding models can facilitate the realization of an effective and transparent governance model for your organization. Governance ensures that organizational resources are allocated to important initiatives, and that they are consumed and leveraged wisely. Therefore, governance must focus on critical aspects of the business where allocation of resources, and oversight of the use of those resources, is possible. SOA governance should follow the same approach.
INFORMATION TECHNOLOGY GOVERNANCE
But how did IT governance become so popular? IT governance is not that different from corporate governance. IT governance is the process of ensuring all IT stakeholders’ best interests are being met in the planning, funding, and execution of IT for a given organization. IT governance became important when IT spending ballooned out of control in the late 1990s with the combined hype of Year 2000 and the rise of the Internet.7 As IT spending got more and more out of control with little return on the investment, business leaders realized little to no impact on their business operations. In fact, in many cases, business leaders did not have much say on how IT spending was managed or how IT dollars were allocated to various initiatives. This lack of input and transparency led to an IT backlash, where many CIOs were reined in, fired, or placed under the oversight of the finance functions. The major change resulting from all of this was the establishment of an IT governance process, where the roles, responsibilities, and decision-making processes of IT planning, funding, and execution were managed by joint business and IT leaders, many times with business leaders having much more influence over IT decisions. Much like the rise of corporate governance, IT governance helped make IT spending and decision-making processes more aligned with the business and corporate stakeholders of the organization.
IT PROCESS FRAMEWORKS: ITIL, COBIT, CMMI, AND OTHERS
Several IT governance frameworks and models have blossomed over the years, particularly to facilitate better governance, process definition, and controls for IT. Major IT governance, process, and architecture frameworks are available for implementation, such as Control Objectives for Information and related Technology (COBIT), Information Technology Infrastructure Library (ITIL), Capability Maturity Model Integration (CMMI), and The Open Group Architecture Framework (TOGAF). These are all major process definition and standardization efforts for IT best practices, governance and audit/financial controls. These frameworks all substantially overlap, are inconsistent, approach IT from differing perspectives, and require “substantial interpretation before implementation.”8 Furthermore, the United States lags in adoption of these frameworks, which is a paradox because the Unites States leads in technology innovation, and especially in the context of SOA and its related technologies and disciplines.
The adoption of ITIL best practices, CMMI certification, and other processes seem to be sub-optimized, lacking overarching governance models to manage these processes. In fact, our experience is that IT governance competencies are wide and varied, with no single organization representing enterprise-wide IT governance for all the necessary decisions required. Most often, high-performing governance models at least demonstrate control over a few key governance dimensions, such as enterprise architecture, planning and budgeting oversight, configuration management, and IT operations readiness. Organizations with baseline competencies in some form of governance will have a far easier time adopting or extending these to SOA governance, while those without a basic governance foundation will suffer mightily to add SOA governance disciplines to their enterprise.
IT GOVERNANCE APPROACHES
IT governance is still an immature discipline for the most part, despite the IT management frameworks mentioned above. One of the more insightful IT governance approaches was developed by Peter Weill and Jeanne Ross in their book IT Governance.9 Weill and Ross provide an excellent, high-level perspective of IT governance by simplifying IT governance down to five key decisions and six IT governance constructs. Weill and Ross define IT governance as follows:
IT governance: Specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT.10
Weill and Ross essentially focus IT governance on five key decisions:
1. IT Principles. Codifying the role of IT in supporting the business through fundamental IT principles that help with alignment and decision making.
2. IT Architecture. Defining enterprise integration and technology standardization requirements. (We prefer to treat this category of governance as EA, and expand the definition to include the business architecture, application architecture, technology/infrastructure architecture, and the information architecture.)
3. Infrastructure Requirements. Determining shared and enabling technology services, such as data centers, networks, telecommunications, desktops, and computing capacity, that are required by the enterprise.
4. Business Application Needs. Specifying the business need for commercial off-the-shelf or internally developed IT applications, as well as the ownership, support, and maintenance for these business applications.
5. IT Investment and Prioritization. Determining what initiatives, programs, and projects to fund and how much to spend. These decisions are made during the annual strategic planning processes, as well as during the execution year. This process also includes adding and cancelling planned IT investments based on business performance as well as emergent business needs.
In addition to focusing on key IT decisions, they also described various “archetypes” for making these decisions, which include business organizations, IT-only organizations, cross-functional organizations, and more. They list the archetypes as follows:11
• Business Monarchies. A group of business executives or individual executives (CxOs) make key IT decisions. This construct includes senior business executive committees that may or may not include the Chief Information Officer (CIO). This does not include individual IT executives making decisions independently.
• IT Monarchies. Individuals or groups of IT executives make key decisions.
• Feudal. Business unit executives, key process owners, or their delegates make key IT decisions at the business unit, regional, or process level. There is no shared IT decision making with a corporate headquarters or centralized IT function.
• Federal. A governance structure where decisions are coordinated between a centralized corporate IT organization and individual business units, strategic business units (SBUs), or geographic or regional structures.
• IT Duopoly. A governance structure that involves two parties—the IT leadership and one other organization, for example, business executives.
Weill and Ross provide a compelling and simplified overview of IT governance and some of the fundamental decisions that must be made, by whom, in order to drive better IT and business performance. However, IT governance requires a deeper level of analysis than Weill and Ross provide, and SOA governance goes far deeper, as we will see.
Weill and Ross provide an excellent basis for the key IT decisions that must be made, and describe various organizational models to help allocate IT decision rights to the enterprise stakeholders. However, they fall short in providing details of how IT policies and decisions are enforced across various processes (e.g., software development lifecycles, architecture governance processes, strategic planning, and execution processes, etc.). Furthermore, they do not develop the concept of policy or a corresponding policy enforcement model for complete IT governance coverage vertically and horizontally in an enterprise that integrates enabling technology, governance processes, and organizational constructs as a comprehensive governance policy enforcement model. Their emphasis is placed on the organizational model dimension of governance, not on the total policy enforcement context for IT policies. As such, it is an incomplete governance framework.
We will explore the many facets of SOA governance in the chapters that follow so that you will not only understand what must be governed in order to capitalize on a SOA initiative, but how to begin designing and implementing SOA governance to ensure you realize the value of SOA. The rise of SOA can be considered to be an inevitable evolution of IT based on the industry adoption of key technology standards and the continued persistence of IT integration and business agility challenges. Below we discuss the SOA governance trend and how to enable SOA governance to be successful.
WHO ARE THE SOA STAKEHOLDERS?
One of the reasons SOA governance is more complex than IT governance is that SOA governance adds many more governance requirements and processes, and therefore more governance stakeholders, into the equation. In addition, as we have emphasized, the fundamental difference between management and governance is that governance requires stakeholder representation. Governance is an oversight process that ensures appropriate stakeholder representation for key enterprise decisions. Who are the stakeholders in an SOA initiative? There are a multitude of SOA stakeholders, as Exhibit 1.2 illustrates.
There are business stakeholders, which includes business unit executives who are concerned with driving revenue, sales, and profit by servicing customers with great products and services. These stakeholders are consumers of IT resources and thus will also be consumers of SOA and services. Their interests include the desire to increase market responsiveness and customer service, while driving IT costs out of their business.
IT stakeholders include IT executives, enterprise architects, project managers, business analysts, developers, and outsourcing partners. These stakeholders represent the service provider roles in an SOA initiative. Their interests include supporting business goals, increasing effectiveness of information exploitation, increasing IT efficiency and reusing of architecture and services, and speeding delivery of products and services to customers.
Service consumers are also stakeholders in an SOA initiative, as are service providers. These two groups of stakeholders are joined by the SOA/ services development lifecycle process, which receives services requirements and demand from consumers and then produces services that can be consumed and composed into business processes and applications for end users and customers. In fact, these stakeholders are best joined by re-engineering the systems development lifecycle to accommodate SOA and services. In our
Exhibit 1.2 SOA Governance Stakeholder Landscape
experience, most SDLC processes are not well-suited to SOA or services, even in their most agile instances. Agile development does not directly translate into an SOA/Services SDLC, although an SOA/Services SDLC process will be far more agile than its precursor. It has to be.