Mike The Architect

Open Group Publishes its First Cloud and International SOA Standards

Today, The Open Group announced three new industry standards to enable businesses to effectively integrate elements of SOA and Cloud Computing into a solution or enterprise architecture. The new standards are:

• SOA Reference Architecture
• Service-Oriented Cloud Computing Infrastructure Framework
• Open Group Service Integration Maturity Model

 

SOA Reference Architecture

Provides a blueprint for creating and evaluating SOA solutions. With the release of the SOA RA Standard, enterprise architects now have a common language and approach for creating SOA solutions that meet different organizational needs, and bridge the gap between business and IT.

 

This specification presents an SOA RA, which provides guidelines and options for making architectural, design, and implementation decisions in the implementation of solutions. The goal of this SOA RA is to provide a blueprint for creating or evaluating architecture.

Additionally, it provides insights, patterns, and the building blocks for integrating fundamental elements of an SOA into a solution or enterprise architecture.

Informally, the aim of the SOA RA is to answer some of the key questions and issues encountered by architects, including but not restricted to common questions such as:

• What are the aspects, building blocks, and layers of an SOA that I need to consider in designing solutions, establishing enterprise architecture guidelines, or assessing an architecture based on service-oriented principles?
• What are the building blocks I need to include in each layer of my solution or standardize as part of a enterprise architecture?
• What are some of the key architectural decisions I need to make when designing a solution, or assessing an architecture that is based on service-oriented principles?
• How do I increase my chances of gaining benefit from using SOA by taking into account key layers and building blocks with which I may initially be unfamiliar as our company makes it journey through higher levels of maturity? One of the ways in which we can establish a baseline and move to higher levels of maturity is to use The Open Group Service Integration Maturity Model (OSIMM) [21].
• Which roles in a project would benefit from using these principles and guidelines?

The SOA RA is used as a blueprint and includes templates and guidelines for enterprise and solution architects as well as software engineering roles within the software development life-cycle. These facilitate and ultimately enable automation and streamlining the process of modeling and documenting the architectural layers, the capabilities and the Architecture Building Blocks (ABB) within them, options for layers and ABBs, mapping of products to the ABBs, and architectural and design decisions that contribute to the creation of an SOA. It is intended to support organizations adopting SOA, product vendors building SOA infrastructure components, integrators engaged in the building of SOA solutions, and standards bodies engaged in the specifications for SOA.

More: http://www.opengroup.org/soa/source-book/soa_refarch/intro.htm

 

Service-Oriented Cloud Computing Infrastructure (SOCCI) Framework

Is the first Cloud standard from The Open Group, which outlines the concepts and architectural building blocks necessary for infrastructures to support SOA and Cloud initiatives.

Service-Oriented Cloud Computing Infrastructure (SOCCI) is the realization of this framework for the cloud. This document details the SOCCI elements, the synergies realized through the cohesive application of SOA and cloud-based principles, and the SOCCI Management Building Blocks. It expands upon the relationships between service-orientation and its application to various infrastructure components. Finally, the concepts outlined are explained in the context of a business scenario – Motor Cars in the Cloud.

Participants have specific requirements from the cloud computing infrastructure. We will be elaborating on these requirements. The relationship of the base roles (Consumer, Provider, and Developer) and composite role (Integrator) are described above.

More: http://www.opengroup.org/soa/source-book/socci/intro.htm

 

Open Group Service Integration Maturity Model

Delivers a common maturity model, which has now been ratified as an ISO and IEC International standard, for advancing the continuing adoption of SOA and Cloud Computing within and across businesses.

The Open Group SOA Integration Maturity Model (OSIMM) provides consultants and IT practitioners with a means to assess an organization’s Service Oriented Architecture (SOA) maturity level. It defines a process to create a roadmap for incremental adoption which maximizes business benefits at each stage along the way. The model consists of seven levels of maturity and seven dimensions of consideration that represent significant views of business and IT capabilities where the application of SOA principles is essential for the deployment of services. The OSIMM acts as a quantitative model to aid in assessment of current state and desired future state of SOA maturity.

 

More: http://www.opengroup.org/soa/source-book/osimmv2/intro.htm

 

More information

• Press Release - www3.opengroup.org/news/press/open-group-publishes-new-standards-soa-and-cloud
• SOA Reference Architecture PDF - https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=12490
• Service-Oriented Cloud Computing Infrastructure (SOCCI) Framework (SOCCI) PDF - https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=12510
• OSIMM V2 PDF - https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=12450

 

Technorati Tags: Enterprise Architecture,Solution Architecture,SOA,Cloud,Reference Architecture,Patterns,Open Group

