CBDI Journal March 2009 Consolidated Text Final2everware-cbdi.com/public/downloads/537sx/Journal2009-03.pdfMarch 2009 Editorial Rich Service Specification Best Practice Report TOGAF

March 2009

Editorial Rich Service Specification Best Practice Report TOGAF 9 complementing SAE practices The recently released TOGAF 9 provides an important standard for Enterprise Architecture that will be widely used. In this report we provide guidance on how TOGAF 9 can be used to good effect in the overall Service Architecture and Engineering process. By Richard Veryard and David Sprott Product Report IBM WebSphere Service Registry and Repository (WSRR) This report takes a look at the capabilities provided by the IBM WebSphere Service Registry and Repository. We explore the customization and extension capabilities provided to understand the support for the meta models inherent in Service Lifecycle Automation and SOA Configuration Management as discussed in recent reports. By Lawrence Wilkes

Independent Guidance for

Service Architecture and Engineering

ISSN 1745-1884

CBDI Journal © Everware-CBDI Inc. March 2009 2

Editorial Rich Service Specification

Four years ago CBDI published a service specification template1. At that time we commented, “Once the main requirements for a software service have been established, we recommend that a comprehensive service specification is put together. This defines the service interface, the quality of service, the standards followed and the functional service behavior. While this is demanding to produce, the rich specification remains of value throughout the service life cycle.”

We used the notion of a “rich” service because at the time a service specification was commonly understood to be the SOAP and WSDL. Our advice was and is that the Web services protocols are the foundation on which we need to define the business behaviors that allow a consumer to fully

interact with the service.

Since then many CBDI members have followed this guidance, using the template which we have made available through our education classes and knowledgebase. We have received a good few examples for review and comment over the years. Most template users have customized the template a little – mostly to make it easier to understand!

We have always advised that a good service specification is unlikely to be a trivial task. Its fundamental purpose is to establish a rigorous specification of the service behaviors in a manner that allow the consumer to use the service without needing to know any implementation details. This means we need to define details such as operation sequencing, data responsibilities and pre and post conditions. While pre and post conditions have been around for a while (the late ‘60s), they won’t necessarily be the most well known technique.

For example:

CONTEXT: MathsService::Square-Root (in a:number, out b:number)

PRE CONDITION: input field “a” is positive or zero

POST CONDITION: output field “b” is square root of “a”

A really good example of this technique was documented by Bertrand Meyer2, pioneer of “design by contract” back in 1997. He used the example of the Ariane 5 rocket that crashed shortly after takeoff due to a software error. It was an integrity constraint that was invalidated. If pre-conditions had been checked the crash would not have happened.

Clearly we don’t make a virtue of complexity, but it is necessary complexity, not for its own sake. A well defined service specification is unlikely to be a user friendly document; it’s

We have always advised that a good service specification is unlikely to be a trivial task.


likely to be very detailed and rigorous. It’s not a replacement for a statement of user requirements, rather it is a more detailed, rigorous statement of requirements.

You may be thinking “but hang on, a rocket control program may need that level of rigor, but surely for most business services this sounds over the top?” Actually not so. Our experience is that if you don’t sort out this level of detail at requirements, then it gets done by the developer, or worse the tester. So we advise that the “rich service specification” is useful for any non trivial service. And the payback is:

• The implementation really can be encapsulated

• The spec forms an excellent basis for governance – validation of requirements

• Also an excellent basis for creating rigorous test scripts. Consider getting the test team to validate the service spec together with the use case by developing the test scripts, as a highly effective governance practice.

Last week we decided to make our rich service specification template available to all. We don’t think there’s any chance, or even need for a standard specification template. But we DO think there’s real merit in getting wider awareness of the need for some form of rich service specification.

In addition to the service specification CBDI provides many templates for SOA deliverables in the SAE Knowledgebase. Most of these shouldn’t be stored in Office tools, rather in a registry repository. It just so happens this month we are reporting on IBM’s Registry Repository (WSRR) which illustrates this idea very well. Also this month we have a detailed guidance note on TOGAF 9 that now includes a service contract template which bears strong resemblance to the CBDI specification.

David Sprott, Everware-CBDI February 2009

1 Practical Service Specification and Design Part 3: Specifying Services http://www.cbdiforum.com/secure/interact/2005-06/practical_serv_spec_pt3_specify_serv.php 2 Design by Contract: The Lessons of Ariane http://archive.eiffel.com/doc/manuals/technology/contract/ariane/page.html

CBDI Forum links on Service Specification Download Specification Template: 0Hhttp://cbdi.wikispaces.com/Service+Specification

CBDI Forum links:: Home: 1Hwww.cbdiforum.com

Resource Portal: 2Hhttp://cbdi.wikispaces.com/

Forum: 3Hhttp://www.linkedin.com/groups?gid=1464387

CBDI Forum is the research capability of Everware-CBDI providing independent guidance on best practice in service oriented architecture and related delivery processes.


Best Practice Report - TOGAF 9 complementing SAE practices The recently released TOGAF 9 provides an important standard for Enterprise Architecture that will be widely used. In this report we provide guidance on how TOGAF 9 can be used to good effect in the overall Service Architecture and Engineering process.

Richard Veryard and David Sprott

Introduction The new version of TOGAF 9 - the Enterprise Architecture framework from the Open Group was released last month1. We have reported on TOGAF previously2 and will not repeat the basics here. Suffice to say TOGAF is an Enterprise Architecture (EA) Framework, and an increasingly widely accepted standard. The framework includes:

• a foundational structure, or set of structures, which can be used for developing a broad range of different architectures

• a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together

• a set of tools

• a common vocabulary

• a list of recommended standards and compliant products that can be used to implement the building blocks.

As is to be expected there is significant overlap with CBDI’s Service Architecture & Engineering (SAETM). But also unsurprisingly TOGAF and SAE are highly complementary.

TOGAF SAE Architecture Development Methodology addressing many architectural styles

SOA specific methodology spanning adoption, architecture, provisioning, governance and management

Structural guidance for architecture best practice

Detailed methodology and framework for SOA best practice

An open framework designed to be customized and extended

A technology and vendor independent methodology that can be customized and extended for specific technologies, platforms and application domains

Table 1 – TOGAF 9 and SAE

In this report we look at how TOGAF 9 has been enhanced to explicitly support SOA, and how TOGAF and SAE may be used in conjunction in support of both architecture and delivery activity.


