Open Group points standards at service-orientation architecture needs and approaches

This guest BriefingsDirect post comes courtesy of Heather Kreger, IBM’s lead architect for SOA Standards in the IBM Software Group.

By Heather Kreger

Last week The Open Group announced two new standards for architects; actually, more appro-priately, for service architects, SOA architects, and cloud architects. These standards are intended to help organizations more easily deploy service-based solutions rapidly and reliably especially in multi-vendor environments.

These standards are the first product in a family of standards being developed for architects by The Open Group’s SOA Work Group. Other standards currently in development for SOA include the SOA Ontology, SOA Reference Architecture, and Service Oriented Infrastructure.

Architecture standards are especially valuable for creating a common, shared language and understanding between service integrators, vendors and customers of all sizes. They provide a common foundation of understanding for the industry. Considering the who’s who of integrators involved in the development of these two new standards -- Capgemini, CGI and HP/EDS, and IBM -- we can expect the standards to reflect validated and mature best practices and industry experience.

[See a post by Sandy Kemsley from Heather's presentation at The Open Group's recent architecture conference in Toronto. Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]

First, the Open Group Service Integration Maturity Model (OSIMM) provides a method to measure service adoption and integration and create roadmaps for incremental transformation to SOA to meet business objectives.

OSIMM provides a context to identify the business benefits of each step along the roadmap and progression toward the appropriate level of maturity for your business goals. The model consists of seven dimensions of consideration within an organization: Business View, Governance and Organization, Methods, Applications, Architecture, Information, and Infrastructure and Management.

Each of these dimensions can, in turn, be assessed on a maturity level scale from one to seven, including: 1: Silo (data integration); 2: Integrated (application integration); 3: Componentized (functional integration); 4: Simple services (process integration); 5: Composite services (supply-chain integration); 6: Virtualized services (virtual infrastructure); and 7: Dynamically reconfigurable services (eco-system integration).

OSIMM resonates with organizations because they can see at a glance what the entire scope of service use and SOA is and they can find themselves somewhere on that continuum. The model also makes it easy to see where they want to be on the continuum to meet objectives and to check on progress toward those goals. It’s important to note that with this maturity model, more is not necessarily better; few companies will need to be at level 7 maturity, most will satisfy their business objectives at level 4 and 5.

Second standard

The second standard, the SOA Governance Framework provides a methodology to help ensure that business objectives are in line with the SOA solutions and IT investment. The framework defines a SOA Governance Reference Model, which includes concepts that architects should understand in relation to governance, such as principles, guidelines, organizations, governed service and SOA processes, governing processes for compliance and dispensation, and supporting technologies.

For each of these concepts, the authors have provided starting points based on best practices. The framework defines the SOA Governance Vitality Method, which is an iterative cycle through the phases of Plan, Define, Implement and Monitor for the governance regimen. The monitor phase uses policies, checkpoints and triggers to ensure the governing processes are in place and being followed. These triggers can also be used to evaluate and adjust the governance regimen itself.

Actually, a great deal of the SOA Governance Framework applies to the governance of architecture in general but is explicitly defined to provide guidance for governing Service portfolios and SOA solution portfolios. Interestingly enough, the governance of service portfolios applies equally to business solutions that use cloud.

These two standards represent a major step forward in creating and simplifying the standards to build SOA. This is increasingly important as more organizations have to justify incremental investment in services. OSIMM helps you figure out where you want to go, and SOA governance ensures that you meet your objectives on the journey.

Heather Kreger is IBM’s lead architect for SOA Standards in the IBM Software Group, with 15 years of standards experience. She has led the development of standards for Web services, Management and Java in numerous industry standards groups including W3C, OASIS, DMTF, and The Open Group. Heather is the author of numerous articles and specifications, as well as the book “Java and JMX, Building Manageable Systems,” and most recently was co-editor of “Navigating the SOA Open Standards Landscape Around Architecture.”