BPM / SOA Consortium Insights

Community Insights: Services, Sprawl, Marketplaces, Bazaars and Portfolio Management

Note: For practitioners, one of the most valuable aspects of consortium participation is the opportunity to exchange ideas in a trusted peer community.  While the diverse group doesn’t always reach a single conclusion, each participant gains new perspective to consider in their unique situations. 

One such SOA Consortium conversation thread started with service value, covered service marketplaces, cathedrals and bazaars, and concluded with service portfolio management.  What follows are notes from that conversation, published not as an answer, but for consideration as you expand the breadth and depth of your service-oriented architecture.  As always, we welcome comments.

CALL #1 – Service Sprawl and Service Marketplaces

In a series of calls, the SOA Consortium’s community of practice engaged in a very interesting discussion on service portfolio management.  The conversation began innocently enough, when one member queried the group on visual methods to demonstrate the value of a services approach to business personnel. 

This member was looking for insights on creating a business intelligence dashboard for business stakeholders to see the value of service adoption, including key metrics on service use and re-use, and time-to-market improvements.  His motivation wasn’t marketing, but an underlying concern that full SOA value wasn’t attained because of service sprawl.

In this case, the service sprawl had two sources.  First, and the more common cause, SOA was simultaneously adopted in different business lines.  In the early stages, each business line created its own services, unaware of reuse or collaboration opportunities.  Second, the organization acquired another organization with similar business lines, which was also pursuing SOA. 

Through conversation, members noted other service sprawl causes, such as lack of trust, immature service governance practices, and no mandates for service rationalization.

From here, the group began discussing ways to reduce and prevent service sprawl.  A popular idea was the creation of a services marketplace.  In a short brainstorming session, the group discussed incorporating prediction markets to gauge service popularity, and social technologies to build trust, as well as to strengthen the service offering with better definition, feature/function, and performance.  Detailed brainstorming notes follow.

Services Market Place Requirements

• Organizations need to “advertise” their services, advertise as in “marketing”, not UDDI type directory listing
• Developers need to learn about “popular services”.  These trusted services will continue to receive investment.  Less popular, duplicate services should be slated for obsolescence.
• Service consumers need ability to provide feedback on service, and suggest improvements
• People need ability to “vote with feet” or code
• Service sprawl is a people problem, therefore a social solution is required

Services Marketplace Functionality/Technology Ideas

• Create a prediction market to understand service popularity (existing or planned service).  Each marketplace participant creates an investment portfolio of 10 services.  To add a service to your portfolio, one must be removed.  The service mix across portfolios will indicate service popularity, as well as pruning trends.  Spigit was cited as a technology example, it is used by Microsoft (and others) for release date prediction
• Use Amazon model for customer review and even for service recommendations “consumers of this service also use this/these service(s)”
• eBay seller rating, equates to service publisher rating, “also available from this publisher…”
• Service definition might benefit from Facebook (Lombardi) extended water cooler model, experts/interested parties can add to definition/requirements in public wiki like environment

Services Marketplace Questions

• Is there a unit of exchange?  If so, what is it?
• What is the best way to bring the marketplace into the work stream of potential service consumers, providers?  Is it via calendaring – associated with design and review meetings?  Modeling tools?  IDE?
• Is there a similar marketplace opportunity for a business process models?

About this point, the group made the leap to the Cathedral & Bazaar metaphor.  Service repository as we know it today is Cathedral, Services marketplace is Bazaar.

Service Bazaar Startup Needs

• Advertise the Bazaar
• Place close to work stream
• Establish minimum entry requirements: Merchants must provide certain attributes for each service: purpose, business process, business process model, nonfunctional attributes, implementation attributes (can and can’t do), chargeback and rates, classes of service (levels, cost), support model (use at own risk or supported)
• Find and win early adopters
• Incorporate knowledge management, social technology and community practices
• Word of mouth marketing – early adopters are best advocates
• Incremental introduction plan

At the close of the call, the member originally posing the service sprawl problem decided to explore prediction market technology for service portfolio rationalization.  As well, the group decided to continue the bazaar discussion on the next call.