How TOGAF 9 supports SOA TOGAF 9 now recognizes SOA as a core architectural style specifically intended to simplify the business, and interoperation of different parts of a business, with the objectives of avoiding duplication and standardizing behavior in order to limit the impact of change. There are some important new features in TOGAF 9 that improve the support for SOA.

Business-Led SOA Shall we see SOA as a software engineering challenge or a business opportunity? TOGAF 9 makes a clear and unequivocal statement in favor of the latter, and identifies the following characteristic features of Business-Led SOA.

• Rich domain knowledge of both horizontal, cross-cutting concerns, such as human resources (HR), finance, and procurement plus vertical, industry-specific concerns

• A structured, quantitative understanding of business value, costs, differentiators, and quality measures

• Broad understanding of current capability, showing both business capability and how it is supported by IT

• Broad understanding of the feasibility and viability of particular SOA technology-driven solutions

This is contrasted with "a technology-centric, developer-led SOA community that maintains a core focus on the similarities across industries, organizations, and products to achieve benefit". (In other words, an emphasis on standardization, and the one-size-fits-all economics of scale characteristic of the technology-centric approach, are complemented with an emphasis on business capability within a specific business context.)

Enterprise architecture is then positioned as "a set of tools and techniques to link top-down business-led SOA to bottom-up developer-led SOA". Enterprise architecture becomes "a foundation for service-orienting an organization". (In other words, enterprise architecture is what puts the A into SOA.)

Technology-centric SOA already makes a clear distinction between the specification of a software service (sometimes known as the service contract), and the implementation and deployment of this service. Business-led SOA applies the same principle at the business level: "Defining business services allows an organization to differentiate between business capability, the fulfillment of business capability, and the consumption of business capability".

In other words, enterprise architecture supports service-orienting the business, not just service-orienting the applications. Service-orienting the business doesn't just involve IT reengineering, and "justifying the cost of IT reengineering against business value", but also business reengineering.

This enhanced emphasis on the business within TOGAF 9 fits well with the business focus already contained within CBDI’s SAE method.

Business Capability Management Following the lead taken by CBDI and others including the architectural frameworks of the defense world (DoDAF and MODAF), TOGAF 9 applies a high-level concept of business capability to the service world.


TOGAF 9 includes a method of Business Capability Assessment that follows a similar pattern to IT Capability Assessment. This is also similar to the approach adopted by CBDI in its SAE methodology, where similar techniques of capability management (including capability modeling and dependency analysis, capability assessment and gap analysis, and capability planning) can be applied equally to business capabilities (in the context of business modeling and business improvement) and SOA capabilities (in the context of SOA adoption).

CBDI has been recommending business capability modeling for many years, and has developed some leading-edge techniques for capability analysis, including capability dependency diagramming.

Specific EA Support for SOA TOGAF 9 sets out the requirement for a set of tools for use in an EA context to link top-down business led SOA to bottom up developer led SOA including:

• Traceable representations

• Principles, constraints, frameworks, patterns and standards.

• Linkage of many perspectives to a business problem.

• Consistent abstractions of top-down and bottom up deliverables that can be collated in a shared repository.

Content Metamodel TOGAF 9 now includes key concepts central to SOA:

• Function

• Business Service

• Information System Service

• Application Component

• Technology Component

Modified Architecture Development Model The ADM has been modified to include SOA concerns at the various stages:

ADM Stage TOGAF 9 SOA Concept Integration

Preliminary The TOGAF framework provides a metamodel and process that is capable of incorporating both business-led and developer-led SOA concepts

Architecture Vision The TOGAF ADM includes specific steps to address SOA concerns, including:

• Consideration of business capability

• Consideration of technology capability

• Consideration of IT governance impacts

Business Architecture The Business Architecture phase elaborates the capabilities of the business and defines explicit portfolios of business services, accompanied by service contracts that formalize service consumption.


Information Systems Architectures

The Information Systems Architectures phase shows how the identified business services map to applications and data.

Technology Architecture The Technology Architecture phase shows how application capabilities identified in the Information Systems Architecture are mapped onto SOA platforms and off-the-shelf SOA services, providing a blueprint for implementation.

Opportunities & Solutions Migration Planning

The TOGAF ADM allows for identification of improvement opportunities and then selection, prioritization, and sequencing of those opportunities according to architectural analysis and stakeholder need.

Implementation Governance

TOGAF provides specific processes for design governance during the implementation of an architecture.

Architecture Change Management

TOGAF allows for implementation issues and external factors to be incorporated into the architecture, allowing the overall approach to be refined.

Table 2 – Summary of ADM SOA Guidance by Stage (Source Open Group)

Guidelines for Service Contract Definition TOGAF 9 now includes explicit mention of service contracts – formal agreements that define services and the terms of the information exchange between providers and consumers. The contract is defined as a set of metadata that describes how the parties will interact both functionally and non functionally.

Governance considerations for service contracts are discussed and there are some contract details including a Service Contract Template. This is a useful contribution which actually looks gratifyingly similar to the CBDI Rich Service Specification3. Strangely the TOGAF guidance includes a separation between a Governance Contract and an Operational Contract, which is not reflected in the detailed template. The following table provides an outline mapping between the TOGAF Service Contract Template and the CBDI Rich Service Specification. (A more detailed mapping will be found in the SAE Knowledgebase).

General TOGAF Service Contract

SAE Service Specification

Comparison

General Properties

Name, Reference, Description

Name, Reference, Aliases, Purpose

Broadly equivalent

Architectural Type (i.e. Architectural Layer)

Portfolio Layer, Dependencies, Domain


Business Properties

RACI, Service Called, Service Called-By, Functional Requirements, Importance to the Process,

Purpose, Domain, Business Ownership, Target Consumers, Business Process Support, Business Objective Support, Critical Success Factors

Similar in scope, but different in detail.

Note that TOGAF uses RACI (responsible, accountable, consulted, informed) while CBDI uses RAEW (responsibility, authority, expertise, work).

Provisioning Properties

Owner, Source Source / Provider

Standards Compliance

Customization Support, Standardization Support

Implementation Instructions

Deployment Instructions

Quality of Service

Contract control requirements, Result control requirements, Quality of service, Service Level Agreement

Not included CBDI recommends that the Quality of Service is described in a separate Service Level Agreement (SLA). There may be multiple SLAs for a given service in different use-contexts.

Performance & Security

Throughput, Throughput period, Growth, Growth period, Service times, Peak profile short term, Peak profile long term, Response requirements

