may 2007 - CBDI Forum · to support SOA adoption and maturity, as well as to ... it’s highly regarded middleware core of integration and messaging infrastructure to provide Service

CBDIJournal2 Editorial

Simplifying the SOA Roadmap

Introducing Capability Dependency Diagramming as an important technique that can be used in many

ways to introduce, simplify and complement the wider SOA Roadmap

4 SOA Best Practice ReportCapability Dependency

We have been drawing capability dependency diagrams to support SOA adoption and maturity, as well as to

understand business requirements. This article provides guidelines on drawing, refining and using these diagrams.

By Richard Veryard

18 SOA Product ReportImplementing the Layered Service Architecture

with TIBCO

In recent years, TIBCO has expanded it’s highly regarded middleware core of integration and messaging infrastructure to provide Service Oriented Architecture

(SOA) and Business Process Management (BPM) support. In this report we look at the suite of products offered by

TIBCO, and consider how they can be used to implement the Service Architecture best practice

recommended by CBDIBy Lawrence Wilkes

Independent Guidance for Service Architecture and Engineering

ISSN 1745–1884

may 2007

Editorial

www.cbdiforum.com

Simplifying the SOA Roadmap

I have commented many times that SOA is a significant challenge in change management. Superficially SOA appears to be an elegant architectural concept that can enable better separation of concerns and reduced complexity. However the reality of SOA is that it requires change to many of the foundation stones that underlie the modern enterprise.

We created the CBDI SOA Roadmap way back when as a way to help simplify the change management task–by organizing SOA capabilities into phases that correspond to increasing maturity. We also use various techniques to analyze, structure and communicate change requirements, tasks and outcomes. One of these is the Capability Dependency Diagram.

I find the Capability Dependency Diagram (CDD) an incredibly useful technique because it easily communicates what needs to be done to support the SOA environment. By simply showing what capabilities are dependent on other capabilities we can build an action plan that is independent of technology, time and resources, and a good basis for project and program planning. What do we mean by capability? It’s the ability and capacity to provide some function and attribute a level of maturity. For example:

Basic service asset management (existence)

Service asset state (planned, published, operational . . . ) management

Service asset dependency management

. . .

I have one CDD instance that I use more than any other. I use it to explain how you might start to bring some structure (order, governance, repeatability) to the SOA effort. The diagram is based on the core principle of SOA that the service provides real separation that allows inherently more flexibility. And the way we implement this principle is with a rich service specification (rSS).

As shown in Figure 1 we can develop a profile for a rSS with a small amount of reference architecture and process. This allows us to provide consistent education and guidance to architects and designers and also to implement a basic level of asset management getting a first level of control over services and perhaps service state. This then allows us to charter service delivery teams in a consistent manner, to create a reference implementation and finally to exert some basic governance. So in a very narrow focus fashion we have established basic reference architecture guidance and process that will allow a significant level of consistency in delivered services and prevented further growth in service anarchy.

Having achieved this first step, it might be sensible to create consistent documentation for all the existing services that have been developed in various ways by individual teams, with at least a basic profile and to record them in the basic asset management database.

I use this example frequently because I meet many architects and program managers that do not yet have this basic level of SOA in place. For them the full SOA Roadmap is often not relevant, it’s too complex and they need to take simple steps to get some basic policies and governance in place. If your SOA implementation effort is in need

•

•

•

•

By simply showing what capabilities are dependent on other capabilities we

can build an action plan that is independent of technology, time and

resources

cbdi journal © Everware–CBDI Inc, May 2007 �

of structure the CDD technique may be a great place to start because it can be focused on immediate issues and needs. Once you have the basics in place you can start to look further out and build a more comprehensive roadmap.

In this month’s CBDI Journal Richard Veryard shows how the CDD technique can be used in many different ways to manage the transition to SOA. He has documented our approach to

CDDs in a comprehensive manner including lots of examples. Also this month we have a report from Lawrence Wilkes exploring how a logical technology model can be very useful in selection and management of SOA technical platforms, using the TIBCO platform as an example.

David Sprott, Everware-CBDI, May 2007

Figure 1: Capability Dependency Diagram Example

CBDI has been busy populating an SOA Knowledgebase over the past 6 months. This will provide our customers

with a much more structured and detailed set of guidance on how to succeed with SOA. We plan to launch this in

June. For more details see pages 16 and 17. WATCH THIS SPACE

Best Practice Report

� cbdi journal © Everware–CBDI Inc, May 2007

By Richard Veryard

Capability DependencyUseful analysis technique–relevant both to business requirements and also to SOA adoption

We have been drawing capability dependency diagrams to support SOA adoption and maturity, as well as to understand business requirements. This article provides guidelines on drawing, refining and using these diagrams.

Introduction

BackgroundIn recent years, Capability has emerged as a first-class construct within SOA and related disciplines. It can be found both in the commercial/civilian arena (such as Microsoft’s Motion1 methodology, described as a method for project prioritization and selection) and in military applications (such as the Strategic View recently added to the MOD architecture framework2).

We have described the analysis of capabilities in previous Journal articles, both in the context of business requirements3 and SOA maturity models4.

TechniqueThis article describes a technique for analyzing capabilities and the dependencies between them. It can be applied at three levels.

Level Definition Comment Context

Business Capability

The business model describes the capabilities of the business, and how these may be deployed in response to the (potentially complex) events of the demand environment.

In a military context (e.g. MODAF), these are known as operational or military capabilities.

Strategic planning and requirements planning is based on business model.

System Capability

Coherent chunk of functionality possessed by a service, system or system-of-systems in support of business capabilities.

Also known as equipment capabilities

Systems / service portfolio planning addresses system-level capabilities.

SOA capability

Capability of an organization relevant to the adoption and execution of SOA in support of system capabilities and business capabilities.

These are the capabilities referenced in a capability maturity model for SOA.

SOA adoption planning is based on understanding the dependencies between SOA capabilities and their outcomes.

Table 1: Levels of Capability


The relationship between business/enterprise capabilities and SOA capabilities is shown in Figure 1.

In a planning context, capability dependencies have two primary implications.

Scheduling / Sequence. A must be implemented (to some defined level) before B can be implemented or achieved. This imposes some scheduling constraints on the implementation of A and B.

