SOA Consortium Insights

SOA Consortium Hot Topics Roundtable Podcast: SOA Governance Roundtable from Brussels Meeting

At our Brussels SOA Consortium Meeting, we held our first SOA Hot Topics Roundtable on SOA Governance.   The purpose of these Hot Topics Roundtables are two-fold.  First, it provides a great opportunity for our members to discuss important topics with recognized SOA thought leaders.  Second, via podcasts, we can extend that conversation to the broader SOA community.  Obviously, this post is notification of that extended conversation.  The podcast, along with supporting slides and transcript is now available on the SOA Consortium site.

The (product-pitch free) podcast features Fill Bowen from IBM, Ed Cobb from BEA Systems, Christian Hastedt-Marckwardt from SAP and the ever pragmatic Clive Read from Cisco Systems, speaking on the following aspects of SOA Governance:

• SOA Governance Program Capabilities
• Human Factors in SOA Governance
• Best SOA Governance Practices from the Field
• Ties to IT and Corporate Governance

In addition to the invited speakers, I acted as proxy for the SOA-C's community of practice, and shared their SOA Governance Considerations.

After the opening insights, about halfway through the podcast, all meeting participants engaged in an open roundtable discussion on SOA governance.

The hour-long roundtable was packed with great discussion on funding and chargeback strategies, realistic service versioning, governance program structures, governance decision-making criteria, the role of the enterprise architect, performance management and incentives, organizational change practices, and the need to focus on process before products.

Since you can get the full story from the podcast and transcript, I'm just call out a handful of excerpts from our thought leaders' opening remarks:

Fill Bowen on an evolutionary SOA Governance Program:

"Set up your SOA governance based on the level of SOA effort. So putting a Cadillac SOA governance system in place when your SOA effort is targeted at just trying to walk seems to be a little bit of overkill. One of the things we talk about regularly is, if you’re just starting out with three or four or five services and maybe one application, you don’t necessarily even need any tools. We’ve had customers that started out with a spreadsheet that kept track of their services. But, what they had was a SOA governance framework in place so that they could add over time. As the SOA effort increased, they could add more SOA governance capability and enforcement...

Focus on process before products...In the case of SOA governance, there’s really two processes involved...you have to think about SOA governance from first establishing governance and then executing governance."

Ed Cobb on the point of SOA Governance:

"So if you think about it (governance) from the point of view, what are you trying to accomplish, what you really want to do is figure out a way to minimize the conflicts that you are going to run across in making decisions. Because you want to make decisions in a way that allows all the stakeholders involved to think the decisions are being made fairly.

You want to enable collaboration because this is (SOA) not something the IT department can do by itself. This is something that’s going to require buy-in from all the stakeholders in the business. And, you want a structure that enables people to collaborate constructively."

Christian Hastedt-Marckwardt on Governance and SOA Success:

"We all hear that there are projects with high benefits and that there are projects with high failures. And the question mark out there when I talk to customers is, how do I make sure that I’m not on the failure side. How do I make sure that I’m on the winner side? SOA governance gives you the tools or at least the mechanisms to get you more on the track on actually going for all the benefits on the winner side.

Why is that? SOA governance is the key piece that actually helps you to link the different pieces, like the business strategy linking with the IT strategy, and with your solution portfolio planning and operations. You need to have those linkages and understand the holistic piece and how they are cross linked in order to have these projects going well. Governance, with all the roles and responsibilities procedures helps to safeguard your projects while you’re on the way. A key factor in showing how well you are doing on the IT side, is how (SOA) drives re-use in the enterprise. That’s one of the key indicators, not the key benefit, but of the key indicators that SOA project is being done well, or not.

If you are doing your SOA projects well, you accelerate your learning curve internally. And there is a learning curve involved. We all are here (SOA Consortium meeting) because we understand there is a learning curve --a lot of learning to do, and we are here to share learnings and experience --to accelerate our learning curve as a community. And governance done in a holistic way also gives you the right tools, gives you the ability to actually accelerate the learning curve."

Clive Read on SOA Governance, Feedback and Operational Performance:

"Last but not least, I’ve been involved at the tail end of IT programs where, guess what, the most important thing is operations because when all the development stuff has been done and cleared out of the way, operations is the thing that gets the attention at the top of the organization. Guess what, it’s the call center meltdowns, the network falling out, it’s all that kind of stuff, and that’s what gets the CIO the sack. So they’re kind of interested in that, and therefore, you do need these feedback mechanisms so you’re absolutely tapped into operational performance. You’re actually feeding that back into the lifecycle and take accounts of those things. In an ideal world, if you’re doing that upfront already, but you sure as hell have to when it hits the fan. So that’s where you’ve got to be."

SOA-C Community of Practice on Sanctioned Non-Compliance:

"...governance programs and processes have to anticipate and plan for valid deviations from standards, right. It’s always going to happen. It might be because of project timelines, quality service requirements, quality of protection requirements, and as we discussed earlier, it might be performance. So, you need to include in your governance program processes for variance and then processes for bringing whatever it is that varies back into the architecture. How are you going to do that? Especially with a timeline based variance. Perhaps you need to figure out at the time of the variance how to move forward. You agree to bring and the deliverable up to standards within the next three months, within the next release cycle."

Again, you can find the podcast here.  Let us know what you think.  At our September meeting, we'll be taking on the hot topic of SOA and BPM. 

Three Definitions of SOA? How about one?

