Thoughts on SOA Governance

Some advice when it comes to the creation process of (web) services for a SOA platform:

1. Only create services from core business logic/funktioality. Where is an overhead in terms of work requiered creating and mainatining web services so focus on the ones most important for your business

2. Bigger is better. Only the really big services qualify as SOA services for reuse througout a company.

3. Don't make a services per function. Again, bigger services with mony functions is easier to reuse and maintain.

4. Document each service separately from other development documentation. That makes the documentation of the service more accessible to its users and to people whating to make changes later on.

5. Create unique SLA's for each web service. The reason is that each web service may be used in different applications with different requirements.

When it comes to management of SOA I believe it's a good idea to separate creation from maintenance of services. I suggest you separate SOA governance in two parts:

1. Create services - The initial decision when you choose what will be a SOA web service and what doesn't is taken by the company's IT architecture board.

2. Change management of services - When a service is changed it may affect others, therefore a Change Control Board for SOA is necessary. That board controls any changes in webservices and they prioritize the development work.

© Copyright 2008, Tomas Elfving