BPM Voices: Standards and why they matter for BPM

What standards are important in the business process management world, and why? Learn about the five types of standards that matter to BPM and why they are valuable to BPM implementers. This content is part of the IBM Business Process Management Journal.

Claus Torp Jensen (ctjensen@us.ibm.com), Senior Technical Staff Member, IBM

Claus JensenClaus Torp Jensen is a Senior Technical Staff Member and Chief Architect for SOA-BPM-EA Technical Strategy at IBM in Somers, NY. He leads IBM's SOA Foundation team, working on the convergence of different architectural disciplines. Claus is a member of the WebSphere Foundation Architecture Board.

Prior to joining IBM, Claus had ten years of experience as a Chief Architect and SOA Evangelist.


developerWorks Contributing author
        level

19 January 2011

Introduction

BPMN, SCA, SOAML, WSDL, OSLC, TOGAF: we've all heard one of more of these acronyms that represent a multitude of existing or emerging standards that apply to the BPM and SOA spaces. Standards are an important part of establishing a common “trading language” for the modern enterprise, internally as well as externally. There are generally five types of standards that are important to a BPM practitioner:

  • Semantic standards such as the The Open Group SOA Ontology define common concepts and terms in support of effective communication and understanding.
  • Format standards such as BPMN 2.0, SOAML, SCA, RAS (Reusable Asset Specification) and OSLC support collaboration and consumability.
  • Framework standards such as TOGAF provide context and structure.
  • Industry model standards such as eTOM (open standard) and IFW (IBM proprietary) act as reference models, benchmarks and accelerators for content and executables.
  • Process standards such as CMMI and ITIL act as benchmarks and accelerators for architecture, engineering and management processes.

You might ask, why do we need so many, and how do they all fit together? To answer that question, let's look in more detail at the standards landscape, and see how semantic standards, format standards, framework standards and industry model standards come together in support of accelerated BPM value.


Semantic standards: The Open Group SOA Ontology

The Open Group recently announced the availability of the Service Oriented Architecture (SOA) Ontology Technical Standard, which is intended to develop and foster a common understanding between business and IT communities regarding SOA concepts and terminology. The ontology defines the concepts, terms and semantics of SOA in a common language that allows for more precise and straightforward communications across the enterprise, reducing ambiguity and misunderstandings.

Semantic standards such as the SOA Ontology provide common terminology and concept mapping that business and technical people can employ to discuss problems and opportunities. Furthermore, such semantic standards bridge different architecture, engineering, business and marketing domains. While rarely complete from a coverage perspective, nevertheless semantic standards create a consistent foundation for inter- and intra-domain communication, a foundation that becomes the backbone of the lingua franca for the enterprise landscape.

Despite years of evolution in systems, SOA, BPM and EA people are often still divided by differing uses of common terms. Definitions of routinely used words like “process,” “service,” “component,” “system,” and “task,” and how those terms relate to each other, can have varied meanings depending on who or what product or tool is doing the defining. In particular, business and technology people may not assign the same definitions or understanding to a concept.

Making sure that you're speaking the same language is essential for any architect to be able to communicate effectively with IT, business, and marketing professionals within the enterprise, as well as with vendors and suppliers outside the enterprise. Until very recently though, there has been little focus in the industry on semantic standards; most standardization efforts have been addressing resource format standard. That balance needs to change, especially because format standards have little value without common semantics for the kinds of things that the format standards apply to. After all, what good is a standard for process model notation if we don't agree on the concept of process itself?


Resource format standards: BPMN

Business Process Modeling Notation 2.0 (BPMN) seems to be the next big thing in the world of BPM, but should we really care from a business perspective? BPM is a business-oriented discipline after all, so does it really matter what the IT industry does to make processes executable? And how does BPMN 2.0, with its focus on the standardized exchange of processes, fit with the notion that we should really stop copying and start linking instead across disciplines and domains like BPM and EA? And what has any of that got to do with agile change?

Let's take a closer look at what BPMN 2.0 is and isn’t:

What is BPMN
BPMN 2.0 is … BPMN 2.0 is not …
  • A formal industry standard.
  • A standardized way of expressing processes (common visual language).
  • Applicable (with value) to a pure business domain.
  • A foundation for standardized exchange of process resources.
  • Executable at the highest level of detail.
  • A substitute for SOA standards.
  • A process editor (but it can support one).
  • A programming model.
  • A platform.
  • A discipline.
  • An architectural approach.

What this tells us is that there are two very different value propositions for BPMN 2.0. Only one of these is related to standardized exchange; the other is related to the need for a common standardized language that allows us to talk about and define business processes. The latter is critically important for a tribal enterprise desiring to become a nation, and is not related to “copying” at all.