My good friend (and OMG Board member) Jan Popkin of TeleLogic has a good piece in Software Development Times (SDTimes) entitled "Three Definitions of SOA".  I generally agree with Jan on most issues (probably as he's right so often) so I was surprised at my negative feelings toward the article.

In short, Jan outlines these three definitions:

• SOA as a technology. Focused on the OASIS SOA Reference Model, this definition is essentially "the technology necessary to connect distributed applications."
• SOA as an architectural principle.  Focused on the OMG's concept of SOA as a way for IT to solve business issues and OMG's ongoing standardization work in business modeling, this definition comes down to "an architectural style for a community of providers and consumers of services to achieve mutual value."
• SOA as an enterprise strategy.  Focused on the concepts of Enterprise Architecture, this definition focuses on what we in the SOA Consortium would most recognize as SOA: a business strategy to achieve business agility.

My biggest problem is with the first definition -- SOA as a technology is Yet Another Integration Technology, and as such, we don't need it.  In my career so far, I've seen far too many "integration technologies" (DCE, CORBA, Web Services, COM, DCOM, .NET, JINI all come to mind) and not enough "integration strategies".  If we as an industry allow SOA to mean Yet Another Integration Technology, we doom ourselves to yet another level of integration middleware, and yet more maintenance hassles caused by the brand-new legacy systems we are installing today.  Please don't let it be so!

SOA is an enterprise strategy, certainly.  Here at the SOA Consortium, the story on which we have focused is that while the IT department is listening now to the value proposition of Service Oriented Architecture, we need to leverage their need to impact corporate strategy, revenue and profit to convince the business leaders, business analysts and project managers of the value of designing the business around processes that can be precisely defined, carefully captured, found again and optimized.  And in order to do that, we must organize the supporting IT infrastructure around the SOA architectural principle -- regardless of the specific integration technology (or technologies) that are eventually deployed.

So I'll spring for the latter two definitions, rolled into one -- SOA is an enterprise strategy based on an architectural principle.  But don't sell me another technology, I've already got too many.

SOA Practitioner'€™s Forum: Service Version Management or Mayhem?

In our Community of Practice's Open Forum, Brenda Michelson shared some comments from CIOs and CTOs on managing SOA environments:

During our February Executive Summits, the CIOs and CTOs expressed concern that there aren't ITIL-like practices and guidelines for managing a SOA based environment.

A specific question was "How many versions of a service should be in production at once?"€ The group stated that "It was naive to believe only one version of a service would be live". But, how many is too many?

Brenda then asked our COP:

What are SOA-C members doing in their organizations? How many versions are active? How many versions are manageable? What are your version limits and practices?

I agree that service versioning is inevitable and must be managed. In this post I'€™d like to share my response to Brenda'€™s question. I focused on "€œwhen and why" to version. At the end, I have some questions for the broader SOA community.

Before I continue, I should introduce myself. I am Surekha Durvasula, Enterprise Architecture Manager for Kohl'€™s and the Leader of the SOA-C'€™s Executing Business-Driven SOA Strategy.

My Service Versioning Perspective

In the broadest sense, there may be two key reasons to support business service versioning.

A) Consumer SLA/ QoS driven

B) Business functionality or business policy driven

Consumer SLA driven service versioning could be supported by just altering the values on the envelope. The envelope level metadata can be used to direct a call from the mediation layer (read ESB) to the appropriate service provider end point. Here the consumer can provide the values for the SLA metadata or a metadata lookup activity for the service consumer can be performed by the mediation layer.

Examples of the Consumer SLAs could be greater audit, more stringent response times, tighter security needs etc. Here the service interface layer may not have to be altered and so the consumer may not be affected. However, the service provider implementation layer may have to support multiple service implementation end points that are in keeping with the QoS requirements.

Business Functionality driven service versions are typically impacted by service interface and/ or the payload level changes.

Here the consumer has to "know" how to construct the new payload and may need to "indicate" to the mediation layer the right business service to invoke. Given this behavior change on the consumer side, service versioning becomes a necessity to insulate existing consumers. One way of limiting the number of service versions being supported may be to leverage the service mediation layer to populate default values on newer payload parameters or to perform payload transformation. The mediation layer can invoke utilities/interceptors on behalf of the service consumer to absorb the impact of changes to the interface or the payload. However, in scenarios where no valid default values are available or else if new consumer context information is required on the payload then a new version of the service would need to be published, thus requiring the enterprise to have to support multiple service versions.

Other considerations for supporting service versioning include management and monitoring costs, efficient use of IT resources, regulatory and central governance policies and the stringency of the contract agreements with the consumers.

Service Versioning Discussion Questions

1. How many versions of a service should be "live" at any given time? How many versions are too many?

2. Do you use the service mediation layer to achieve backward compatibility?

3. Where do you determine the service version - the mediation layer, the service consumer or a service provider?

4. Do you have governance models and policies around transitioning existing consumers to new versions? Who is responsible for executing that transition?

5. What is the most graceful way of "retiring" or "decommissioning" a service?

Please share your comments on this post, your own blog with a trackback, or via email to blog at soa-consortium dot org

Audio available from the Gartner Summit

Back in June I reported on a couple of SOA Consortium sessions at events in California and Tennessee.  In particular, there was a great panel at the Gartner Application Architecture, Development & Integration Summit in Nashville, featuring several active SOA Consortium members talking about their SOA implementation experiences.

Thanks to the helpful folks at Gartner Events, we are able to post the audio from this excellent panel, which can be downloaded here.  At almost 14MB, it might take a few minutes to download, but it's worth a listen.  The insights from Nida Davis Roemer (CTO of the American Red Cross), Yoav Intrator (Chief Architect of Deutsche Bank) and our own Ground-Floor SOA leader, Surekha Durvasula (Kohl's Department Stores) are all worthwhile.

Our partnership with Gartner continues in December, with SOA Consortium sessions at both the Application Architecture, Development & Integration Summit and the Enterprise Architecture Summit.  Don't miss us at these excellent, colocated events!