Justification / Benefits. A must be implemented (to some defined level) in order to enable B. This provides the motivation for implementing A, and allows the costs and benefits of the SOA programme to be managed.

There are two additional implications.

Viability / Sustainability. Identifying the dynamic factors that establish the ongoing viability and sustainability of a complex set of services. For example, at what stage does the volume of usage achieve a critical mass, generating sufficient value for a given scheme to be self-funding?

Risk Management / Uncertainty. What are the significant uncertainties in a given plan, and how can these be contained?

1.

2.

3.

4.

ContextWhile capability dependency analysis is not limited to SOA, it is particularly relevant to SOA because of the following characteristics.

Collaboration–SOA adoption typically involves collaboration across multiple units within a single large enterprise, or between multiple organizations and agencies

Network externalities–Among other things, SOA is a way of making connections between systems and services. Therefore the potential benefits increase as the number of available systems and services increase.

Learning by doing–SOA adoption follows a typical learning curve, in which potential benefits increase with experience.

Capabilities and DependenciesCapability DependencyThe capability dependency diagram is a simple network diagram, using the UML convention of an arrow from the dependent object to the independent object. (This is opposite to the older convention, still practiced in some domains, whereby the arrow reflects a logical time sequence from the independent object to the dependent one.)

•

•

•

Figure 1: Capability Planning5


Capability Dependency continued . . .

We can identify two kinds of dependency within the capability maturity model, which we may call ‘Hard’ and ‘Soft’.

For example, in the SOA Roadmap, there are hard dependencies from the lower levels of maturity to the higher-levels of maturity. (Some of the lower-level capabilities are necessary to enable some of the higher-level capabilities.) There are also some soft dependencies from the higher levels of maturity to the lower levels. (Some of the later capabilities amplify or optimize the earlier capabilities.)

It is important to recognize soft dependencies as well as hard dependencies because we sometimes want to say that an

Figure 2: Capability Dependency

Type Definition Example Notation

Hard A hard dependency from P to Q indicates that Q is practically impossible (or downright foolhardy) without P.

For example, you just can’t implement an enterprise-wide metamodel strategy without having some kind of metamodel repository.

Soft A soft dependency from P to Q indicates that Q is possible without, but is significantly enhanced/improved by P. (In other words, you could attempt Q without P, but it would be less efficient/effective, or there would be a greater risk of failure.)

For example, you can have some shared service capability without having a reward and recognition scheme in place, but you may not be able to achieve the maximum shared service capability until you have such a scheme (and a few other things as well).

Table 2: Hard and Soft Dependencies

Concept Definition Notation Example

Aggregation A1 is a specific level of a generic capability AA2 is a higher level of A

Phasing A2 is superior to A1A2 replaces / complements A1replacement may be instantaneous or gradual

Table 3: Aggregation and Phasing

cbdi journal © Everware–CBDI Inc, May 2007 7

organization can get the tick-in-the-box for a given capability at a given maturity level, but there may still scope to improve that capability to achieve a higher maturity level.

Aggregation and PhasingWe can now put together the notations introduced in Table 2 and Table 3. Suppose B has a hard dependency on A1 and a soft dependency on A2. At a high level of abstraction, we can show a simple dependency between A and B, while at a more detailed level we can make some more complex dependencies visible.

Outcomes

Outcome DistributionIn many situations, outcomes are not just simple binary events, but can be quantified. It is often useful to distribute outcomes across two dimensions–breadth and depth.

Breadth refers to the scale, quantity and diversity of the outcome. For example, the penetration of a given technology across a target user population. Given an assumption of heterogeneity across the target population, greater breadth typically requires some degree of differentiation.

Depth refers to the quality and intensity of the outcome. For example, the ability of some sectors within the target population to achieve maximum exploitation of a given technology. Given an assumption of complexity in the systems architectures, greater depth typically requires some degree of integration (which may be physical or virtual),

We can usually identify different sets of capabilities to attain each of the four quadrants in the outcome distribution chart, as shown in Figure 4.

Note that some advanced capabilities may themselves be dependent on achieving some outcomes–this is because they rely on some practical experience within the target organization to refine and calibrate the adoption and management of SOA.

The capability dependency model may therefore contain stepping stone capabilities, which support a learning cycle.

In all cases, the adoption starts with “initial” outcomes (bottom left). Assuming that the target is to achieve a “full” outcome (top right) there are three possible strategies.

1 Up-and-across–“deep” outcomes take priority over “broad” outcomes

2 Across-and-up–“broad” outcomes take priority over “deep” outcomes

3 Parallel–“deep” and “broad” outcomes are pursued simultaneously

Figure 3: Outcome Distribution

Simple (Abstracted) View Complex View (with Phasing)

Table 4: Simple and Complex Views

. . . possibly equivalent to . . .



Figure 4: Outcome Distribution and Capability Phasing

Capability Depth Capability Breadth

Leve

ls

ConflictedDeconflictedCoordinatedCollaborativeAgileAgile Enterprise

••••••

FragmentedProcessDomainEnterpriseEcosystem

•••••

Quo

te

“These C2 maturity levels are scalable, in that they can be applied to groups of individuals and organizations of any size.”7

“A scope based approach to maturity is the most useful determinant of maturity that decomposes well to each of the stream views because services are increasingly useful as they are used more widely, and conversely expanding the SOA scope beyond traditional organizational boundaries is without question the hardest thing to achieve”8

Table 5: Two Dimensions of Capability Maturity


Increasing scopetherefore

increasing maturity

Figure 5: Capability Taxonomy–Example9

Figure 6: Two Strategies for Interoperability and Integration

10 cbdi journal © Everware–CBDI Inc, May 2007


Capability Maturity StrategiesCapability maturity can be defined in terms of capability depth or capability breadth or both. For example, the NATO C26 capability maturity is defined in terms of depth, while the CBDI’s own SOA Roadmap is primarily defined in terms of breadth.

Roles

Capabilities and RolesSometimes it is useful to assign the capabilities to different roles. This is done by defining zones or swimlanes in the diagram for each role or role type. For example in Figure 7, the user’s ability to perform searching is dependent upon the supplier’s capability to provide a search facility.

Roles and PhasingWe can identify two capability levels for the search facility – basic and user-friendly. (The user-friendly level is going to be defined not intrinsically in terms of features but extrinsically in terms of outcomes.)

We attain the basic level first. This enables the users to search, but with only some degree of user support. This is fine for the low levels of usage expected initially, but is unsustainable for high levels of usage.

There is a resource constraint on the User Support capability, which imposes a volume constraint on Searching. (This is not shown explicitly in the diagram, but should be described in the associated metadata.)

In phase 2 we introduce a higher (user-friendly) level of the search capability. (This may involve developing a new version of some service that implements this capability.) This enables searching without user support.

We may need some experience at the basic level before we have enough knowledge to move to the user-friendly level. (There may be an interdependency between User Support and Knowledge, but this is not shown on this diagram.)

Capability Role MigrationIn some cases, a capability may migrate from one role to another. For example external support in Phase 1, leading to internal support in Phase 2.

Note that the dependency from user awareness is indifferent to the type of training, and so it makes sense in this instance to link to the supertype. The supertype is abstract and is not allocated to a specific role.

There are two alternatives for showing the roles on the diagram. Either a partition of the diagram labeled with each role (Figure 10). Or an icon associated with one or more capabilities (Figure 11). The first alternative looks more elegant, but the second alternative might be useful in some cases.

Figure 7: Capabilities assigned to Role

Figure 8: Phased Capabilities within Role

Figure 9: Phasing Dependencies Between Roles

Figure 10: Migrating Capabilities Between Roles


PatternsWe can identify some generic patterns and frameworks for common business requirements. For example, “quality” generally unpacks into a set of specific capabilities:

One aspect of the quality of the catalog is the availability of the services advertised in the catalog.

We need to further decompose these capabilities by role.

Which capabilities does the catalog administrator need?

Which capabilities does the service provider need?

Which capabilities does the service consumer need?

Who has the authority to remove services with unsatisfactory availability levels from the catalog?

•

•

•

•

Figure 11: Migrating Capabilities Between Roles–Alternative Notation

Capability Detail

Planning / Requirements Defining quality requirements (e.g. SLA)

Monitoring Quality levelQuality trends

Controlling / Enforcing Corrective actionPreventative action

Governance Reviewing validity and cost-effectiveness of quality levels.

Table 6: Pattern Example–Quality

Figure 12: Pattern Example–Quality

Figure 13: Pattern Instantiation–Catalog Quality



Guidelines

Production GuidelinesStart from the desired outcomes. What do you want to achieve?

People using a catalog

People using a catalog efficiently and effectively.

Consider quantification of outcomes, but don’t put these on the diagram yet.

How many people?

How much usage?

How efficient, how effective?

What timescale?

Now determine what capabilities make these outcomes possible?

Where an outcome depends on voluntary or discretionary behaviour, consider the capabilities that

Enable these behaviors

Encourage these behaviors

Empower these behaviors

Extend the diagram to show how capabilities themselves depend on other capabilities.

Include all capabilities that are specific to this program.

Exclude capabilities that are generic, can be taken for granted, and do not require management action or verification.

Show dependencies between capabilities.

For example, ability to use a catalog depends (among other things) on having technical access to the catalog.

Group the capabilities into broad roles. A capability required by one role may be dependent on a capability possessed by another role.

For example, awareness in the consumer role might be dependent upon some marketing communication capability in the provider role.

Refinement GuidelinesCheck management and governance for completeness.

•

•

•

•

•

•

•

•

•

•

•

•

•

What capabilities are required to monitor what is going on? How much metrication is required to support mature governance?

What capabilities are required to set and enforce policies, and monitor their effectiveness?

What capabilities are required to coordinate activity across multiple stakeholders and organizations? How are these capabilities joined up?

Check that every stakeholder role has some way of exercising its rights and responsibilities.

For example, the end-user may need some capability to participate or influence service planning and provision. This can be modeled as a user-side governance capability. Supply-side governance then has a soft dependency on user-side governance.

Look for closed dependency loops. (A depends on B depends on C depends on A). If these are all hard dependencies, then you will have to implement the whole loop simultaneously (synchronization or tight coupling). You should consider ways to break these loops, to allow different elements of the SOA adoption to be desynchronized, allowing greater planning flexibility and efficiency.

Replace hard dependency with soft dependency. Then one part of the loop can be deferred. Note that complete management and governance generally involve closed dependency loops, but these are almost always soft dependencies and it is usually possible (indeed, necessary) to implement partial management and governance to start with.

Insert an abstraction step. For example A depends on B depends on C depends on A* – where A* is a generalization of A that doesn’t depend on B. Then you can start by implementing A1 as a temporary capability, and then replace A1 with A at a later date.

Look for opportunities for decoupling and deconfliction. This means taking management action to reduce dependencies between different streams of activity–although this may possible involve the expenditure of additional resources or elapsed time–so-called buffers. There is therefore a trade-off between a just-in-time approach (which may be more efficient but less agile) and a deconflicted approach (which may involve less interoperability and risk).

•

•

•

•

•

•

cbdi journal © Everware–CBDI Inc, May 2007 1�

Usage GuidelinesCapability dependency diagrams may be used in different ways, supported by different classes of software tool.

Requirements planning. The capability dependencies can be used to define system requirements and system testing.

Project planning. The capability dependencies can be used to produce schedules of work.

System dynamics. The capability dependencies can be imported into a simulation tool, which allows quantification and analysis of the feedback loops. Among other things, this helps to quantify the causal relationships within complex dependency diagrams.

AcknowledgementsSome of this material was originally commissioned by the Danish Government (ISK). Our thanks for permission to reuse this material.

NotesThe full Motion methodology is not in the public domain, but you can find descriptions of Motion Lite on the Microsoft website. http://msdn2.microsoft.com/en-us/architecture/aa902582.aspx. See also John Devadoss’s blog at http://blogs.msdn.com/jdevados/archive/2007/03/12/it-project-prioritization-with-motion.aspx

•

•

•

1.

MODAF Version 1.1 April 2007. Available at http://www.modaf.org.uk/Business Modelling for SOA Part 1 (Jan 2006) http://www.cbdiforum.com/secure/interact/2006–01/Business_Modeling_SOA_Part1.php Exploring Business Capability (June 2006) http://www.cbdiforum.com/secure/interact/2006–06/Exploring_Business_Capability.phpSOA Maturity Model (Dec 2005) http://www.cbdiforum.com/secure/interact/2005–12/The_SOA_Maturity_Model.php See also my blog on SOA Maturity Models (Nov 2005) http://www.veryard.com/so/2005/11/soa-maturity-models.htmBased on MODAF V1.1 StV-1Command and ControlMaturity Levels for NATO NEC Command, Dec 2006David Sprott, “Fine-Tuning the SOA Maturity Model”, April 2007Based on MODAF V1.1. StV-2.

2.

3.

4.

5.6.7.8.

9.

1� cbdi journal © Everware–CBDI Inc, May 2007


Appendix: Material Published in Earlier Journal ArticlesThe following material is required for a complete account of capability dependency analysis, but has already been published in the Journal.

Basic Classification of OutcomesWe can identify four basic categories of outcome, as shown in Table 7.

You can do three things with an outcome. Firstly, you can strive to make it happen – in which case you call it a goal. Secondly, you can strive to make it not happen – which means you are turning its negation into a goal. Thirdly you can detach yourself from it – so that you no longer care how/where/whether it happens or not. This is called hedging, and is achieved through decoupling.

CapabilityA capability is . . .

A simple view of capability is that you either have it or you haven’t. This simple view is okay for achieving an entry-level with a given capability (for example getting started with SOA), but does not support a drive towards excellence.

A capability may follow a development lifecycle. Therefore we can take a more sophisticated view, mapping critical capabilities on a scale from Adequate to Excellent, as shown in Figure 14.

Capability Example: FundingIn the context of SOA adoption, funding is a capability area within the Management stream. You may be able to achieve some limited results with existing funding and/or skunkworks. But this is not scaleable. Therefore there are several aspects of the SOA program that have a soft dependency on ADEQUATE funding.

The critical question about this capability is not just “do you have any funds, yes or no” but “do you have the ability to allocate and manage funds appropriately”

To achieve an EXCELLENT rating in the funding capability, you need to have a proper management loop between funding and ROI. Obviously this is not going to be possible in the early stages of the SOA adoption, because some of the other enablers are not yet in place. For example, ROI and other management metrics.

The funding capability therefore has a soft dependency on these enablers.

Transitional CapabilitiesSome capabilities may be required during the early phases of the SOA adoption program, but will be superceded in the later phases. For example, Project-Based Service Ownership is a necessary capability in the early phases, but is replaced by Central or Federated Service Ownership in later phases.

Category ExamplesProject & System Outcomes Delivering projects

Delivering project qualityDeveloping and maintaining system artifacts including architectures, plans, models, test data and live systems.

Service Outcomes Acquisition, production and consumption of servicesAchieving service quality targetsAchieving service consumption / reuse targets

IT Outcomes Achieving IT productivity and quality targets.Achieving IT cost savings.Reducing complexityIncreasing adaptability

Business Outcomes Achieving end-customer satisfactionAchieving revenue growthGaining measurable strategic advantageDeliver business cost savings

Table 7: Outcome Classification


This type of transitional capability may be needed to resolve a dependency conflict, or to remove a circular dependency.

Something is dependent upon Service Ownership

Central Service Ownership depends on Something Else.

Looking at how a given capability relates to other capabilities, we can see that Central Service Ownership is better than Project-Based Service Ownership. Either because it is a more efficient or effective way of implementing the Service Ownership capability. (In other words, Project-Based is ADEQUATE but not EXCELLENT.) Or because there are yet more things dependent on Central Service Ownership.

•

•

Figure 15: Transitional Capabilities

Figure 14: Capability Development Curve

CBDI-SAETM

KnowledgeBaseCBDI Forum Service Architecture & EngineeringTM

Many large enterprises are planning to evolve their

SOA deployments from a predominantly tactical, ad

hoc environment to a strategic level in order to ensure

governance over future business agility.

To assist organizations make rapid progress in strategic

SOA adoption Everware-CBDI provides CBDI Service

Architecture & Engineering (CBDI-SAETM), a collection

of knowledge and best practice including a reference

model for SOA comprising defined concepts, reference

architecture and processes that can provide enterprises

with a structured approach and framework for SOA

based on sound architectural principles for flexibility,

sharing, and consistency of Services.

Everware-CBDI has been developing the components

of CBDI-SAETM for the last few years in its education,

consulting engagements and research. This is now

being made available for customer use through the

CBDI-SAETM Knowledgebase which provides users

detailed guidance on all aspects of the CBDI-SAETM

SOA Reference Framework, including:

A Reference Model and Reference Architecture

Detailed SOA deliverables with templates

Discipline and process definitions detailing tasks and

techniques

The CBDI-SAETM Knowledgebase will be continually

evolving and updated and will be made available to

organizations via an annual license.

•

•

•CBDI-SAETM SOA Reference Framework

Model

SOA Principles

Service Life CycleSOA Meta Model

Glossary

Architecture

Business

Deployment

Patterns

Policy

Techniques

SOA Views

Organization

Roles & Structure

Funding Models

Project Profiles

Models

Deliverables

SOA Best Practice

Process

Enable

Consume

Manage

Provide

Technology

Standards

Implementation

Specification

Ref

eren

ce F

ram

ewo

rk

Evolving. The Knowledgebase will continuously develop as practical experience is synthesized into best practice and new areas of guidance arise.

Community. Collaborate in forums with a global community of peers and world-leading experts.

Open. The published reference model and meta-model enables integration of complimentary frameworks

•

•

•Feat

ures

Consistent Enterprise-wide SOA Blueprint. A common language and framework for describing and managing Services and SOA solutions. Eliminates confusion and facilitates cross enterprise collaboration and sharing.

Standards Based. Everware-CBDI is committed to working with the industry to deliver relevant standards, particularly those supporting automation and sharing.

Constantly Updated with best practice and the latest techniques.

Real World SOA Experience. CBDI-SAETM is based on real-world experience gained through consulting assignments and feedback from users.

•

•

•

•

Ben

efits

© Everware-CBDI Inc 2007

© Everware-CBDI Inc 2007

Reference Architecture. A framework for the work products used in CBDI-SAETM supporting the business, implementation and deployment views of SOA. Work product templates for Reference Architecture consisting:

Deliverables. Candidate work products used to document SOA deliverables. Each deliverable is described and accompanied by a template where relevant, together with reference examples. Example templates include:

Service Specification

Business Service Architecture Specification and accompanying models

Techniques. Detailed explanation of appropriate techniques

Standards. Candidate standards that apply to specific work products. These standards can be internal, or de facto or de jure industry standards

Tools. Candidate infrastructure and automation required to support the work product and populate the SOA Meta Model

Policies. Candidate policies required for governance

Patterns. The CBDI-SAETM Knowledgebase contains both candidate patterns and a catalog of patterns synthesized from project experience including

Architecture

Service design and behavior

Tutorials. Self paced tutorial modules with audio help to guide users on all aspects of CBDI-SAETM

Discussion Forums. Opportunity to discuss issues with other customers and Everware-CBDI experts.

•

°

°

•

•

•

•

•

°

°

Reference Model. Reference material for core SOA understanding including:

SOA Principles. Definition of the core principles that underpin SOA

The Service Life Cycle. State definitions as a basis for managing the life cycle of a Service

SAE Meta Model for SOA. A detailed and precise model of the meta data required to support the specification of Services and Service Architectures

Glossary of Terms

SAE Repeatable Process Guidance. Detailed process guidance is provided for each SAE discipline, comprising:

Disciplines

Processes

Task lists

Recommended techniques

Pre-requisites and dependencies

Delivery and use of deliverables

•

•

•

•

•

•

•

•

•

•

Delivery. The CBDI-SAETM Knowledgebase will be delivered through an on-line portal.

Availability. The CBDI-SAETM Knowledgebase will be delivered on a phased basis. Please contact Everware-CBDI for further information

Det

aile

d C

ont

ents

For more information contact Everware-CBDI Inc. [email protected]

RESEARCH PORTAL: www.cbdiforum.com SERVICES: www.everware-cbdi.com



SOA Product Report

By Lawrence Wilkes

Implementing the Layered Service Architecture with TIBCO

In recent years, TIBCO has expanded it’s highly regarded middleware core of integration and messaging infrastructure to provide Service Oriented Architecture (SOA) and Business Process Management (BPM) support. In this report we look at the suite of products offered by TIBCO, and consider how they can be used to implement the Service Architecture best practice recommended by CBDI.

IntroductionToday, TIBCO’s product set reflects the two convergent trends:

SOA–providing a virtualized, loosely coupled environment in which to deliver the functional capabilities required as Services, and enabling agility and reuse in the provision of those Services

BPM–providing a process driven environment in which to assemble and orchestrate the Services into business solutions, and enabling process flexibility

SOA support can be seen as a natural evolution for TIBCO’s middleware market, with message delivery and broking providing the core of the Enterprise Service Bus (ESB). In addition, TIBCO also provide Service hosting, orchestration, assembly and management capabilities, delivering a rich SOA platform. The core technology is also well suited to the delivery of “real-time” Services, providing accessibility and visibility of information, that reflect the nature of modern business.

BPM is not separate from, or an alternative to SOA. Rather the two are just “flip sides of the same coin”. In the CBDI-SAETM service oriented process1 we show Business Improvement and Solution Assembly as two key activity areas in the “Consume” layer. BPM would be an appropriate approach for modeling business process improvements, and with appropriate tooling an ideal mechanism for assembling Services into an automated business process solution.

Figure 1 provides a logical decomposition of the run-time infrastructure required to support SOA and BPM. This decomposition provides a technology independent model by which to understand the capabilities required, as listed in Table 1.

The potential path taken by Service Requests and Responses as they move between Provider and Consumer is also illustrated by Figure 1. Above the Provision/Host layer, each of the other layers, or the capabilities within them is optional.

•

•


Infrastructure Layer Capabilities TIBCO Products

UI

Whilst the UI might not be normally considered part of the SOA infrastructure, portals should be “Service aware”, able to present information retrieved from Services

Presentation and user interactionDialog ManagementPortal

•

••

TIBCO General InterfaceTIBCO PortalBuilder

••

Process ManagementBusiness Process Management will be a prime Service Consumer in the solution layer, hence again the capabilities in the Process Management layer should be “Service Aware”

Process ExecutionWorkflow, Task ManagementProcess MonitoringService Consumption

••••

TIBCO iProcess EngineTIBCO iProcess Business RulesTIBCO BusinessFactor

••

•

Service OrchestrationAt each layer of the Service Architecture, Services will often orchestrate Services in underlying layers in order provide a composite capability and aggregate information

Orchestration/choreography of multiple ServicesService ProvisionService ConsumptionTransaction Management

•

•••

TIBCO BusinessWorks•

MediationMediation is the term used to describe Transformation–where the message sent by the Service Consumer needs to be transformed in some way to match the format required by the Service Provider, and Routing–to dynamically route messages to their destination.Additional agility can be enabled if message formats and endpoint addresses are not hardcoded into the applications at each endpoint Instead they can be resolved at run-time.

Message Transformation (including enrichment)Message Routing

•

•

TIBCO BusinessWorksTIBCO BusinessWorks SmartMapperTIBCO Adaptors

••

•

MessagingA messaging capability is required to transport messages between the provider and consumerAssured delivery is a desirable capability to ensure reliable, guaranteed messaging where integrity is required.

Message DeliveryAssured Delivery (reliable messaging)Message Queuing, cachingMulti-transportMultiple messaging patterns

••

•••

TIBCO Enterprise Messaging ServiceTIBCO RendezvousTIBCO SmartSockets

•

••

SecurityThe federated participation of Service provider, consumer and intermediary, who may be external to the organization, and use unsecured transports, requires careful attention to security.The use of marked up XML messages potentially makes it easier to tamper with the message or compromise confidentialityLoose coupling requires message level security as an alternative to the use of secure transports.

AuthenticationConfidentiality–EncryptionMessage IntegrityAuthorization–PermissionsThreat Management–Firewall

•••••

TIBCO ActiveMatrix Service GridTIBCO BusinessWorksTIBCO ActiveMatrix Policy Manager (Policy Agents that plug into ActiveMatrix and BusinessWorks)

•

••


Layered Service Architecture with tibCo continued . . .

Not all messages for example require signing and encrypting, or transforming and routing. Ideally, such decisions are driven by policies and rules that are abstracted away from the providing or consuming applications. A decision to encrypt a message for example, or the need to transform it to support new requirements should be transparent to the applications and instead is configured within the infrastructure.

Some capabilities span several layers. Security requirements for example may mean that mediation and orchestration functions need to be able to sign messages, or handle encrypted messages. Similarly, in each layer many components of the infrastructure

need to communicate with the Service Management capabilities, or host some management “plug in”.

Vendor’s products are often packaged in a less logical way, hence the decomposition in Table 1 also provides a mechanism against which different products might be assessed in terms of the capabilities they offer, perhaps revealing gaps or duplication in their functionality. So called Enterprise Service Bus (ESB) products are a good example in that they often offer capabilities that span several of these layers. Table 1 and Figure 2 provide a high level mapping of TIBCO products. Further detail is provided in Tables 3–5.

Provision/HostService Endpoints act as an agent to their corresponding Automation Unit(s) (AU)The Service Endpoint visible to the Service Consumer does not have to be co-located with the AU, but may act as a further intermediary in the overall message path.

Service Endpoint HostingAutomation Unit Hosting

••

TIBCO ActiveMatrix Service GridTIBCO BusinessWorks

•

•

Service ManagementServices need to be managed as independent resources. However, at the same time it is important to maintain the correlation between Service and System activity.Services should be managed according to the SLA between the Provider and Consumer

Service Endpoint and Message MonitoringService ConfigurationService Level ManagementLoggingCorrelate Service and System level activity

•

••••

TIBCO ActiveMatrix Service GridTIBCO BusinessWorksTIBCO ActiveMatrix Policy Manager (Policy Agents that plug into ActiveMatrix and BusinessWorks)

•

••

Registry/DirectoryService Registries enable both design and runtime discovery of Services.Registries or directories can be used at runtime to dynamically resolve endpoint addresses

Discovery (for run-time endpoint resolution)Description (to support dynamic transformation)

•

•

TIBCO ActiveMatrix Registry•

GovernanceOperational run-time governance usually relates to Security and Service Management. The rules should be contained in policies that are abstracted away from the applications, and can be maintained independently.Policy engines might also be used at run-time to drive mediation rules.

Policy AdministrationCompliance Monitoring

••

TIBCO ActiveMatrix Policy Manager

•

Table 1: SOA and BPM Runtime Infrastructure

Infrastructure Layer Capabilities TIBCO Products


Figure 1: Logical Decomposition of the SOA and BPM Run-Time Infrastructure

Figure 2: Mapping the Logical View to TIBCO Products



Another way of considering how SOA and BPM work together is via the layered Service Architecture pattern that CBDI Forum advocate, as illustrated in Figure 3. Each layer represents a separation of concerns, with Service dependencies made within or to a lower layer. BPM would be an appropriate approach in the Solution layer, to model and execute the overall business process and workflow. It may also be used for some long running Services in the Process Service layer, again to modeling the process and also to provide orchestration of the required Services.

In the second half of this report we will consider how the TIBCO product set maps to the layers shown in Figure 3.

Supporting the Service Architecture LayersFigure 1 is an example of a Service Implementation Diagram. As well as showing how the Services are assigned to layers it also illustrates how they are mapped to Automation Units (AU)2. As the diagram suggests, there are many different forms of AU. These could be new components, simple or complex scripts, or wrappers around legacy or packaged applications. Though some tools might be applicable at all layers–for example developers might choose to code everything using a programming environment (if you only have a hammer, everything looks like a nail)–organizations are likely to be more productive and flexible if they use tools with features specific to the requirements of each layer.

The separation of concerns represented by the Service layers also reflects that different skills might be appropriate or that different participants may be involved at each layer.

ManufacturingSystem

Figure 3: BPM and the Layered Service Architecture


What then are the appropriate TIBCO tools to use in each layer, and more specifically what SOA centric capabilities do they offer?

Solution LayerThe role of the solution layer in the service architecture is primarily to provide an effective end-user experience and support the BPM process characteristics outlined in Table 2. The solution layer isn’t strictly a Service layer, rather the primary Service consumer. Solution layer capabilities required are listed in Table 3 together with a mapping to TIBCO products.

TIBCO’s core offering in this layer is the iProcess Suite, a set of products supporting BPM and user interaction.

Whereas many SOA products provide only BPEL based Service

Orchestration, iProcess Modeler and Engine provide full BPMN and XPDL support. This is more appropriate to complete solution delivery where the business process typically combines elements of both human and system activities. The workflow support is a particular strength for TIBCO reflecting the acquired Staffware products. BPEL support is provided as part of the TIBCO BusinessWorks ESB (see Process Services Layer).

The solution layer may also comprise a set of B2B Services that are exposed externally for use by partners and customers in their own solutions. These may be similar to the Process Services in the layer below, but may also be specialized to meet the specific needs of B2B, for example the patterns of message behavior supported, or bindings to particular message transports. Note: Some architects may choose to define this as another, separate layer within their architecture.

Characteristics of BPM “Processes” Characteristics of SOA “Processes”

Long-runningEnd-to-EndHuman-to-HumanSystem-to-SystemHuman-to-SystemComplex Flow PatternsLoops, Joins, Splits,Withdraws, etc.Business Rules, Deadlines, Priorities, Escalations, etc.

•••••••••

Short-lived (seconds)System-to-System onlyTypically Highly SequentialStrong Error Handling,Mapping, Transformations, etc.

•••••

Table 2: Contrasting Characteristics of BPM and SOA Processes (source: TIBCO)

Requirement TIBCO Product

User Interface TIBCO General Interface. Ajax Rich Internet Application (RIA)

PortalConsume Services, particularly WS-RP compliant Web Services

•TIBCO PortalBuilder. Support for JSR 168 and WS-RP (consumer and producer). SOAP/WSDL/UDDI support for consuming Web Services

Business Process Management and WorkflowModel processes in terms of required ServicesConsume Services in run-time engine

••

TIBCO iProcess Modeler, and iProcess Engine. Service repositories can be introspected and service definition brought into BPM project

B2B ServicesProvide and Consume Services to/from business partnersSupport diverse range of message formats

••

TIBCO BusinessConnect, BusinessPartner. Support for RosettaNet, EDI, HIPAA, UCCNet, cXML, ebXML, SOAP Web Services

Business Activity Monitoring (BAM) TIBCO BusinessFactor

Table 3: Mapping Solution Layer Requirements



TIBCO includes support for the traditional B2B protocols as well as SOAP Web Services in the TIBCO BusinessConnect and BusinessPartner products.

As well as providing dashboard information to the end user, TIBCO is able to close the loop with Business Activity Monitoring (BAM). Events are collated from BusinessWorks in BusinessFactor, enabling different real-time process decisions to be made in iProcess Engine based on the BAM feedback.

Process Service LayerThe role of Process Services is to expose common sub-processes as Services so that they can be standardized across more than one solution and the prime function is to orchestrate core Business and Utility Services in lower layers. . These services are in TIBCO terms the “SOA Services” shown in Table 2. Capabilities required to support Process Services are outlined in Table 4.

Process Services typically orchestrate Services in short lived processes such as the relatively narrow activity of accepting (or rejecting) a Sales Order, rather than the much broader Order to Fulfillment process that would be found in the Solution Layer.

TIBCO BusinessWorks is the ESB and integration backbone of TIBCO’s SOA platform, and provides the core mediation and orchestration capabilities.

Two options are provided for orchestration. BPEL for long and short running Process Services. or BusinessWorks own native XML-based process language which is more comprehensive than BPEL providing, in the same manner as other vendors

the option of limited standards based functionality or more comprehensive proprietary functionality.

Hosting the Service endpoints and the corresponding AU depends on the implementation requirements. In a prior CBDI Report3, we outlined how Process Service endpoints and the associated AU might be hosted within the ESB itself, or on an application server (or even split between the two). Using the ESB as the host may be more appropriate where the main task is orchestration of other Services, the mediation functionality built into the ESB is core to the Service composition, and where a declarative and scripting environment suffices. TIBCO support both approaches either via the BusinessWorks ESB or ActiveMatrix Service Grid for more complex code-centric implementations.

The iProcess Decisions Business Rules Engine could also be useful in this layer, as Process Services are likely to be rules driven–for example:

Business rules guiding process decisions such as whether to accept or reject an order

Mediation decisions such as where to route a message based on its content

Services in the Process Service layer are also liable to more frequent change than those in lower layers. Providing an environment in which those rules can be easily configured, rather than baked in code, enhances business responsiveness. iProcess Decisions provides a business rules engine that can be used to define process rules that are based on the business meaningful content of the message that is more powerful than the rule capabilities typically found in an ESB

1.

2.

Capabilities Required TIBCO Product

Service Composition/Orchestration TIBCO BusinessWorksBPEL supportService Provider and Consumer

••

Policy/Governance TIBCO ActiveMatrix Policy ManagerRun-time focus•

MediationMessage RoutingMessage TransformationTransport Bridging

•••

TIBCO BusinessWorks

HostingService Endpoint HostingAU Hosting

••

TIBCO BusinessWorksTIBCO ActiveMatrix Service Grid

Business Rules TIBCO iProcess Decisions Business Rules Engine

Table 4: Service Capability Requirements


Meanwhile TIBCO ActiveMatrix Policy Manager provides further rule-based policy management, primarily to support run-time Operational Governance over Security, auditing and Service Levels. By applying such policies in-stream on the message traffic or at the Service endpoint, rather than within the AU or its container, consistent governance can be implemented across all Services regardless of what platform they are hosted on. ActiveMatrix Policy Manager uses code licensed from AmberPoint, a leading Service Management vendor.

Core Business Service LayerThe role of a Core Business Service is to manage key business resources, to implement business logic and often to provide a “360 degree” view of that resource. It is responsible for providing a wide variety of information retrieval operations regarding the instances of one core business type and it enables the data stored about the core type to be updated in a consistent manner for the entire enterprise. For example, the Customers Service, the Accounts Service, the Locations Service.

It is worth noting at this point that as well as providing business process modeling, iProcess Business Studio also provides support for Business Concept modeling. This allows the definition of a business vocabulary by defining business types (e.g. Customer, Order), attributes (e.g. CustID) and relationships (e.g. Order contains multiple OrderLine). This provides a single cross-project type model used for Service definitions, Business Rules definitions and other domains such as user forms design.

To support Core Business Services at runtime, several of the capabilities required in this layer are common to all Service Layers. For example:

Service Composition/Orchestration. In the layered Service architecture pattern Services at each layer are assembled from other Services in the layer below, or within same layer.

Mediation. Required at all layers as routing may be based on content and/or policy or messages may not be a direct match between Provider and Consumer

Policy. Governance, such as the operational governance referenced above applies at all layers.

The TIBCO products referenced in Table 4 will therefore be valid at all Service layers.

•

•

•

TIBCO has assembled a comprehensive product set that pulls BPM and SOA together. It provides

a common infrastructure, with a common repository, administration and installation, and a common design environment providing

alternative perspectives for different roles such as IT Developer, Business

Analyst, etc. There is also the Business Concept modeling tool that provides a common business vocabulary for both

BPM and SOA.



In the Core Business Service layer the Automation Unit may be hosted in an Application Server environment for a number of reasons including:

The rules are considered more static

The AU is “self contained”. That is, it has little or no need to orchestrate further Services, for example Underlying Services that access legacy or packaged applications.

The AU is maintaining the data for the Core Business Type (though even data access might be Service based today)

Performance optimization may be better in the Application Server compared to the ESB. For example the rules may be expressed in compiled code, rather than interpreted XML.

The AU may of course be acquired, and only available as an Application Server executable

Relevant to this, the recently released TIBCO ActiveMatrix Service Grid provides unique distributed service container functionality that supports both Java/Java EE, and Microsoft .NET. Based on JSR 208 Java Business Integration (JBI) and Service Component Architecture (SCA) specifications, the ActiveMatrix Service Grid is also right up to date with SOA standards. This enables BusinessWorks to be hosted as a managed Service, making its ESB capabilities, including BPEL, available to other components in the container. It should be noted that ActiveMatrix is not an ESB, nor a replacement for BusinessWorks, though TIBCO indicate BusinessWorks will itself become an ActiveMatrix component.

ActiveMatrix Service Grid is a component of the ActiveMatrix product set. The goal of the ActiveMatrix product set is to have as many Services and corresponding AU’s as possible managed within a single environment, with ActiveMatrix Policy Manager, and ActiveMatrix Registry providing consistent governance and visibility across them.

•

•

•

•

•

ActiveMatrix Service Grid provides a single “virtual” environment for the creation, deployment and management of otherwise heterogeneous Services and AU’s. One aim is to remove concerns of Service “plumbing” from the developer. Many Application Servers do that already. However, ActiveMatrix Service Grid does this consistently across any managed Service it hosts, irrespective of whether they are Java EE or Microsoft .NET.

ActiveMatrix also provides support for the JBI Normalized Message Router which handles container level WS-* differences, and provides communication “virtualization” supporting for example SOAP, HTTP, JMS, and EJB.

The final component ActiveMatrix Registry is a Service Registry providing UDDI V2 and V3 compliance. Thought integrated within ActiveMatrix, it is OEM’ed from HP (Systinet) and therefore provides useful life cycle governance capabilities that we have reported on previously4.

Underlying Service LayerMany Automation Units are going to be comprised of legacy and packaged applications which reside on platforms outside of ActiveMatrix. Even new development work currently underway in many organizations isn’t always going to be JBI or SCA compliant. Or as is quite likely, the breadth of data and capabilities required to provide the full “360 degree” view of a business resource means that the Automation unit is comprised of several different components and applications, both new and existing. For example, an organization might want to expose a single Service providing a consistent “360 degree” view of customer, whereas the customer data itself is dispersed across several existing line of business systems.

The role of Underlying Services as the name suggests, is to provide access to these underlying applications that do not offer well formed service interfaces, often being proprietary to the platform and/or package. From a Service Architecture perspective, these interfaces are not likely to be expressed in the same business vocabulary as the information and process

Capabilities Required TIBCO Product

MediationMessage RoutingMessage TransformationTransport Bridging

•••

TIBCO BusinessWorks

Data mapping TIBCO BusinessWorks SmartMapper

Enterprise Application Adaptors TIBCO Adaptors

Table 5: Underlying Service Capability Requirements


model that forms the taxonomy used to define Process Services and Core Business Services or match the granularity required for those Services. Note the comments earlier on Business Concept modeling.

The prime requirement therefore is to provide some form of façade or wrapper around these systems so that they can participate in the Service Architecture and be easily used by a service consumer. Whilst the platform they are deployed to today might provide a simple option to turn native interfaces into Web Services, or these may have been added by the package vendor, it is highly unlikely they will comply with the vocabulary and policies of the Service Architecture.

Consequently an ESB is the most useful capability in supporting this layer, particularly one that has ready-made enterprise application adaptors for the most common platforms and packages such as might be found in an ESB from a vendor that has an Enterprise Application Integration (EAI) heritage. Additionally, the TIBCO BusinessWorks SmartMapper is a useful extension to simplify and manage the modeling and mapping of the diverse data formats that will be presented by these underlying systems.

SummaryTIBCO has assembled a comprehensive product set that pulls BPM and SOA together. It provides a common infrastructure, with a common repository, administration and installation, and a common design environment providing alternative perspectives for different roles such as IT Developer, Business Analyst, etc. There is also the Business Concept modeling tool that provides a common business vocabulary for both BPM and SOA.

One area where there is opportunity for greater alignment is in governance, providing policy management that spans both BPM and SOA–supporting both business as well as policies that are centered more on the IT operational side. But this is an industry wide issue, and not TIBCO specific.

ActiveMatrix represents something of a new market for TIBCO, and it certainly needs to be differentiated to stand out in an already well served and competitive Application Server market. Features such as the virtualization of heterogeneous Service containers, as well as it’s place in the overall BMP/SOA product set go some way to achieving that.

Further InformationTIBCO Software Products: http://www.tibco.com/software/default.jsp

NotesThe Service Oriented Process. CBDI Journal February 2007. http://www.cbdiforum.com/secure/interact/2007–02/service_oriented_process.phpA collection of one or more executable modules that together provide the implementation for a software serviceApplying ESB, CBDI Journal April 2006. http://www.cbdiforum.com/secure/interact/2006–04/Applying_ESB.phpImproving SOA Governance with the Systinet Business Services Registry. CBDI Journal, April 2005. http://www.cbdiforum.com/secure/interact/2005–04/Improving_SOA_Gove_Systinet_Business_Registry.php

1.

2.

3.

4.

Subscribe to the CBDI Forum

The CBDI Journal is published monthly with a combined July/August

edition.

An annual corporate subscription includes

access to all back numbers plus access to Powerpoint Libraries and the CBDI

Hot Line Service. In addition Corporate

Subscribers are encouraged to participate in Special Interest Groups (SIGs),

Reviews and general Forum Meetings.

For more details see: www.cbdiforum.com

CBDI ObjectivesCBDI Forum aims to provide independent, action oriented practice guidance on Service Oriented Architecture and Component Based Development for architects, business analysts, project managers, designers and others involved in creating and delivering advanced architectures.

CBDI Delivery ChannelsCBDI Forum provides:

• Subscription services – continuous practice guidance published in the CBDI Journal every month (with July/August combined into one volume)

• Workshops and Seminars – providing indepth education on architecture, process and practice. Public and In-house classes are available.

• Consulting – specific guidance on adoption roadmap including status assessments, methodology customization, architectural guidance including reference architecture development, governance reviews, business design and strategy development.

CBDI BackgroundCBDI Forum is the Everware-CBDI research capability and portal providing independent guidance on best practice in service oriented architecture and related delivery processes. Working with F1000 enterprises and governments the CBDI Forum research team is progressively developing structured methodology and reference architectures for all aspects of service oriented architecture.

A CBDI Forum Subscription provides a corporation or government department with access to a unique knowledgebase, ongoing continuous practice research guidance materials and hotline access to CBDI Forum experts. The monthly CBDI Journal provides in-depth treatment of key practice issues and guidance for architects, business analysts and managers. Forum Meetings are held periodically in Europe and North America allowing peers to engage and exchange experience and best practices.

Contact UsFor further information on any of our services contact us at: [email protected] or +353 28 38073 (International)

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. CBDI Forum Limited 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 recognised and acknowledged.


Documents

may 2007 - CBDI Forum · to support SOA adoption and maturity, as well as to ... it’s highly regarded middleware core of integration and messaging infrastructure to provide Service