SOA is the solution to all integration problems. Legacy apps, apps written in different eras, different platforms, languages all talk to each other through SOA. Now with SOA being the solution to everything, causes a new problem 
Everyone is using SOA, means that everyone is exposing their functionality through a service, and a typical organization has a lot of functionality, resulting in a lot of, I mean “quite” a lot of services. Keeping track of all these services is a new nightmare! Is SOA actually giving more headaches than it solves? Well, not exactly. That is where governance comes in. You need to govern your SOA, and that needs to be a key factor when your planning your SOA deployment. So, when your planning you need what’s now popularly termed “Design-Time Governance”.
Everyone is using SOA, means that everyone is exposing their functionality through a service, and a typical organization has a lot of functionality, resulting in a lot of, I mean “quite” a lot of services. Keeping track of all these services is a new nightmare! Is SOA actually giving more headaches than it solves? Well, not exactly. That is where governance comes in. You need to govern your SOA, and that needs to be a key factor when your planning your SOA deployment. So, when your planning you need what’s now popularly termed “Design-Time Governance”.
So, what do you need to look for in this space?
- Central location – To avoid the nightmare of everyone maintaining different documents, you need a central place where everyone
- Separate locations – This might appear to contradict with the point above. But this refers the ability to drop documents into separate locations that are only visible to the relevant servers. For example: If you want only want one particular server to see/access the document, you drop it to one location, but if you want a set of servers in a cluster to see the document you drop it to a different location. Furthermore, if you want your whole SOA deployment to see the document you drop it to that location.
- Versioning – Your SOA setup is done and it is working like a charm. Your job is done. Or is it? 6 months down the line, you won’t be keeping the same functionality now, would you? No, you’ll be adding more functionality and exposing new versions of the service. So you need to support versioning of your services. It’s important to that you be able to easily create new versions, maintain old versions and restore old versions if something goes wrong.
- Permissions – That’s right, now you wouldn’t want everyone to see the company’s pay roll now would you? I thought so. So you need to restrict who sees which documents and control access to.
Have these essentials incorporated into your SOA deployment and I’m sure governing your SOA deployment would be a breeze. It is important remember that proper design-time governance often decided the success (or the failure) of your SOA initiative. To easily have the ability to use all these features take a look at this fully fledged commercial product available here and it’s available free of charge.
