Application Platform Strategies Blog

Effort to define standards for RESTful registries beginning

Blogger: Anne Thomas Manes

Back in January, shortly after MuleSource and WSO2 announced their RESTful registry products (Mule Galaxy and WSO2 Registry respectively), I issued a call to arms to the vendor community to define some standards that would enable information exchange. I'm glad to report that an effort is beginning. 

Glen Daniels from WSO2  raised the issue again in his blog last week, and Dan Diephouse from MuleSource picked up the baton and offered some basic scoping requirements. Glen responded the next day with some thoughts on open repositories and APP patterns, and Paul Fremantle from WSO2 set up a Google Code Project for it.  Michael Neale from Red Hat (core team member for JBoss Rules and Drools) has joined the project, too.

Microsoft's SOA Strategy

Blogger: Chris Haddad

After Microsoft’s Server and Tools Business (STB) analyst summit (held in early June), I wasn’t the only person wondering if Microsoft is heading in the right direction. Ron and Judith have concerns as well. While we share a common theme, our perspective and confidence on Microsoft’s ability to articulate and execute a SOA strategy differ.

Microsoft’s states their strategic direction is in ‘Making a new class of model-driven and service-enabled applications mainstream’ and enabling ‘Real World SOA’.  At a vision level, Microsoft understands service-orientation and adoption challenges. They are also focused on enabling a pragmatic approach to achieve success [1]. Microsoft has always been extremely successful at enabling productive and efficient development of discrete applications and services. Early ‘real world service-oriented’ success stories capitalize on faster integration through web services and realizing re-use across a limited number of consuming systems. Over the last five years, web service based integration has been adopted by mainstream developers, yet development teams have not yet transitioned their software assets to realize a flexible and agile architecture. The market message describing ‘the value of SOA’ is evolving to focus on the ‘architectural aspects’.

To obtain agility, development teams must reduce complexity. Complexity increases the time and effort required to enhance or modify applications and services. Service-oriented patterns to reduce complexity include:

·         Re-use and share existing software assets

·         Consolidate duplicative software assets

·         Conform projects to common standards

According to Microsoft, the Oslo vision is to “Significantly simplify the effort required to design, build, deploy and manage distributed applications within and across organizations.” [2] Microsoft’s challenge is to re-align their product portfolio to support a cross-project, portolio-oriented view of software assets and enable re-use through intuitive matching of project requirements to service definition. Being able to expose, compose, and consume services in a more rapid, simple manner will not demonstrate recognizable business value. After all, most development teams right now cannot quantify ‘how fast’ they develop service providers and consumers. Also, developing 'more services faster', without considering the set of existing service capabilities, keeps programmers employed, but is a stratgy which doesn't simplify a company's software portfolio (aka a clear path to code bloat).

At a strategy level Microsoft describes Service Oriented Architecture as “a standards-based design approach to creating an integrated IT infrastructure capable of rapidly responding to changing business needs. SOA provides the principles and guidance to transform a company's existing array of heterogeneous, distributed, complex and inflexible IT resources into integrated, simplified and highly flexible resources that can be changed and composed to more directly support business goals.” [1] While Burton Group agrees with Microsoft’s strategic statement, we feel Microsoft must invest more time to clearly articulate their view of SOA principles, how their product roadmap will be realigned to support service-orientation, and describe fundamental architectural service-oriented building blocks required to realize value. Current industry dissatisfaction with Microsoft’s SOA direction is due to a lack of communication. To demonstrate progress towards their strategic vision, Microsoft must better communicate how Visual Studio and BizTalk Server will align with Microsoft’s Oslo initiative. While Microsoft states development using Microsoft’s products will be ‘business driven’, include ‘next generation declarative languages’, and 'place models in a repository', an effective SOA strategy must also include ‘software asset discovery and visualization’, integrate various ‘service model perspectives’, and a present a ‘portfolio oriented view'. We look forward to Microsoft articulating a broader set of service-oriented principles and goals (i.e. beyond current web services and interoperability messagae), a relationship between goals/architecture/business value, and an enabling product/framework roadmap as they did with their prior ground breaking initiative, Indigo (aka Windows Communication Foundation).

[1]Microsoft SOA FAQ http://www.microsoft.com/soa/about/faq.aspx#soafaq