In short, BPMN 2.0 remains an integral part of the future of BPM, but we should adopt a perspective on how best to apply BPMN 2.0 that is more nuanced than much of what has so far been discussed publicly. This perspective must include how to leverage BPMN 2.0 for consumability within and across BPM and other process-oriented disciplines, as well as how to merge linking and BPMN 2.0 resource representations in an effective fashion.


Linking format standards: OSLC

Open Services for Lifecycle Collaboration ([OSLC]) is an open community of individuals from customers, IBM partners, systems integrators, competitors, open source communities and academia (see Figure 1). The community focuses on interoperability interfaces between lifecycle tools for software and systems development, using a technology-neutral approach based on internet standards and protocols.

Figure 1. Front page of open-services.net
Front page of open-services.net

What's important for our understanding of the standards landscape is that, contrary to many other format standards, the OSLC specifications do not focus on the format of a resource, but rather on standardized semantics and formats for links between resources. OSLC specifications importantly include both REST interfaces that must be supported for creating, managing and linking resources and user interface components that must be provided for remote lookup, search, and so on. Different OSLC servers will own and control their own OSLC resources, but will provide just enough standardized interaction semantics to provide a integrated network of linked resources. This environment is not a federated repository, nor a set of isolated repository islands, but rather a semantic resource web very similar in nature to the World Wide Web of internet pages.

Without an industry standard for links it would be very hard, if not impossible, to stop copying and start linking across the enterprise landscape. Consequently, the OSLC specifications are a very critical enabler for the transition from "tribes" to "nations."


Framework standards: TOGAF

The Open Group Architecture Framework (TOGAF) is a documented set of techniques and tools for developing and supporting enterprise architecture. TOGAF describes a meta model, the views and viewpoints associated with the meta model, and the types of phases that a typical enterprise architecture practice will perform. Okay, so what has an EA standard got to do with BPM? TOGAF is relevant to BPM in two different ways:

  • As the preferred architectural framework for many enterprises, hence something that BPM practitioners must be able to relate to.
  • As a representative of the class of framework standards. Currently no BPM-specific framework standards exist, but wouldn’t it be far easier to collaborate within large distributed BPM initiatives if we had clear standardized definitions of BPM phases and artifact types?

Continuing with TOGAF as our example of a framework standard, the phases of TOGAF provide a general approach to enterprise architecture development, as shown in Figure 2.

Figure 2. TOGAF phase model
TOGAF phase model

Each of these phases consumes and produces work products and artifacts that assist in the development of the architecture. Underlying these phases is an abstract artifact meta model that can be interpreted and augmented for a particular enterprise, serving as both a benchmark and an accelerator for architecture development.

In general, framework standards such as TOGAF provide much needed classification and structure for work products--something that is especially important for cross-domain collaboration where crisp context and linking is required.


Industry model standards: IFW

IBM’s Information Framework for Banking (IFW) is a typical example of an industry asset that is a benchmark, a reference model, and an accelerator all at the same time:

  • As a benchmark IFW provides input to and guidance for BPM blueprints and standards.
  • As a reference model, IFW provides business structure and classification to the resources and assets in a BPM portfolio.
  • As an accelerator, IFW provides seed content for BPM projects and solutions.

Not all industry model standards will address all three of these, but all three are in fact typically needed for an accelerated and sustainable BPM transformation. Consequently an enterprise embarking on such a transformation should consider up front which industry models and industry model standards to apply, and leverage those industry models and standards right from the start of the journey. After all, creating models and content is relatively easy compared to the challenges intrinsic in managing and governing what has been created over time.


Process standards: CMMI

Capability Maturity Model Integration (CMMI) is a process improvement approach that helps organizations improve their performance. CMMI can be used to guide process improvement across a project, a division, or an entire organization. This is not process improvement in the BPM sense of optimizing business processes, rather it is improvement of the requirements, engineering and management processes that need to be focused on for effective development and collaboration.

While not directly applicable to the enterprise landscape, CMMI does provide a catalog of engineering processes for which we need to establish a common language and appropriate collaboration patterns. Furthermore CMMI allows us to benchmark the maturity of our existing engineering processes, as well as measure progress over time.

In general, process standards have the same characteristics as CMMI, and while not absolutely required, such standards do provide an additional tool in the tool box for enterprises embarking on a long term journey towards better business outcomes and improved business agility.

Conclusion

In truth, few enterprises need to consider all the different kinds of standards described above--at least not for the first few years of a BPM journey. Having said that, it is still important to understand the value of each type of standard in order to better decide which standards to leverage and when. In particular, understanding the different format standards is critically important for the immature BPM initiative; without such understanding it is very easy to produce assets that are not robust against change or that fail to be understood by anyone outside the initial BPM team.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere
ArticleID=608314
ArticleTitle=BPM Voices: Standards and why they matter for BPM
publish-date=01192011