Execution Frequency, Availability, Reliability, Throughput, Response Times

Security Security requirements Performance, Message Integrity, Privacy, Authorization, Non-repudiation


Operation Behaviour

Invocation

Invocation preconditions,

Business objects

Behavior characteristics

Operation Signatures

Mandatory Operation Sequences

Service Information Model

Operation Specifications including Pre and post conditions for Successful and Exception cases.

This is where much of the detail in the SAE Service Specification can be found.

Note that much of this detail (e.g. preconditions and postconditions) needs to be specified for each service operation rather than for the service as a whole.

Configuration Management

Version Status, Predicted Stability, Release Information, Specification History

Table 3 – Comparison of TOGAF 9 Service Contract and SAE Rich Service Specification

Architecture Principles In TOGAF 9 we see a significant change in that it explicitly identifies Service Orientation as a major architectural principle, which was really only implicit in TOGAF 8. Quite reasonably TOGAF illustrates principles by way of example because there may be application domains where certain principles are not applicable or lower priority. But in the set of examples given in TOGAF 9, Service Orientation is defined in the business principles along with primacy of principles, benefit to the enterprise, information management, business continuity, common use, compliance with the law etc.

Using TOGAF 9 and SAE Whilst there is no absolute conflict between TOGAF 9 and SAE, it is clear that SOA has been incorporated into TOGAF as simply another style that is required to fit within an existing conceptual framework. See Table 4 and 5 for detailed comparisons. This causes some issues that need to be addressed:

• TOGAF 9 treats the Service Contract as an encapsulation of application functionality and part of the Application View. In contrast SAE defines a separate, application independent Specification View. CBDI would be concerned that the TOGAF 9 approach may compromise the logicality of the service specification, and potentially suboptimize the use of the service independent of a specific application.

• Similarly the Technology Component is not a direct equivalent of an SAE Automation Unit (AU). The AU is a conceptual view of the implementation that is separate and many to many with the deployable artifacts. This approach allows strong architectural governance over the implementation architecture and design and traceability of SOA Policy across all architectural Views.

• By continuing to view SOA as just another architectural style TOGAF 9 does continue to use pre SOA terminology that will inevitably confuse. See Table 4


for details but notable is the continued use of service in its most generalized sense. SAE users will probably wish to selectively adopt TOGAF 9 metadata and extend with the more precise and consistent SAE concepts.

TOGAF Metamodel

Brief Description SAE Metamodel

Comment

Actor A person, organization, or system that is outside the consideration of the architecture model, but interacts with it.

Person In the SAE Metamodel, Person and Actor are linked via Role-of-Party. There is an obvious and potentially confusing difference in terminology between the TOGAF metamodel (Actor-Role) and the SAE metamodel (Person-Actor).

Application Component

An encapsulation of application functionality that is aligned to implementation structuring.

Service Specification

The service specification is identified as a unit of application functionality. It is not the implementation of this functionality, but may be aligned to an implementation (known as an Automation Unit).

Business Service

Supports business capabilities through an explicitly defined interface and is explicitly governed by an organization.

Business Service

The SAE metamodel contains the concept of Business Service within the Business Modeling Package.

However, this concept is not fully articulated in the current version of SAE. The Business Service Architecture is not composed of Business Services but of Notional

Data Entity An encapsulation of data that is recognized by a business domain expert as a discrete concept. Data entities can be tied to applications, repositories, and services and may be structured according to implementation considerations.

Business Type

SAE defines a business type as a category of business object, the instances of which your company needs to keep track of in its computer systems. There seems to be an important difference between TOGAF 9 and SAE insofar as the business type is always independent of implementation, and definitely not tied to applications.


TOGAF Metamodel

Brief Description SAE Metamodel

Comment

Function Delivers business capabilities closely aligned to an organization, but not explicitly governed by the organization.

Business Capability

In TOGAF business capability is defined rather loosely. In SAE capability is a defined concept and in the reference architecture the Capability Service is a discrete layer. This may be regarded simply as an example of where SAE provides more detail and specialization of the concepts in the service architecture.

Organization A self-contained unit of resources with line management responsibility, goals, objectives, and measures. Organizations may include external parties and business partner organizations.

Party, Organization Unit

Party: A body that can perform actions and make decisions. A generalization of Organization Unit, Person and Post.

Organization Unit: An enterprise or some other legal entity, or a subdivision of such.

SAE models are generally more detailed and more generalized.

Platform Service

A technical capability required to provide enabling infrastructure that supports the delivery of applications.

Environment Capability

SAE: A facility available within an Execution Environment.

TOGAF 9 inherits concepts from pre SOA days when “service” was used in a non specific manner. In today’s SOA world, a consistent vocabulary that facilitates communication is rather important.

Role An actor assumes a role to perform a task.

Actor See comment above

Technology Component

An encapsulation of technology infrastructure that represents a class of technology product or specific technology product.

Automation Unit

Automation Unit can be a service implementation or a legacy application/component

In the CBDI SAE Metamodel, it is the automation units that are associated with architecture layers.

Table 4 – TOGAF 9 and SAE Concepts Compared


BusinessService

OrganizationalObjective

ApplicationComponent

TechnologyComponent

deployed onto

deployed onto

supports

*

* *

*

*

*

BusinessService

Business ServiceSubject

ServiceSpecification

AutomationUnit

detailed in

realized by

handlesrequirements of

*

* *

*

*

*

TOGAF Metamodel (extract) SAE Metamodel (extract)

Table 5 – TOGAF 9 and SAE Metamodels Compared

Using TOGAF 9 ADM and SAE Having discussed the significant SOA relevant upgrades in TOGAF 9 let’s now look in some detail at how these impact each of the ADM Phases.

Preliminary Phase The TOGAF Preliminary Phase is concerned with setting up the architectural capability for an enterprise. To establish committed sponsors and stakeholders; to identify scope and capabilities including people and responsibilities. A major part of the phase is to define the architecture principles, frameworks and detailed methodologies and tools, and to ensure an appropriate governance framework is in place.

We might observe that for many organizations the Preliminary Phase in context with SOA has been missed completely, and there is a real need to retrofit the SOA specific capabilities into existing architecture practices.

TOGAF 9 provides general guidance in terms of the approach, enterprise and organizational context and management frameworks but is not specific and detailed in guidance on SOA.