[2] Oslo Backgrounder, November 2007, http://www.microsoft.com/presspass/events/soa-bpm/docs/OsloBG.doc

Interoperability on demand

Blogger: Chris Haddad

I had an excellent opportunity to moderate a panel discussion during Tech Ed 2008. Drawing out a contentious discussion during the interoperability love fest was challenging. Obviously the participants are serious about playing nice in the sandbox.

This Panel discussion centers around the use of standards to facilitate interoperability between different technologies. The participants have all implemented their own version of a reference application and speak about any challenges they faced in implementing the application. The main discussion points of this Panel include: interoperability through SOAP; WS-* standards and how they facilitate interoperability; common problems with interoperability; identity and security in a distributed application; and future directions/remaining challenges in interoperability. The discussion included Raghu Thiagarajan (TIBCO), Gerald Beuchelt (Sun Microsystems), Gregory Leake (Microsoft), Jonathan Marsh (WSO2), and Chris Haddad.

The panel discussion can be viewed here

On a more personal note, I had the opportunity to point Greg Leake towards local Redfish guides and discussed the benefits/drawbacks of living abroad with conference guide Michael Iem.

The 2 paradoxes of SOA funding

Blogger: Richard Watson

A business case for SOA investment is so littered with paradoxes it’s astonishing any of them get funded at all.  Joe McKendrick, in his ZDNet SOA blog, has written about the paradox of including SOA in a business case:

In presenting a business case, the three letters “SOA” probably shouldn’t even be mentioned. However, SOA inevitably results in a bump in costs (at least for the short-term) that needs to be explained and sold to the business.

Let’s look at 2 more paradoxes inherent in funding for SOA investments.

The paradox of too much project funding

In many organizations the IT funding model works like this.

Here’s the money, just build it.  Now.

Demand for IT projects comes from lines of business and the supply of funding for all projects also comes from those same business lines.  Shadow IT moves in and out of vogue in cycles responding to this paradox.  At the peak of the cycle CIOs and CTOs can add some value implementing portfolio management and enterprise architecture.  At the trough, CIOs look like mere demand aggregators with little influence to mediate the demand and supply of IT funding.

The real resolution to this tension comes down to transformation along a number of axes including incentives, accounting, control and culture.  Right now business units are not comfortable being asked to do any of the following things:

• act like a service provider for the organization
• rely on services provided by other business units
• fund infrastructure, architecture or education improvements
• • or accept that designing reusable services takes more time and needs deeper collaboration than bespoke applications.

In fact it’s unrealistic to expect business units to act in any other way, given the metrics and related incentives that feed and nourish this behaviour.   One of the clients we interviewed for the SOA contextual research project pithily summarised this point:

Altruism is not an effective corporate strategy

An organization’s incentives need to be shaped to promote service provision, service reuse and support for shared infrastructure.  Other changes are required to follow through with this strategy including the accounting and financial flexibility to fund and charge-back shared infrastructure and service development and new control and operations strategies to govern cross-business system dependencies.

Often achieving this means fundamentally restructuring a business into horizontal capabilities.  Aren’t you sorry now you started pulling on that thread?  You just wanted to get funding for a SOA initiative and now you’re restructuring the business.

This is the reason executive level sponsorship is a common theme in all our clients’ SOA success stories.

The annual budget cycle paradox

SOA is not a quick fix to the problems in IT; it’s a long-term strategic investment that will take decades to pay-back.  However, projects are typically scoped and funded on an annual basis.  The issue here is finding return on investment (ROI) measurements that are required as a minimum to get that SOA business case over the line.

Oracle CEO Larry Ellison acknowledged 6 months ago in a CIO magazine article that slow SOA adoption has been widely documented:

 

While I've read [about slow adoption], people have to understand when you have a fundamentally new computer software architecture, SOA, it takes a long time for adoption.

Moving to SOA is not as easy as flipping a switch.

It takes about 10 to 20 years before [you can] rewrite all of your applications.

We think it's a long-term growth story, it's a very rapid growth story.

It takes a long time for our customers to have a majority of their applications modernised and we think this is a growth story for a decade for us.

Larry’s sales force, like the rest of us, is finely attuned to the need to show quarterly value.   They know that just because the full ROI of SOA infrastructure they sell won’t be realized for a decade, they have to have a good enough story to sell it this quarter.  So it is within IT organizations and annual budgets.

