In a new InfoQ article, Jean-Jacques Dubray discusses how to create an efficient Service governance organization to ensure an SOA initiative fulfills the expectations associated with it. According to Jean-Jacques, the most important aspect of such a governance organization is to ensure services are re-used appropriately. The article covers the five types of activities needed from a process perspective (Service Candidate Management, Service Change Management, Service Consumer Management, Service Roadmap Management, SOA Governance Policy Changes), as well as the technology needed to support this and the relationship to other governance activities.
Read the full article.
Read the full article.
Community comments
What is the actual SOA governance ?
by Pierre Bonnet,
One of its kind!!!
by Rohit Rai,
Re: One of its kind!!!
by Jean-Jacques Dubray,
Re: One of its kind!!!
by Michael Poulin,
What is the actual SOA governance ?
by Pierre Bonnet,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi,
The software providers confuse "Cosmetic SOA" (adding services to existing systems such as a revamping) with restructuring the existing system (Overhaul SOA). In each case, governance is very different:
"Cosmetic SOA" governance is not strategic. In essence, service agility depends on the quality of the patrimony and it should be said that there isn't much to govern. Because we don't conceive of a new system, the UML modeling is limited and meta-data very limited, except those which are already recognized in the ESB-type intermediation layers and some SLA in the exposed services.
"Overhaul SOA" governance supports modeling of the future system and should integrate UML CASE. Unfortunately, this is not the case if you hear how software vendors describe SOA governance.
Indeed, most meta-data comes from UML modeling. The remainder comes essentially from the SLA concerns. Thus, the repository described by SOA software vendors (design time governance) is not strategic because knowledge of the architecture is already fixed upstream in the UML modeling, then recaptured in the IDE. The repository would be usefull if there were perfect integration in the UML CASE and in the IDE but this is not possible: a new generation of CASE and IDE would be created! The only possible scenario would be the creation of complete connectors between all tools, each with their own repository. They also would need to be synchronized.
The challenge of SOA governance is not only the meta-data which remains a modeling concerns and interface with IDE. Real governance refers to functional and technical data management that will react to the internal behavior of each service : functional parameters, reference table filtering, multilingualism, technical infrastructure parameters, etc. This configuration time governance – oriented toward reference data and parameters management – leads us to the MDM (Master Data Management) component in the ACMS agility chain. It should be in the hands of the business team because they are affected by the services' functional configuration. The technicians (development and production) also use MDM, in this case, to value technical data, particularly configurations of the SOA platform, such as ESB, mapping and transcodification tables.
The services' execution contexts are then managed by MDM. These contexts do not only concern the services directly exposed to the user (coarse grained), and those present in the registry (SLA), but also all services (meduim and fine grained) that require execution variants be taken into consideration.
See more on my web site : www.sustainableitarchitecture.com
Pierre Bonnet
pierre.bonnet@orchestranetworks.com
One of its kind!!!
by Rohit Rai,
Your message is awaiting moderation. Thank you for participating in the discussion.
This is beautiful...
Most of the stuff I find online on SOA and SOA governance is marketing crap and I always love to read something meaningful. And for this article - Hats off!!!
Long bck I tried my hand explaining SOA Governance in short and sweet newbies language.
mytechrantings.blogspot.com/2007/07/soa-governa...
But this article here takes an A++ for newbies as well as experts it'll definitely be very useful!!!
Re: One of its kind!!!
by Jean-Jacques Dubray,
Your message is awaiting moderation. Thank you for participating in the discussion.
Rohit, Pierre:
thanks for commenting on the article. The goal of the article was to help people jump start their "Service Governance" effort. As Rohit points out, this is different from "SOA Governance". IMHO, a lot of governance organizations are formed because someone said so. Right-sizing governance is critical in the beginning because could quickly lose interest if the pipeline of services to govern is weak. The other important aspect of this paper is that it focuses on "reuse" because we need to show benefits as quickly as possible to keep expanding the SOA initiative.
This paper provides a model for Maturity Level 1 (on a scale of 4). It is agile (build only what you need) and requires only two main roles: governance lead and librarian who should really be knowledgeable about the process and the technologies and guide the council towards producing meaningful recommendations.
The distinction between "Cosmetic" and "Overhaul" is important to understand and I would never argue that this paper represents a governance organization at a level of maturity higher than 1. Again, I think the modeling efforts should be adapted to the amount of governance required.
SOA is complicated, and needs to be simplified. Right-sizing (don’t do more than you need), Prioritization (do only what you need) and Vision (align the benefits of SOA with your organization strategy) are key success factors of any SOA initiative. It is very difficult to succeed without keeping these recommendations in mind.
JJ-
Re: One of its kind!!!
by Michael Poulin,
Your message is awaiting moderation. Thank you for participating in the discussion.
The article is fundamental I do like it. However, I have a few comments on
"SOA is complicated, and needs to be simplified. Right-sizing (don’t do more than you need), Prioritization (do only what you need) and Vision (align the benefits of SOA with your organization strategy) are key success factors of any SOA initiative. It is very difficult to succeed without keeping these recommendations in mind."
1)Why SOA has to be simple? Are we considering a business as simple? What is a simple business?
2) to me, articulated Vision rule - align the benefits of SOA with your organization strategy - gets into a very strong boundle with Right-sizing (don’t do more than you need) and Prioritization (do only what you need). The question on the surface is: What do you need? If you concern with your organization strategy, your needs are strategical in addition to today needs, right? Otherwise, how SOA might be aligned with your organization strategy...
I would like to outline that traditional SW development, especially, traditional PM, which deals with requirement for today only and requests don’t do more than "required" and do only what is "required", is a bad advisor for SOA development because SOA must look into the future flexibility. SOA Governance has to set special development and execution policies to promote SOA capability of adopting to the frequently changing business market; this may be achived not necessary via "as-is" reuse but via smarter design for changes (this is what is you need in SOA in reality)
- M.P.