Andrej Koelewijn

Today, during a SOA workshop we had a discussion about governance. Most people see the need for Governance when applying SOA. Without governance your beautiful flexible architecture will soon evolve into SOA spaghetti. Hard to modify, the opposite of business agility.

One goal of SOA governance is that it should verify that Services are reusable: Shared services over specific-purpose implementations.

Governance is usually associated with an enterprise architect role: a boss in charge of architecture. Someone who will police all architectural decision.

This approach to SOA governance is what i would call explicit governance. You explicitly appoint someone to do it. There are other ways of achieving the same goal. You can often design your systems and infrastructure in such a way that it’s only possible to do the right thing. You could call this implicit governance.

An example outside the field of IT: a restaurant has a goal to serve as many customers as possible per table everynight. To achieve this you could ask all the waiters to make sure the customers order fast, and pay fast. In this case the waiters are the police that have to implement to governance. Another way of achieving the same goal would be by having hard uncomfortable chairs, play loud music, and have loud colors in the decoration of the restaurant. In this situation nobody would have to do active governance: customers would just leave soon by themselves.

When doing SOA, you can also implement implicit governance: structure your infrastructure, methodology and organisation in such a way that it becomes really hard to do the wrong thing.

Some examples:

• I often get the question if it’s ok for different services to share one database. Technically that isn’t a problem. As long as you have clearly separated services, only used by their interfaces. However, when you use just one database, you make it really easy to do the wrong thing. Developers can easily query a table part of another service. This will happen. Maybe because of deadlines, maybe because the business wants you to create a quick win. If every service has it’s own database, it will become harder for developers to cut corners.
• If you have feature teams it’s easier for development teams to implement feature specific operations in a service. They just have their own requirements to think about, and may not consider re-usability enough. You can limit this risk by having service based teams which need to service requirements from multiple other teams. When implementing SOA it makes sense to have service based teams for the generic services, and feature based teams for the higher level requirements. It will make it harder for teams to do the wrong thing.

SOA governance will always be a combination of explicit and implicit governance, but i think it’s important to think about ways to do implicit governance.

More on this topic can be found in the design of everyday things: it discusses things like affordances and limitations. How do you design a product in such a way that it can only be used in the way intended? Many of the suggestions in this book can also be applied to the design of IT systems.