Thursday, February 17, 2011

Bridging the gap between abstract SOA models and reality

Many organizations tell us they are classifying SOA as mainstream – that is the architectural pattern and associated technologies are mandated for all projects and programs and strategic applications are progressively being modernized with service interfaces. Further, as organizations’ use of SOA matures, we observe increasing commitment to common, cross-cutting capability and core business services which naturally lead to standardization of the service portfolio.

This progressive maturing of SOA capability requires consistency of approach across disparate programs that facilitates collaboration and effective governance and naturally creates the requirement for standardization of reference models and reference architecture.

Whilst there is a plethora of reference materials from the standards organizations such as OASIS, The Open Group, The OMG and ITIL(OGC) it’s clear that in addition to inconsistency of definitions and expression, most of the standards are abstract and narrowly focused on core concepts and ontology. Whilst these standards are often very useful in guiding conceptual understanding, they may not provide the detailed models on thebroader scope required by practitioners to establish best practices for architecture and solution delivery teams.

What’s required from an SOA reference model:

- a basis for common agreement on concepts across disparate groups that allows sharing of models.

- at a level of detail that is unambiguous and supports tooling. A fully detailed UML model, defined, enumerated and attributed.

- across a scope that supports a typical end to end business project covering: business models, service specification, service implementation, solutions, deployment and runtime, technology, testing, policy and organization.

- an attempt at some level of compliance with the various standards groups, recognizing that there is no single model or agreed ontology, nor standardization of definitions or expression.

In order to support use cases:

- integrate SOA into wider business practices:

- - - - enterprise architecture

- - - - solution architecture

- - - - business modeling

- - - - BPM

- - - - application delivery projects

- support common service definition across ecosystems such as industry groups, supply chains, business partners

- define policy relating to reference model compliance (and thereby support governance of same)

- define required traceability

- support seamless interaction between teams (and parties) carrying out business modelling, service architecture and design, provisioning/procurement, implementation, test, service management and operation

- eliminate ambiguity in service agreements with outsourcing and offshore parties

- support common schema definition for what may be a disparate set of tools being used in modeling, asset management, cataloguing, version and configuration management

- support definition of a set of common and or project specific deliverables across the architecture and delivery life cycle

- support creation of UML Profile or domain specific language (DSL)

The Everware-CBDI SOA meta model attempts to meet the above requirements and support these use cases. You can download the V3 model here.

Tuesday, February 15, 2011

Beyond IaaS - the Business Service Network

I note Joe McKendrick at ZDnet asks "Will telcos become the Cloud brokers for integration as a service". It's a good question. In fact it's a really good question that I posed back in 2005 in a CBDI report titled Enabling the Business Service Network. In the report I said:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Over the next decade there is high probability that large and small enterprises will transition away from providing their own service collaboration and management infrastructure.

A critical element of all these infrastructure process improvement initiatives is to enable consistent information on the infrastructure capability and status that supports policy driven deployment. Although it might seem too simplistic, the overall ambition of these process and technology improvement initiativesis to turn the IT capability into a black box that largely self managing.
  • IT resources are shared, not isolated or application/organization specific
  • Resources and services are managed according to predetermined policy
  • Unpredictable demand is managed to deliver predictability and consistency
  • Operational costs are reduced through automation and reduced human intervention
  • More complex architectures and scalability are delivered without proportionate dependency on people and skills
  • Error and failure rates are reduced
  • Standardization increases operational efficiencies
  • Infrastructure knowledge is collected in a single information model
  • IT services are enabled as self service to users
  • Service levels are improved by dynamic change of services
  • Increased agility is achieved by rapid provisioning of new services or resources and reconfiguration of existing services
The Business Service Network (BSN) acts as an intermediary between service providers and consumers providing many value adding services that make service execution more reliable, controllable and adaptable. The BSN architecture is independent of location and organization and by design capable of supporting continuous change in the usage, behaviours and deployed resources of the business service and supporting technical infrastructure.

The basic BSN architecture is an SOA at both business and infrastructure level. All capabilities are implemented as services in a layered architecture in which each layer encapsulates lower layers, simplifying utilization and management. Individual services form components which provide atomic capabilities that can be reused in many situations and create an inherently adaptable architecture. Provisioning is an assembly based process in which services are contracted to provide resources to specific assemblies on a dynamic basis.

But the BSN architecture is more than an SOA. The BSN must automate the entire life cycle processes of business and infrastructure service delivery and should do this with minimal human intervention. To do this the SOA needs to be complemented with an Operational Support System, a comprehensive management environment that controls the supply/demand of resources to services.

The BSN architecture represents a significant advance on discrete SOA and OSS architectures because the consolidated view of business service and infrastructure layers creates opportunities for advanced management and control capabilities, which are much more difficult to deliver from separate component parts. These capabilities are enabled by the shared information model that maps the physical resource description and usage model to the logical assembly level model, that in turn is mapped to the business service viewpoint. The shared information model allows static and dynamic metadata from all the technical domains in the aggregated stack to be pooled and used for end-to-end management control purposes including:
· Comprehensive dashboard and reporting structure
· Business policy driven infrastructure – a clear linkage between the business service perspective and the technical infrastructure and resources allowing management of resources for specific services. For example policies (rules) may be defined that call for levels of resource to be made available dependent on business service traffic.
· Infrastructure resource status influences business decisions (e.g. allocation of call centre resources)
· End to end Service Level Agreement (SLA) – a common SLA structure internal to the BSN in which all collaborating components integrate with a common SLA protocol that allows aggregate SLA status reporting on a common basis

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
However from what I can see, the really important point that I made in 2005 hasn't been picked up - this isn't just about a broker pattern for integration as a service - it's the provision of an END TO END SERVICE that delivers an SLA including the network and security. One of the biggest worries about Cloud is the probability of becoming locked in to single Cloud providers because it's the only way to deliver security and end to end SLA. However in my BSN model the telcos provide that single integrated SLA covering the totality of the service provision. Back in 2005 I said it would take a decade to realize this, and it seems I wasn't far wrong.


See the January 2011 CBDI Journal for other reports on Cloud