Showing posts with label SOA meta model. Show all posts
Showing posts with label SOA meta model. Show all posts

Monday, June 6, 2011

Cloud-SOA Meta Model L1

There's a lot of loose talk about Cloud and SOA. From what I see most SaaS today is not SOA. In fact it's mostly multi-tenanted Web applications with a browser interface. This "may" be satisfactory for SMEs but for larger enterprises this likely to be unacceptable. The primary inhibitor delaying enterprises migrating to the Cloud is less likely to be security than portability. And here enterprises need an architecture driven approach that forms the basis for good governance at all levels.

In retrospect, when we required effective governance for SOA, as an industry we developed rigorous models and profiles that allowed us to establish repeatable structure for deliverable and governance tooling. For Cloud we need to develop those vanilla SOA models to incorporate new classes and relationships. Interestingly, whilst there are some very important modifications to the base SOA model, for the Consumer perspective the differences are quite limited.

I have posted a discussion draft of an L1 Cloud Meta Model. Note this is a Consumer View and is a conceptual level model, based on the CBDI-SAE V3 Meta Model, intended to explore the key concepts and relationships for scoping purposes. Of course each package needs to be extended and or developed. I will be documenting this and providing explanatory materials in an upcoming CBDI Journal article. Meantime you can download the base CBDI-SAE V3 model and specification for definitions.

Be very interested to get feedback.

NB: See earlier posts on this topic.

Thursday, June 2, 2011

Industry Cloud models are all very hazy!

I am currently working on extending the CBDI-SAE meta model for Cloud. I started this exercise by making some specific assumptions:
1. I am interested in the larger enterprise perspective; enterprises probably need more knowledge of the underlying capabilities than SMEs if for no other reason than good governance
2. For similar reasons I am exploring primarily the SaaS and PaaS layers because most enterprises will usually outsource the infrastructure, even if its private.
3. And in defining the meta classes for these layers I am interested in supporting an application modernization process and life cycle because, again, that's where most enterprises are at in their Cloud efforts.

In looking at some of the excellent work that has been published already on Cloud, particularly by NIST, I was struck by the Provider centric focus of all the deliverables. I suppose I shouldn't be so surprised because most of the work is being supported by service provider based people. Yet, in context with my assumptions above, I am finding the models not as helpful as they might be. The NIST Reference Architecture is mostly Actor centric, yet the Provider capabilities are expanded, whereas the Consumer, Broker and Auditor are either not expanded at all or at a very superficial level. Well it's all superficial, but nevertheless it presents a very unbalanced picture.

So pretty soon I decided that (at least) my initial model would be a Consumer View - because that's the primary requirement of enterprises. And of course I find a high level of overlap with the SAE model because the Cloud from the Consumer perspective is all about services. But there are some interesting alterations and extensions that I will be detailing in due course.

If anyone is working on meta models in this area I would be very interested to hear from them.

Wednesday, May 11, 2011

Version 3.0 of the CBDI-SAE UML Profile for SOA

Everware-CBDI has announced the immediate availability of the CBDI-SAE UML Profile for SOA V3 (SAE Profile). The SAE Profile makes Model Driven Architecture (MDA) for SOA practical for everyone. Whilst introducing a sensible level of compliance with industry standards such as SoaML, the SAE Profile provides a more extensive and detailed coverage of the complete lifecycle, from business models to deployment. As well as capturing requirements in a precise manner, the ability to model service architectures and service specifications facilitates SOA governance with the production of more formal models and other key deliverables that conform to a detailed meta model.

  • Modeling Service Architectures and Service Specifications
  • Making MDA for SOA practical for everyone
  • Enabling sensible compliance with industry standards such as SoaML
  • Facilitating SOA governance, with production of formal SOA models and specifications

The CBDI-SAE UML Profile for SOA V3 is now available for download from the Everware-CBDI website. The profile is available by simple, no cost registration with the CBDI Forum, or login by existing members.

The SAE Profile allows architects and designers to use UML tools such as Sparx Systems Enterprise Architect and No Magic Inc's MagicDraw and to create purpose designed, consistent deliverables for SOA.

The SAE Profile is based on the CBDI-SAE methodology which is defined in the CBDI-SAE meta model for SOA. This is a detailed set of meta class models that define SOA concepts at a level of precision suitable for project deliverables. The models are broadly scoped to integrate with architecture, design and solution delivery practices and span the entire life cycle.