Changing architecture and culture is a multi-year, perhaps decade-long project.  Looking for the quick fix is counterproductive to this effort, and likely to create more complexity in your environment, not less.  But don’t confuse the quick fix with projects that deliver value early and often, and recognise the need to architect for the long-term.

The resolution to the tension in this paradox comes in two flavours.  Firstly, if your organization has a mature IT portfolio management effort, with a central project management office (PMO) that offers multi-year funding for strategic projects, take that route.

Secondly, suck it up like Larry’s sales animals.   Restructure the business case to deliver value annually if not quarterly.  This is the only route to building up that trust relationship with the sponsors.  Look for projects that deliver value as clear business outcomes: increased revenue per client, increased client retention, more visibility into customers’ purchasing patterns, more flexibility to outsource non-core business capabilities.

One success story amongst our clients in resolving the tension in these 2 paradoxes together is a financial services company that favours the centralized funding approach.  There is a mature IT governance process in place which means that while much of the funding demands are still for business unit driven projects they are funded from a central budget controlled by the CTO. The CTO architecture group has a unique vantage point from which to plan the evolution of IT, and identify the contribution each discrete project can make.  The remaining demand comes from the CTO-governed group itself for strategic projects, including those that cannot show ROI over one, two or even five years, but are crucial to transforming IT.

If you’re trapped in what looks like a paradox, change your viewpoint.  If your paradox is working out the question of how to get funding for your SOA initiative, change the question to this one: how to get funding to add business value while transforming IT in the long-run.

 

WOA, ROA, SOA: When will it stop?

Blogger: Anne Thomas Manes

Yikes! The "WOA" term (Web Oriented Architecture) has popped up again. Nick Gall first introduced the term in late 2005 at a Gartner Summit. He described it as a subset of SOA that embraces the principles of REST and W3C's Architecture of the World Wide Web. No one really picked up on the term at the time. I suspect it was drowned out by the Web 2.0 hype.

But then Dion Hinchcliff wrote about it (and redefined it) in February this year. And now there's been a flurry of discussion about the term, starting with a post on ZDNet by Dana Gardner in early April hailing WOA as the savior for SOA. Dion followed up with another article on ZDNet recounting Web 2.0 success stories and implying that SOA might be more successful if it focused on WOA instead. But the pundit community has reacted poorly to yet another "xOA" acronym. Mike Meehan at SearchSOA summarized the discussion nicely and asked if WOA brings anything new to SOA. The same day Dana Gardner published a second article on ZDnet entitled "Enough with WOA". And just last week the ZapThinkers weighed in on the discussion, pointing out that SOA and WOA are different levels of abstraction, and proposing yet another term, "Web-oriented SOA". (Please, no!)

Personally, I don't see any value in the WOA term. I don't view it as significantly different from a RESTful style of building services, but Nick provided some additional reasoning behind the term in a post from August 2006, indicating that the W3C Web Architecture adds some additional constraints.

Dion's revised definition seems to miss Nick's subtle distinction between REST and WOA. Dion's definition is essentially REST, and I don't see the point of using multiple terms for the same thing. We already have way too many terms:

• Tim Bray calls it "Web Style".
• Leonard Richardson and Sam Ruby call it ROA (Resource Oriented Architecture) in their book on RESTful Web Services.

Note that ROA has an entry in Wikipedia, but WOA does not. No doubt someone will rectify the situation soon and ensure that the term "WOA" is formally defined and remains to confuse us all.

I find it amusing that Dion's Web 2.0 Success Stories article was indirectly in response to my post calling for SOA success stories. Advocates of WOA/ROA/WebStyle/etc claim that development of services using simpler technologies such as POX (plain old XML) over HTTP will facilitate SOA success. But as I've recounted before, SOA is not about technology. Using REST rather than WS-* isn't likely to improve the success rate of your SOA initiative. Our research makes it clear that the primary impediment is adoption (i.e., getting the business to buy into the initiative and sponsor development of services).

And actually, the most important thing to understand from a technical perspective is that a service should support access via multiple styles of interface. It should enable an application to interact with it using whatever means it wants:

• A method-oriented interface (e.g., SOAP)
• A message-oriented interface (e.g., JMS)
• A resource-oriented interface (e.g., HTTP)