CALL #2 – Service Cathedrals and Bazaars

Continuing the services marketplace conversation theme, but with many new call participants, there was a strong sense that service sprawl needs to be managed both proactively, via portfolio definition/management practices and reactively, via both top-down rationalization efforts and bottoms-up service marketplace advertising and consumption patterns.

Call participants from enterprises expressed concerned that a pure services marketplace – introducing competing code – is not behavior a development organization can afford to participate in.

There was strong support for the advertising aspect of the services marketplace, letting people know a service existed, its purpose, current usage scenarios, community ratings etc. 

For a services marketplace to be successful, it needs to be close to where developers work.  Oracle’s Enterprise repository (BEA Flashline) was cited as an example of tool with community engagement vision.

It was noted that in organizations where sprawl exists, or M&A activity is underway, the services marketplace can provide a mechanism to contain further sprawl and promote (Darwinian) rationalization, even before formal rationalization assignments/efforts are underway. 

Another note was that duplication does not always equate to waste.  An organization’s operating model (see Ross & Weil) may call for some separation of services to support a fast growing/changing business unit/activity.

There was a call for distinction in the marketplace’s unit of exchange (used in funding decisions) from service portfolio metrics.  Service portfolio metrics should not be number of services; instead use percentage of (unplanned) redundancy & coverage gaps. 

The group believes portfolio management – value of IT investment over time – is an important concept.  The current project focus in most organizations – on-time and on-budget measurement – is very short sighted.  Businesses do look at total IT spend over time, and percent of development versus maintenance, but most often don’t drill into the specific business domains or business capability.  This lack of transparency can lead to a behavior of delivering sub-par solutions that require frequent replacement. 

In respect to proactive service rationalization, the group spoke of defining enterprise and/or domain service maps. They also spoke of the need to get business analysts involved in service definition, and that business analysts might be better accepted by business units if they (business analysts) reported to Finance or Quality, rather than IT.

Additionally, the group discussed incentives for sharing services.  The biggest point/concern here is that the incentives need to map to portfolio metrics and goals.  Avoid the trap of putting incentives in place that encourage “gaming the system” to receive the incentive while damaging the overall service portfolio.  Some members believe the incentive is keeping your job.

A late discussion point was that sustainable SOA has organizational implications beyond initial centers of excellence.  Sustainable SOA requires pervasive practice, cascading changes (service thinking and management) to funding practices, project management, solution delivery, operations, and change management.  In other words, SOA cannot be a side practice forever.

CALL #3 – Service Portfolio Management

Reviewing the key discussion points over the past two calls, the group concludes that both models – Services Cathedral and Services Bazaar – are valid.

The adoption of a cathedral and/or bazaar approach may vary based on project lifecycle phase, business criticality of the problem being solved, experience of the project/development team in respect to SOA, and/or time to market considerations.

A discussion on project lifecycle practices leads to a discussion on portfolio management practices:

• Organizations most often view portfolio management in respect to managing concurrent projects and managing IT investment. 
• Organizations also practice asset management in respect to purchased (infrastructure oriented) software and hardware.  Vendor contracts, releases, technology advances and the like drive these asset management practices.
• Organizations seldom practice asset management practices on their application portfolios, and if they do, it is for purchased rather than custom-built software. 

A service-oriented approach fundamentally changes the basic management unit from an application, to services, or a bundle of services that represent a business function (component, segment, flow or capability), which are consumed by many applications, business processes and/or domains.

The multi-purpose aspect of services, and bill-of-materials structure of service compositions and solution assemblies, point more towards product management practices than traditional application management practices.  The shift to product, rather than project or application thinking, forces changes to funding, project management, asset management and operations practices. 

Most notably, organizations will need to be deliberate in the realm of service portfolio management, understanding what business capabilities are offered in the portfolio (marketplace), how those capabilities are instantiated via software and information assets (model to asset mapping), and how/where those capabilities are packaged into end-products (applications, processes) that solve a business need.

