Enterprise Initiatives

We are in the process of defining and implementing our SOA governance processes. We are a medium size company so having armies of process cops is not an option, not to mention totally undesirable. At the same time, we need some level of process to ensure that we architect business services in a consistent manner and that we design for the enterprise as opposed to the old application silo approach. To make governance even more challenging, we want to deploy in cycles of 12 weeks or less. 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 using BPMN, use case diagrams, and architecture diagrams. These artifacts are like blue prints 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 him blue prints?

Another way to stay agile and still enforce governance is to tightly control scope and requirements. Users are used to asking for the sun and the moon because they typically have to wait several months to get the next release. It is similar to the way politicians load up a bill with pet projects because they know it might be their only chance to get their stuff done. We must train the user community that in an agile approach, we will deploy more frequently and in shorter time spans. This means that you don't need to get every last requirement jammed into the project because another release is coming on the heals of the current release.

But the most critical way to stay agile while having a solid governance model in place is to use processes where it makes sense. Focus on artifacts that mean something to those who have to develop software. Don't focus on documents that are never used once they get signed off. One of my favorites is the team structure document. I have seen teams waste days creating a document that nobody other then the PM uses that describes all the roles, who the team members are, what their contact info is, how meetings will be held, when they will be held, and so on. Who cares? The PM needs to know this but why waste the rest of the teams time with reviewing this stuff. I can look up people's information on the portal faster then I can even find this document. Over the years I have seen teams create documents for the sake of satisfying a check list. This is a total waste of time. SOA Governance is all about managing services and the service life cycle. SOA governance can plug into your existing methodology (if you so desire). Focus on the processes that add value and discard everything else.

For small and medium sized businesses, we must be careful not to get bogged down in process. Unlike large enterprises, we don't have the luxury of dedicating several full time employees to enforcing processes and procedures. Instead, we must put a solid framework in place and rely on our people to enforce the necessary processes. Setting up a SOA Center of Excellence and an IT Steering committee under the watchful eye of a strong executive sponsor (CIO, Chief Architect, etc.) is one way to approach it.

There is no silver bullet here. Each company must decide for themselves how much process to put in place. If they put too much process in place, they can get bogged down and never meet expectations. If they don't implement enough process, then they will eventually spiral into mass chaos and won't realize the benefits of SOA like reuse, reduced maintenance costs, and increased flexibility.