As the ZapThinkers said, SOA and WOA specify different layers of abstraction. SOA specifies a system-level architectural style (i.e., how to implement capabilities so that they can be consumed by many applications). WOA refers to an interface-level architectural style (i.e., the means by which service capabilities are exposed to consumers). WOA (aka REST or ROA) advocates a resource-oriented interface. (Note, though, that many folks interpret WOA simply as POX over HTTP, which may actually support a method-oriented interface rather than a resource-oriented interface.)

SOA is about services at a conceptual level -- not about any particular technology, interface style, or protocol. You should be designing your services for the long-term. It's highly likely that the technologies that are all the rage this year will fade away into obscurity within the next five years. A service encapsulates a capability and makes it available to application consumers through one or more interfaces/protocols. Be careful to maintain a clear separation of concerns between the service implementation and the interfaces used to expose it. Chances are high that you will need to add additional interfaces over time.

Are you in Shape for SOA?

Blogger: Richard Watson

Are you in shape for SOA this summer?  Get ready for the SOA initiative you've always dreamed about by working out with us in the "SOA: Assessment And Planning" workshop at Catalyst North America 2008.

Chris Haddad and I will be presenting tools for allowing you to make an honest and measured assessment of your organization's SOA baseline and a recognition of areas that could be more toned.  As an example, here's a checklist we'll be walking through to assess your Incentive Systems:

People alignment with SOA principles
Mark as True [T] or False [F] 

• Services publicized
• Sharing encouraged
• Open source mindset is present (i.e., solutions delivered to other teams are documented, evangelized, and supported)
• Business stakeholders expected to define capabilities
• Teams discouraged from creating redundant software assets
• Compliance with corporate standards is expected

We will also be sending you away with box of tools you can use to plan the evolution of service-oriented thinking.   Another sneak preview, shown here, gives a checklist for Service Classification meta-data:

Service Classification Meta-data 

