Articles about governance typically discuss the changing role that governance plays as companies mature in their Service-Oriented Architecture (SOA) implementations. As the enterprise architecture (EA) groups develop governance policies and procedures, and as the chief information officer (CIO) forms committees to enforce governance, application development groups begin to wonder how this will affect them. Often, application groups go into a defiant mode: "Those enterprise guys -- they don't understand my work and my priorities. I don't have the time and money to deal with this!"
This article clarifies the value of governance to application development teams. It also helps architects to understand the development groups' viewpoint and how to adjust their message to get more buy-in and less resistance.
The recent developerWorks article "Introduction to SOA governance" (see Resources for a link) talks in detail about governance. It defines governance as the means of establishing and enforcing how a group agrees to work together.
Governance is about empowerment. It provides a framework of policies and best practices that can be used to define who has the right to make what sort of IT decisions. It also helps hold people accountable for those decisions. Many analysts have drawn a clear distinction between governance and management -- and it's important to reiterate this difference.
Governance isn't about specific IT decisions; it determines the roles of the people who have the ability to make those decisions. Management, which is empowered using the governance guidelines, makes specific IT decisions.
Confused? Think about your SOA projects; governance in such projects is more complex than it is in traditional projects. Now you're building smaller services that everyone wants to (and should) reuse. Governance policies are defined to control the life cycles of those services to maximize reuse. You have to constantly monitor who is putting out a service, how it's being designed and built, who is paying for it, who is managing security, and much more.
Governance is the key to the success of your SOA project. Without governance, you can't fully realize the value of your SOA; without it, you could end up with a mess on your hands.
The value of governance may not be immediately obvious. You may not begin to appreciate the importance of governance policies until the first SOA project is complete. However, many SOA practitioners feel strongly that you should begin defining these policies up front -- even before you start the first project to build services.
Governance prevents chaos by laying out the rules and policies around service creation, service discovery, service identification and reuse, and so on. It defines the service-level agreements (SLAs) for how services should perform, so that both the consumers and the provider know their limitations and expectations. In a nutshell, governance gives the provider and the consumers the same view of the service's quality. Governance also prevents or reduces the number of redundant services and duplicated efforts, by defining the process to register and discover services across the enterprise.
Governance policies ensure that you follow standard processes and have the appropriate documentation at each step of the process. This allows for the enforcement of legal, regulatory, and other compliance issues, such as Sarbanes-Oxley.
Avoiding common mistakes in implementing governance structures
Application development teams and the centralized EA group often wrestle over the fact that the EA group comes up with processes, procedures, guidelines, and so on in a vacuum. Many times, they don't talk in detail with all the project teams to understand their unique project requirements, timelines, and business drivers. The key word in the previous sentence is all. EA groups may feel that it's sufficient to talk only to project groups that are
- Working on the largest project
- Working on the highest visibility project
- The easiest group to work with
The application teams that aren't consulted feel left out. These groups tend to provide the most resistance to the implementation of governance and as a result, can impede the overall success of the SOA initiative.
A better tactic for the EA group is to start with a small project and demonstrate the value of governance on that project. This way, they can show value quickly and then extrapolate those benefits to bigger projects and to all the other groups.
A recommendation is to split the policy makers and enforcers from these EA groups. EA groups should function as mentors. They should show application groups how to use better design guidelines and follow standard practices, and explain the governance policies to those groups. They should not fill a "policing" function of making sure application groups comply with all the governance guidelines. Enforcement of governance policies should be left to a steering committee or a governance body specifically empowered to play that role. Figure 1 shows a high-level view of how the office of the CIO can build such an organization.
Figure 1. Governance structures
The different players shown in Figure 1 must work together to ensure the success of the SOA and of individual projects. The governance review board is the policy definition group, and the enterprise architect is the glue between this group and the line-of-business IT group (application architects and developers). You can't have a successful SOA if there is a constant tug of war between these groups. The remainder of this article talks about the roles that enterprise architects, application architects, and developers need to play on a project.
Governance for enterprise architects
Suppose that governance has been defined for your organization, regardless of whether you have an organization structure, as shown in Figure 1. You as the enterprise architect may or may not have been involved in the definition of the governance policies. What's next for you?
SOA governance is a social change. The enterprise architect plays the role of the teacher or educator, not the policeman. The policing can be performed by the review board. Your role as the mentor to the application teams is to show them the value of governance; how they can benefit from the governance processes, policies, and tools in place; and how the additional work involved in following these policies can help them be more productive and deliver more business value. You must become a salesperson who tries to understand the application team's perception of pain from all these new policies and helps them work governance into their process. Be sympathetic about how they feel -- but be ready to answer the tough questions. You need to understand and appreciate the value of governance before you can help others do so.
Another job of the enterprise architect is to continually monitor the SOA governance policies. You must keep an eye on which policies are working, which aren't, and which need to be tweaked. You need to be in touch with the review board to make sure policies are amended or created as needed. You must also ensure that policies are documented clearly and that the community of application architects and developers is kept abreast of the latest policies.
The success of the governance program lies on the shoulders of the enterprise architect. If your interactions with the application architects and developers gets off on the right foot, you'll help the entire project move ahead more smoothly.
Governance for application architects
When confronted with governance, the initial reaction of most application architects is, "Big Brother is watching you." This response is justified. However, as an application architect, you need to begin to understand and internalize the value that governance brings. Governance will help you bridge the gap between people and processes to expand your focus from just applications or projects. Your role isn't just to make sure that you conform to all the governance policies and processes. You must also demonstrate how these policies are effective or ineffective and help your team understand and reap the benefits of having these policies in place. You have to ensure that the tools in place let you deliver your applications or services in a more effective manner.
Governance should save application architects from having to put these processes and controls in place for your team, which in turn enables you to focus more on business and architectural issues and help identify better business solutions and services for your project. Collaboration and communication are your buzzwords.
It's also important to remember that governance doesn't take over your job. You still play the role of architect who must design the applications or services. Governance just provides guidelines and parameters to help you with the design. It answers some questions involving requirements for scalability, availability, and more.
As a developer, governance should affect you the least. It doesn't concern you on a daily basis. Governance is more about politics than technology. Let your architect or project manager deal with the politics -- from your perspective, governance policies provide the necessary tools, best practices, and guidelines that let you work on projects and deliver solutions or services more effectively. These policies are built to try to reduce the stress in your job by ensuring consistency in the way you build and manage services.
The governance policies show you how to build your services, how you can find services built by others and available to you, and what SLAs your services need to conform to. They also give you the tools you need to do all of this. Governance reduces the unpredictability and unknowns that come with implementing SOA. So, having governance in place can reduce finger-pointing by providing a clear set of standards and policies to follow.
SOA is EA that is service based or service oriented. Issues around governance aren't new. The initial sign of governance in IT organizations was the formation of EA groups or project management offices (PMOs). These came with their own benefits and challenges. However, governance is becoming increasingly important as IT organizations move up the SOA maturity curve. As an IT team member -- architect or developer -- you don't need to fear governance; rather, you should embrace it, because it will help make your job less stressful. You can be more productive, because governance removes some of the unknowns and answers basic questions about SOA. It also helps address legal requirements, such as Sarbanes-Oxley compliance.
Governance and SOA require teamwork. At the end of the day, all the different people involved need to work together to ensure the success of the SOA and individual projects.
Learn
- The developerWorks SOA and Web services zone provides more articles on these topics.
- Read "Introduction to SOA governance" by Bobby Woolf for IBM's official definition of SOA governance and why you need it.
- Read "A case for SOA governance" by Tilak Mitra for a roadmap on how to implement governance.
- Read "Dueling SOA governance initiatives questioned" by Paul Krill to learn more about two emerging SOA governance standards.
Get products and technologies
-
Build your next development project with IBM trial software, available for download directly from developerWorks.
Discuss
- Participate in the discussion forum.
-
Participate in developerWorks blogs and get involved in the developerWorks community.
Kunal Mittal is a consultant specializing in Java technology, J2EE, and Web services technologies. He is the coauthor of, and has contributed to, several books on these topics. He works as a director within the Domestic TV IT group for Sony Pictures Entertainment, where he's responsible for the technical architecture and management of applications for that division. In his spare time he writes for IBM developerWorks, consults on SOA, and is a private pilot. For more information, visit Kunal's Web site at www.kunalmittal.com or contact him at kunal@kunalmittal.com.
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
