# On the Move to Business-Driven Alignment of Service Monitoring Requirements

Patrício De Alencar Silva, Hans Weigand

► To cite this version:

Patrício De Alencar Silva, Hans Weigand. On the Move to Business-Driven Alignment of Service Monitoring Requirements. 3rd IFIP Working Conference on Enterprise Interoperability (IWEI), Mar 2011, Stockholm, Sweden. pp.103-117, 10.1007/978-3-642-19680-5_10 . hal-01572099

HAL Id: hal-01572099

https://inria.hal.science/hal-01572099

Submitted on 4 Aug 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# On the move to Business-Driven Alignment of Service Monitoring Requirements

Patrício de Alencar Silva and Hans Weigand

Department of Information Management
Tilburg University, P.O. Box 90153
5000LE Tilburg, the Netherlands
{p.silva, h.weigand}@uvt.nl

**Abstract.** Current service monitoring capabilities have been not designed in alignment with business needs. We argue that service monitoring should be primarily thought of as an economic concern, with proper needs being elicited on the business strategy level and further drilled down to process and IT services management layers. Monitoring needs and capabilities should be designed independently from each other and exposed as abstract monitoring interfaces for matchmaking. This allows for treating monitoring as a service, with more flexibility and adaptability to fulfill specific business needs.

**Keywords:** Early Requirements Analysis, Monitoring as a Service, Value Models.

## 1 Introduction

Value modeling, as structured by the e³value framework, builds upon a set of primitive economic concepts which allow for specifying how enterprises jointly satisfy a consumer's need, by exchange of valuable goods and services [1]. The rationale of a value model is to configure a value network such that its actors create a positive cash flow. By instantiating a value model (via running profitability sheets), it is possible to prospect the profit to be yielded by each actor, to whom it may represent a motivation to join the network or not. A value model, as a business case representation, can be used to configure business processes and IT services from an economic perspective [2].

A value model, nonetheless, states just “promises” made by business actors to create value in discourse. “Real” value delivery bounds to performance constraints of underlying business processes and IT services. As there are risks of sub-optimal value delivery by any of the actors engaged on a network, a research question that arises is *how value networks can be monitored*. This question further split into (1) *what monitoring requirements are critical for preserving a value network* and (2) *how these requirements can be realized by service monitoring mechanisms*. Answering these questions somewhat depend on a reality check on how service monitoring has been *designed* and *realized* nowadays.

An extensive literature overview has revealed that, in general, service monitoring *has not* been actually business-driven. Strategic business goals (e.g. to maximize value creation) and business process monitoring capabilities are rather disconnected. Although process modelers may have knowledge on process monitoring aspects, typically they are not assigned to define enterprise-level service monitoring affairs. For instance, monitoring has a cost and can constitute a business in its own, with a proper rationale, roles, services
and policies. From this point-of-view, it is worth to design service monitoring as a value-
adding process, complementary to core businesses. Yet, without defining enterprise-level
service performance metrics (a.k.a. Key Performance Indicators – KPIs) [3], “business”
process monitoring is relegated to random Process Performance Metrics (PPMs), which
may become meaningless to the business if not precisely connected to its strategic KPIs.
Actually, such a practice leads to overfitting and underfitting of service monitoring
requirements. When a KPI is more comprehensive than its potentially related PPMs,
which in turn may not be computable from process execution data, KPIs overfit PPMs. In
the opposite situation, KPIs underfit PPMs. In the last case, PPMs query too much from
process execution data, therefore wasting service monitoring resources, and recursively
turning monitoring into a system bottleneck. Our first research problem therefore is that
start thinking about monitoring on the “process” level gives no hint on what monitoring
requirements are critical for a business case.

This study has also revealed that, generally, service monitoring *has not* been designed
in a service-oriented way. The initial WfMC vision [4] for process/service monitoring as a
pluggable component to process execution environments is not a reality yet. Distinction
between monitoring needs and capabilities is rather blurred. Tightly coupling of
monitoring requirements specifications with monitoring services' capabilities reduces
flexibility and adaptability on discovering, selecting and composing monitoring services
and resources. This in turn affects negatively the economy of monitoring. Our second
research problem thence comprises that *it is currently difficult to assert precisely how*
*monitoring requirements can be fulfilled by service monitoring mechanisms, because*
*“what-has-to-be” is still hardly-coupled with the “how-can-it-be” monitored.*

To start treating these problems, we propose two guidelines for designing service
monitoring requirements on business collaborations: (1) start designing these requirements
from the business strategic level, and further drill them down to the process and IT service
layers, via Model Driven Engineering (MDE); and (2) decouple service monitoring
“needs” from corresponding capabilities, treating *monitoring as a service* (MaaS). These
two principles are integrated in a conceptual framework, whose architectural description is
the first contribution of this paper. The framework grounds on the idea of using value
models to configure business processes and IT services [2]. The concepts behind value
models are extended with monitoring concepts, so as to enable an early service monitoring
requirements analysis *from* and *for* the core business case. We therefore use *value models
for monitoring value models*, which is the second contribution of this paper. Finally, we
employ the framework on deriving service monitoring requirements of a real-world case
study in electricity markets. The case brings about the specification of strategic service
monitoring requirements for a value network of actors trading electricity production and
consumption in a highly valued market of renewable energy resources, whose delivery of
forecasted electricity amount depends on the stochastic nature of power generation.

