SOA Governance Defined
In the yesterday's post I started writing about the definition of SOA Governance, but by the time I covered other points of view it was already too long. So I decided to leave my point of view for a separate entry. So here it goes:
I view SOA Governance as the defining characteristic of SOA. The following definitions highlight this vision:
Enterprise Service is a self-contained component delivering business functionality combined with an extendible set of non-functional, policy-driven qualities (such as security, industry/customer defined service policies, management, monitoring, and lifecycle management) which responds to requests through a well-defined, standard, published interface.
In view of this definition, SOA itself can be described as:
An architectural style that provides and facilitates evolution of enterprise IT towards a network of Enterprise Services.
And finally, the SOA Governance simply becomes:
A combination of processes, practices and tools which facilitate lifecycle of Enterprise Services and provide means for creating, communicating, enforcing and managing compliance to corporate policies regarding the non-functional service characteristics that are of importance to business today.
According to these definitions, SOA Governance is what turns Enterprise Services from digital artifacts into true business assets by allowing responsible reuse across the domains of control of SOA participants.
For me the underlined text paired up with the illustration above are the ultimate definiton of SOA Governance ans it contains both the charter and the value proposition for the entire undertaking. Let me provide an example to illustrate this point.
Imagine a multinational company Foxtrot PLC that has two business units (divisions) Alpha and Bravo. They have separate management, P&L responsibilities, IT capabilities and budgets, but operate within the same corporate entity.
At some point the leadership of Alpha decides to implement a new application on which they intend to runt their core business functions. They do so at a cost of one million dollars and being good corporate citizens they spend additional $50k to package the newly developed functionality in the form of reusable services and expose it for the benefit of the entire company.
Next year the management of Bravo realizes that they need to build a new application on which to run their core business and it so happens that it needs exactly the functionality that six months earlier has been developed, packaged, deployed and made available to them courtesy of Alpha. [Sounds like a textbook business case for SOA, isn’t it?] Bravo’s IT now has a choice: either to reuse those services or spend another million dollars (re)developing this functionality from scratch. I would stipulate that if the underlying technology is say CORBA or ungoverned (according to the above definitions) SOA, the only responsible course of action for Bravo’s management is to go and spend the money to implement the required functionality within their domain of control. And here is why: the original services were implemented and are being hosted by Alpha, so although they happen to be a 100% match from the functional point of view, Bravo has no way of knowing any of the following factors, all of which are vital in determining the usability of these services within Bravo’s business context:
- What are the expected availability, reliability, MTBF and Time To Repair?
- What security and accountability mechanisms are in place?
- Where these service implementations have been audited and found in compliance with the relevant regulations (SOX in USA, privacy in EU, HIPAA in healthcare etc.)?
- What performance levels are supported and what load levels are acceptable? Are those constant or do they vary by time of day, day or the week, season, etc?
- How service usage is metered and accounted for?
And even if Bravo’s management finds out all of this information from their counterparts in Alpha, one vital question remains: how do we know that all of this is not going to change next week (month, year)?
Hopefully this illustrates what we mean by responsible reuse, why we defined SOA Governance the way we did, and why we believe that it is the defining characteristic of SOA, that will allow it to deliver on its original promises, that many similar technologies failed to do.
Hello Alex,
It is clear from your Foxtrot scenario that you believe that the consideration of the non-functional policies are a necessary "minimum bar" that any and all services must pass to be considered an Enterprise Service.
I completely agree. I couldn't agree more. You are 100% correct.
May I suggest another bar? One a bit higher than the one you propose and one that depends entirely upon the bar you describe...
In your example, Alpha has implemented an application and Bravo has the opportunity to consider reusing services from it. Let's call this application "Tango"
Let's say that Tango performs 10 functions. Eight are in what I call the 'supporting set' in that they are fairly generic business functions that any business could get value from. The other two are not 'out of the box' but were customized from the the initial product. They are in the 'core set' of functions, and are tailored to the business processes, and differentiating value, of the Alpha division in the marketplace.
Clearly, if Bravo division wants to leverage Foxtrot, they have a strong opportunity to leverage the 'supporting set' of functions, and a far weaker opportunity to leverage the 'core set' of functions. (note, my definition of core and supporting come from here: http://blogs.msdn.com/nickmalik/archive/2008/02/15/introducing-the-double-iron-triangle-of-enterprise-architecture.aspx ).
Now, consider this. Let's say that the services authored by the Alpha division have met your definition of Enterprise Services. All of the information you request has been provided. The services have passed all of the governance checks.
We have a different bar: how USEFUL will the 'supporting set' of services be to the Bravo division if the information is structured according to assumptions that do not align with the business of Bravo?
Consider this very real possibility. Let's say that Tango is a customer relationship management (CRM) system. In the Alpha division, where most of the customers are direct, the CRM system has the names of actual customers. Those customers have purchased directly from Foxtrot enterprises. Alpha division initiates relationships with individual people.
The Bravo division sells through large retail organizations. The 'customer' for products sold in Bravo are distributors and large retailers. (Think retailers like Walmart as well as distributors like Ingram).
Here, the 'customer' is an organization and there are many divisions within each organization, and we have contacts into those divisions, and we understand the relationships in terms of the business goals of those divisions as well as the business goals of the overall customer.
Bravo division cannot use the CRM system unless Alpha division built up their understand of customer in the same information model, with a customer being a contact for himself, potentially as a 'trivial' organization.
Bravo is going to have to create new software on top of the Tango system. That is a typical case. But Bravo cannot use these services if the information model doesn't support the necessary complexity of its line of business.
Now we CAN say that this is a good example of a case where we want there to be two systems... we could say that, but should we?
Let's say that Tom is a major executive in a customer organization. He is responsible for signing a purchase agreement to distribute $200M worth of product. He also is a direct consumer, having bought one of those products for home use through the Alpha division.
The product he purchased for his home needs service. He calls customer service in the Alpha division. They answer the phone. What do they know about Tom?
Not much. To Alpha, Tom is an ordinary customer.
To Foxtrot, Tom is a power customer... very important customer. Alpha division has an opportunity to treat Tom like royalty. Do they?
Not if there are two CRM systems, they don't.
What avoids this situation? What do we need to get over that "slightly higher" bar, to make a service not only operationally viable, but fundamentally strategic?
A common information model.
If that model exists in the beginning, and if our governance extends not only to services, but to the entire of IT, where we implemented the CRM system in the Alpha division, we would be able to create services that are immediately useful to Alpha and eventually useful to Bravo.
Without that common understanding, we are stuck. SOA does not fix this.
Think about it.
Posted by Nick Malik on March 25, 2008 at 07:48 PM CDT #
Hi Nick,
thanks for a very thorough response - it's probably the most detailed and relevant I ever got. Naturally, I could not resist the temptation to answer, but my reply quickly grew past what's reasonable for a comment in both size and scope, so I decided to post it here: http://blogs.sun.com/RealSOA/entry/to_or_not_to and put these trackbacks in both comment streams.
And for the record: I agree with your agreement ;)
Posted by Alex V Maclinovsky on March 26, 2008 at 05:28 PM CDT #
Hi Alex,
unfortunately, I am not one of your fans. I’ve read a few of your posts and found a bit of mess in them.
I do not know if you are familiar with OASIS SOA RM standard and general definition of Governance but I have to say that Governance deals with policies and regulations, not with policy enforcement tools and activities. It is Management, which enforces policies and management policy tools that do the job. Governance is agnostic to its implementation.
Thus, the Aspect-Based Governance, as a term, sounds like buttery-butter because Governance is about aspects by definition. I understand, you tried to address a technical solution, probably, based on aspect-oriented programming, for implementation of the PEPs (policy enforcement points) into the code.
I do support the idea of separation of the service code and PEP but still believe that PEP implemented through the AO and Spring (which is almost the same thing) is THE mixture of concerns/responsibilities. Objects are not the model of distributed world and injection creates too close coupling between service code and policy enforcement. I prefer PEP to be remote to the code to avoid a temptation to couple them indeed.
Finally, SOA Governance is a set of domain specific policies and regulations (for business/technical architecture and technical solution development) while practices are Blueprints and processes/tools are management arsenal. Governance does not “provide means for creating, communicating, enforcing and managing compliance to corporate policies “, it is the ‘policies’ itself; all listed above are managerial activities.
Regarding the “non-functional service characteristics”/SLA, I do not think it is possible to regulate such things at the enterprise level (except for the enterprise scoped services) – particular business needs are not that clear at this level. The “non-functional service characteristics” are subject of the concrete Service Description and Service Contract (according to the standard) but Governance must specify a policy and/or regulation which requires Service Description and Service Contracts themselves as well as an inclusion of SLA into them.
Cheers,
- Michael
Posted by Michael_Poulin on June 08, 2008 at 01:26 PM CDT #
Hi Michael,
thank you for taking your time to comment on my article. I feel that your critique warranted a full-length response which I have just posted on http://blogs.sun.com/RealSOA/entry/plucked_chickens
I could not find any blog associated with you so I could not post a trackback.
Looking forward to continued discussion.
Regards,
Alex.
Posted by Alex V Maclinovsky on June 12, 2008 at 03:53 PM CDT #
Michael -- you say "...Governance deals with policies and regulations, not with policy enforcement tools and activities."
That is rather a purist view but I should point out, than when dealing with human law, the legislature creates the laws (policies), but the executive enforces the laws (policy enforcement), while the judicial branch provides rulings on the validity of such policy enforcement on a case by case basis...and all are considered branches of "government".
Posted by SunSword on July 21, 2008 at 01:13 PM CDT #
The Solaris 10 03/05 Certified software consists of the Solaris 10 03/05 Operating Environment and a subset of Solaris 10 patches which have been reviewed to ensure that their application introduces no new security vulnerabilities.
http://www.watchrolexshop.com
http://www.gamegoldme.com
http://www.cheap-lotrogold.com
http://www.globalsale.me/Aion-gold-083.aspx
http://www.cheap-gamegold.org
http://www.gamegoldvip.org
Posted by aion gold on June 25, 2009 at 12:31 AM CDT #
It was a very nice idea! Just wanna say thank you for the information you have shared. Just continue writing this kind of post. I will be your loyal reader. Thanks again.
thanks
Posted by christian laboutin on October 29, 2009 at 09:34 PM CDT #
I have received several similar emails like this one.
Posted by link of london on November 06, 2009 at 07:02 PM CST #
I really believe that these social networks will have a huge impact on what we can accomplish as groups, it'll help us be very organized and communicate.
Posted by christian louboutin on November 13, 2009 at 01:04 AM CST #
Very cool! Congrats on the pairing.
Posted by tiffany rings on November 13, 2009 at 06:49 PM CST #
yeah ,i think so
Posted by christian louboutin on November 15, 2009 at 12:58 AM CST #
I really believe that these social networks will have a huge impact on what we can accomplish as groups, it'll help us be very organized and communicate.
Posted by ed hardy hats on November 16, 2009 at 07:00 PM CST #
yeah ,i think so
Posted by christian louboutin on November 18, 2009 at 01:58 AM CST #
I have received several similar emails like this one. http://www.gifico.com
Posted by louis vuitton on November 18, 2009 at 11:47 PM CST #