Comment lines: Scott Simmons: SOA governance and the prevention of service-oriented anarchy

Success with SOA, at an enterprise level, mandates adoption of a robust and disciplined governance framework. Although organizations may differ on the specific functions enabled within their governance model, a common set of capabilities needs to be addressed for SOA. This column discusses the need to build effective governance frameworks while examining customer examples.

Scott Simmons, Executive IT Architect, EMC

Scott SimmonsScott Simmons is an Executive IT Architect for the Worldwide WebSphere Integration Technical Sales Support team. Scott specializes in the design and development of integration architectures for customers and partners with a specialized focus on B2B integration solutions.


developerWorks Contributing author
        level

20 September 2006

Also available in Chinese

From the IBM WebSphere Developer Technical Journal.

The governance imperative

The early results on customer SOA adoption illustrate the promise of SOA to transform organizations through increased flexibility and adaptability. Although some of this is anecdotal, there are real metrics which evidence the increased responsiveness to business requirements and decreased costs for development that are emerging. At the same time, these findings must be reconciled with realism -- success with SOA does not "just happen." Customers finding success with SOA have a common characteristic: they have implemented a governance approach to support the design, development, deployment, and operations of an SOA solution framework.

SOA imparts extended requirements across development, deployment, and management of information technology solutions. Although the overall challenges and governance requirements of IT remain similar, the service concept provides an increased relevancy of the IT function to business. No longer is IT viewed as the function that manages a set of siloed applications; the IT portfolio of an SOA-enabled organization is founded on a set of evolving common base functions and services that are LOBs and system agnostic. As a result, SOA governance extends IT governance in many ways, for example by:

  • Changing the traditional development lifecycle arising from new design and modeling paradigms, service reuse considerations, and composite application development.

  • Extending the concept of operational management to deal with the issues of distributed deployment and management, measuring effectiveness, performance, and security at the level of the service interfaces and their underlying implementation.

  • Changing the organizational model in terms of roles and responsibilities (for example, requirements assessment, communication, service ownership, and project funding), breaking down the traditional walls between business and IT.

It can be questioned whether SOA governance mandates an existing IT governance approach, but it is clear that effective governance provides an initial framework for an SOA governance approach.


Governance approaches: The good, bad and ugly

In my job as an SOA Architect at IBM, I work with successful -- as well as unsuccessful -- implementations of SOA. Customers ask me to specify the ingredients needed for SOA success and, equally important, the factors that contribute to failure. The common answer to both of these questions comes down to governance. Although I could develop a list of SOA governance functions, I will limit my discussion to four core areas:

  • The definition and enforcement of policies and procedures to support SOA design, development, deployment, and management of services with a corresponding set of methods, techniques, and tools to support SOA and the tactical and strategic requirements of the business.

  • Establishment of a Center of Competence (or Center of Excellence), representing both IT and business to maintain and advance SOA initiatives as a shared competency across the organization.

  • Ongoing executive and business sponsorship of the SOA intent and objectives, with the mandate to support continuous communication to organizational stakeholders on the development, implementation, and management of SOA.

  • An understanding at the organizational level to tactically execute and strategically plan with SOA adoption; SOA is an incremental and evolutionary change to IT and the organization, and benefits from an iterative implementation.

It should be stated directly: SOA changes the IT mission and IT's relationship to the business.

SOA directs a different approach to IT development and management, enabling solutions to span organization business units versus a silo-based application approach that is linked to specific lines of business. SOA will not succeed at an enterprise level if organizations do not both understand and reconcile these considerations.

SOA story 1: Acme Assurance

A European customer of IBM® in the financial industry (hereafter referenced as "Acme Assurance") began to build a structured approach to integration in 1999, which has since evolved into an enterprise SOA framework. The project started as a message integration architecture to span the mainframe (IMS™, CICS® and now WebSphere®), AIX®/UNIX™, Windows®, and iSeries®. Acme Assurance uses DB2® and Oracle as the primary databases with applications (custom and off-the-shelf) running over a variety of implementations including COBOL, PL/SQL, and Java™. As part of the initial framework, they built a framework using XML to define common message formats, an in-house custom registry to categorize message flow components, and syntax (pre-WSDL) to define flow operations. Their current solution consists of over 300 common services (now migrating to WSDL) with an overall reuse rate of over 50%. More importantly, 40% of their daily transactions flow through one or more of these services generating an estimated savings of over 3 million pounds in IT development, based on reuse and quality metrics.