In contrast as you might expect, SAE provides detailed and SOA specific guidance on all of these topics. TOGAF 9 does advise relating the various management frameworks including Business Planning, Operations Management, Portfolio/Project Management and Solution Development. We strongly recommend the framework needs to include the integration of SOA specific framework requirements. See Figure 1.

Another key element of the TOGAF 9 Preliminary Phase is planning for Change and Maturity Evaluation. TOGAF 9 like SAE uses the SEI CMM approach for architecture capability maturity. The SAE approach is very similar but a) covering the entire life cycle, not purely enterprise architecture and b) with some extensions specific to SOA:

• Comprehensive definition of capabilities for service architecture, but also showing how these are integrated with all the other disciplines.

• A defined assessment and reporting approach and toolkit


Figure 1 – Interoperability Between Management Frameworks to include SOA - Based on the TOGAF 9 Figure 6-3.

Whilst TOGAF is by definition an Architecture Framework, it does not provide a detailed Reference Architecture for SOA. Some general and outline guidance in the areas of separation of concerns and types of service is provided but this is not detailed nor does it approach the level of a reference architecture which establishes detailed guidance and policy. In contrast SAE provides detailed guidance on establishing a reference architecture as well as detailed reference architecture policy covering classification, layering, dependency rules etc.

TOGAF 9 Outputs Complementary SAE Assets SAE Work Packages

Organizational Model for Enterprise Architecture

SOA Maturity Model

SOA Roadmap Streams and Capability Areas

Roles and Responsibilities

SOA Status Assessment

Establish SOA Center of Excellence

SOA Adoption Roadmap

Tailored Architecture Framework including principles

SAE Reference Model

SAE Reference Framework

Principles

Establish SOA Reference Framework

Initial Architecture Repository

SAE Meta Model Establish SOA Reference Framework

Restatement of business principles, goals, drivers

SO Business Modeling and Business Improvement Processes

Determine SOA Objectives & Strategy

Outline SOA Business Case

Governance Framework SAE Governance Framework SOA Governance Assessment

Table 6 – Detailing the Preliminary Phase using SAE Assets and Work Packages

Business Planning Enterprise Architecture

Operations Management

Portfolio / Project Management

Solution Development

Business Direction

Runs the Enterprise

Structured Direction

Delivers

Delivers

ArchitecturalGovernance

ProjectManagementGovernance

Resources

ArchitecturalGovernance

Business ModelingSOAD

Solution Arch

Technology Arch

Delivery Mgt

Quality Mgt

Governance

GovernanceGovernance

Business Improvement

Solution Provisioning

Solution Assembly

Service Provisioning

Platform Design & Install

SOA Ops Mgt

Legacy Transition Plan

Adoption & ExcellenceBusiness Modeling

Business Improvement


Phase A: Architecture Vision The TOGAF Architecture Vision is concerned with creating a summary of the architecture and what it should achieve, for communication throughout the enterprise (and to obtain approval and funding).

Although TOGAF 9 now includes service-orientation as a key principle, most organizations will wish to implement SOA progressively across the enterprise, or according to specific business needs, rather than in a single leap – in other words, starting with a Solution SOA before progressing to Enterprise SOA. So the visioning and scoping of the Service Architecture will be a progressive process.

CBDI strongly supports the TOGAF approach to establishing architecture vision and goes beyond the support provided by TOGAF to provide guidance on SOA vision and goals.


Approved Statement of Architecture Work


Defined Process Units – Service Oriented Architecture & Engineering

Determine SOA Objectives & Strategy

Refined statement of business principles, goals and business drivers

SAE Principles (business)

Architecture principles SAE Principles (architecture)

Capability Assessment SOA Capability Assessment Workshop

SOA Status Assessment

Tailored Architecture Framework


SOA Reference Framework Workshop


Architecture Vision SOA Opportunities Workshop

Determine SOA Objectives and Strategy

Outline Business Model


Table 7 – Architecture Vision Phase Using SAE Assets and Work Packages

Phase B: Business Architecture The TOGAF Business Architecture is concerned with describing the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment, based on business principles, business goals, and strategic drivers.

As mentioned above, TOGAF now sees business architecture in terms of business capabilities – a view of business that CBDI has been promoting for some years now. Business capabilities lead naturally to the identification of business services, and of the information system services to support them. SAE provides detailed guidance on identifying and modeling business


capabilities that extend and support the general guidance provided by TOGAF on this concept.

We should also mention our early work on the Component-Based Business – an approach to structuring the business itself based on the principles of loose coupling – which quite frankly was far ahead of its time when we first published it.


Refined Architecture Vision

Business Model Scoping Workshop

Outline Business Model


Draft (Business) Architecture Document

Baseline Business Architecture

Target Business Architecture

Business Modeling Workshop

Process Guidance and Worked Examples for AS-IS and TO-BE Business Models including:

Business Concept Model

Business Capability Model

Business Process Model

Business Outcomes Model

Develop Business Models

Draft Architecture Requirements Specification

Service Descriptions (Outline service specifications)

Develop Business Service Architecture

Draft Architecture Components of an Architecture Roadmap

Solution Architecture

Table 8 – Business Architecture Phase Using SAE Assets and Work Packages

Phase C: Information Systems Architectures The TOGAF Information Systems Architecture is concerned with defining the major types and sources of data necessary to support the business (Data Architecture) and defining the major kinds of application system necessary to process the data and support the business (Applications Architecture).

For SOA, the applications and data will be designed and specified in terms of loosely-coupled services, within a service architecture. Therefore the service architecture becomes a key component of the Information Systems Architecture.

Clearly SOA has a major impact on the Application Architecture, which can now evolve towards a Service Architecture. The evolution of a Service Architecture is a key discipline within CBDI-SAE. The Data Architecture (known as the Business Type Model in SAE) is a


key enabler of the Service Architecture, as it drives the identification of core business services.

A key requirement for the Information Systems Architecture is to maintain interoperability between the new service-oriented applications and data, and the legacy systems. Within SAE, this is managed by the Legacy Transition Planning discipline.

This TOGAF Phase maps to the SAE Specification and Implementation Views. Whilst mechanically this is not a particular issue, CBDI would be concerned that tying the Service Architecture to an Application Architecture may seriously compromise the Service Architecture. In SAE, CBDI has created a Specification View to guide the development of the Service Architecture independent of implementation, which of course includes Applications. CBDI recommend TOGAF users introduce a Specification Architecture View as an important enhancement to TOGAF which will ensure the Service Architecture is developed to meet a broader set of needs.