The diagram below, previously published, illustrates services and the various process and portfolio interaction points across the service lifecycle.

[Click on diagram to enlarge]

SOA Consortium EA2010 Working Group’s Business Architecture Paper Now Available

The SOA Consortium’s EA2010 Working Group – a group of “street-smart” enterprise architecture practitioners – has been actively discussing the domains, services, practices and skills required for a thriving, business relevant enterprise architecture practice in the 2010s. 

A critical finding of these discussions is the emphasis of technology concerns at the expense of business understanding, and ultimately, true business enablement, in most enterprise architecture practices today. Successful enterprise architecture practices in the 2010s must give equal emphasis to technology and business concerns. The means for this re-balancing is the elevation, and in some cases initial adoption, of business architecture practices.

Typically, the business architecture practices and artifacts in enterprise architecture frameworks focus on business processes and business uses cases. This is not surprising, since these artifacts and practices are a prerequisite to IT-based business solution delivery. However, this is not sufficient.

To reap the benefits of business architecture – business visibility and agility – the business architecture must reflect the entire business design, from the point of view of business designers and owners, rather than IT solution delivery. This point of view begins with business motivations, includes key business execution elements – such as operating model, capabilities, value chains, processes, and organizational models – and transcends information technology representations, such as business services, rules, events and information models.

While we strongly believe that business architecture is a business domain, the Chief Information Officer (CIO), given his/her unique position to view business plans, business processes, information flows, and technology portfolios across the organization, most often champions business architecture formalization. 

In this discussion-oriented paper, the EA2010 group shares their findings on the following questions:

•    What comprises business architecture? 
•    What is the purpose? 
•    Who participates? 
•    How do you make business architecture accessible? 
•    How does business architecture facilitate business decision-making and change? 
•    How do you keep business architecture current?
•    How does business architecture relate to BPM, SOA and IT solution delivery?

To read the paper please go here.

If you have comments on the paper and/or insights on the discussion questions, please leave a comment here or email us.

Community Insights: Services, Business Solutions, Portfolios, Management Units & Clouds (continued)

Last month, I shared some of our Community of Practice’s work in flight regarding services, portfolios, management units, and the fit within the overall IT landscape.  At the time, the following diagram best represented our on-going conversation.  [Click on diagram to enlarge]

Along with the diagram, I posed some questions for broader community feedback:

1.  Has your organization’s management perspective shifted away from business solutions (applications, business process implementations) to business capabilities/functions?  If so, in which areas: IT funding, IT delivery, IT operations, and/or IT product management?

2. Are you engaging in service portfolio management practices, such as service value prediction and assessment, marketing, sourcing, rationalization, refresh, and retirement?  If so, what techniques and/or tools are you employing?

For example, to manage service sprawl that began from federated service development and was compounded by a merger, one of our members is considering marketplace techniques, both real and predictive, to let developers choose which of a redundant set of services survives, rendering the less popular obsolete.

3.  Who manages the service portfolio?  How does this compare, contrast with the management of the business solution and IT asset portfolios?

Since that post, our group continued its discussion, which is reflected in this updated version of the Services, Portfolios, Management Units & Clouds diagram.  [Click on diagram to enlarge]

 

The major changes:

