CBDI Web Services Roadmap - Guiding the Transition to Web Service and SOA

Sponsored by

Sponsored Papers

Vendor Web Services Roadmap Report - IBM. IBM's strategy today is centered around "Business On Deman...
more

Many Organizations are now undertaking development of service oriented architectures, but the probab...
more

Whilst investment in Application Integration initiatives over the last decade has undoubtedly improv...
more

Moving to SOA cont'd...

A Framework for SOA

A service oriented architecture is one view or perspective of the overall architecture. It's a mechanism for ensuring the application and infrastructure is and remains loosely coupled. Of course the SOA is implemented as a series of alterations or delta to conventional practice, and we need to determine for any particular enterprise what that delta is.

In Table 1 we provide a framework, as a useful way to document this, and both ensure some consistency and completeness of the list. We have commenced with something like a Zachman framework, which is widely used by enterprise architects, and then developed a fairly arbitrary set of domains, against which we can record SOA decisions and or deliverables. The Zachman framework analyses architectural elements across conceptual, logical and physical layers, but we have found it more useful to think about requirements, specifications and implementations.

However we do stress this is a framework in the best meaning of the term, and encourage organizations to use this as a starting point, and to develop and customize as appropriate. The advantage of this framework level of abstraction is that it moves just a little beyond vague, and ill understood terms like "architecture", while retaining the ability to have an overall perspective. A framework of this nature would also form a good communication vehicle between the (architecture) provider and consumer. It also has the advantage of allowing specialist architects to develop customized views that can easily be mapped to other views.

Another important aspect of SOA is the question of how to ensure architectural decisions get implemented - otherwise known as the governance issue. Each deliverable can be attributed with governance roles, including standards or guidelines, mandatory or optional, which themselves have applicability to specific domains which might include platform, product, layer, application, relationship etc. We provide some examples of governance deliverables in Table 2.

Domain / View	Requirements (Conceptual)	Specifications (Logical)	Implementations (Physical)
Business	Standardized business services	Business Service Bus	WSDL specifications
	Business virtualization	BPO Service architecture	UDDI based service registry
	Purely information based products	Information service specifications	WSDL specifications
	Service based product components providing value add to physical products	Service product specifications	WSDL specifications
Information	Definition of the real information owner, internal and external to the business and strategy for managing that class of information	Information currency and ownership distribution analysis	Information access services
	Common semantics and domain applicability (business unit, enterprise, ecosystem, sector etc)	Semantic standards	XML documents and mapping and transformation rules
Application		Applications redefined as sets of business objects and related services	Applications acquired as (hosted) services
Service	Service is first order construct in business process	Service as unit of provision and consumption	Delivered service
	Standard/common business services	Standard/common business services	Standard/common business services
		Standard/common infrastructural services	Standard/common infrastructural services
	Business service patterns	Domain business service patterns
	Business service contract templates	Service specification contract templates and reusable components	BPEL4WS or ebXML template specifications
Component	Business domains mirror business requirements for articulation	Business components encapsulate a single business concept (entity or process)	Offers well defined network interfaces that offer services
Middleware	Business Service Bus	Wire protocol standards	XML Messages
		Message security services	Message security services
			Component and Service container
Service Management	Business rules	Rule specifications	XSLT or similar
	Business policies	Policy specifications	XSLT or similar
	Business service requirements	Service Level Agreements	Dependency specifications, thresholds, contingency plans
	Business trust requirement	Trust specification	Monitoring policies and rules, breakpoints and escalation specifications
		Management services pipeline	Management services pipeline
Platform		Grid based services virtualize physical platform resource	Platform functionality delivered as services
		Integrity Units define domains for trust, resource management, technical	Virtual physical resources
		upgrade
Device	Device independent UI	Service interface specification NOT the User Interface	Service interface specification NOT the User Interface
User	Roles	User profiles	Directory Server

Table 1 - Service Oriented Architecture Framework

Architecture Deliverable Type	Governance Role		Domain applicability
	Standard or guideline	Mandatory or optional
Patterns
Templates
Common components
Common services
Protocols
Semantics
Products
Practices

Table 2 - Architectural Governance

Conclusions

Most organizations should now be planning and executing on some level of SOA based environment. For some the change will happen by default as they implement new versions of packages such as SAP that have embraced the concepts. But most organizations have a heterogeneous environment and need to manage the transition to ensure they achieve a high level of componentization and separation, that will flow through into improved economics and response time to change.

The archetypal enterprise organization is highly distributed, but in a service context it is very important that there is coordination of service creation and reuse, to ensure the common usage where necessary. Governance policies are an essential pre-requisite to make this happen. It won't happen without serious cross organizational effort.

Roadmap Actions

Roadmap Actions

Define a Business Service Bus Establish a vehicle that enables policy development and communications at the service level between IT and business communities.

Develop a component based architecture to support the Business Service Bus Make plans on how clear separation will be established at the (application) implementation level. Build into all project and acquisition plans. Ensure that acquisitions confirm to separation policies.

Implement a Service Based Scoping Policy for Projects Ensure that all projects are required to scope and justify their activity on the basis of services used and implemented.

Implement Relevant Governance Mechanisms Implement appropriate practices to ensure that corporate SOA strategy gets implemented in delivered and acquired applications.

1. Services Oriented Architecture - A Series of CBDI Reports by Oliver Sims
This series is about the effective specification, design, and delivery of service-oriented applications and business processes in the enterprise environment. It assumes that applications must integrate not only with legacy, but also with each other, in order to avoid creating tomorrow's stovepipe legacy. In particular, we address the major "choke points" from end-to-end of the development lifecycle, and end-to-end from front to back of the distributed enterprise system.

Part 1 - The Foundation - http://www.cbdiforum.com/secure/interact/2003-03/foundation.php3
Part 2 - The Bridge - http://www.cbdiforum.com/secure/interact/2003-04/bridge.php3
Part 3 - Federation - http://www.cbdiforum.com/secure/interact/2003-05/federation.php3
Part 4 - The Platform - http://www.cbdiforum.com/secure/interact/2003-06/federation.php3
Part 5 - The Service Based Business - http://www.cbdiforum.com/secure/interact/2003-07/services_oriented_arch.php3