Draft Architecture Definition Document

- Baseline and Target data and application architecture.

Detailed guidance and process for developing:

- Business Type Models

- Domain Models

- Service Specification Architecture

- Service Implementation Architecture


Draft Architecture Requirements Specification

Service Descriptions (outline service specification)

Information Systems Components of the Architecture Roadmap

Project Service Plan

Table 9 – Information Systems Architecture Phase - Using SAE Assets and Work Packages

Phase D: Technology Architecture The TOGAF Technology Architecture is concerned with delivering a specification of the technical solution at the level necessary to support implementation. In SAE the Architecture Views are broken out into Implementation, Deployment and Technology. The reason for this is to have clearer separation between different stakeholder perspectives.

The Implementation View provides a clear statement of the software components (sic) required to implement the Specification (logical) Architecture. The Deployment View separates deployment decisions. The Technology View separates the infrastructure decisions. The comparison of meta models in Table 5 illustrates the issue that easy to confuse Views, particularly implementation and deployment.


TOGAF 9 Outputs Complementary SAE Assets

SAE Work Packages

Baseline and target technology architecture including:

- technology components

- technology platforms

-

Service Implementation Architecture

Service Deployment Architecture

Service Technology Architecture

SOA Infrastructure Assessment

Establish Technology Infrastructure Strategy

Architecture Requirement Specifications

Automation Unit Specification

Table 10 – Technology Architecture Phase - Using SAE Assets and Work Packages

Phase E and F: Opportunities & Solutions, Migration Planning The TOGAF Opportunities and Solutions phase is focused on generating an overall implementation and migration strategy by evaluating implementation options, identifying parameters for change, and assessing dependencies, costs, and benefits.

The TOGAF Migration Planning phase is concerned with sorting the various implementation projects into priority order and creating a detailed Implementation Plan and Migration Plan.

SOA introduces some new options for provisioning services, so it may be a good idea to look at the procurement arrangements.

Another consequence of a service-oriented approach may be to affect the granularity of planning, so that we may have a greater number of fine-grained assets to plan and manage. This increases the need for formal tools to support this activity.

SOA Requirements Complementary SAE Assets SAE Work Packages

Architecture Roadmap Process and Technique Guidance for Service Portfolio Plan

Transition Architecture Process and Technique Guidance for Service Portfolio Plan

Implementation and Migration Plan

Process and Technique Guidance for Service Portfolio Plan

Governance Model SOA Governance Framework Customize SOA Policies

Implement Governance Program

Table 11 – Opportunities & Solutions, Migration Planning Phase –

Using SAE Assets and Work Packages


Phase G: Implementation Governance The TOGAF Implementation Governance phase is about developing and operating a process to ensure conformance with the defined architecture by implementation projects.

Good governance is a key requirement for SOA, and a comprehensive Governance Framework is a key feature of SAE.

In TOGAF governance guidance is provided in two ways:

1. There is a conventional approach to implementation governance that is focused on establishing the organization and processes necessary to ensure the implementation is compliant with the architecture.

2. In addition there is further guidance specific to SOA under the heading “Using TOGAF to Define and Govern SOAs. This section contain the useful Service Contract guidance referred to above plus very high level description of how the SOA architecture style extends the basic enterprise architecture framework.

TOGAF 9 users will find the SAE Governance Framework a useful plug-in – providing a highly specific framework for managing the SOA policy using four views - process, organization, infrastructure and maturity.

TOGAF Outputs Complementary SAE Assets SAE Work Packages

Architecture compliant solutions

SAE Governance Framework SOA Governance Assessment

Customize SOA Policies

Implement Governance Program

Table 12 – Implementation Governance Phase –


Phase H: Architecture Change Management The TOGAF Architecture Change Management phase is focused on establishing a process for the evolution of the new enterprise architecture in the light of developments in technology and changes in the business environment.

TOGAF 9 describes a change request driven, architecture change management process in which governance is exerted to establish whether the correct action is to update the architecture or to start a new ADM Cycle. TOGAF 9 also describes three drivers for change:

1. Strategic, top down directed change

2. Bottom up changes to correct or enhance capability

3. Experiences with previously delivered project increments.

SAE doesn’t include architecture change management and CBDI would be happy to recommend using a structure along these lines.

However SAE does provide detailed guidance on the creation and maintenance of a Service Portfolio Plan (SPP), and CBDI recommend this as a useful plug-in to TOGAF 9, providing a


structured approach to managing the life cycle of enterprise services. The portfolio approach is particularly relevant to SOA. It is a primary objective that the lower layers of services particularly remain highly stable and support a high level of change in the higher layers. Consequently there will need to be strong, business led governance over the entire portfolio that ensures there is appropriate standardization of business process and data that allows this managed stability/agility model to work effectively.


Managed architecture change SAE Reference Architecture

Service Portfolio Plan



Table 13 – Architecture Change Management Phase –


Requirements Management The TOGAF Requirements Management is concerned with managing the requirements lifecycle, and maintaining forward and backward traceability.

There is no SOA specific requirements management guidance in TOGAF 9. Users of TOGAF may adopt the methodology described in the SAE disciplines Business Modeling and Business Improvement which are specifically focused on establishing requirements that drive out well formed service architecture including requirements for agility.


Requirements Impact Assessment

Updated Architecture Requirements Specification

Business Modeling Process Unit

Business Improvement Process Unit

Service Portfolio Plan

SAE Reference Model




SOA Adoption Roadmap

Table 14 – Requirements Management Phase –



Preliminary

Requirements Management GovernanceRequirements Management Governance

Principle of Service-Orientation

Architecture Vision

Business Architecture Technology ArchitectureInformation Systems ArchitectureBusiness Architecture Technology ArchitectureInformation Systems Architecture

SOA Vision, Scope & Roadmap

Principle of Service-Orientation

SOA Roadmap

Opportunity & Solutions Migration Planning

Service Infrastructure

Service Architecture

SO Business Models

Figure 2 – Summary of the key SOA-related flows between the ADM phases.

Summary and Conclusions TOGAF is a generalized enterprise architecture framework applicable to varying architectural styles. TOGAF 9 provides some useful alignment with SOA architecture development at a fairly high level.

SAE is an SOA specific framework and methodology that covers a much broader life cycle footprint in great detail.

There is no absolute conflict between TOGAF 9 and SAE. There are many opportunities to use SAE assets and work packages to guide and inform detailed SOA activity.