1. Explicitly stated a usage relationship between the IT Delivery Value Chains and the Service Portfolio.
2. Assigned management responsibility of the Service Portfolio to the Enterprise Architecture group, and declared that the Service Portfolio is part of the Enterprise Architecture Portfolio. (answered our question #3)
3. Indicated the Business Capability map is one of many Business Architecture Artifacts, and that those Business Architecture Artifacts are managed as part of the Enterprise Architecture Portfolio.
4. Explicitly stated the business-driven relationship between Business Capability criticality and Project Portfolio prioritization.
5. Collapsed the Cloud Service view into the main diagram.
6. Noted the specific management policies at each portfolio, recognizing the need for federated policy administration, communication, and enforcement, or as Todd Biske would say, “governance”.

We welcome your feedback on any aspect of our evolved diagram, as well as your thoughts on the following questions. (Question #3 is new)

1.  Has your organization’s management perspective shifted away from business solutions (applications, business process implementations) to business capabilities/functions?  If so, in which areas: IT funding, IT delivery, IT operations, and/or IT product management?

2. Are you engaging in service portfolio management practices, such as service value prediction and assessment, marketing, sourcing, rationalization, refresh, and retirement?  If so, what techniques and/or tools are you employing?

For example, to manage service sprawl that began from federated service development and was compounded by a merger, one of our members is considering marketplace techniques, both real and predictive, to let developers choose which of a redundant set of services survives, rendering the less popular obsolete.

3. Is your organization using, or considering, ITIL V3 to manage the full service lifecyle from inception (business architecture) through development/consumption (IT Delivery Value Chains), operations (IT asset and runtime management) and product management (service portfolio management)?

Please share any thoughts on the post, and/or our direct questions, via comment, blog post, or discussion forum.  Just link to this post, we’ll find you.

Community Insights: Services, Business Solutions, Portfolios & Management Units

Over the last few months, members of the SOA Consortium’s Community of Practice have been discussing concerns, practices, tips and gaps related to creating and maintaining a vibrant service portfolio.  Discussion topics have included service investment, definition, reuse, rationalization, payback, governance, marketing, operations and asset management.

In recent weeks, these discussions have converged on the concepts of “management units” and “portfolio management”.  From our working notes:

“Taking a service-oriented approach fundamentally changes IT’s basic management unit from an application, to services, or a bundle of services that represent a business capability (component, segment, flow or function), and can be applied to many applications, business processes and/or domains. 

This unit shift ultimately forces changes to funding, project management and asset management practices.  Most notably, organizations will need to be deliberate in the realm of product portfolio management, understanding the business capabilities offered in the portfolio, how those capabilities are instantiated via software and information assets, and how/where those capabilities are packaged into products (applications, processes) that solve a business need.”

This week, I distilled our on-going conversation into the diagram below.  [Click on diagram to enlarge]

As you can see, and probably expect, the diagram spans business architecture, IT planning, IT delivery, IT operations, and service portfolio management concerns. 

The arrowed lines show the connections between concerns.  For example “Business solutions provide business capabilities” and “Business solutions consume services”.

The purpose of this post is two-fold.  First, we want to share our in-flight work, particularly the diagram, in case it can be helpful as you enter into service management discusses across your organization.

Second, we have some questions that we’d love the broader community’s feedback on.

1.  Has your organization’s management perspective shifted away from business solutions (applications, business process implementations) to business capabilities/functions?  If so, in which areas: IT funding, IT delivery, IT operations, and/or IT product management?

2. Are you engaging in service portfolio management practices, such as service value prediction and assessment, marketing, sourcing, rationalization, refresh, and retirement?  If so, what techniques and/or tools are you employing?

For example, to manage service sprawl that began from federated service development and was compounded by a merger, one of our members is considering marketplace techniques, both real and predictive, to let developers choose which of a redundant set of services survives, rendering the less popular obsolete.

3.  Who manages the service portfolio?  How does this compare, contrast with the management of the business solution and IT asset portfolios?

Given the convergence of SOA and Cloud Computing, I did a quick extension to include consuming cloud services.  The extensions are in yellow.  [Click on diagram to enlarge]

Obviously, an externally sourced cloud service is not an IT asset.  However, since the cloud service does instantiate business capability, it is a member of your service portfolio.  The question becomes which service portfolio management practices and policies apply to an externally sourced (and controlled) cloud service?  I’ll be thinking that one over myself, and would love to hear your thoughts.

Please share any thoughts on the post, and/or our direct questions, via comment, blog post, or discussion forum.  Just link to this post, we’ll find you.

CIO Magazine | SOA Consortium Case Study Contest: Judging Criteria

A few people have asked us how we determined the winners of the case study contest.  Rather than responding privately in email, we thought it made sense to post publicly about the process.  The judging criteria and process were devised by our Executive Suite working group, which is comprised of SOA practitioners, suppliers and me.  This is group also initiated the contest. 

To best explain the judging criteria, I'm going to start with the submission process.

The call for submissions:

"The competition is open to organizations of all sizes, including government agencies, which have successfully delivered business or mission value using a SOA approach.

The goal of the SOA Case Study Competition is to highlight business success stories and lessons learned to provide proof points and insights for other organizations considering or pursuing SOA adoption. To qualify for the competition, the SOA project must be complete with demonstrated business results.

Entries will be judged on the complexity of the business problem addressed, the ROI/Business Value achieved (Agility/Innovation/Flexibility), the level and sophistication of the cross-organizational collaboration (Business/Technical) and the usage of SOA approaches and supporting technology. In addition to one overall winner, organizations will be recognized by industry/government and project size/scope."

During the submission process, entrants were given the following guidelines:

"SOA is focused on a business/IT alignment, and the case study needs to consider how SOA addressed a particular business challenge or problem. This is not intended to be a detailed discussion of technology, but a view of how business and IT can, with SOA, drive improved business value. Answer the questions as if you were trying to convince the CEO of the value of SOA to the organization. NOTE: Questions must be answered by a SOA Project Team Member."

Entrants were asked to answer 6 questions about their projects.  For each question, we provided some guidance and a word count limit.  The questions:

1. What was the business challenge or problem addressed by the SOA project, and why was SOA selected to address this?

2. When was the project started, how large was the project and how was it funded, and how long did it take to see results?

3. What was the planned and achieved ROI/Business Value (ie, improved agility, innovation, flexibility)?

4. How was the SOA Project team organized and what types of business staff were on the team? How was cross-organization collaboration (Business/Technical) achieved? Was a Center of Excellence (CoE) created?

5. What technology or software was used in the project? What vendors were involved? Was service reuse taken into consideration? What was the most complex technical challenge encountered?

6. What were the most significant lessons learned from the SOA project?

The Judging

There were 6 contest judges, all committed and announced as the contest went live.  This prior commitment was a good thing, because the submissions received far exceeded our initial projections.  After the contest closed, the submissions were validated and sent to the judges.  Accompanying the submissions were the judging rules and a tally-keeping workbook.  During the judging period, we held check-in calls to surface any questions on the process or entries and to keep us on task.

We used the following weighted scoring system:

Weight	Question(s)	Aspect
20%	1	Business Challenge
30%	2 & 3	Project Size, ROI/Business Value
30%	4	Collaboration
20%	5	SOA Approach

This gave us our first score, the total weighted score.  Judges could award extra points for lessons learned or any "wow" factor.  The weighted score plus the extra points gave us our second score, the total score. 

We selected the winners by reviewing both the weighted score and the total score.  In other words, we allowed extra credit to augment the scoring, not distort it.

As for the scoring the individual questions...

Question 1 - Business Challenge: 1 - 5 points based on the complexity / scope / criticality of the business challenge

Question 2 - Project Size: 1 - 4 points based on the project size and time to value; highest scores went to "large, quick projects", lowest to "small, slow projects"

Question 3 - ROI/Business Value: 1 - 8 points based on the business value type and span; highest scores went to "new value creation across a wide span", lowest to "SOA readiness at a small span".  Here is the matrix we used:

Question 4 - Collaboration: 1 to 5 points based on the degree of collaboration within IT, between business & IT, with external business partners and/or with customers.   Technology suppliers did not count as external business partners.

Question 5 - SOA Approach: 1 to 5 points based on the sophistication, appropriateness and execution of the SOA approach.

Reconciliation

Astoundingly, the six winning cases were at the top of each judge's scorecard.  From there, it became a simple matter of math to identify the overall winner, Synovus Financial, and the special recognition winners -- Canada Infoway, Con-Way, Penn National, SunGard, and US DoD AT&L.

As I've mentioned previously, there were really no "losers".  We received tons of great cases, full of insights and lessons.  I'll be mining all of those for fun facts and more.  Stay tuned.

Enterprise Architecture 2010 Talk-- Where EA Means Business -- at SAP ASUG on May 5, 2008

On Monday, I'll be representing the SOA Consortium's EA2010 working group at SAP's ASUG conference in, you guessed it, sunny Orlando.  I'll be giving a talk on our EA2010 work.  Areas of discussion include 21st century business, service-orientation, business architecture, enterprise architecture and enterprise architects.  If you are attending the show, please come by, Monday at 9:30-10:30, in 308C. 

If you'd like to connect at the show, I'll be at the Sunday evening ESOA Community Networking Session and taking in sessions and wandering around the expo floor on Monday.  Drop me an email at bmichelson at gmail dot com.

SOA Consortium and CIO magazine launch Case Study Contest

Today, the SOA Consortium and CIO magazine are announcing the launch of a SOA case study contest.  The goal of the SOA case study contest is to highlight business success stories and lessons learned to provide proof points and insights for other organizations considering or pursuing SOA adoption.

Case study submissions must be for completed projects that used a SOA approach to deliver business value.   In keeping with our charter, we are not looking for dissertations on the technical beauty of the architecture and implementation. Rather, we are interested in the business story, the business value generated, the degree of cross-organizational collaboration, and the usages of SOA approaches and supporting technology.

For more information on the contest and participation, please go here.

Thanks to our Executive Suite SOA team and CIO magazine for putting this contest together! 

Enterprise Architecture 2010: Questions for EA, SOA and Business Architecture Communities

Have you had a chance to check out our new released EA2010 webcast and position deck?  If you did, great.  If not, no worries.  You can still participate in the discussion.  In our work, we call out the importance of business architecture as organizations progress with service-orientating their business and IT operations.  (Yes, SOA as a strategy.  No, SOA as a technology.)

As you can imagine, we had a lot of healthy (and some circular) discussion as we were working on the EA2010 material.  In the end, we decided we would publish the frame, and use it to solicit feedback and insight.

Some of the questions we would love the broader EA, SOA and Business Architecture communities to chime in on are:

1. Do you agree that Business Architecture as an important emerging enterprise architecture discipline?  Does your organization already practice business architecture?  If so, formally or informally?

2. Where will/do business architects come from?  Are these business savvy technologists?  Technology savvy business professionals?  Today's business analysts?  Other?

3. Assuming Enterprise Architecture 2010 encompasses not only today's technology laden "enterprise architecture" but also Business Architecture, where will it report?  Is this still an IT function?  Does it report to a business executive?

Please share your thoughts with us, as a comment on this post, via a trackback from your blog, or drop me an email brenda at soa-consortium dot org.  If you have other thoughts on the EA2010 work, please share those as well.

Enterprise Architecture in 2010 Means Business

One of the working groups in the SOA Consortium’s community of practice is the “EA2010” group. This group of seasoned enterprise architects from industry, government, systems integrators and vendors, has been actively discussing and defining the next generation role of enterprise architecture. Specifically, what enterprise architecture looks like – organization, practices and people – in a business-driven, service-oriented world.

This week, the EA2010 working group published the first release of their view of Enterprise Architecture 2010 in a Powerpoint deck.  Here's a sneak peak:

In preparation for this release, I sat down with the EA2010 working group leaders, Ashok Kumar and Yogish Pai, to discuss their working group’s motivation, findings and next steps. That conversation is available to the public as an on-demand webcast or podcast.

During our conversation, Ashok and Yogish touched on a wide range of enterprise architecture concerns, including catalyzing business change, gaining business-smarts, shifting focus to business architecture, managing enterprise architecture, participating in strategy and delivery, and winning enterprise constituents.

After viewing or listening to the webcast, please share your thoughts with us. As we discuss in the webcast, this is a work-in-progress and we really want to hear from the broader enterprise architecture community.  Leave a comment here or send an email to brenda at soa-consortium dot org.

And yes, the full EA2010 presentation deck is available for download at the webcast location).  Feel free to discuss and use any and all materials in your own enterprise architecture programs.

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