Navigating through the Complexities of Architectures

A common challenge among architects and architecture organizations is the challenge of properly understanding the landscape of architecture assets within and external to the enterprise. With all the different definitions, hierarchy and levels of abstraction it can be difficult to really get your arms this problem space.

At an architecture summit were questions like:

• What is a pattern?
• Is there a difference between a reference architecture and a pattern?
• How would you classify an architecture asset?
• What is the difference or the line between architecture and implementation?

These are all great questions and I am sure there are questions asked by many others as well.

There are things you can do to alleviate this pain. Below are four activities I have used to help clear up the confusion:

• Lock on Vocabulary - A large part of the problem (not the only) is one of vocabulary. Having a common definition for these terms goes a long way. After walking through the questions above with architects what we quickly found was that we were actually deriving to the same definition but using different terms.
• Classification – As you go through the terms there will be quite a bit of iteration on the relationships of these terms. This classification or taxonomy is important to lock for your organization. It helps you understand the context and the relationships of the asset to all other things. 
• Leverage Mainstream Vocabulary and Classification – In a past experience of mine (7 or so years back) when aiding in building an Office of Enterprise Architecture we found this same issue of locking on terms we can all understand as an enterprise. We spent the better part of 6 months (in duration not effort) just trying to lock on terms. This involved passionate debates and religious wars on how people understood the space and their personal preferences. Save yourself the heartache and leverage an existing standard. It will be better for your organization in the long run.
• Provide Examples – Run through a few scenarios to exercises the vocabulary and classification system. This will accelerate the end users understanding of the concepts.

 

There has actually been quite a bit of work done in this space. The Open Group’s TOGAF 9 has defined this space really well at the macro level. This is what they call the Enterprise Continuum. There site has a lot of detail on this and you can find more on the Enterprise Continuum Online Book Chapter. 

The definition of the Enterprise Continuum is: a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures

So essentially it is providing a classification and common set of definitions for the space. There is a small bit of taxonomy work here but it is inferred not in a typical taxonomy format but the outcomes are that of a taxonomy.

 

I really like that this framework accommodates real world challenges such as regulatory compliance, business change, technology disruptors and competitive forces. This is all rationalized in the context of business and IT strategy which is a first class citizen in the framework.

This is demonstrated in the diagram below when you look at the traceability aspects of the framework.

Above shows abstraction at a high-level and below is an exercised high-level architecture partitioning of the model that can be mapped to the ADM methodology. This is what makes the model actionable as it leverages the deep definition of an architecture method to make the classification implementable.

 

If you are looking to supplement TOGAF or look at other perspectives there are great resources at the OMG, IEEE, FODA, and others. Of all the sources TOGAF (in my opinion) is by far the most complete across the spectrum and is the highest used by both enterprises and tools vendors.

Another helpful piece of context setting which isn’t necessarily in the Enterprise Continuum is the notion of an Architectural Style. I talk about his in a post I wrote a couple years back in “What is an Architectural Style” . I think that this is complementary to the Enterprise Continuum as it is more of guiding principles of the Architecture and Solution Continuum.

I define an architecture style as:

An Architecture Style is a logical grouping of patterns or architecture references that is implemented through cohesive methods for solving a problem area with a unique set of concerns.

 

At the time this was a way to reduce confusion around key macro technology patterns such as SOA, now this has shifted to another amorphous concept of Cloud Computing. See below for an example:

 

Additionally, J.D. Meier has a good post on Reference Models, Reference Architectures and Reference Implementations that could be either worked into the TOGAF vocabulary but also used independently if need be.  The reason I bring this post up is that he has some good definitions that could be an alternative or provide additional context.

See J.D.’s descriptions below:

• Reference Model - A Reference model is a model of something that embodies the basic goals or ideas, and you can use it at as a reference for various purposes. It’s like holding up a diamond and looking at the different facets. It basically serves as a backdrop or canvas, or a foundation and springboard for deeper dives. They are also useful for pulling together a bird’s-eye view of a domain or problem space. A well-known example is the OSI model. Key Attributes include: abstract, entities and Relationships, technology agnostic, and they clarify things within a context. By using a model, you can focus on higher-level concepts, ideas, and decisions.
• Reference Architecture - A reference architecture provides a proven template solution for an architecture for a particular domain. It’s the high-level “blue prints” for putting the pieces of the puzzle together.
• Reference Implementation - A reference Implementation goes beyond a reference architecture and is an actual implementation. This is where the rubber meets the road and it serves as an exemplar down at the implementation level.

 

Technorati Tags: Enterprise Architecture,EA,Open Group,TOGAF,Taxonomy