TOGAF 9 remains a generic framework and in certain areas, particularly treatment of Views, this does raise some issues. These are very easily overcome.

Key CBDI Recommendations for TOGAF Users

1 • Create a set of business models (Business Capability Model, Business Process Model, Business Concept/Type Model) for the whole enterprise or a significant domain.

• Use these models to drive both Business Improvement and Service Architecture.

• Then the Service Architecture will support the Business Improvement.


2 • Develop the Business Capability Model to support Business Improvement.

• Analyze the Business Capability Model to separate generic capabilities (amenable to high levels of reuse and sharing) from differentiating capabilities. (We call this “triage”.) Use this analysis to drive the portfolio planning.

3 • Include the Service Portfolio Plan as a key deliverable within the TOGAF Content Framework (see below).

• Adopt SAE methods for defining and planning the service portfolio.

• Apply TOGAF / ITIL portfolio management practices to the service portfolio, for analyzing where to invest, prioritizing and allocating resources, risk management and financial modeling.

4 • Use SAE’s layered Service Architecture to provide a complete view of services across the enterprise continuum..

5 • Adopt a rigorous approach to service management and governance.

• Acquire and evolve the infrastructure to match the growing demand and sophisticated of the organization.

Table 15 – Summary Recommendations

EA Status SOA

Status Recommendation Next Steps

TOGAF 9 SOA and SAE

Congratulations!

TOGAF 9 SOA Incorporate SAE plug-ins and concept alignment as recommended

SAE Knowledgebase

TOGAF 8 SOA and SAE

Use SAE to facilitate the migration from TOGAF 8 to TOGAF 9

SAE Knowledgebase

TOGAF 8 SOA but not SAE

Consider adopting SAE to facilitate the migration from TOGAF 8 to TOGAF 9

SOA Roadmap

TOGAF 8 no SOA Moving to TOGAF 9 gives you an opportunity to adopt SOA. The SAE methodology is already aligned to TOGAF 9, so it is the obvious choice.

SOA Roadmap


EA Status SOA Status

Recommendation Next Steps

No formal enterprise architecture

SOA and SAE

SAE already contains some of the building blocks of enterprise architecture, but is not a full enterprise architecture methodology. Consider extending SAE with appropriate elements of TOGAF 9.

EA Roadmap


SOA but not SAE

Consider adopting SAE and TOGAF 9 in parallel, to get adoption synergies between the two.

SOA Roadmap


no SOA Explore the possible benefits of SOA and enterprise architecture within your organization.

SOA Opportunities Workshop

Table 16 - Decision Table: Next Steps

References SOA Source Book - a collection of source material for use by enterprise architects working with Service-Oriented Architecture comprising materials that have been considered and in part developed by The Open Group's SOA Working Group. http://www.opengroup.org/projects/soa-book/

1 TOGAF 9 http://www.opengroup.org/togaf/ 2 Previous CBDI reports on TOGAF:

• Service-Oriented Architecture Frameworks (December 2003) http://www.cbdiforum.com/secure/interact/2003-12/service_oriented_architecture.php3

• Enhancing the Enterprise Architecture with Service Orientation (October 2007) http://www.cbdiforum.com/secure/interact/2007-10/enhancing_enterprise_architecture_service_orientation.php

3 CBDI Rich Service Specification http://cbdi.wikispaces.com/Service+Specification

http://www.opengroup.org/projects/soa-book/


Product Report: IBM WebSphere Service Registry and Repository (WSRR) This report takes a look at the capabilities provided by the IBM WebSphere Service Registry and Repository. We explore the customization and extension capabilities provided to understand the support for the meta models inherent in Service Lifecycle Automation and SOA Configuration Management as discussed in recent reports.

By Lawrence Wilkes

Introduction As its name suggests, WebSphere Service Registry and Repository (WSRR) provides both a registry of Services as well as providing a repository capability to store documents that hold further metadata to detail them.

WSRR is not limited to Web Services, and can support services defined using a variety of other protocols and programming models. By using the customization capabilities provided it can also be used to define and store Service at a more conceptual level, such as Business Services. Customization can also be used to define the metadata and documents to describe just about any SOA asset type so these can also be stored in WSRR as well as their relationships to the Services.

WSRR also provides a customizable SOA lifecycle, together with Policy Management function that can be used to provide governance over the Service metadata and lifecycle within WSRR, as well as SOA policies that can be enforced elsewhere in the run-time environment, such as by an ESB.

In this report we look at WSRR capabilities and examine how the customization and extension approach might be used in support of the CBD-SAE approach.

This report is based on WSRR 6.2.

Content Structure and Meta Model WSRR ships with a sample Configuration Profile (called the Governance Profile) that contains various configuration files detailing the content types that can be stored, the classification systems used, roles, plus the lifecycle used to control governance.

Whilst the provided Governance Profile contains the basic structure for managing standard Service metadata such as WSDL files, IBM fully expects users to customize and extend the profile to capture further objects and define governance activities that the customer uses in their SOA approach.

Content held in WSRR is based on the following elements as shown in Figure 1:

Service Description Entities These are either,

• Documents: Documents containing structured service metadata. This includes


o Standard-based schemas for describing Services such as

Web Service Description Language (WSDL)

Service Component Definition Language (SCDL) for Service Component Architecture (SCA) Services

o Policy Documents. For example, conforming to WS-Policy

o User-defined documents in XSD or just XML. For example, these might be schemas for business objects or business messages that are standardized within a particular vertical industry, that might form the basis of a service specification.

o Other types of document can be loaded into WSRR , such as Microsoft Office documents (e.g. a Word description or a Vizio diagram)

o Documents can also be broken down into logical objects (derivations). For example, a WSDL Document can be parsed into logical objects for each of the interfaces, messages, bindings, and so on.

• Concepts (business objects): Allows the user to define any generic object that doesn’t have an associated document type. It may just be a pointer to content held elsewhere, such as in a development tool. A Concept can also be used to group documents.

Figure 1 - WSRR Home Page

Service Description Metadata This defines the various additional metadata that may not already be part of a document. This includes metadata such as


• Classifications. Including industry standard service classifications, or user defined. For example, adding classification of Services according to SAE Service Architecture Layers

• Relationships. Associations to other documents or concepts

• Properties. Whatever further properties the user wishes to add

Services can therefore be represented and managed in WSRR in a number of ways.

For example, a Business Service - a service provided by the business, irrespective of whether it is implemented in software or not - could be managed as a Concept, whereas its implementation can be managed as a WSDL Document.

