SOA Infrastructure Blog

SOA Governance and Management - the Difference

Joe McKendrick's recent post comments that many analysts are now putting SOA governance and SOA management tools into a single category. He cites arguments that they are in fact very different, stating that while governance is about managing the development and the life cycle of services, management is about the technical monitoring of such. I couldn’t agree more.

Lets spell it out: in simple terms SOA governance is focused mainly on the development process, while SOA management is focused on the 'running' aspects of SOA infrastructure. Management systems must ensure that that the business services in the SOA remain reliable and live up to the expectations of the business partners, customers, suppliers, internal users and regulators.

I believe people are confused by the various contexts in which the term "SOA governance is used." In the context of a product category it is indeed confusing to lump together products with very different uses and characteristics. However, if an organisation is designing a "SOA governance strategy" then tools to aid in the development life cycle of services as well as tools to allow those services to be monitored at run-time may be required. Some organisations may describe this latter capability as "runtime governance."

Developmental governance and run-time management tools are distinct but closely related. They both aid to make SOA successful. Increasingly they work together to form a link across the entire life cycle of development and production deployment, in terms of enforcing and sharing enterprise and business policy.

So, feel free to think about the governance of your SOA in holistic, wide-ranging terms. But when it comes to thinking about which products to use, remember the distinctions. The fog of confusion will only arise if you don't.

Data Integration in SOA

As we talk to customers and prospects who are beginning to plan or enhance their SOA, we've realized that data is often overlooked in the development of a SOA infrastructure. As a matter of fact, some SOA technologists refer to it as the "day 2" problem. Why? Well, we think it might be because application and data architects may have difficulty making informed architectural decisions about it. Below is a 6 minute podcast by Ken Rugg, VP of Products for DataXtend and ObjectStore at Progress Software, that talks about the importance of data integration in SOA, why people may forget to plan for it, and some concepts related to smart data mediation.

Subscribe to our iTunes channel for more SOA Infrastructure podcasts from Progress Software.

Does your organization shape your SOA or is it the other way around?

I had the privilege to speak at the IDC Event in Buenos Aries last week on Socially Oriented Architecture and then visit some companies who have or are about to invest in SOA infrastructure - in one form or another.  While the speaking engagement was fun and there were loads of questions, it was the visits to the companies that were enlightening because the questions in Argentina are very similar to the ones that I hear in the US.

As I was visiting the various companies, I noticed how many questions were NOT about the details of the technology - in this case the ESB - but about how the deployment maps into their existing organizational structure.  This means that many people use ESBs/SOA to essentially optimize what they are doing today, and as such the benefits of this must be limited by the organization that owns and implements the SOA. What I did not hear is how SOA changed their organization(s); in fact I only heard this question asked by a handful of people in all my years working with SOA technology.

This got me thinking...  When will we really know that a successful SOA implementation is achieved?  Sure, if the SOA matches the current organization, then essentially the existing systems and processes can be optimized, but the maximum potential appears to end there.  If, however, SOA changes an organization in a bigger, more fundamental way, the chance for even greater benefits and success can be achieved.

Perhaps most successful SOA implementations come as part of an organizational shift as well as a technology shift. This obviously means that the biggest reward comes with the biggest risk, and I guess more chance of failure is also possible.

SOA What?  Does your SOA project change the world or just your immediate surroundings?  And, if the organizational scope creep happens, can you and your SOA cope? Because, lets face it, scope creep will happen...

Loose coupling versus decoupling ...

Last week Jeremy Suratt made an interesting point on the Infor Tech Talk blog.  He says that event-driven architecture (EDA) is different from traditional service-oriented architecture (SOA) in the manner in which applications are related - or not related.  In particular he says "key to event-driven SOA is the ability for decoupled, asynchronous operations."  I agree wholeheartedly with Jeremy and think this point is one of the least well understood aspects of modern enterprise architectures and the complexity inherent in large integration projects. 

There is a great book on this topic entitled "Software Fortresses" by Roger Sessions.  Though the book doesn't mention the term SOA (it largely predates SOA and the current hype), it does point to the fundamental need for decoupling of systems through asynchronous messaging.  In the book, one of the golden rules is "never let transactions cross software fortresses."  I may be misquoting this a bit ... but the essential point is that between application domains, which are referred to as fortresses, you should allow for no dependencies which might block a transaction's completion.  This rule flies in the face of what most SOA infrastructure advocates today suggest is the very purpose of this new architecture.  Aren't we to just make a Web Service call when we want to leverage components in other systems?  Roger says - just because you can doesn't mean you should.  Once you grok these simple architectural best practices and the power it brings through "isolation", you're fast on the road to understanding the difference between traditional SOA and event-driven SOA.  The latter abides by the golden rule by inverting the control of intra fortress communications - using an event publishing rather than a service invocation model.  The former decouples the applications and the latter couples them - albeit loosely through Web services. 

Perhaps this is a long winded "dah" moment for you, but for many organizations it's still something they wrestle with daily.   Progress chose this decoupled model for the design of our integration backbone, Sonic ESB.   As a result, applications integrated with Sonic ESB are naturally decoupled.  This means you can shut down any application without impact to the overall operation of the other applications.  Unlike systems that link through traditional SOA request/reply invocation... Sonic ensures that messages get through when the application comes back online.  Now this is very different from other ESBs on the market or available through open source today.  These ESBs employ a "traditional SOA" architecture - meaning that applications connected through them are coupled via service-proxy rather being decoupled through asynchronous message forwarding.  I don't want to belabor the point, but a loose coupling of Web services is an insufficient architecture for large integration projects.   If you're not familiar with this type of ESB, I encourage you to download our latest Sonic ESB 7.6 version and go through the tutorial on "batch to real-time" processing - which shows the power of event-driven integration in the form of a continuous pipeline processing example. 

Marrying Best-of-Breed Tools for SOA Governance

1+1=3: Marrying Best-of-Breed Tools for Business Process Governance
Tuesday, April 29, 2008 at 11:00 am EST
Register to participate >

Communication is the basis of any successful relationship, including the communications between business people and technologists. Bringing together BPM and SOA Governance enables business drivers to be translated quickly to SOA implementation, with full accountability, lower cost of ownership, and business-level SOA optimization.

Join David Bressler, Actional Product Evangelist, and Marc Smith, Director of Product Marketing, Lombardi Software, tomorrow, April 29th, for a live webinar entitled, 1+1=3: Marrying Best-of-Breed Tools for Business Process Governance .  Listen to what David and Marc believe are SOA best practices for company's looking to ensure consistent enforcement of policies across all teams building SOA applications.

Other upcoming SOA infrastructure webinars you may be interested in, include:

• Visibility and Tracking for Critical Applications – Optimize Application Performance and Increase Revenue
  Tuesday, May 6, 2008 at 11:00 am EST
  Presented by: Julianna Cammarano, Sr. Product Marketing Manager, Progress Software