Since an ICEE is intended to be used by business analysts, it must provide an environment that conforms to their thinking and terminology. Taking a holistic approach, we need to define a business context and represent the entire business ecosystem with its many entities and relationships among them in a way that suits the needs and expectations of the business analyst.

Most of today's BPM software products fail when it comes to describing context. While construction, behavior, information and organization perspectives are supported in varying degrees, the context perspective has long been neglected. However, it is the context perspective that adds a meta perspective at different levels: business level, business process level, business service level, business rule level, information asset level, etc.

Clearly, an ICEE designed for business analysts must provide advanced support for the context perspective at different levels. The most important ones are briefly outlined below.

Business Context

At the business level, business context adds a meta perspective to management. Various organizations have made substantial contributions towards the definition of a generic business-oriented context description. A number of specifications have been developed or are currently under development, including the following specifications:

• Business Motivation Model (BMM)

• Semantics of Business Vocabulary and Rules (SBVR)

• Organization Structure Metamodel (OSM) – in progress

• Value Delivery Metamodel (VDM) – in progress

• Business Process Maturity Model (BPMM)

• Business Process Model and Notation (BPMN)

• Case Management Process Model (CMPM) – in progress

• Unified Service Description Language (USDL) – in progress

Almost all of the above mentioned specifications are driven by different work groups operating under the auspices of the Object Management Group (OMG). Only USDL is being developed by a W3C work group.

While a BPMS can form a solid basis for an ICEE, it is also true that a BPMS that only supports the business process life-cycle is simply inadequate. A business analyst must be able to define the overall business context, starting with the vision statement all the way down to the executable implementations of business objectives. Today's typical BPMS falls short of this requirement.

Completeness of scope refers to a software vendor's vision and determination to help businesses describe their entire business ecosystem, involving business and technical models, in a machine-interpretable form. In more concrete terms, completeness of scope considers a vendor's approach to enable business analysts to develop executable architecture with as little support from IT experts as possible.

Business Process Context

The process context adds a meta perspective to a business process. It relates a business process to various elements, such as:

• A process objective that states the expected result after execution. A process objective, in turn, is related to one or more business objectives.

• A process owner.

• Process customers.

• Governance, risk, and compliance management processes.

• Performance metrics, often using key performance indicators (KPIs).

• Service Level Agreements (SLAs), particularly when processes are exposed as services to customers.

The process context is typically not adequately supported in business process modeling languages, such as BPMN. However, from the business analyst's viewpoint, the process context definitely represents an indispensable perspective.

Business Service Context

We have previously stated that business capabilities can also be thought of as business services. Viewed from a different angle, for a service to be really considered a service, it must represent a business capability. Thus, as we describe business capabilities, we effectively describe potentially marketable artifacts that constitute encapsulated, reusable and business-aligned services. The service context adds a meta perspective to a business service and relates it to various elements, such as:

• Service provider, i.e. the actor that holds governance and operational responsibility for a service.

• Service consumers.

• Governance, risk, and compliance management processes.

• Service KPIs (quality metrics).

• Pricing.

• Legal aspects, describing usage rights as well as general terms and conditions.

• Service Level Agreements (SLAs), which define expected service behavior as well as non-functional properties and qualities under which the service operates.

With conventional service description approaches, the focus is primarily on technical aspects, such as technical access. As a consequence, business persons and service consumers are left in the dark when it comes to understanding what capability a service implements, how it is priced, what the legal terms are, etc.

Business Rule Context

The rule context adds a meta perspective to a business rule and relates it to various elements, such as:

• Business policy that the rule expresses and is derived from.

• Business rule owner.

• Governance, risk, and compliance management processes.

Information Asset Context

The information asset context adds a meta perspective to an information artifact and relates it to various elements, such as:

• Asset owner.

• Usage rights.

• Governance, risk, and compliance management processes.