This paper is structured as follows. In section 2, we present some of the current
interoperability gaps in service monitoring based on surveying criteria derived from our
research questions. In section 3, we introduce our framework for alignment of service
monitoring requirements. In section 4, we pave the first layer of the framework by
extending value models to specify service monitoring requirements. The extension is then
applied on the electricity trading business case. Finally, we provide some discussions and
outline for future research in section 5.
## 2 Currently Open Interoperability Issues in Service Monitoring

In this section, we present the results of a literature survey in business process monitoring. The objective is to position our research questions in the state-of-the-art in this field, so as to attest problem relevance. Based on those questions, we defined a set of evaluation criteria defined in terms of requirements. The six first ones relate to the specification of “what-has-to-be” monitored. The seventh one relates to the practical issue of how the “what-has-to-be” could be matched with the “how-can-it-be” specification. The evaluation requirements are detailed as follows:

**RQ-1: Business Rationale Definition** – this requirement answers *why* to monitor. It relates to business strategic goals behind monitoring strategies. For instance, the business rationale behind a value model is the shared goal of “maximizing profitability”. This economic principle can be the same goal of monitoring, which ought to be configured to add value to the business. Other business rationales may be employed, though, grounded on different business management theories. This requirement requests on to what extent a strategic business goal has been considered as a primary driver for service monitoring configuration.

**RQ-2: Business Level Requirements Specification** – this requirement requests for the definition of *who*, *what* and *how* to monitor on the business level. These aspects refer to business monitoring *actors*, *objects* and *policies*, respectively, which can comprise the specification or an *abstract monitoring protocol*.

**RQ-3: Process Level Requirements Specification** – this requirement requests for the definition of the same elements stated in **RQ-2**, but referring to a set of processes, messages and process-level communication policies necessary to monitor process collaborations.

**RQ-4: IT Service Level Requirements Specification** – similar to **RQ-3**, but referring to the specification of IT services' inputs, outputs and access policies subject to monitoring from underpinning processes.

**RQ-5: Organizational Requirements Specification** – this requirement requests for the definition of role hierarchies and separation of duties (SoD) possibly maintained apart from monitoring policies. It constrains *who* can be involved in a monitoring. Such constraints should be initially defined on the business level and further refined in the IT services level.

**RQ-6: Monitoring Metrics Specification** – this requirement specializes how monitoring can be performed. Monitoring metrics are used to disclose verifiable information from monitored objects. They can be specified on the business strategy level (i.e. KPIs for measuring organizational performance), on the process level (i.e. PPMs for measuring process collaboration performance) and on the IT services level (i.e. for measuring network QoS).

**RQ-7: Monitoring Interfaces Specification** – this requirement requests for a clear separation of monitoring needs and capabilities. It assesses whether the principle of service orientation has been somewhat applied on the monitoring configuration.

The evaluation is summarized in **Table 1**. The analyzed works are ordered chronologically. Each a work is evaluated by considering each requirement explicitly, partially, or not considering. **RQ-7** is not applicable in some sparse cases. The works were selected from peer-reviewed publications in the field of business process monitoring, from 2004 to the current year.
<table><caption>**Table 1.** Comparison of approaches for business process monitoring.</caption><thead><tr><th rowspan="2">REFERENCE</th><th rowspan="2">RQ-1</th><th rowspan="2">RQ-2</th><th rowspan="2">RQ-3</th><th rowspan="2">RQ-4</th><th colspan="2">RQ-5</th><th colspan="3">RQ-6</th><th rowspan="2">RQ-7</th></tr><tr><th>BUS.</th><th>IT</th><th>KPI</th><th>PPM</th><th>QoS</th></tr></thead><tbody><tr><td>Zur Muehlen [5]</td><td>No</td><td>No</td><td>Part.</td><td>No</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td><td>No</td><td>Part.</td></tr><tr><td>Küng et al.[6]</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td></tr><tr><td>Srinivasan et al.[7]</td><td>Part.</td><td>No</td><td>Part.</td><td>No</td><td>Yes</td><td>No</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td></tr><tr><td>Yu, Jeng [8]</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Part.</td><td>Part.</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td></tr><tr><td>Alles et al [9]</td><td>Part.</td><td>No</td><td>No</td><td>No</td><td>Part.</td><td>Part.</td><td>No</td><td>No</td><td>No</td><td>No</td></tr><tr><td>Greiner et al [10]</td><td>Part.</td><td>Part.</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td></tr><tr><td>Abe, Jeng [11]</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Part.</td><td>Part.</td><td>Yes</td><td>No</td><td>No</td><td>Yes</td></tr><tr><td>Beeri et al.[12]</td><td>No</td><td>No</td><td>No</td><td>Part.</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td><td>Yes</td></tr><tr><td>Kim et al.[13]</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td><td>No</td></tr><tr><td>Strnadl [14]</td><td>Part.</td><td>No</td><td>Part.</td><td>No</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td><td>No</td><td>Part.</td></tr><tr><td>Chen [15]</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Part.</td><td>No</td><td>Yes</td><td>No</td><td>No</td><td>No</td></tr><tr><td>Ferro et al.[16]</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td><td>No</td></tr><tr><td>Lamparter et al.[17]</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>-</td></tr><tr><td>Paschke, Bichler[18]</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>-</td></tr><tr><td>Pedrinaci et al.[19]</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Part.</td><td>Part.</td><td>Yes</td><td>Yes</td><td>No</td><td>Part.</td></tr><tr><td>Rimini, Roberti[20]</td><td>No</td><td>Part.</td><td>No</td><td>No</td><td>Part.</td><td>No</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td></tr><tr><td>Tsai et al.[21]</td><td>No</td><td>No</td><td>Yes</td><td>Part.</td><td>No</td><td>Part.</td><td>No</td><td>No</td><td>Yes</td><td>No</td></tr><tr><td>Unger et al.[22]</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>-</td></tr><tr><td>Vaculín, Sycara[23]</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>No</td></tr><tr><td>Bai et al.[24]</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td><td>No</td></tr><tr><td>Comuzzi et al.[25]</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>Part.</td></tr><tr><td>Fugini, Siadat[26]</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>No</td></tr><tr><td>Kang et al.[27]</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>No</td><td>No</td><td>No</td></tr><tr><td>Momm et al.[28]</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td><td>No</td><td>Yes</td></tr><tr><td>Pourshahid et al.[29]</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>No</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td></tr><tr><td>Robinson, Purao[30]</td><td>No</td><td>Part.</td><td>Yes</td><td>No</td><td>Part.</td><td>Part.</td><td>No</td><td>Yes</td><td>No</td><td>Part.</td></tr><tr><td>Spillner et al[31]</td><td>Part.</td><td>Part.</td><td>No</td><td>Yes</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td></tr><tr><td>Wang et al.[32]</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>No</td></tr><tr><td>Han et al.[33]</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>No</td></tr><tr><td>v. d. Aalst et al.[34]</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td><td>Yes</td></tr><tr><td>Wetzstein et al.[35]</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td><td>Part.</td><td>Part.</td><td>Yes</td><td>Yes</td><td>Yes</td><td>No</td></tr></tbody></table>

From **Table 1** it can be inferred that most of the contributions have focused on SLAs and QoS metrics. KPIs and PPMs are the second most considered aspects, followed by organizational aspects, and business strategy and business level agreements at last. That is, current business process monitoring has been driven more by QoS related aspects than properly by business ones. Although this may indicate an increasing maturity of system-related monitoring capabilities, their effectiveness for businesses depend on how aligned they are with real business needs defined in terms of strategic business goals.

Specific findings include that: (1) with the exception of the work of Wetzstein et al. [35], correlations between KPIs, PPMs and QoS metrics were not fully considered; (2) few works have aligned organizational monitoring requirements in both business and IT service levels; (3) none of the works consider business, process and IT service monitoring requirements specifications as related by derivation; (4) even when partially considered, business monitoring requirements are not drilled down to the IT service layer; and (5) the concept of monitoring interface is seldom used.

The literature survey has revealed some critical research gaps in business process/service monitoring, which match with our research questions and attest their relevance. At a first instance, there is a problem of *design* of monitoring requirements on the business strategy level. Second, there is a problem of integration of cross-layered service monitoring requirements. In the next section we introduce our approach to start dealing with these problems.
# 3 Business-Driven Alignment of Service Monitoring Requirements

## 3.1 Value-Driven Service Monitoring Configuration Framework

Our framework is depicted in Fig. 1. We use architectural description guidelines provided by the IEEE Std 1471-2000 recommended practice [36]. The starting point is a 3- viewpoint service configuration framework which uses value models to derive business process and IT services models [2]. Each viewpoint comprises a service management layer. A value model represents a business case, with a proper system of economic actors and transactions. This system is derived from the concepts defined by the *e³value* framework meta-model, which formalizes primitive economic concepts for service exchange. A value model derives business processes and IT services’ descriptions, which can be executed in different service execution platforms. For instance, a value model can be “executed” by running profitability sheets (a value-level reasoning service), whereby its concepts are instantiated for calculating an expected profit to be yielded by each actor within the collaboration, based on an estimation on the number of transactions to be performed. The configured process and IT service models can be executed on different execution services.

<figure><img src="image_2.png" /><figcaption>Fig 1. Value-Driven Service Monitoring Configuration Framework.</figcaption></figure>

We extend this framework with a mirrored supporting one for seamlessly deriving service monitoring requirements from and for the core business case. The extension starts with a value monitoring meta-model, which extends the *e³value* meta-model with a set of
monitoring concepts for defining abstract monitoring protocols. The so-called value monitoring meta-model is used as a starting point to derive a 3-viewpoint set of monitoring models aligned with the core business. The monitoring models do not constitute a completely independent business, but consist on subsystems of the core business' ones. The internal separation of requirements, though, is aimed to enable cost assessment of different monitoring strategies and configurations. Truly, if monitoring aspects interleave the core business ones, it becomes difficult to assess monitoring as a value-adding process *per se*.

The generated monitoring models define monitoring needs *from* and *for* the underpinning business cases, and can be exposed as provided service interfaces. The same interface can be fulfilled by different monitoring services. For instance, by providing the monetary cost of economic objects traded on the value network, it is possible to perform a value-level monitoring via calculations provided from different investment theories (performed as reasoning services), such as the Discounted Net Present Cash Flow (DNPC) or Return on Total Assets (ROTA). If performed *ex-ante* the connection of the monitoring services to the (core) service execution environments, such calculations can provide just an *estimation* of value creation. If performed *ex-post*, i.e. in execution time via gathering monitoring data from BAM and/or PM engines, they can potentially reveal to what extent value creation is dependent on the performance of underlying processes and IT services. The *abstract state* of the framework, with its systems and subsystems is depicted in Fig.1.

The framework *dynamics* is briefly described as follows. A business case is defined using a value model, from which process and IT service models are derived. These models are delivered to service execution platforms, enclosing the core business service configuration process, which for a detailed description we refer the reader to [2]. From the core business value model, monitoring requirements are elicited, which drive the specification of corresponding requirements on the process and IT service viewpoints. These requirements can be exposed as required monitoring interfaces. Service discovery, selection and composition mechanisms can be used to match monitoring needs with capabilities exposed by monitoring services. An example of monitoring capability is the set of monitoring metrics (e.g. KPIs, PPMs and QoS metrics) directly computable from service execution data. Being it part of the monitoring configuration, this matchmaking can define, in *design time*, what monitoring requirements are amenable to verification. By connecting the service monitoring services to the (core) business execution ones, monitoring metrics become amenable to verification in *execution time*. In short, the framework aims to integrate MDE and MaaS on service monitoring configuration.

## 3.2 Value Viewpoint on Service Monitoring

We start paving the vision of the framework by specifying the concepts of the value monitoring meta-model. As depicted in Fig. 2, all of its concepts are defined as stereotypes extending the meta-classes defined in the original *e³value* meta-model (vide Fig. 2(a)). We describe each element as follows:

**Monitoring Actor:** an economically independent entity involved in a monitoring problem emerged from a business case. A monitoring problem starts with the typical scenario from the Agency Theory, where a *manager* (consumer) requests a service/good of value from an *agent* (provider) in exchange of an economically reciprocal one. As the
agent may omit information about real value production and delivery, the manager may employ different strategies to get access to disclosure reliable information. Disclosure of internal value creation of enterprises is generally subject to regulation and may involve external parties. A monitoring actor, thence, can play different roles in a monitoring scenario, such as: (1) a *manager*, the active party who requests for monitoring; (2) an *agent* (the passive party subject to monitoring); (3) a *third-party*, who provides monitoring services, acting on behalf of the manager (e.g. accountants, auditors, expert witnesses, consultants, etc.); and (4) a *regulator* (who can grant access to verifiable information to any of the other parties [37]). Monitoring actors comprise the organizational view on the value monitoring viewpoint.

**Monitoring Market Segment:** consists of a set of monitoring actors involved in a same monitoring service, i.e. providing and/or consuming the same type of monitoring objects.

**Monitoring Object:** refers to the concept of monitoring *evidence* or reliable information about value creation, disclosed from and to a monitoring actor, in a document-based form. It can be of a *primary* type (i.e. raw information obtained directly from the agent) or a *secondary* one (e.g. reports and all kinds of information synthesized by third-parties). It can be subject to voluntary or mandatory disclosure [38].

**Monitoring Port:** used to request or to provide monitoring objects from and to its environment, which consist of other actors exchanging other objects.

**Monitoring Interface:** comprehends a logical container of monitoring ports, consisting of a channel whereby monitoring objects are offered from and to a monitoring actor. In *e³value*, interfaces can be attached to internal value activities. However, as we are dealing with monitoring on the enterprise-level, we consider monitoring interfaces being attached only to actors.

<figure><img src="image_3.png" /><figcaption>Fig 2. (a) *e³value* meta-model and (b) value monitoring meta-model.</figcaption></figure>

**Monitoring Exchange:** comprises the communication act of transferring a monitoring object *from* and *to* a monitoring actor, through a monitoring interface.

**Monitoring Transaction:** a pair of economically reciprocal monitoring exchanges.
**Monitoring Policy:** a concept derived from the Role Based Access Control (RBAC) standard [39], which provides an abstract framework for promoting security administration on the business enterprise level. RBAC defines policies as *permissions*, which are referred to as functions that map a set of operations into a set of objects. Policy semantics depend on the abstraction level of the system in analysis. Here, policies are necessary to restrict access to private information about value creation. They define constraints over monitoring transactions, i.e. it defines *what* monitoring objects can be transferred from and to *whom*. Policies are attached to interfaces, which contains ports giving access to the monitoring objects. They can be derived from scenarios [40] and involve specific relations among monitoring roles, which for the sake of simplicity are not shown in **Fig. 2(b)**, but will be further demonstrated in **section 4**, through the analysis of the business case study.

**Monitoring Metric:** refers to enterprise-level performance metrics, i.e. KPIs. In *e*<sup>3</sup>*value*, a value port is used in profitability sheets to register the number of value objects produced/consumed by an actor. KPIs can cover different facets of organizational performance, such as the ones defined by the Balance Scorecard [3]. For instance, from a financial perspective, a KPI can be formulated declaratively on top of value ports as a composition of an *aggregation function*, a *value object*, a *time component* and a *location component*. An example of a simple KPI could be "*the average number of service units sold per day in region X*". Complex KPIs can be formulated on top of simpler KPIs (e.g. *annual net profit*). More specific KPIs can be specified by using a qualitative aspect to define the way the value object is provided, defined elsewhere as "second-order" value [41]. Examples of second-order values are speed and reliability (defined separately on benchmarking standards). Although not explicitly defined in *e*<sup>3</sup>*value*, KPIs can be used to measure enterprise-level performance, both on core and monitoring value networks.

The rationale behind this meta-model is to allow for treating monitoring as a business in its own, aimed to maximize value production of the (core) supported business case. In the next section, we demonstrate how these concepts can be used to derive business requirements for monitoring, by applying them on a real-world case study.

# 4 Early Service Monitoring Requirements Analysis via Value Models

In this section, we apply the value monitoring viewpoint on a case study in electricity trading markets. The case is provided by the Energy research Center of the Netherlands (ECN) and is concerned with the need for enterprise-level monitoring strategies to cope with the problem of reducing the imbalance between the amount of energy produced and consumed. We provide firstly a snapshot on the core business case. Following, we elaborate on the monitoring problems in the case, by providing guidelines to mitigate them using *value models to monitor value models*.

## 4.1 Business Case Description

The Electricity System is composed by two related subsystems: the *commodity subsystem* (for energy trading) and the *physical subsystem* (for energy generation, transmission and distribution). The Directive 2003/54/EC [42] provides a full description of attributions and legal responsibilities of the actors operating in the whole system. The Transmission
System Operator (TSO) is on the intersection of these two systems, being responsible for matching overall production with demand for electricity. Energy suppliers accredited as Balance Resource Parties (BRPs) have the obligation to supply the TSO with energy programs, which posit the amount of electricity to be consumed and produced within a time interval of 15 minutes, based on forecast. This is necessary so as the TSO can prospect the full system capability to mitigate risks of surpluses or shortages.

High instance drivers, such as environmental issues, have pushed the inclusion of renewable energy resources so as to boost the energy mix (e.g. wind, solar, and biomass). However, even being effectively used to balance the system, intermittent sources such as wind and solar energy often create extra imbalances. When a wind turbine fails on delivering the expected electricity, it has to pay costs to the TSO. Two options are left to the supplier to cope with the failure: (1) to pay the balancing costs directly to the TSO, which may be high, for service transparency; or (2) use its own reserves to balance the system, which include either to freelance on the wholesale market to discover a bundle of Distributed Energy Resources (DER), or to use DERs from its own portfolio of reserves; in both cases, the DERs could fulfill the balance in aggregation. The second option has a high business value. In the best case, it can balance the system and yield profit. In the worst case, though, it can cause extra system imbalances.

A basic value model for this scenario is depicted in Fig. 3. It starts with the BRP's need for balancing its electricity production, which can be fulfilled by the DERs in two ways: the BRP can manage DERs directly, or can do it via intermediaries, so-called *aggregators*, which bundle DERs' individual capacities and offers to the BRP. This service has an aggregated value, as it hides from the BRPs the complexity of managing small-scale DERs. Low-capacity DERs increase their chances to sell energy to BRPs when included in an aggregators' portfolio. Aggregators constitute a new market segment, being subject of current research and future regulation. From this point, many monitoring scenarios can be identified. The electricity offered here is just an estimate. Risks of sub-optimal energy delivery threats value creation of all the actors. To mitigate these risks, actors can employ different monitoring strategies on one another, which can include the design of parallel monitoring sub-networks, with their corresponding set of actors and services, aimed to support value production on the core business scenario.

## 4.2 Value Monitoring Viewpoint on the Electricity Imbalance Reduction Case

We have followed five steps for developing a value viewpoint on defining monitoring strategies for a business case. They elaborate on the concepts defined in **section 3** and are described as follows, interleaving examples from the case study:

**Step 1 - Identify monitoring scenarios:** as monitoring can be treated as a (business) need, we start by eliciting *who* wants to monitor *whom*. This can be done on a two-by-two actors' basis. From our business case, we take a snapshot on aggregators (as *managers*) which want to monitor DERs (as *agents*). Other scenarios would include BRPs and aggregators, and BRPs and DERs. From this point, the problem is to find alternative monitoring networks of *third-parties*, which could provide monitoring objects primarily produced *by* the agent *to* the manager.
<figure><img src="image_4.png" /><figcaption>Fig 3. Snapshot on the Imbalance Reduction Business Case.</figcaption></figure>

**Step 2 – Define monitoring policies:** these policies reduce the space of possible monitoring configurations to a set of law-compliant ones. Generally, they are defined by *regulators*, but can be subject of negotiation among the other actors. Consider our scenario of aggregators and DERs. A DER “promises” to deliver electricity to the aggregator, but the “real” electricity production can only be verified by duly authorized metering services. Recently, smart meters have been considered as a mean to collect more accurate information about electricity consumption and production [43]. Apart from its envisioned benefits, the introduction of smart meters in the electricity market has generated controversies on the disclosure of private verifiable information. Before the deregulation of the metering market segment, the Distribution Network Operator (DNO) was exclusively responsible for the management of collected consumption data. However, after the deregulation, BRPs can be granted with the responsibility for obtaining and validating measurement data from DERs [44]. Instead of being dependent on the DNO, an aggregator could therefore exercise control over this process, provided that either it enters into an agreement with an authorized Metering Responsible Party (MRP, *third-party*) or gets accredited as a MRP by the DNO. It is up to the monitored party to decide which parties, apart from the DNO, are to be given any additional access to the raw (*primary*) measurement data obtained via the meter.

We model this new situation for the metering scenario as a monitoring policy, depicted in **Fig. 4**. The starting point is the *manager's need* for monitoring the agent. This need can be fulfilled by monitoring objects provided by different monitoring actors, through different *traces*. A *trace* is a value creation path, starting at the manager's need and ending on the agent's boundary element, where the monitoring object is produced. The OR and AND-dependencies define policy *alternatives* and *duties*, respectively. These policies can be defined following a contract-first approach: a hierarchy of monitoring objects must be defined first, and then, they are attached to interfaces. The interfaces can further be attached to value activities and then to actors performing these activities. As we are
defining an enterprise-level monitoring protocol, the internal activities are suppressed here, and we focus on monitoring objects rather than on the way they are produced. All the actors and monitoring objects are stereotyped using a UML-like graphical representation, according to the meta-model shown in **section 3**. The other objects are not typical monitoring ones, but are necessary to preserve the economical reciprocity. More complex policies can be defined by adding role hierarchies (e.g. hierarchies of regulators), separation of duties (for solving policy conflicts on role hierarchies) and time constraints (e.g. by setting different contractual times for the value transactions). Nonetheless, for the sake of tractability, we start from a *flat* RBAC strategy, which comprises basically defining policies and assigning them to stereotyped roles and further to actors [39].

<figure><img src="image_5.png" /><figcaption>Fig 4. Example of a monitoring policy expressed in a value model.</figcaption></figure>

**Step 3 – Select a short-list of policy-compliant monitoring alternatives:** from the example depicted in Fig. 4, it is possible to identify three alternative paths for the aggregator to monitor DERs: it can get *secondary* monitoring information from the MRP, *primary* data from the DERs, or it can get both. In a more complex policy definition, a wider list of policies could be identified. Monitoring paths not specified in the policies are not allowed. That is why the monitoring policies reduce the monitoring configuration space. Selecting a pre-list of alternatives may depend on aspects such as the manager’s internal assets to process data, or the need for more accurate data, in highly distrusted relationships. For instance, it could be sufficient for an aggregator to trust on the data provided by the MRP. For another one, however, it could be necessary to cross evidences from both primary data and secondary information. The last case can be particularly effective on mitigating fraud risks.

**Step 4 – Derive KPIs to evaluate monitoring alternatives:** KPIs can be defined to assess the pay-off of each monitoring strategy. According to our monitoring meta-model, these metrics are attached to value ports. If an actor wants to assess its *delivered* performance, the KPIs shall be attached to its *outgoing-points*. For assessing *received* performance, KPIs shall be attached to *ongoing-ports*. A KPI query can be formulated by concatenating an *aggregation function* (e.g. average, total, maximum,
minimum) with a value *object discriminator* (e.g. units transferred), a *time unit* and a *locative unit* (not originally defined in *e*<sup>3</sup>*value*, but important for this case study). For instance, a KPI for prospecting performance received from the aggregator could be the *average power delivered by the DERs per month in Noord-Brabant, NL*. This KPI is for assessing performance of the “monitoring” transaction. It has to be compared with the corresponding KPI from the core business, e.g. the *average power offered/promised by the DERs per month in Noord-Brabant, NL*. The difference between monitoring and core business KPIs can be used on incurring penalties and compensations for the parties involved. For generating reports, KPIs can appear on the model in form of annotations, or can be defined apart, in profitability sheets.

**Step 5 – Calculate ROI for each monitoring alternative:** finally, the return on investment of each monitoring strategy can be calculated. Thus, it is necessary to assess *investments* and *expenses* on monitoring. For instance, if an aggregator decides to process by itself the raw data gathered from the DERs, it has to cope with incurred investments on internal monitoring resources (e.g. metering information systems). If it decides to get data from a metering party, it has to cover the expenses with metering fees. Investments and expenses have to be subtracted from the expected return of the monitoring strategy (previously calculated via KPIs), for the sake of risk analysis. We can here identify two trade-off monitoring scenarios in this situation. If the DERs fail on delivering the electricity, the aggregator can use the penalty to cover the costs of monitoring and also to pay its own implied penalties to the BRP, in the macro business scenario depicted in **Fig. 3**. If the DERs deliver the promised amount of electricity, the costs of monitoring for the aggregator can be compensated by absenting from incurred penalties to the BRP, in the macro business scenario. Many other trade-offs can be identified, which can be used to select the (potentially) best pay-off monitoring configuration. The selected monitoring configuration can be attached to the core business scenario, as contractual terms and conditions expressed in terms of information disclosure policies.

These five steps produce a value viewpoint on service monitoring. Here we
developed the monitoring rationale from the *manager's role* view, which in the
electricity imbalance case, corresponds to the aggregator's role. Nevertheless,
perspectives from the other monitoring actors may coexist, derived from the same core
business case, which may not be necessarily convergent a priori. They can be used,
however, for negotiating monitoring policies on enterprise-level business collaborations.

**5 Discussion**

In this paper we have demonstrated on a gap existing between the way business
process/service monitoring is currently performed and critical business drivers (for
monitoring). To start filling this gap, we have proposed a conceptual framework
aimed to start configuring monitoring strategies from the business strategy layer.
Assuming the use of value models on configuring business processes and services, we
have demonstrated how to use them per se to reason about monitoring problems and
alternative solutions from and for a business case. Proof-of-concept was provided via
early monitoring requirement analysis from a real-world case study. We have primed
for simplicity on the design of the value viewpoint on monitoring, as it is still unclear
whether and how its most basic concepts can be drilled down to the process and IT
service management layers. At this phase, complexity may introduce additional
alignment problems across service management layers, which should be avoided.

Next steps of this research include: (1) the mapping of the value viewpoint on service monitoring on the process viewpoint one; and (2) formalization of the operations for discovery, selection and composition of monitoring services based on the abstract monitoring interfaces and protocols defined on these two viewpoints. A second real-world case study, on Intellectual Property Rights in the music industry is planned.

References

1. Gordijn, J., and Akkermans, H.: Value based requirements engineering: Exploring innovative e-commerce idea. In: Requirements. Eng. Journal, Vol. 8(2), 114-134 (2003)

2. Gordijn, J., Weigand, H., Reichert, M., and Wieringa, R.: Towards self-configuration and management of e-service provisioning in dynamic value constellations. In Proc. SAC '08, 566-571 (2008)

3. Parmenter, D.: Key Performance Indicators. Willey (2007)

4. Hollingsworth, D.: Workflow Management Coalition (WfMC), The Workflow Reference Model, Document Number TC00-1003, Document Status - Issue 1.1 (1995)

5. zur Mühlen, M.: Workflow-based Process Controlling. Foundation, Design, and Implementation of Workflow-driven Process Information Systems, vol. 6 of Advances in Information Systems and Management Science. Logos, Berlin (2004)

6. Küng, P., Hagen, C., Rodel, M., Seifert, S.: Business Process Monitoring & Measurement in a Large Bank: Challenges and Selected Approaches. In: Proc. DEXA'05), 955-961 (2005)

7. Srinivasan, S., Krishna, V., and Holmes, S.: Web-Log-Driven Business Activity Monitoring. Computer 38, 3, 61-68 (2005)

8. Yu, T and Jeng, J.-J.: Model Driven Development of Business Process Monitoring and Control Systems. In Proc. ICEIS 2005, vol. 3, 161-166 (2005)

9. Greiner, T., Düster, W., Pouatcha, F., von Ammon, R., Brandl, H., and Guschakowski, D.: Business activity monitoring of norisbank taking the example of the application easyCredit and the future adoption of Complex Event Processing (CEP). In: Proc. PPPJ '06, vol. 178, 237-242 (2006)

10. Alles, M., Brennan, G., Kogan, A., Vasarhelyi, M.A. Continuous Monitoring of Business Process Controls: A Pilot Implementation of a Continuous Auditing System at Siemens. Int. Jour. of Accounting Information Systems, vol. 7, 137-161 (2006)

11. Abe, M., Jeng, J., and Li, Y.: A Tool Framework for KPI Application Development. In: Proc. ICEBE.'07, 22-29 (2007)

12. Beeri, C., Eyal, A., Milo, T., and Pilberg, A.: Monitoring business processes with queries. In Proc. 33rd VLDB, 603-614 (2007)

13. Kim, H. Lee, Y.-H. Yim, H. Cho, N. W.: Design and Implementation of a Personalized Business Activity Monitoring System. In: J. Jacko (Rd.): HCII, Part IV, LNCS 4553, 581-590 (2007)

14. Chen, P.: Goal-Oriented Business Process Monitoring: An Approach based on User Requirements Notation Combined with Business Intelligence and Web Services, M. Sc. Thesis, Carleton University, Ottawa, Ontario, Canada (2007)

15. Ferro, D. N., Hoogendoorn, M., and Jonker, C. M.: Ontology-Based Business Activity Monitoring Agent. In: Proc. WIC'08, 491-495 (2008)
16.Strnadl, C. F.: Bridging Architectural Boundaries Design and Implementation of a Semantic BPM and SOA Governance Tool. In: Proc. ICSOC'07. B. J. Krämer, K. Lin, and P. Narasimhan (Eds.) LNCS, vol. 4749, 518-529 (2007)

17.Pedrinaci, C., Lambert, D., Wetzstein, B., van Lessen, T., Cekov, L., and Dimitrov, M.: SENTINEL: a semantic business process monitoring tool. In: Proc. OBI '08, vol. 308, 1-12 (2008)

18.Paschke, A. and Bichler, M.: Knowledge representation concepts for automated SLA management. Decis. Support Syst. 46, 1 (Dec. 2008), 187-205.

19.Lamparter, S., Luckner, S., and Mutschler, S.: Semi-Automated Management of Web Service Contracts. Int. Jour. of Service Sciences (IJSSci), 1, (3/4), (2008)

20.Rimini, G., and Roberti, P.: Business Process Monitoring: BT Italy case study. In: Mazzeo, A., Bellini, R., and Motta, G. (Eds.): IFIP Fed. for Inf. Processing: E-Government ICT Professionalism and Competences Service Science, vol. 280, 227-234 (2008)

21.Tsai, W. T., Zhou, X., Wei, X.: A Policy Enforcement Framework for Verification and Control of Service Collaboration., ISeB 6, 83-107 (2008)

22.Unger, T., Leymann, F., Mauchart, S., and Scheibler, T.: Aggregation of Service Level Agreements in the Context of Business Processes. In Proc. EDOC'08, 43-52 (2008)

23.Vaculin, R. and Sycara, K.: Semantic Web Services Monitoring: An OWL-S Based Approach. In: Proc. HICSS'08, 313- (2008)

24.Comuzzi, M., Kotsokalis, C., Spanoudakis, G., and Yahyapour, R.: Establishing and Monitoring SLAs in Complex Service Based Systems. In: Proc. ICWS'09, 783-790 (2009)

25.Bai, X., Liu, Y., Wang, L., Tsai, W., and Zhong, P.: Model-Based Monitoring and Policy Enforcement of Services. In: Proc. SERVICES'09, 789-796 (2009)

26.Fugini, M., and Siadat, H.: SLA Contract for Cross-Layer Monitoring and Adaptation. In: Rinderle-Ma et al. (Eds.): BPM 2009 International Workshops, LNBIP 43, 412-423 (2010)

27.Kang, B., Lee, S. K., Min, Y.-b., Kang, S.-H., Cho, N. W.: Real-time Process Quality Control for Business Activity Monitoring. In: Proc. of ICCSA'09, 237-242 (2009)

28.Momm, C., Gebhart, M., and Abeck, S.: A Model-Driven Approach for Monitoring Business Performance in Web Service Compositions. In: Proc. ICIW'09, 343-350 (2009)

29.Pourshahid, A., Amyot, D., Peyton, L., Ghanavati, S., Chen, P., Weiss, M., and Forster, A. J.: Business process management with the user requirements notation. Electronic Commerce Research 9, 4 (Dec. 2009), 269-316

30.Robinson, W. N. and Purao, S.: Specifying and Monitoring Interactions and Commitments in Open Business Processes. IEEE Softw. 26, 2 (Mar. 2009), 72-79.

31.Spillner, J., Winkler, M., Reichert, S., Cardoso, J., and Schill, A. Distributed Contracting and Monitoring in the Internet of Services. In: Proc. 9th IFIP WG 6.1 DAIS'09. In: T. Senivongse and R. Oliveira (Eds.), LNCS, vol.5523, 129-142 (2009)

32.Wang, Q., Shao, J., Deng, F., Liu, Y., Li, M., Han, J., and Mei, H.: An Online Monitoring Approach for Web Service Requirements. IEEE Trans. Serv. Comput. 2, 4 (Oct. 2009), 338-351.

33.Han, K. H., Choi, S. H., Kang, J. G., and Lee, G.: Performance-centric business activity monitoring framework for continuous process improvement. In: Proc. WSEAS'10. In: L. A. Zadeh, J. Kacprzyk, N. Mastorakis, A. Kuri-Morales, P. Borne, and L. Kazovsky (Eds.) Artificial Intelligence Series, Stevens Point, Wisconsin, 40-45 (2010)

34.van der Aalst, W.M.P., Rubin, V., Verbeek, H.M.W., van Dongen, B.F., Kindler, E., and Günther, C.W.: Process Mining: A Two-Step Approach to Balance Between Underfitting and Overfitting. In: SoSyM, Vol. 9(1), 87-111 (2010)

35.Wetzstein, B., Strauch, S., and Leymann, F.: Measuring Performance Metrics of WS-BPEL Service Compositions. In: Proc.ICNS'09, 49-56 (2009)

36.IEEE Std 1471.: Recommended Practice for Architectural Description of Software-Intensive Systems (2000)

37.Cormier, D., Aerts, W., Ledoux, M. J., and Magnan, M.: Web-Based Disclosure about Value Creation Processes: A Monitoring Perspective. Abacus, 46, 320-347 (2010)
38.Dimitrako, T., Daskalopulu, A., and Maibaum, T.: Evidence-based Electronic Contract Performance Monitoring. INFORMS Jour. Of Group Decision and Negotiation, Special Issue: forma Modeling of Electronic Commerce, Vol. 11, N. 6, 469-485 (2002)

39.Ferraiolo, D. F., and Kuhn, D. R.: Role Based Access Control: In: Proc. 15th National Computer Security Conference, 554-563 (1992)

40.Neumann, G., and Strembeck, M.: A Scenario-driven Role Engineering Process for Functional RBAC Roles. In: Proc. SACMAT'02, 33-42 (2002)

41.Weigand, H., Johannesson, P., Andersson, B., Bergholtz, M., Edirisuriya, A., and Ilayperuma, T.: Strategic Analysis using Value Modeling: The c³value Approach. In: Proc. HICSS'07, 175c. (2007)

42.European Parliament and Council. Common Rules for the Internal Market in Electricity. EU Directive 2004/54/EC in: Official Journal of the European Union, 15.7.2003 (2003)

43.ESMA.: Annual Report on the Progress in Smart Metering 2009. Version 2.0, January 2010. European Smart Metering Alliance (2010)

44.NMa/DTe.: Electricity Metering Code: Conditions within the meaning of Section 31, subsection 1b of the Electricity Act 1998, Informal Translation (4 September 2007). Office of Energy Regulation (part of the Netherlands Competition Authority)