CBDI Forum CBDI Web Services Roadmap. Guiding the transition to Web Services and SOA
 
CBDI Knowledgebase

Web Services Roadmap Planning cont'd...

Plan & Manage Stream

Topic Area
Deliverables
WS Maturity Phase Applicability
1
EL		 2
INT		 3
RE		 4
MAT
Service strategy Agreed roadmap - Organizational consensus on the overall plan for transitioning business and technology environments, synchronizing relative maturity of capabilities and applications   Y Y Y
Business and Technical Justification Identified Business Opportunities
Support to Technical Strategy		   Y Y  
Coordination, Communications & Policy Management Identified areas for cross organizational coordination
Mechanisms for cross organizational policy setting, projects support, decision making		 Y      
Funding & Charging Funding Strategy & Policy   Y Y  
Organizational change Roles and responsibilities   Y Y  
Classification systems Common classification policy and schemas Y Y    
Service Level Management SLA policies - levels and processes   Y Y  
Monitoring and reporting Management policies and systems   Y Y Y
Marketing Promote common services   Y Y  

Table 1 - The CBDI Roadmap Framework - Plan and Manage Stream

The transition to a more federated environment, enabled by SOA, requires the development and coordination of common policies and practices between the parts of the federation. The management stream provides a clustering of topics and deliverables required to establish these.

Service strategy

Generally the requirement for, and understanding of a service strategy will surface after only after early learning experience has demonstrated the need for common services, classifications and agreements. However our observation is that the strategic nature of service orientation as it applies to an enterprise is likely to develop progressively over time. An important factor in this is business management understanding. In our survey, carried out in early 20031, there was very low awareness outside of technical management, and this will take time to permeate outside the IT world, given the relatively slow take-up of Web Services and the dismal economic climate which militates against IT led investment. Also from the IT perspective in the archetypal enterprise, there is much work to be done in creating a critical mass of existing and legacy applications in an SOA, before real cross enterprise business advantage will be perceived.

The roadmap concept is therefore recommended as a living deliverable, which will in the early stages reflect the technical nature of the tasks at hand, but will allow technical managers to communicate in understandable terms how and when the IT investment will support new business models.

Business and Technical Justification

A key part of the roadmap process is guiding the use of new technologies appropriately. Many organizations have moved slowly with Web Services because they do not have clear justification for implementing new protocols, and particularly the necessary infrastructure and management environment, when existing arrangements work entirely satisfactorily.

In our research on ROI and cost justification2 we have primarily focused on benefits to specific and individual applications in terms of productivity, quality, ease of integration and enablement of new business models. In the context of Roadmap planning there is the additional opportunity to take an enterprise wide view of the infrastructure investment and returns.

Coordination, Communications & Policy Management

Many organizations do not have mechanisms for enterprise wide policy setting. More than a few enterprises tell us they deliberately operate different technical and application sourcing policies in order to segregate business divisions. Those organizations that have already been developing intra and inter company document exchange based on XML will have established organizational mechanisms to manage document content semantics and schemas, and also transport, document security and guaranteed delivery arrangements. With Web Services the cross and inter enterprise coordination requirements expand to include service level agreements, contract agreements, process choreography and service management.

Funding & Charging

You may think that charging automatically moves to a "per service" basis, simply because it's made easier by a) the business transaction relevance and b) the management and monitoring systems that make per service billing easy. However think before you charge, because all of the time honored intricacies of charging apply here also, and free, partial per service and many other arrangements may apply. It's all about behavior modification through the pricing mechanism.

The most important principle is that many Web Services will not be chargeable at all - because the Web Service is an intrinsic component of a business service or transaction. So the purchaser of a book from Amazon pays for the book, which in some manner subsumes the cost of providing the service. But clearly there will be some level of internal accounting within Amazon that accounts for product costing. We can rationalize this as two different classes of Consumer charge

  1. usage charging, charging someone for using the service, and
  2. cost recovery, charging for the execution of the service, which is often most relevant when the service is provided to the end user at no charge.

We discussed usage charging in our report Component Pricing3. We suggested that at this early stage, we are inclined to the opinion that the well known Boston Grid will be the dominant influence in macro pricing strategy. Subscription-based pricing seems particularly appropriate for mature products - which may represent "cash cows" for the suppliers - where the users usually know what they're getting. "Cash cow" is one of the four stages of the product lifecycle, known as the Boston Grid. Other stages of the product lifecycle probably need other pricing schemes, as shown in the table.

Product stage
Market dynamics
Market share
Objectives
Pricing model
Problem child growing small Develop product. Encourage experimentation Low unit pricing.
Rising star growing large Maintain market share. Encourage customer roll-out, Site licenses. Volume discounts.
Cash cow stable large Maintain long-term revenues from product Subscription-based licence
Dying dog stable small Transfer customers onto alternative products  

Table 2 - Boston Grid

In the report we went on to say - Although subscription pricing remains rare for software components, it has sometimes been predicted as the dominant model for Web Services. However, we believe it would be incorrect to assume that Web Services will automatically be priced in this manner. Whilst consumer Web Services (B2C) may largely adopt subscription pricing, business (B2B) Web Services are much more likely to be an integral part of a product (bundled) or priced in some manner that modifies behavior.

Organizational Change

Service architectures introduce clear separation, with a high level of formality between provider and consumer. In the early learning stages things will remain pretty much unchanged. But as soon as services are better understood there's massive potential for productivity and quality gain.

