Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

A Spoonful of Governance for SOA

Don’t let the term, "governance" strike fear in your heart while planning your Service Oriented Architecture. You might already practice governance and don’t even know it. Now learn how to use governance to your advantage.


advertisement
"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 GovernancePlanningEstablish key benefits of SOA
Analysis and DesignDetermine which services to build
Choose technologies
Establish Policies
Establish SLA
ConstructionStandards
TestingTest Strategy
DeploymentCataloging
Categorization
Versioning
Publish Policies
Publish SLA
Publish Test Results
Run-Time GovernanceOperationLogging
Auditing
Enforcing Policies
Enforcing SLA
MaintenanceDeploying New Versions
Retiring Old Versions
Establishing Dependencies

Let's dive into the issues that you need to consider within these two broad categories.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap