Underlying Services – Architecture for Existing and Acquired Resources

Most organizations expect to reuse their existing or externally provided systems as the primary resources to support their Service Architecture. Now that most operating environments and packaged applications have been ‘service enabled’, using such resources in the Service Architecture is technically straightforward. However, the native Services provided by these disparate resources will probably have inconsistent specifications, business taxonomy and business information models. Using them directly in the Service Architecture will probably compromise SOA goals. The report we have published considers where the Services provided by existing and acquired resources fit into the layered Service Architecture and how constraints and compromises can be minimized.

Appendix A1 of the CBDI-SAE Meta Model V2.0 identifies nine Service Architecture layers. It is a policy decision for organizations as to which layers they actually want to use. However, there are four basic service layers we would expect to see in all instances of Service Architecture.

• The core functionality is delivered by the Core Business Services. Each Core Business Service is based on a major business type identified in a Business Type Model. Some people may think of these as ‘Entity or Domain Services’.
• The Process Services then orchestrate these Core Business Services to deliver a specific business process.
• In turn, both these service types may use Utility Services that provide common business or technical utility functions, such as Address Formatting or Authentication.
• Finally, the Underlying Service layer classifies those Services which are provided by the existing systems or packaged applications, but which have inconsistent information models that are not based on the Business Type Model.

The Service Specification Architecture then assigns instances of services their respective place in the layered architecture and shows the dependencies between them. The Service Specification Architecture is then used as the basis for the Service Implementation Architecture where the Automation Units that provide the implementation for the Services are identified.

A natural question to ask is, why can’t an existing or external resource just be the Automation Unit or Implementation of the Core Business Service? Why is it delegated to a different layer? After all, as stated most organizations will want to use these resources as providers in their Service Architecture as these will contain the operational data required.
However, there are many challenges to doing this, especially if you want to deliver the agility promises of SOA.

Hence this report looks at those challenges and how they are overcome by using the layered Service Architecture.

The report also identifies policies and techniques for identifying, creating and consuming Underlying Services.

See Underlying Services – Architecture for Existing and Acquired Resources (subscription required)

SOA Exception Management

Our SOA Exception Management Framework provides a structured approach to specifying exception conditions and dealing with them at run-time. In this report we look at some techniques that may be used

The report primarily considers exception management within Service-based solutions. That is, how both Service Providers and Service Consumers should handle exceptions that may occur in the processing of Service requests and responses.

That said, SOA exception management should not be distinct from broader exception management approaches that ought to be in place to deal with solutions that are not Service-based, and elements of the framework presented in this report should be common to both.

However, as we find ourselves routinely saying, SOA brings new challenges. For example:

• The federation of participants implies that the Service Provider and Consumer may be in different organizations.
• Loose coupling implies there is no shared technology or infrastructure. Hence, there may be no common exception handling software, systems management, or error log.
• The Service Provider and Consumer must rely on Service Contracts such as the Service Specification to document exceptions and specify any obligations on them when an exception occurs.

Consequently, the obligation is on both Service Provider and Consumer to independently manage exceptions. It is not the Service Provider’s responsibility to resolve errors in the Service Consumer’s requests. The Service Provider may simply reject invalid requests and do little else. It is up to the Service Consumer to handle such exceptions, log them, notify any interested parties, analyze the cause, and finally take any remedial action if required.

Equally, there is little point in the Service Provider giving detailed feedback on exceptions that represent problems behind the Service ‘façade’ as it is not the Consumer’s responsibility to do anything about it. But of course, the Provider must log and respond to such conditions.

That said, in many cases the Service Provider and Consumer will be in the same organization. As such it may make sense for them to:

• agree on a consistent approach to exception handing.
• standardize exception ‘protocols’. For example, exception codes and messages.
• provide common utilities or infrastructure for exception management.

Even where the participants are not in the same organization, they will still need to agree on the exception handing protocols. Though the detail of this should be part of each Service Specification, ideally there should be some generalized framework in place for exception management so that ‘sets’ of related Service Specifications at least behave in the same way. For example, all Services in a Business Domain. This report therefore sets out to describe such a framework.

Service Implementation Architecture and Automation Unit Specification

The Service Implementation Architecture and Automation Units Specifications provide the transition from the logical Business Service Architecture and Service Specifications to the implementation of Services in software. In our latest report we will look at how Automation Units are identified, modeled and specified, and advise on how they are documented in the Service Implementation Architecture.

This report presents Automation Units as a relatively flexible concept that can be used to represent a variety of different implementation approaches. The degree of documentation may vary by type or by the nature of the provisioner/implementer relationship. We would expect organizations to define policies that more tightly scope the permitted Automation Unit types in their organization and the associated documentation they require. From a process perspective, the Service Implementation Architecture is a deliverable from the Service Oriented Architecture and Design discipline, and the Automation Unit Specification is a deliverable from Service Provisioning. Together with the Service Specification, these will be key inputs to the Service Implementation activity.

See Service Implementation Architecture and Automation Unit Specification

Open Group Release SOA Source Book

We notice that the Open Group have this week released their "SOA Source Book".

The SOA Source Book is available athttp://www.opengroup.org/projects/soa-book/
Ideas in the SOA Sourcebook have been circulating around the SOA world for some time, and there is (not surprisingly) a lot of overlap (with more or less variation) with material the CBDI Forum has published from 2003 onwards. In particular the following have strong affinity to work we published in the past few years.

SOA Source Book	CBDI
A Maturity Model for SOA	SOA Adoption Roadmap Planning Framework
High-Level Perspective of the SOA Reference Architecture	Based upon our early layered architecture published in reports such as Understanding SOA
Service-Oriented Infrastructure	SOI Maturity Model
Introduction to SOA Governance	SOA Governance Framework

For example, compare and contrast the Open Group Maturity Model for SOA:

With that from CBDI Forum. The Streams are almost identical, and the phases whilst named differently have a similar basis.

The Open Group SOA Source Book SOA Reference Architecture. This was itself based upon an earlier IBM model, which was markedly similar to CBDI's.

With the CBDI Model from 2003,

The Open Group SOA Source Book SOI Reference Model


With the CBDI SOI Model from 2006

And finally, the Open Group SOA Source Book SOA Governance Regimes
with the CBDI SOA Governance Framework from 2007

 
Recently, we published a report TOGAF 9 complementing SAE practices and concluded

"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."

Everware-CBDI Delivers Major Upgrade to SOA eLearning Capability

eLearning portfolio for developing SOA skills across all roles in the organization

• 21 eLearning modules
• Fundamentals and Practitioner levels
• Cost efficient SOA skills development
• For business analysts, architects, designers, developers, testers, governance reviewers and project managers
• Associated certification services
• SCORM compliant modules for hosting in customer Learning Management System
• Available now to CBDI Platinum subscribers in the Knowledgebase

Everware-CBDI announces today that it has delivered a major upgrade to its SOA eLearning portfolio. Twenty-one eLearning modules are now available providing both fundamentals and practitioner level education for a broad range of SOA skills. In addition CBDI certification services are available, which together with the eLearning modules, can address critical skills shortages in SOA efforts.
Though many IT architects are very knowledgeable about SOA there remains considerable confusion and inconsistency of practice and process. SOA skills in many organizations are often limited to the architecture role and focused primarily on technology. As a result SOA projects often spend more time and energy determining how to apply SOA concepts than delivering project results.

The new Everware-CBDI eLearning portfolio is designed to equip a broader set of roles including business analysts, architects, designers, developers, testers, governance reviewers and project managers with consistent, detailed understanding of SOA practice. The e-Learning modules allow practitioners to educate themselves when it is convenient for them in a cost efficient manner.

The CBDI Certification process enables candidates to calibrate and communicate their skill level and allows program and project management to plan more effective and consistent resource utilization. There are two certification levels – Fundamentals and Practitioner. The Fundamentals level can be achieved entirely through eLearning and self study. The Practitioner level can be achieved through various combinations of eLearning, self study, remote and face to face classes.

The eLearning and certification products are delivered either as an integral part of the CBDI Service Architecture & Engineering (SAE) Knowledgebase or as standalone executables that can be hosted by the customer. They can also be provided as SCORM-compliant modules so that they can be used within a customer’s Learning Management System. All CBDI Platinum subscribers and Knowledgebase licensees will have immediate access to all the eLearning modules.

More information:

Everware-CBDI SOA eLearning

CBDI Forum publish Rich Service Specification Template for SOA

The Service Specification is a pivotal SOA deliverable that enables both Service Provider and Consumer to share a common view of a Service’s behavior. However, despite the importance of Service Specification there is no widely adopted standard.

CBDI Forum first developed our Service Specification Template in 2005 and it has since been used on numerous projects by our customers and ourselves.

TOGAF have recently published a Service Specification that, whilst rather more high level, bears strong resemblance to the CBDI template.

Following several requests to make our template more widely available CBDI is making the Service Specification Template freely available to the public under licence.

The template is now available for download


The Service Specification Template is designed to address the following requirements

Contract First Delivery
One of the important principles of SOA is that of contract-first delivery, and this is one of the principles that motivates and drives the need for a Service Specification.
Contract-first means the specification of the service should precede development of its implementation.

Use in Multiple Roles
The Service Consumer will of course want to know exactly what the service does. They will want to know what behaviour it offers, and what they have to do in order to use the Service.
A Service Provisioner whose role it is to locate a suitable Service will need to be able to compare the available Services against a specification to see if it meets requirements. Or if they are commissioning a new Service (or implementation of) they will need to precisely detail the required behavior of that Service.
Hence, the developer in the Service Providing organization who has to build an implementation of the Service also needs to know what requirements need to be meet.
A Service Specification is an implementation-neutral deliverable that contains all the information necessary to meet all these needs.
The Service Specification facilitates exchange of consistent and precise instructions between different participants in the Service supply chain

The Service Lifecycle
The Service Specification is expected to be developed iteratively across the service lifecycle. For example, as a;
Planned Service it may start as a high-level description of requirements
Specified Service it will provide precise detail of the required behaviour
Provisioned Service it may reflect any choices or compromises that have been made in the provisioning process, that diverge from the ideal specification
Deployed Service it will detail the actual endpoints and other aspects required to use the service at runtime

Using the Service Specification Template
CBDI provides templates for various SAE deliverables as Word documents. However, we do not really expect users to then complete and store instances of those documents using Word. Rather, they should treat them as the basis for schemas from which they could create a database to store the data in a more structured way – for example in some form of Service Catalog. Our Word templates might then be better used as a format in which to report from that database, rather than the place in which the data is itself stored.

For example, the Operation Signatures would be held as WSDL documents, and the Service Information Model might be held as a UML Class diagram in a modelling tool.

Further guidance on this is provided in two CBDI Journal Reports
Service Lifecycle Automation
Service Lifecycle Configuration Management

The template itself is only part of the story however. The delivery of a Service Specification is just one step, mid way through the CBDI-SAE SO Process.
Though the Service Specification Template is fully documented, ideally further guidance in its use is required.

CBDI have published Service Specification guidance in the CBDI Journal (gold subscribers), and further process guidance is also provided in the SAE Knowledgebase.
Practical Service Specification and Design Part 3: Specifying Services
Documenting Service Behavior
Process Logic and the Identification of Service Behavior
Produce Service Specification (SAE Process Unit) (platinum suscribers only)

We invite discussion on the Service Specification Template via CBDI LinkedIn

SOA Governance Framework

At CBDI we have always advocated that governance needs to be rooted in clear policy definition and in fact devoted an article to this. Since that time we have been busy assisting organizations improve SOA governance approaches based on an underlying foundation of clear policy definition. One thing that has emerged vividly from this work is that organizations must move forward at their own pace and in a way that is realistic in terms of their current SOA adoption level.

Moreover the approach taken to SOA governance must be in tune with the overall governance requirements and political climate. We have therefore distilled these experiences into an SOA Governance Framework - embracing policy, process, infrastructure and capability maturity - that can be tailored to each organization's specific needs.

The basics of the CBDI SOA Governance Framework are now publicly available without requiring registration

An overview of the process of creating a SOA Governance Framework is presented in this slide show

| View | Upload your own