• Service Overview (e.g. name, description)   
• Lifecycle Attributes (e.g. version, version relationships, lifecycle status)
• Classification (e.g. basic, composite, infrastructure, business)
• Endpoint Deployment Attributes (e.g. protocols, location, WS-* specifications)
• Data Model (e.g. XML Schema, WSDL, version, semantics, validation)
• Service Level Requirements and Policies (e.g. availability, capacity, responsiveness, security, transaction rate)
• Mediation (e.g. routing, queuing, caching, transformation)
• Service Dependency Attributes (e.g. services, databases, directories, frameworks)   
• Physical Instance Dependencies (e.g. application platform, security, management)
• Business Process Model (e.g. UML diagram, business classification)
• Contract information (e.g. consumers, providers, utilization)
• Usage Guidelines (e.g. time of day, availability, # of users. throughput)
• Accounting or remuneration options (e.g. pay per use, subscription, chargeback amount)

Other tools in that goodie bag include a customizable SOA maturity model, those circuit training assessment surveys and samples for creating your own organization’s SOA roadmap.

In Search of SOA Success (SOSS).....

Blogger: Chris Haddad

How do you measure SOA success? Why is SOA a risky proposition? Which steps should you take to gain and maintain business support, funding, and SOA initiative momentum? Our recent SOA investigation yields new insights, timely reaffirmations, and straightforward guidance on how to better shape Burton Group’s research and client interactions. In an early June telebriefing titled In Search of SOA Success, I will  present our contextual research methodology, SOA project questions answered, and research project revelations on how we can best partner with you. The presentation will preview  sessions that Anne and end-user speakers will present at Catalyst 2008. 

The following table presents a high level overview of how we structured the consolidated data. How many questions are adequately answered within your organization?

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

Report   Card
Question	Focus
Why create a scorecard?	Needs and elements
What is the report card score?	Findings (people,   process, technology, and results)
Why is SOA a risky proposition?	Success Killers   (disconnects,   dysfunctions, missing elements,   mis-directions, and   mis-information)

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

Roadmap   dynamics
Question	Focus
Why invest in SOA?	Understand goals   and drivers
How do I implement a service oriented   environment?	Establish   foundation and educate
How do I gain and maintain support,   funding, and momentum?	Establish   credibility, trust, influence, and participation
Is the world flat?	Sell new reality and   path (improve outcomes, realize opportunity, and transform business)

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

Success   factors
Question	Focus
How do I mitigate risk?	Success factors
How do I gain social capital and buy-in to   the path?	Think IT1
What actions facilitate adoption?	Take Small Steps
How do I move beyond my current state?	Deliver value

I look forward to our future conversations.  Stay tuned for an update to the telebriefing registration page.......

Consolidating SOA stories

Blogger: Chris Haddad

During the past three months, we have been collecting SOA stories. Even though Anne and I have talked with hundreds of IT professionals over the past four years, we felt obtaining a fresh perspective to the SOA conundrum would be beneficial. Burton Group's SOA research team met in Florida last week to consolidate several client interviews, identify trends, and divine insights. We reviewed client interviews spanning banking, insurance, investment, government, systems integrator, telecommunications, hospitality, and retail organizations. In many organizations, we captured data points across multiple stakeholders. During the consolidation process, we used a manual, low-tech approach to view and consolidate the information. Data points were printed out on 3X3 papers and literally thrown on the walls. Setting appropriate SOA expectations requires  listening and analysis skills to understand the rich context surrounding SOA success factors and success killers. Over a period of three days, our team of seven experts (with representatives from Identity, Security, Application, Executive Advisory, and Consulting teams) analyzed and arranged data points.

At the end of the week, all four walls and the entry hallway were papered with information. Our war room delivered an immersing experience reminiscent of Spielberg's Minority Report, but without dazzling special effects. Patterns quickly emerged and the team crafted high level topics, categories, and section headings. 

The analysis also generated key insights and relationships. Information flowed into twelve different topic areas:

• Lessons learned
• Roadmap
• Goals
• Advocacy
• Sponsorship
• Sphere of influence
• Adoption
• Funding
• Business case
• Culture and collaboration
• People relationships and roles
• Organization
• Education
• Governance guiding SOA implementation
• Service portfolio planning
• Infrastructure
• Projects

Surprisingly, interviewees talked more about culture and people  instead of technology. Stay tuned for deep insights as we continue to normalize SOA CR information, rethink success factors, and tune our  recommendations.

SOA Expectations

Blogger: Anne Thomas Manes

Todd Biske recently responded to my post from March 9 (Looking for SOA success stories) with a valuable discourse on Setting SOA Expectations followed by another post yesterday on Organizing for SOA. I'm still noodling on the organization topic, so I'll save that for a later post, but I would like to respond to the comments Todd made regarding SOA expectations.

Todd said:

I’ve always believed that the changes associated with SOA adoption were a long term effort, at least 5 years or so, but it was very surprising to see Anne only find one success story, although further comments indicated she had only talked to 7 companies. 1 out of 7 certainly feels right to me. Things became even more interesting, though, with some comments on the post which indicated that Anne’s definition of success was, “Has the initiative delivered any of the benefits specified as the goals of the initiative?” She indicated that every company said that their goals were cost reduction and increased agility. My question is how did they measure this?

First I want to point out that our research methodology looks for patterns and trends rather than statistics. We've interviewed 12 companies so far, which was our minimum target. We expect to interview another half dozen or so. Obviously, this small sample size is not going to produce any kind of statistically relevant numbers. But we are identifying plenty of patterns. And that's our goal. We're identifying the issues that cause breakdowns. And the situation is remarkably similar at most of companies.

I agree with Todd that a SOA initiative is a long term effort. I typically put it at 20 years rather than 5 years. So I'm actually pretty stunned at the enormous success my one success story has achieved in just 4 years. And I'm not sure that it's appropriate to attribute all of its success to SOA. In addition to the SOA initiative, the company executed a very significant IT transformation effort that involved reorganization, a radically modified incentive program, and adoption of agile methodologies. All factors have contributed to its success.

Todd points out that "success" is relative. Perhaps. But every company that Chris and I have interviewed has told us that the goals of the SOA initiative are to reduce costs and increase agility. And our first question when they tell us this is always, "How do you measure agility?". Most companies that we've interviewed don't have a satisfactory answer. (Unspecified metrics is a key trend.)

I have absolutely no doubt, though, that my one success story has attained these goals: The business units that pay for new applications are eager to extol the virtues of the new IT group and its ability to deliver new systems quickly and at a fraction of the previous costs. In fact, the VP of sales said to the CIO, "Whoa, slow down. We can can't handle all these improvements to the CRM system."

I'm anxious to find other success stories and compare them with this one so that we can identify trends. One company provides an anecdote. I need at least three companies to be able to identify trends. I'm scheduled to interview someone tomorrow that claims to be successful. I'm hopeful.

But let me get back to the heart of Todd's post, where he says:

Rather than starting out with a goal of “cost reduction” or “increased agility”, start out with a goal of “create a service portfolio.” This sets the organization up for an appropriate milestone on the journey rather than exclusively focusing on the end state. Without interim, achievable milestones, that end state will simply remain as an ever-elusive pot of gold at the end of the rainbow.

I completely agree that definition of reasonable goals (as well as metrics for measuring success) is an important aspect of a SOA initiative. But I'm not convinced that "cost reduction" and "increased agility" are bad goals -- they just need to be set up as long term goals. I don't think "create a service portfolio" is an appropriate goal. (It's a milestone rather than a goal.) The SOA team won't be able to justify continued funding just by building a service portfolio. A goal needs to represent demonstrable value to the business (i.e, cost reduction, faster time-to-market, improved employee efficiency, etc.)

Nonetheless, the IT team needs milestones. It needs a roadmap with well defined deliverables to measure progress on its SOA journey. So "creating a service portfolio" is a good milestone. And based on the trends we've seen, "creating a service portfolio" is not an easy milestone to attain.

HP/Systinet finally published GIF

Blogger: Anne Thomas Manes

Way back in April 2005, Systinet (now a part of HP) announced the Governance Interoperability Framework (GIF), which proposed to define standard formats and practices to enable interoperability among SOA infrastructure ecosystem products (service platforms, mediation systems, and management systems) via UDDI. At the time Systinet recruited about a dozen SOA infrastructure vendors to participate in a partnership  to implement support for GIF in their products. Most of these vendors implemented at least some support for GIF by mid 2006. But the program remained a proprietary partnership. Other registry vendors (e.g., Infravio and SOA Software) were not invited to participate in the program. I was very disappointed with the closed nature of the effort, and I railed repeatedly on Systinet to publish the specs in a public forum.

Now, nearly three years later, HP has finally published the Governance Interoperability Framework Reference specification. I've only given it a quick glance, but it appears to provide enough information to enable other UDDI-compliant registry vendors/users to configure their systems to act as a GIF hub. It also provides enough information for other infrastructure vendors to use GIF to exchange service metadata, policy, and management information.

The publication is not quite as open as I'd like -- you must register with HP and forfeit private information to gain access to the document. But at least it does not require acceptance of a license agreement or signing any type of partnership agreement. And the Copyright Notice is quite benign:

Copyright Notice
Copyright © 2008 Hewlett-Packard Development Company, L.P.
DISCLAIMER OF WARRANTEES. USER ACKNOWLEDGES THAT THE SPECIFICATION MAY HAVE
ERRORS OR DEFECTS AND IS PROVIDED "AS IS." HEWLETT-PACKARD MAKES NO EXPRESS OR
IMPLIED WARRANTIES OF ANY KIND WITH RESPECT TO THE SPECIFICATION, AND
SPECIFICALLY DISCLAIM THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, EVEN IF THAT PURPOSE IS KNOWN TO HEWLETT-PACKARD.
LIMITATION OF LIABILITY. HEWLET-PACKARD SHALL NOT BE RESPONSIBLE FOR ANY LOSS TO ANY THIRDS PARTIES CAUSED BY USING THE SPECIFICATION IN ANY MANNER
WHATSOEVER. HEWLETT-PACKARD SHALL NOT BE LIABLE FOR ANY DIRECT, INDIRECT,
SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER BASED ON CONTRACT,
TORT OR ANY OTHER LEGAL THEORY, ARISING OUT OF ANY USE OF THE SPECIFICATION OR ANY PERFORMANCE OF HEWLETT-PACKARD RELATED TO THIS SPECIFICATION. USER FURTHER ACKNOWLEDGES THAT THE SPECIFICATION IS PROVIDED FOR EVALUATION PURPOSES ONLY, AND USER ASSUMES ALL RISKS ASSOCIATED WITH ITS USE.

GIF defines a model that supports information exchange based on UDDI (v2 or v3, but v3 is recommended to enable subscription capabilities), WS-PolicyAttachment, and WS-Management. It supports information exchange related to service management, policies (constraints, configuration, and capabilities), dependency relationships, consumers and providers, property information, and management metrics. All-in-all, quite a valuable document.