Many organizations that embraced component based development (CBD) implemented significant levels of separation between the supplier and consumer of a component. This base concept is fundamental to the service world, but for services we have the addition dimension of design time and run time reuse. In Figure 2 we show a real world perspective where we have new parties involved and changed responsibilities in the process:

  • Developer - yes of course the developer still exists, BUT now the developer is providing to the provisioner who undertakes the publishing tasks.
  • Process Owner - the process owner's view is now entirely service based. The process owner specifies, acquires, assembles, tests and deploys services.
  • Provisioner - the provisioner is a new role, that may well take responsibility as an intermediary, as a BPO operator or application provider to provide the entire life cycle of a service.
  • Collaborator - the essential part of a service is that there are two parties to the use of a service. The collaborator is tracking a parallel view of the service throughout the life cycle.

Figure 2 - The Evolving Organization

As the organization matures its use of services, roles and responsibilities will change. For example who undertakes the testing process? In the early stages as services are part of projects, budgets may dictate that the services are simply developed and tested and consumed as part of a common process - Though we might actually disagree and would advise against, but we accept reality sometimes makes this difficult. But as services become shared between projects, then across the organization and SLA's are required, it is essential that some form of (independent) certification comes into play.

Classification systems

Services are only useful if they can be found, and managed. Many are dismissing UDDI because they think that they will only use services that they already know about. They are ignoring the power of a directory as the basis of managing the service life cycle.

Our observation is that classification systems are going to evolve. It's important to set policies for specific issues such as versioning, usage, certification and so on, but it's also very important to allow developers and projects to extend the classification system to accommodate new requirements.

Actual QoS; Certification; Platform Class; Conformance; Configuration; Criticality; Deployment; Capability; Funding; Ownership; Pricing; Target QoS; Taxonomy; Security Class; Service Level; Usage Policy; Version

Box 1 - Example Classification Criteria

Service Level Management

SLM is closely related to classification. Part of a classification system needs to provide information on service level policies. In most enterprises the SLM policy will be established on an enterprise basis, covering two primary dimensions:

  • Service trust - allows the provider to offer the service in a manner that is fit for purpose, and for consumer to easily understand the context in which it can reasonably be used. Service trust classification data includes - source, certification, protocol profile conformance, warranty, reusability, customer rating, security etc

  • Service operations - allows the provider to establish standards, practices and platform products that are clustered around levels of operational guarantee. Service operational classification data includes - availability, reliability, performance, capacity, security, pre-requisites etc

Early learning and integration stage activity will use SLM classifications that have been developed specifically for the enterprise. However standards will evolve in this area, particularly in industry sectors and ecosystems where collaborations are implementing wide area business processes.

Monitoring and Recording

Services are a product, and the separation of provision and consumption creates the obligation on the provider to deliver service according to some form of agreement. Standardized classification taxonomies for operational guarantees and service trust characteristics provide the basis for enterprise standard monitoring and recording. A key part of establishing confidence in a Web Service is providing the infrastructure that allows customers and suppliers, and just as important disparate parts of the enterprise, with consistent and timely feedback on the performance of services provided.

Marketing

Yes, services are going to need marketing! Services are products, and must be sold to potential consumers. The prior two topics, classification and monitoring are the basics of marketing, - it works, let me prove it to you! However beyond the basics there is a requirement for a product life cycle approach to services. For some organizations this is as simple as managing specification in a collaborative manner that maximizes reuse. However for others the service will be a front line business product, where the technical aspects of the delivery are really trivial, compared with the complexities of market research and development. Our report on the BT authentication service4 is a good example of this latter category, and is covered in the next topic.

Services as business products

Financial services organizations in particular have for some time now understood the concept of information as a product. Some organizations such as Amazon are moving rapidly to use the easier and deeper integration capabilities of Web Services to create extended products, particularly for their affiliates. It is notable that in the Amazon case, this productization is clearly early learning for Amazon also. However by the time organizations reach the third, reengineering stage of Web Service usage, it is to be expected that many enterprises will be offering Web Services as products, or as an integral part of pre-existing and or new core business products. What is particularly important to note here is that innovative enterprises such as Amazon, and BT mentioned earlier, have already embarked on R & D for integrated products. The lesson that financial services organizations have learnt long ago, is that the critical path is the business product, not the technology. Over and again we hear the comment that the technology is easy by comparison.

Security and Trust

In the past we have protected enterprise assets by erecting high walls which prevent access at a transport level; it is assumed that inside the high walls everyone is to be trusted. Today we recognize the inadequacies of these assumptions. We now understand that blunt instruments are inadequate, and that finer grained control over access and usage is essential. Web Services provide that finer grained control, BUT have the potential to increase exposure to greater levels of risk.

We also understand that security is never absolute; the best technical security will always be under threat from determined individuals. What we need are levels of protection that are relevant to an individual business service, which are an intrinsic part of the service design. The application level security oriented business logic, is then used in conjunction with broader grained security mechanisms which in combination create a trusted environment. Security creates barriers, trust establishes confidence that the service provides the advertised capability with understood and acceptable levels of risk.

As a consequence, delivering security and trust is increasingly the concern of everyone involved in the service life cycle. In planning Web Service and SOA related activity, it is a vital task to establish policies that define acceptable levels of risk in context with the specific business, and to implement these with new or altered roles and responsibilities as appropriate.

References

  1. CBDI Web Services Usage Survey, February/March 2003
    http://www.cbdiforum.com/bronze/webserv_usage/webserv_usage.php3
  2. CBDI Report - Inside Every Web Service is a Benefit Struggling to Get Out
    http://www.cbdiforum.com/bronze/inside_web.php3
  3. CBDI Journal Report - Component Pricing, July/August 2001
    http://www.cbdiforum.com/secure/interact/2001-08/comp_pricing.php3
  4. CBDI Journal Report - The BT Authentication Service, April 2003
    http://www.cbdiforum.com/secure/interact/2003-04/bt.php

Contents...


Previous Page Next Page
CBDI Knowledgebase

  © Everware-CBDI Inc 1999-2008