o you have a governance plan?" It's not a question you want to hear while putting together a world changing Service Oriented Architecture (SOA). Governance is one of those words that can strike fear into the heart of a software architect. Visions of endless meetings and committee reviews immediately give you that queasy feeling in the pit of your stomach. Process and overhead guarantee a slow down in an already tight project plan and cause developers to spend more time drawing diagrams and writing documents than actually writing code.
As I delved into the world of SOA governance, I quickly realized that it was nothing new. Rather, it is simply a reorientation and formalization of many of the things good software architects have been doing all along. When you create software architecture, requirements exist that go beyond the immediate requests of the business users. Consistency, repeatability, testability, scalability, and manageability are built into good software architecture. SOA governance ensures that your SOA has them. Governance doesn't have to be a bad word. In fact, you may already have some of the pieces in place for your SOA governance plan and not even know it. If you've spent any time designing software, you might have already solved some of the issues.
Governance allows you to proceed in a proper, consistent, and repeatable manner. Consistency is essential when designing, building, deploying, and managing services across an organization. You've used these same principles in enterprise architectures, but now, you're using them for SOA. It's about making sure that your SOA scales beyond an initial set of services. In any software architecture, it is important to look at your process and ask yourself if it will work when the application is twice as big. How about five times as big? How about ten? How about when ten other applications are using that component you designed? The point is that adding SOA to the equation does not somehow change the fundamental best practices that you and your organization have followed all along. Let's explore some of those issues and discuss how they apply to SOA. You'll see that governance is nothing more than a fancy word for the same things good architects already perform. If you're building an SOA without considering governance, then you're only solving half the problem.
Often, governance concepts are divided into two broad categories: design-time and run-time. It helps to bring this
back to the familiar realm of traditional software architecture. You can apply a set of best practices and management principles at various phases of the software development lifecycle. Analysis, design, construction,
deployment, and maintenance still happen for an SOA and there are still best practices and management principles that
you can apply at each phase.
Roughly speaking, design-time governance covers the analysis, design, construction, and
deployment phases while run-time governance applies to operations and maintenance. Together, these two phases make up
the service lifecycle. Now, you have a taxonomy when designing an SOA. A taxonomy like this is useful because it helps
drive the right decisions at the right times.
|Table 1. Taxonomy: Taxonomies are useful in driving decisions.|
|Design-Time Governance||Planning||Establish key benefits of SOA|
|Analysis and Design||Determine which services to build|
|Publish Test Results|
|Maintenance||Deploying New Versions|
|Retiring Old Versions|
Let's dive into the issues that you need to consider within these two broad categories.