SOA Governance: Balancing Process and Agility

I have seen many companies fall into two different traps when attempting to implement SOA governance. The first trap is not having a robust enough governance model. The second trap is having so much process that it takes forever to get things done. The trick is balancing process and agility.

Not enough process creates chaos

There are a number of reasons why companies do not have a robust enough governance model. Here are a few reasons that I have seen:

• Lack complete understanding of both design time and runtime best practices

• Culture does not support standards and best practices

• Lack of funding for governance resources and tools

• Unrealistic deadlines

• Lack of executive support

Without an effective governance model, your dreams of SOA nirvana can turn into nightmares of down systems, high development costs, unmanageable production environments and unhappy customers. To get the reuse, flexibility, agility, and ease of integration that SOA promises, design time governance must ensure that services are built in a consistent manner that provides business value, meets certain performance and security requirements, is platform neutral, and does not break anything that already is deployed.

Runtime governance is crucial because of the distributed and abstract nature of SOA. A single business service may be made up of a number of components within numerous layers of the architecture. When that service fails, you better have the proper processes and tools in place to quickly identify the issues and to recover before your customers notice first.

Then there is the complexity of managing service versioning, proactively monitoring performance and security, ensuring compliance and enforcing regulatory controls, and much more.

Implementing SOA without a solid governance model is the equivalent to having an airport without a control tower. Sure, there are some very good planes and talented pilots, but without the proper planning and timely information the end results would be disastrous. So make sure you build a control tower and hire some air traffic controllers!

Too much process stifles innovation and deters agility

On the flip side of the coin are the shops that believe in process for the sake of process. They create so much process that the team gets bogged down in documentation and loses sight of the business drivers. I have seen people break down services that are so fine grained they provide little or no value and never become reused. Often, “overkill governance” or “death by process” models make the architects think like robots and simply perform whatever the documents or checklists tell them to do. Then there are the long review processes that take weeks to approve things that should take a day or two. Reasons for this type of model are:

• Viewing SOA as a technology problem instead of a business enabler

• Lack of trust and empowerment for architects and leads

• Process heavy culture used to long delivery cycles

• Lack of technical and business expertise in the leadership ranks

Finding the right balance

Every company culture and every SOA initiative is unique. There is no silver bullet or one size fits all governance model. Stack vendors, SOA implementation consulting firms and standards bodies all have well-documented methodologies for SOA governance. Pick one that best matches your culture and customize it to your company’s needs.

So how can we be agile and enforce SOA governance at the same time? One way is to shift from text heavy documentation to visual documentation. In other words, stop generating hundred-page Word documents and start creating UML models, business process models, use case diagrams and architecture diagrams. These artifacts are like blueprints for a building architect. If you were building your dream house, would you type up the specs for your house in a Word document and hand it to your builder—or would you give her blueprints? My motto has always been “focus on artifacts that add value and discard everything else.” Don’t make your staff perform steps that serve no purpose other than to satisfy a checklist. SOA governance should not be created by project managers; it is the architects that need to define it. It is all about service life cycle management and the standard n-tier processes do not apply.

Evolve governance over time

Even if you do get the right balance of process and agility, don’t try to implement it all at once. Like SOA, SOA governance is a journey that never ends. Start small and implement only the steps that are necessary at that time.

For example, if your first implementation has fifteen to twenty services, you may not need to have a robust SOA center of excellence (COE) in place, especially if the team consists of only a hand full of technicians. As the number of services increase and the number of architects and developers grow, grow your governance model accordingly. I have seen where some companies have spent over a year putting all of the proper governance processes in place. That is one year with zero value added to the business. My recommendation is to include SOA governance as a critical piece of your SOA roadmap. At the end of the day we will be judged by the business value that SOA delivers. So make sure that your SOA governance model balances SOA best practices with business agility.