These can then be associated together via relationships, so that the conceptual Business Service can be traced though to its realization as a Web Service.

WSRR enables objects and their relationships to be viewed graphically as well as via the text-based explorer, as shown in Figure 2 where the logical derivations of a WSDL file are visualized.

Figure 2 - Graphical View of WSRR Content

Business Model Templates Concepts can be created from scratch, or more likely created from a Business Model template that ensures all instances of similar concepts follow the same structure. The naming is probably a little misleading as the use of templates is not limited to defining Business Models or Business Objects. Rather they are used to define the properties and relationships for any object the user wants to manage as a Concept in WSRR.

Classification Classifications enable the content of WSRR to be more easily searched, filtered or navigated. For example, classifying Service Types according to Service Architecture layers in SAE.

Classifications should not be used as a substitute for modeling objects. For example to show which Services belong to a business domain, you could create the business domain as a


concept, and then make relationships to the Services it contains. However, if you have no need to store any additional properties about business domains or create further relationships to them, then a simple classification may be sufficient.

Web Ontology Language (OWL) Both Business Model Templates and Classification systems in WSRR are defined using Web Ontology Language (OWL) files.

Whilst OWL may be a powerful mechanism for architects, it is nevertheless perhaps a bit more daunting than simply allowing users to define new objects and their properties quickly via a UI.

However, it means a certain level of governance is inherent in the OWL structure and WSRR can then enforce those rules without having to write additional policies or rules elsewhere.

In the case of the classification system this can be built by using the WSRR Web UI and saved as an OWL file, or by importing the OWL file from some other source.

However, the OWL files for Business Model Templates must be imported. You could build these by hand, or preferably use tools such as IBM’s own Integrated Ontology Development Toolkit1 that is available via their alphaWorks program.

Service LifeCycle and Governance The default Configuration Profile contains a lifecycle based on the IBM SOA Foundation life cycle. This includes the stages: model, assemble, deploy, and manage.

Figure 3 - WebSphere Integration Designer (WID) used to define Service Lifecycle


The lifecycle can be customized, or a new one defined using WebSphere Integration Developer (WID). The lifecycle defines the permitted states, transitions allowed between states, conditions for transition, and actions that are upon transition.As an example, the life cycle state machine diagram for the IBM SOA Foundation life cycle is shown in Figure 3.

WID creates State Adaptive Choreography Language (SACL) files containing an XML representation of the State Machine. An example of SACL is shown below. These could be defined manually without WID.

<sacl:mainStateMachine> <sacl:state name="State1"/> <sacl:compositeState name="CompositeState1"/> <sacl:transition name="transition1"/> </sacl:mainStateMachine>

Example of SACL (source IBM)

As a final step, the SACL files must also be turned into an OWL file. At least this is done by WSRR.

WSRR only allows one SACL file to be loaded at a time. This is not as constraining as it might sound, as a SACL file can hold multiple, complex lifecycles. This makes it possible to define alternative paths through the lifecycle for different objects.

Constructing a WSRR lifecycle based on CBDI-SAE Service Lifecycle2 would therefore be straightforward.

A list of the states together with permitted transitions is also available in the CBDI-SAE Knowledgebase3

We note that WSRR did ship with a sample lifecyle very similar to the CBDI-SAE Service Lifecycle in an earlier version, so this may still be available to users.

The SOA or Service lifecycle states should not be confused with the development status of a particular document instance in terms of whether it is still in the ‘draft’ stage or has been ‘approved’. WSRR does not currently manage this sort of document lifecycle, so any content would be considered ‘approved’. Though users could limit access to objects that they do not wish others to see by using permissions, or role-based views.

Governance Policy Validator Documents and Concepts can be declared as ‘governed entities’. Governed entities are then subject to the lifecycle for that entity.

The Governance Policy Validator is a plug-in that is used to define the assertions (rules) that will be applied to operations performed on governed entities such as state transitions, or on their creation, update or deletion. The assertions are formed from the properties, relationships and classifications that apply to the entity.

The assertions are held in policy files. These contain a set of assertions that test whether the operation should be permitted. For example a policy can assert that in order for an entity to transition to a new state, then it must have certain property values, and certain relationships must exist (or should not exist).


Policy Management A significant new feature of WSRR 6.2 is Policy Management. This enables SOA Policies to be managed as documents in WSRR, as well as providing a Policy Authoring tool that runs in the WSRR web-UI.

As well as being used to define the policy files used by the Governance Policy Validator mentioned above, the policy authoring tool can be can be used to author SOA policies that will be enforced elsewhere, outside of WSRR. For example these could be run-time policies enforced by an Enterprise Service Bus (ESB), Service/Systems management tool, or security products.

The challenge in this activity is identifying the structure and content of the policies that could be published to such tools, particularly the detail of the assertion languages they understand to determine the rules they must enforce.

As a consequence, WSRR currently enables policies to be authored based on the WS-Policy standard, such as those that cover security, reliable messaging or transaction co-ordination. As these provide standardized assertion languages, WSRR is able to provide the UI to define the policy, as illustrated in Figure 4

Figure 4 - WS-Reliable Messaging Policy, edited in WSRR

Versioning and Configurations WSRR provides versioning capabilities. Versions of objects are considered as new objects.

A Concept (Service Description Entity) in WSRR can be used to define a group of objects. Hence it is straightforward to show dependencies based on specific versions of objects. E.g. objectA.V1 is dependent on objectB.V2


This can be used to define ‘configurations’ as discussed in the report on Service Configuration Management4. For example, ‘Service Specification’ can be defined as a Concept that groups the various documents that make up the Service Specification in the Service Lifecyle Automation report5. When creating an instance of that group, the relationships can be made to specific versions of the documents in the group. The Service Specification would also be defined as a Business Model Template to ensure all instances of Service Specification had the same content. And as a ‘Governed Entity’ this could be subject to a lifecycle that determines which objects in the group and their relationships should exist at each lifecycle state.

Interoperability Access to, and interoperability with WSRR is provided through a comprehensive API that is exposed either via Java, SOAP Web Services or REST (Representative State Transfer) protocols.

These allow content, lifecycle and ontology to be managed via the API, providing additional import/export mechanisms, or interoperability with tools.

Some specific interoperability features are listed in Table 1.

IDE and other development tools

IBM Rational Asset Management can publish content to, or retrieve from, WSRR

A SupportPac enables Visual Studio to exchange documents with WSRR