When I met with Acme Assurance and asked what they felt led to their success, they responded that success was related to management support they had since the onset of the work, and the incremental definition and delivery of the architecture enabled them to generate results to business quickly. Through a tight linkage with business, they define services and operational characteristics at technical and business levels via their Center of Excellence (CoE), which interacts across teams specializing in messaging, Java, XML and security. The CoE is responsible for:

  • Defining the design process, infrastructure components, and overall framework.
  • Defining and implementing the service management processes including the definition, documentation, and publishing of service.
  • Defined the process and operational implementation of measuring reuse.

The benefits of the approach at Acme Assurance can be summarized as follows:

  • Over 70 applications running in production which consume one or more services.
  • Over 40% of back-end transactions are initiated through SOA.
  • Management of over 300 reusable services in their business service directory.
  • Over 50% of business services are reused.

The success of this solution largely occurred through the investment in a strong governance approach via definition of policies and processes through their CoE. This organization continues to be successful in the wake of technology and organizational changes over the last seven years, largely due to the discipline and rigor in ensuring governance of the architecture. In addition, IT secured executive commitment early in the project, which enabled the solutions to find credibility across the organization. Finally, their ongoing work in tracking and managing the deployment and operational aspects of their solution has been outstanding. Weill and Ross (see Resources) state the ability to track and manage these aspects is the Number 1 correlation with successful governance.

SOA story 2: Worldwide Resources

Another customer followed a similar path at project initiation, but did not have the same results. This worldwide Global 100 Company (we will call "Worldwide Resources") manages operations in nearly every country in the world. I was called in to do an architectural assessment review as part of a Worldwide Resources re-evaluation of their investment in five key IT projects, intended to support a more flexible IT architecture.

On one hand, the company was successful in developing an internal organization to establish policies and procedures around the concept of integration. Unfortunately, the Competency Center became a technology think-tank and quickly became isolated from the lines of business, with overall executive sponsorship evaporating as a result. Development quickly moved to a bottom-up development effort based on tactical execution of a set of projects without defined business value. This issue was compounded by a number of sub-optimal design decisions which further stalled an ability to deliver tangible short-term successes. Two years after commencing the project, the business users were in revolt with issues centering on non-delivery of strategic capabilities, budgeting dissension surrounding integration, and overall frustration with the technical team to realize value from resource investments.

What went wrong at Worldwide Resources? The list is pretty evident from the above discussion:

  • The business case definition and involvement of business stakeholders was minimal.
  • The stakeholders did not define goals and objectives as well as cross-organizational roles and responsibilities.
  • There was lack of reuse of services and components, as each team created solutions on their own with no effective method to track reuse or define utilization.
  • There was limited adherence to standards and procedures in areas of solution definition, deployment, and QA/test procedures, resulting from a lack in governance.
  • As a critical issue, there was never a definition of funding across implementations -- organizations requesting a solution became funding points without cost recovery.

In the end, Worldwide Resources tried to replace a fragmented department-centric development process with a costly approach based a hope that a technology-based approach would correct organizational dysfunction. These issues, in tandem with the non-existence of a sound IT governance approach, led to a crisis of credibility between business and IT. I should add that they are "healthier" now, but many of the underlying organizational issues continue to plague the IT/business relationship; achieving governance and transforming IT is not as easy task.

Is Worldwide Resources a unique case? Unfortunately not. Many companies run into similar issues. The lack of a formal, well-honed governance approach plagues and continues to stall organizations in SOA adoption.

SOA story 3: Tech Equipment Inc.

Another company ("Tech Equipment Inc.") is a large, worldwide company based in the US and the market leader in their specific high technology sector. Their business problem is common to large organizations: they had over 15 different channels for business-to-business interactions with over 1000 strategic partners, ranging from FTP and EDI to Rosetta Net. The internal private processes implementing these interactions were contained in separate systems arising from acquisition and tactical solutions to support business requirements. As a result, there was no visibility at Tech Equipment Inc. into operations without reconciling the output from these varied systems. Following an extended assessment process, IBM Global Services was contracted to manage the B2B consolidation process and the development of a service oriented approach for system development.