Making the CBDI-SAE Meta Model for SOA available as a UML Profile enables users to model SOA design and architecture using diagrams that are UML compliant and to progressively define detailed meta data that can be used directly in key project and governance deliverables including all architecture views, service specifications, implementation, technology and deployment specifications.

A new report “An Introduction to Service Architecture Modeling with the CBDI-SAE UML Profile for SOA V3” provides guidance on how to use the SAE Profile and walks through the process of modeling a service specification architecture.

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.

Wednesday, April 28, 2010

Back to the Future – What IS a Service!!

Last year I set a goal of integrating SAE with other frameworks and standards. Inevitably this has been a considerable task, but to date I am pleased to say we have mapped to the TOGAF 9 framework, and of course aligned the SAE meta model and profile closely with the SoaML standard.

I started to look at the ITIL framework last year, but to be honest found it a slippery beast. But I have now created the time to have another go and I am pleased to report I have this month published guidance on how to use the SAE and ITIL frameworks collaboratively. The issue that I struggled with last year is that ITIL is a highly generic framework. It provides process guidance for service management activity, where the service is almost anything you want it to be. Whilst it is perfectly understandable that the service providers like HP, IBM, TCS et al envisage the scope of their services to be ever expanding, it doesn’t make it easy to get to grips with processes that are reduced to highly generic descriptions.

Further the nomenclature is very hard to work with. Whilst there is an ITIL glossary, there is no meta model, and similar to the Event Architecture space where, last year I also struggled with the Event Processing Glossary[i] for the same reasons, I found lots of inconsistency and no attempt on the part of the ITIL community to address core issues of nomenclature.

The root problem, (there are many more but I will focus on the core issue) is that ITIL describes the service as, “A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks”. The term is in direct conflict with the SOA community that has established formal standards backed up by automation around the term Service. However the ITIL community choose to ignore this, leaving their customers to resolve the inevitable confusion.

The IT infrastructure professional makes word associations with Service that go along the lines of Network Service, ERP Service, Desktop Service and so on. Whereas the Application Architect thinks of a Customers Core Business Service, or an Events Service.

The ITIL documentation is really no help. In fact there is a section in the ITIL books headed WHAT ARE SERVICES? Which admits “.. over the years organizations have debated the definition of what is a service”, yet completely fails to provide answers, just generalizations. I have to admit some frustration with this, and it probably caused me to drop the research topic last year. No less than 10 years ago we were grappling with nomenclature in the service domain, and it seems incredible that we should have to repeat the experience.

In consequence, in my work this month on the collaborative use of SAE and ITIL I felt I couldn’t write sensible guidance unless I had some semantic consistency. I have therefore proposed a nomenclature and a simple classification system which I hope will at least avoid senseless time wasting over semantics.

I suggest in context with SAE and ITIL in collaboration, the ITIL service is called an IT Service and the first class SOA concept is called a Service. I have then provided outline meta models for the (ITIL SAE) intersection which is aimed at creating delivery and life cycle consistency.

In my report I do say that “we recommend SAE users adopt this approach as . . . it is essential to have clarity and consistency of core concepts. However we are not wedded to the specific term IT Service, and we will encourage standards organizations to resolve this. So in the meantime local solutions may be preferable. Consequently, if a major service provider chose to substitute the IT prefix with their company or division name, that might actually be a great solution that also representing very effective marketing!”

A wider issue is how and whether we should incorporate the concepts into the SAE meta model without any rigorous work from the ITIL community.

I do believe this is an area where the standards bodies need to undertake some work on an urgent basis, and maybe this needs to happen outside of the ITIL community in order to achieve a sensible result. Meantime, if you follow our advice, you will at least have internal consistency.

CBDI Report: SOA and ITIL Framework Collaboration
ITIL (The IT Infrastructure Library) is becoming widely adopted as the standard for IT Service Management. Described as a service management framework, the service concept at the heart of the ITIL process is about the general capability delivered by a service provider, which might coincidentally include SOA based services amongst the range of components delivered and managed. In this report we provide guidance on how to use the ITIL framework in collaboration with the Service Architecture and Engineering Framework (CBDI-SAE) for the Service Strategy and Design stages, and how to deliver better service management for SOA and modernization programs. By David Sprott