A SupportPac enables developers to exchange documents with WSRR within an Eclipse environment

UDDI Registry

WSRR does not provide standard UDDI interfaces.

However, the UDDI Synchronizer feature allows content in WSRR to be mapped to and synchronized with UDDI V3 registries using the WSRR API

CMDB Tivoli can exchange information with WSRR. For example, publishing deployment metadata into WSRR.

Service Management

A SupportPac for Tivoli Composite Application enables the SOA Event Handler to publish events to that update metadata in WSRR. This would for example, enable the operational status of services or other QoS information to be visible from within WSRR.

Service Discovery

WSRR can discover and import WSDL files from

• IBM WebSphere Application Server

• Oracle Application Server

• Microsoft Windows .NET

WSRR can also discover and import SCA integration modules in WebSphere Enterprise Service Bus and WebSphere Process Server.

The Service Discovery Framework enables developers to build plug-ins for any environment.

Table 1 - Interoperability Features


Representing CBDI-SAE Implementing the structures of CBDI-SAE inside WSRR should be straightforward, although would require preparation, primarily to construct the OWL ontology to represent SAE.

Various classes in the CBDI-SAE Meta Model for SOA could be represented as concepts in WSRR, and then as shown in Table 2, further concepts could be defined to represent deliverables. These deliverables could then show relationships to contained objects. We are aware of at least one CBDI subscriber that has implemented SAE concepts within WSRR in this way.

The Business Model Templates to define these Concepts and their relationships in WSRR can be constructed from deliverable templates provided by CBDI or from the attribute definitions for the CBDI-SAE Meta Model for SOA. These are provided in the resource library of the CBDI-SAE Knowledgebase6

Structuring it this way would enable the ontology to enforce governance rules via WSRR. For example, a Service Specification must have a relationship to a Service Architecture, whilst a Service Architecture must have a relationship to a Service Portfolio. Or that a Service Specification must have a relationship to Specified Operations and a Service Information Model.

A specific configuration of Service Portfolio Plan could then be defined as a Concept Group that groups the physical documents together as a unit.

SAE Deliverable or Concept

Instantiation in WSRR

Service (notional) Concept. Relationship to contained or associated objects

• One or more Service Specifications

Service Portfolio Concept. Relationship to contained or associated objects

• Business Models (pointer to)

• Service Architectures

• Service (notional)

Service Architecture Concept. Relationship to contained or associated objects

• Service Specifications

• Architecture Model (pointer to)

Service Specification Concept. Relationship to contained or associated objects. e.g.

• Specified Operation

• Service Information Model (pointer to)

Specified Operation Concept. Relationship to contained or associated objects. e.g.

• Operation Signature = XSD document

Service Level Agreement Concept. Might be possible to define some elements of the SLA using Policy. e.g. Security Policy


SAE Deliverable or Concept

Instantiation in WSRR

Automation Unit Specification

Concept: Relationship to contained or associated objects. e.g.

• SCA Module Document

Policy Type Policy Domain

Policy Policy Document. Attach to relevant objects

Table 2 - Defining CBDI-SAE in WRSS

Summary WSRR is a powerful product, essentially an ‘engine’ that is totally driven though a configuration profile. However, building the configuration profile required is a relatively complex activity and needs planning and forethought. Architects cannot just dive in and quickly establish a meta model or lifecycle through the WSRR UI as might be possible in some other registry/repository products. Rather various schemas and ontologies must be defined and imported into WSRR first. Subsequent updates to the configuration must undergo the same process.

However, encouraging architects to properly think through their requirements and produce their ontology for SOA is not a bad thing. We imagine that many users will look to IBM for help in building their configuration.

WSRR is therefore aimed at the more mature SOA organization, which has a growing inventory of SOA assets, and recognizes the need for additional governance. They are likely to have already established their SOA approach and framework, either as part of their own EA initiatives, or by adopting something like TOGAF, IBM’s own SOMA approach, or CBDI SAE.

WSRR then provides them with a capability in which they can physically instantiate that approach in a registry/repository and better enforce their Service Lifecycle and the policies that should govern their deliverables.

1 http://www.alphaworks.ibm.com/tech/semanticstk 2 The Service Lifecycle. CBDI Journal, Nov 2005. http://www.cbdiforum.com/secure/interact/2005-11/the_service_lifecycle.php 3 http://www.soakb.com/knowledgebase/Lists/Service%20Life%20Cycle%20State/Transitions.aspx 4 Service Lifecycle Configuration Management. CBDI Journal, Jan 2009. http://www.cbdiforum.com/secure/interact/2009-01/service_life_cycle_configuration_management.php 5 Service Lifecycle Automation. CBDI Journal, Dec 2008. See Table 6, elements of a Service Specification. http://www.cbdiforum.com/secure/interact/2008-12/service_life_cycle_automation.php 6 http://www.soakb.com/knowledgebase/SAE%20Resources/Forms/AllItems.aspx


About CBDI CBDI Forum is the Everware-CBDI research capability and portal providing independent guidance on best practice in service oriented architecture and related disciplines.

Working with F5000 enterprises and governments the CBDI Research Team is progressively developing structured methodology and reference architecture for all aspects of SOA.

CBDI Products A CBDI Forum subscription provides an enterprise or individual with access to a unique knowledgebase, ongoing practice research , guidance materials and resources.

The CBDI Journal, published 11 times a year provides in-depth treatment of key practice issues for all roles and disciplines involved in planning, architecting, managing and delivering business solutions.

Platinum subscription – access to all CBDI research and knowledge products including the SAE Knowledgebase

Gold subscription -access to the CBDI Journal past and present, plus other premium reports and foundational eLearning materials

Consulting Services - always highly focused, either short sharp initiatives designed to accelerate the customer’s current capability, or longer term mentoring relationships. In both cases our services are provided by expert practitioners whose objectives are to effect skills transfer.

Education Services – face to face and eLearning products. Options include train the trainer and customization.

Contact CBDI For further information on CBDI products and services contact [email protected]

IMPORTANT NOTICE: The information available in CBDI publications and services, irrespective of delivery channel or media is given in good faith and is believed to be reliable. Everware-CBDI Inc. expressly excludes any representation or warranty (express or implied) about the suitability of materials for any particular purpose and excludes to the fullest extent possible any liability in contract, tort or howsoever for implementation of, or reliance upon, the information provided. All trademarks and copyrights are recognized and acknowledged.

mailto:[email protected]