In my view, the key in the ongoing success at Tech Equipment Inc. was the initial involvement of business sponsors to define the problem and to work with the technical team to develop a tactical approach, as well as a strategic plan for rolling out multiple iterations of the solution architecture. As a result of the development of a phased approach to development and design, and the early definition of policies and processes as part of their IT governance approach, the project continues to deliver on their promise. In addition to the identification of business objectives upfront, the project has done a remarkable job of keeping stakeholders across the company appraised on project progress, including sales, marketing, and partner management organizations. This glowing appraisal of the project does not ignore that there are both business and technical issues encountered on a periodic basis, but overall the governance of the project ensures that problems are dealt with as they occur -- not after they have multiplied. Currently, the B2B consolidation project is on schedule and has reduced the number of B2B channels by half, largely through governance and management of both the tactical and strategic plan.

SOA story 4: Exchange Unlimited

As my last customer example, I was involved in the development of an exchange hub in Asia Pacific, which I will reference as "Exchange Unlimited." The company had an existing exchange hub for conducting business-to-business transactions for "subscribing organizations" over a variety of interfaces, including FTP, Rosetta Net, and portal-based interactions. The project intention was to convert the hub to a service-oriented solution using J2EE, portal, and partner management technologies (similar to Tech Equipment Inc.).

Although the business requirements and overall context for the solution was defined at the beginning of the project, there was a lack of effective communication between the business stakeholders and the technical team. Working with the project team, we conducted multiple architectural reviews over a nine month period, and began to establish the underpinnings of a Center of Excellence approach. After three architecture reviews, it was clear that there were issues in the system design concerning performance, security, and management. The core issue was that these issues were not being communicated to business stakeholders. In addition to suffering from an exodus of experienced talent to other companies, there was a gap between business expectations and technical feasibility. This gap was exacerbated by a lack of honest communication and trust between the different functions at Exchange Unlimited, and no definition of formal processes for development and design of components and services. Even with a governance framework, the problems at Exchange Unlimited may not have been eliminated, but the problems would have surfaced more quickly and been dealt with.

So let's review the scorecard:

Table 1. SOA success criteria
CompanyDefinition of policies and proceduresCenter of Competency and communicationExecutive and business sponsorshipIncremental SOA adopttion
Acme AssuranceYESYESYESYES
Worldwide ResourcesPARTIAL
(Technical only)
YESNO
(Initially YES)
NO
Tech Equipment Inc.YESYESYESYES
Exchange UnlimitedNONONONO

Success with SOA governance

I want to provide some guidance in terms of what are the ingredients in a successful approach to SOA governance. Although there are "skunk-works" SOA investigation projects that may start with an immature or non-existent governance approach, I find that success with SOA initiatives requires an organizational commitment to governance.

In my work, I find that establishing SOA governance to support SOA often occurs through the creation of (or extension to) a Center of Excellence. In many cases, organizations utilize the experience of outside consultants in CoE creation to benefit from the cumulative best practices learned through other SOA engagements. It should be noted that establishing a CoE is not sufficient in itself for SOA success; the definition of policies, processes, and methods to support SOA are integral for governance as well. Additionally, the ongoing sponsorship of the initiative by executives and business stakeholders with active communication is a critical requirement for success. Finally, the ability to incrementally adopt SOA is a key facet to success; forcing SOA adoption as a single (or as multiple, as seen at Worldwide Resources) insurmountable project(s) is a mistake and will result in failure in nearly all cases.

Although many companies have IT governance in place and are involved with extending these frameworks to support SOA, experience shows that successful SOA governance often requires outside assistance to ensure coherence and alignment with corporate governance and IT governance frameworks.


Conclusion

Within many organizations, SOA adoption may occur organically at the department level, but as it expands to an enterprise directive, SOA requires enterprise commitment and the ongoing involvement across business and IT stakeholders. To be successful with implementing SOA, organizations must define and implement SOA governance. As stated by Eric Mark, "Service oriented culture binds the firm's vision, strategy and objectives with its SOA strategy, vision and governance model."

SOA governance requires significant planning and preparation to ensure success. In many cases, SOA governance may germinate from the SOA project team; however, it is important that business stakeholders are an active and ongoing part of the governance framework to ensure communication, and to support the overall goals and objectives of the business.

In closing, SOA governance is not optional -- it is critical to support SOA adoption and evolution. SOA governance is not a given -- organizations with existing organizational and IT governance do not have SOA governance naturally. Finally, SOA governance is not a point-in-time solution -- SOA governance requires ongoing assessment and iterative refinement to ensure SOA success. "Forewarned is forearmed" -- make the right governance decisions early to be successful with SOA.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, SOA and web services, Architecture
ArticleID=160958
ArticleTitle=Comment lines: Scott Simmons: SOA governance and the prevention of service-oriented anarchy
publish-date=09202006