Software and Systems Modeling (2020) 19:371–398

https://doi.org/10.1007/s10270-019-00756-7

SPECIAL SECTION PAPER

Extending organizational capabilities with Open Data to support

sustainable and dynamic business ecosystems
Jānis Kampars1 · Jelena Zdravkovic2 · Janis Stirna2 · Jānis Grabis1

Received: 5 October 2018 / Revised: 1 August 2019 / Accepted: 8 September 2019 / Published online: 18 September 2019
© Springer-Verlag GmbH Germany, part of Springer Nature 2019

Abstract
Open Data (OD) is data available in a machine-readable format and without restrictions on the permissions for using or
distributing it. OD may include textual artifacts, images, maps, video content, and other. The data can be published and
maintained by different entities, both public and private. Despite its power to distribute knowledge freely and availability
of a large number of datasets, OD initiatives face important challenges related to its widespread take up. More specifically,
OD provisioning is based on a unidirectional linking from OD providers to OD users without considering requirements and
preferences of the users. The OD users also lack metadata, and they need to develop specific technical solutions for provid-
ing a continuous OD flow and processing, which is particularly difficult when real-time OD are to be used. In this paper, we
propose solving these challenges by envisioning a business ecosystem for OD. It is network-based, federated, and supports
interplay between OD provisioning and knowledge management. As a methodological solution, we have applied the capa-
bility-driven development approach, which allows modeling of OD processing ecosystems, facilitates knowledge exchange
about OD usage among members of the ecosystem, and supports configuring information systems for OD processing. The
proposal is explicated with a theoretical study of its usability for the service of road maintenance in varying conditions.

Keywords Open Data · Capability · Context · Requirements · CDD

1 Introduction contextual situation in which enterprises function is defined

by internal private data (e.g., the data originating from
Enterprises operating in highly competitive and dynamically Online Transaction Processing Systems) and external data
changing environments need to have a continuous access (the data originating from third parties). Usually, enterprises
to relevant, accurate, and usable data. This also requires are well-aware of their own data and are already benefiting
improving their business functions in order to be able to from mature technologies such as business intelligence and
benefit from new, often changed and updated data [1]. The big data suites. Usage of the external data is more cumber-
some because of data discoverability issues, unclear quality
of data, and the need to establish continuous data delivery
Communicated by Iris Reinhartz-Berger and Sérgio Guerreiro.
and processing pipelines, which are mandatory when low
* Jānis Kampars latency data are considered.
janis.kampars@rtu.lv The principle of Open Data (OD) offers the potential for
Jelena Zdravkovic the external data sources to be used for making organizations
jelenaz@dsv.su.se information systems (IS) more efficient as well as designing
Janis Stirna new ones potentially creating business solutions that would
js@dsv.su.se not be feasible if based only on organization’s own data. To
Jānis Grabis facilitate sharing and reuse of large and potentially valuable
grabis@rtu.lv datasets the concept of OD was established. Open Data is
defined as data available in a machine-readable format and
1
Information Technology Institute, Riga Technical University, without restrictions on permissions for using or distributing
Kalku iela 1, Riga, Latvia
the information that it contains [2]. The driving forces of the
2
Department of Computer and Systems Sciences, Stockholm OD movement are government transparency, development
University, Postbox 7003, 164 07, Kista, Sweden

13
Vol.:(0123456789)
372
of services by third parties for the benefit of citizens and
companies, as well as the development of new services that
stimulate the economy [3].
There are a number of studies confirming the great poten-
tial of OD. For instance, the value of improved use of data
across Europe’s public sector is estimated to be around 250
billion EUR annually [4]. A study by [5] predicts that by
2020 the EU28+ direct market of OD will reach 75.7 bil-
lion EUR, while total OD market will be around 280 billion
EUR. The global potential value of OD in education, trans-
portation, consumer products, electric power, oil and gas,
health care, and consumer finance has been estimated as 3
trillion USD [4].
The majority of available OD is relatively static, accu-
mulated over time, and it is typically distributed using spe-
cialized portals. EU Open Data portal contains more than
12,000 datasets on subjects such as science, environment,
economics, trade, and finance [6]. There are also national
OD initiatives such as Latvia’s OD portal with 241 datasets
and 64 publishers [7] and municipal OD portals like Open
Stockholm [8]. So far, the OD movement has been mostly
concentrating on provisioning accumulated data, which has
led to a research gap in the areas of OD applicability [3,
9, 10] and real-time OD specifically, which traditional OD
tools and methodologies fail to support [11].
1.1 Challenges of Open Data application
The number of successful OD application use cases is a
more important factor than the number of published OD
datasets and the volume of data that have been made avail-
able to the general public. Despite many OD datasets being
available, several sources conclude that only a small portion
of them is actually used, hence the current level of OD adop-
tion can be considered as insufficient [12–14]. The following
challenges are related to OD usage:
• OD providers, in general, have limited understanding
about requirements and preferences of OD users, since
traditional OD portals do not provide a bidirectional
link between OD providers and OD users. In addition,
OD providers are seldom troubled with establishing the
required technical infrastructure needed by OD users,
e.g., in a form of rich APIs for data query and retrieval.
• OD users (enterprises) are unsure about the quality of
data and the associated metadata might be incomplete.
They need to establish specific technical solutions for
ensuring continuous flow and processing of OD. Many
OD users are still reluctant to use OD because they do
not know how to find the data, and because some data
sets are not available in a fully machine-readable form.
The data may also be outdated, and not offering a rich or
efficient API [15].
13
J. Kampars et al.
• Potential OD users are uncertain about which data they
need for fulfilling their business goals, as well as how
to develop business applications that use OD to meet
their goals. This is especially cumbersome when multiple
OD providers exist and offer custom APIs, which signifi-
cantly complicate the data integration task. Moreover,
APIs tend to change over time.
• From a technical point of view, traditional APIs of OD
portals provide limited ways of querying data (data pull
via REST or other means). However, it is complicated to
react on a certain contextual situation in a timely manner
because OD users have to constantly pull the data set of
interest. This is not suitable for scenarios where real-time
OD are used. Some exceptions like [16] exist, however
real-time OD are still a rarity since traditional OD tools
and methodologies are not applicable [11].
In the preparatory stages of this research, we inter-
viewed several municipal organizations in Latvia and they
confirmed that OD extraction from systems of their origin
and publishing are not streamlined processes. They require
manual work, and therefore organizations are reluctant to
commit to frequent data updates and often choose publish-
ing only data that change rarely. While the expectations are
that for the maximum benefit the data pipeline connecting
an OD provider and an OD user should be seamlessly inte-
grated combining data push and data pull, the reality falls
short of this vision.
A literature review by Susha et al. [17] suggests that
measures promoting OD usage and creation of sustainable
OD solutions are (1) supporting research; (2) supporting
building of community of data users; (3) supporting deploy-
ment of newly developed services and their repurposing in
other regions; and (4) integrating data-driven content and
services into government operations and organizational pro-
cesses. A research by Lnenicka et al. [18] states that the
use of OD and big data should be addressed on the level of
enterprise architecture and lists cloud computing as a key
supporting technology for wider OD adoption.
1.2 Motivation and research questions
Considering the challenges for successful OD utilization,
many of them could be solved by forming a business eco-
system, i.e., a network of organizations—including OD
providers, government agencies and other stakeholders,
intermediaries and OD users. In essence, the OD ecosystem
would consist of some entities providing or managing Open
Data while others would be OD users consuming the data.
Such an ecosystem would create a multi-point exchange of
OD, which would be organically evolving and growing in
terms of data use. It would also be able to identify and share
knowledge and reusable solutions for OD usage.
Extending organizational capabilities with Open Data to support sustainable and dynamic…
Capability-driven development (CDD) is chosen as an
approach to substantiate such an OD ecosystem. CDD is a
methodological approach for configuring dynamic, context-
aware, re-deployable business capabilities on top of exist-
ing enterprise information systems [19–21]. It also supports
identification and use of information resources outside the
organization and its IS, as well as modeling collaborations
among organizations. CDD is a reference methodology
developed to support continuous delivery of business capa-
bilities in a variety of cases by being able to capture and take
advantage of changes in business context. It encompasses
existing enterprise models, software applications, context
models, and patterns. The technical environment of CDD
contains facilities for data publishing and anonymization,
knowledge management, and sharing. CDD is deemed suit-
able for the OD ecosystem because it provides models at
different levels of abstraction starting with the enterprise
level down to the executable data management level; the tool
support is provided for model-based development and execu-
tion of data processing; facilities for matching data users
and data providers are provided; the overall solution can be
tailored to individual needs of the ecosystem’s members and
knowledge sharing is enabled. At the same time, the base
CDD does not offer concepts for dealing specifically with
OD and extension of the methodology could be developed
to support these aspects.
This paper examines the possibilities of using OD to
configure and adjust business solutions and services with
the support of the CDD methodology. With respect to the
problems discussed in the previous section, the envisioned
solution should ensure the following criteria: (1) seamless
OD publishing at the OD provider’s side; (2) seamless OD
usage for adapting enterprise’s business capabilities accord-
ing to dynamic change of context situation at OD user’s side;
(3) OD usage feedback and two-way collaboration between
OD provider and OD user; (4) systematic support for sharing
reusable artifacts such as OD usage solutions, designs and
configurations of capabilities based on OD.
To this end ,the following research question has been put
forward—how to support Open Data ecosystems by Capa-
bility-Driven Development? The overall research question
is refined into two subquestions: (RQ1) what extensions to
CDD are necessary to support OD ecosystems? and (RQ2)
What information system architecture is necessary to sup-
port capability-based OD ecosystems?
The rest of the paper is organized as follows. Section 2
outlines a background to the Open Data initiative and to
the capability-driven development approach. Section 3 pre-
sents the requirements, an extended CDD metamodel with
components for representing Open Data sources for use of
Open Data by IT-supported business capabilities and their
application specifically in a CDD-enabled user environ-
ment. Section 4 elaborates the theoretical proposal on a real
373
business case concerning regional road maintenance. A dis-
cussion and concluding remarks are presented in Sects. 5
and 6 respectively.
2 Background
2.1 State of the art in Open Data usage
Carrara et al. [5] present the vision of the concept of Open
Data. OD are data that “…can be freely used, modified,
and shared by anyone for any purpose. OD must be avail-
able under an open license and provided in a convenient
and modifiable form that is machine readable” [ibid]. This
requires that OD should be reusable by third parties to reap
benefits from OD outside the organizational structure that
created them.
For example, The Open Data Institute [22] reports a
survey of 270 UK-based companies that use, produce,
and invest in OD. They have over 500,000 employees in
total, and 70% of them are microenterprises with up to 10
employees. About half of them work in the IT sector and
the rest work in 12 other industries, such as research, busi-
ness administration, arts, and entertainment. The business
approach of these companies is to use OD to exploit gaps in
the existing market offerings by creating new products and
services. In doing so they also develop new business models
by disruption of the existing ones. This survey reports that
most of the solutions use governmental OD (70%) while
49% use OD from non-governmental sources. The most
commonly used types of OD are geospatial data, transport
data, environmental data, and demographic data. The inhibi-
tors of OD usage are lack of APIs, inefficient data market-
places, underdeveloped data reuse culture, and the existing
OD are not always accurate, up to date, and accessible in
machine-readable format [22, 23].
The majority of OD application cases available in the
scientific literature illustrate OD being used for the purpose
of building research prototypes and, as it is common for such
applications, they are using conventional IS development
approaches that do not specifically address issues such as
OD identification and reuse.
For example, in respect to the data quality, an applica-
tion of OD to get a better understanding of China’s urbani-
zation is considered [24]. The authors acknowledge OD
fragmentation and discrepancy issues—relevant OD are
scattered across multiple online and even offline sources.
Sometimes the same data are gathered by multiple organi-
zation. The needed data are heterogeneous and often gov-
ernment monitoring and census programs fall behind, and
therefore, it is not timely enough. The topic of urbanization
is also addressed in [25] by a general OD framework pro-
moting more effective collaboration between government
13
374
and companies. The city of Barcelona is used as a baseline
case; however, no explicit examples of how firms could gain
competitive advantage using OD are presented in the article.
To improve data quality and to support reuse, [26] proposes
an OD infrastructure containing a metadata model, interac-
tion mechanisms, and data quality indicators thus facilitating
easier discoverability and applicability of OD. The metadata
model proposes that users should be given an option to rate
datasets and follow other OD users and individual datasets.
Traditional attributes like usage statistics and revision date
should be enriched by linked visualizations, application area
and scientific context, geographic and temporal context. To
evaluate the effectiveness of the approach, experiments are
conducted on searching for and finding OD, OD analysis and
visualization, and OD quality analysis [26]. It was confirmed
that availability of metadata, interaction mechanisms, and
quality indicators positively influences the ease and speed
of OD usage. Thus, these three elements are crucial for OD
infrastructures.
The commercial use of OD requires addressing concerns
data reuse culture and having a methodological approach
to building OD applications [10]. The study states that the
use of OD requires specific in-house capabilities and com-
putational resources and that locating relevant OD datasets
is a difficult task. If a company lacks some of the necessary
resources or skills, it should form alliances with other OD
stakeholders. However, a more specific guidance for estab-
lishing such alliances is currently lacking.
Development of OD alliances can potentially be sup-
ported by OD marketplaces. They provide two-side col-
laboration between OD users and providers. An example of
such an OD marketplace, namely, Traffiklab is reported in
Smith et al. [16]. Traffiklab is a Swedish OD marketplace
distributing open public transport data and linking together
public transport authorities and Open Data users. It pro-
motes the development of digital travel services for public
transport companies and their customers. The main compo-
nent of Traffiklab is a technical platform (backend and API)
(Fig. 1). The marketplace also provides documentation and
some ways of sharing knowledge like general code exam-
ples, forum, and newsletters. However, there is no methodo-
logical support and Traffiklab does not contain concrete OD
usage patterns.
Traffiklab supports direct publishing of third-party APIs
as well as providing access to third-party APIs through
its own API management system. The use of the API
management system allows consolidating information
about performance and errors of individual OD provid-
ers. According to the user survey, the most prominent per-
ceived values of this OD marketplace are lover complexity,
improved access to knowledge, lower risk, and higher vis-
ibility. Although Traffiklab provides a variety of different
APIs including data pull that is suitable for real-time data,
13
J. Kampars et al.
OD User
OD marketplace traffiklab.se
API management
system
OD provider 1 OD provider 2
API API
Fig. 1  OD marketplace structure. Adapted from [16]
there is little evidence of wide adoption for business use.
The Traffiklab team has identified the use of Open Data
and development of cross-organizational IT infrastructures
among the main challenges of the project [27]. Users of
the Traffiklab need to provision and adequate infrastruc-
ture and implement the data integration and interpretation
logic themselves.
The growing popularity of the Internet of Things [15]
and the fact that real-time data originates from various sen-
sor networks has drawn attention of many researches. Most
of the current research concentrates on the infrastructure
challenges associated with consuming and publishing data
streams in general and as a result solutions that consider the
perspective of OD and cross-organizational IT infrastruc-
ture are lacking. One of few contributions to real-time OD
proposes to use a model-driven development-based solution
[11]. The developed tool currently only supports consum-
ing data in the CSV format and is applied in an air-quality-
monitoring use case. Another real-time OD distribution case
is reported in [28]. It proposes a message queue for sharing
smart cities related data. The proposal supports the data
push model that allows subscribers to be notified in a case
of certain events such as a broken light bulb on a road. It
uses the well-known MQTT messaging protocol. However,
there are some challenges of using it in the OD domain. The
protocol does not support labeling of messages with types
or metadata. This is addressed by proposing a topic naming
convention (MQTT-Topic Naming of Open Data for smart
Cities, namely MTNC). In correspondence to MTNC, the
name of the topic is set according to a pattern MainObjec-
tive/SubObjective/X (e.g., environment/water/temperature).
Practical experiments with 50 OD users showed that they
were able to find topics that were named corresponding to
MTNC in 70% cases, while the success rate was 30% when
MTNC was not applied.
Extending organizational capabilities with Open Data to support sustainable and dynamic…
One of the OD usage success criteria is an ability of an
OD-based solution to address identified business needs
[22]. Zeleti et al. [29] propose a theoretical OD competitive
capability framework for OD-driven organizations (Table 1).
It covers business, relational rent, infrastructure and offer-
ing aspects. It aims to familiarize organizations and their
management team with the areas where they must plan and
develop a comprehensive vision and action plan to use OD
more efficiently. The framework can be used to reduce both
business and technology-related risks. Government organi-
zations can use this framework to familiarize themselves
with OD-driven organizations as well to analyze the OD
problem domain from a perspective of an OD user. The aim
of this framework is to facilitate publishing more OD and
establishing the technical infrastructure that fits the actual
requirements of OD users.
Various researches suggest that adoption of Open Data
and big data should be addressed on higher levels of abstrac-
tion rather than simply creating a series of isolated small-
scale data integration and interpretation processes, that
are separated from organizational goals and other existing
processes. Gong et al. [30] have investigated the use of big
data at the Dutch Tax organization, which started various
big data initiatives in a bottom-up manner. The research-
ers expected that this approach would facilitate creation of
cross-departmental new big data-related processes and pro-
cedures; however, the resulting solutions turned out to be too
diverse and incompatible. The bottom-up approach resulted
in fragmentation of initiatives, control and maintenance
problems, and overall higher cost. The authors concluded
Table 1  Open Data competitive capability framework. Adapted from
[29]
Business Growth and commercialization
Pricing method
Market
Differentiation
Management
Relational Rent Intra-firm collaboration
Partner network
Business interaction
Customer relationship
Offering Quality
Delivery
Fee/price
Response time
Flexibility and volume
Infrastructure Service
Source
Application
Integration
Infrastructure
375
that an Enterprise Architecture based top-down approach
should be used instead as a way to deal with complexity,
integrating new systems in the landscape, facilitating reuse
and communication. Lnenicka et al. [18] propose a Govern-
ment Enterprise Architecture Framework (GEAF) for stor-
ing, processing and publishing of big and open linked data.
The objective of GEAF is to create a unified ICT environ-
ment across an entire public organization and one of its key
components is cloud computing.
In summary, OD usage has become relatively common,
but there are also challenges:
• it only focuses on certain application areas,
• real-time OD are unpopular as traditional OD solutions
fail to support it,
• building OD-based applications is not explicitly sup-
ported from a methodological perspective, and as a
result, companies follow the bottom-up approach which
results in creation of isolated incompatible data process-
ing solutions that are hard to maintain, and
• the key areas that need more support are: establishment
of data reuse culture, data marketplaces, sharing mecha-
nisms, as well as alliances and ecosystems.
2.2 Capability‑driven development
Capability as a concept is used in a variety of contexts with
differences in its meaning and interpretation (c.f. [20, 31]).
However, most views on capability agree that possessing a
capability means to have competence and ability, and to have
the right resources in adequate amount, to do something. An
example for advantages of capabilities in comparison with
more widely used concepts of business design, such as busi-
ness service or business process is that of context-dependent
variability. The fact that an organization is able to implement
a business solution or carry out a business service in one
setting does not necessarily guarantee that it is also able to
do the same in another setting. More about the suitability
of capability-based approaches and CDD, in particular, is
available in [20]. As discussed previously, the problems in
the OD domain can be associated to the need to provide
support for OD identification, reuse, incorporation in busi-
ness solutions, as well as dealing with varying data qual-
ity and establishing organizational alliances (ecosystems)
of efficient OD creation and reuse. Building such types of
ecosystems requires considering holistic organization-wide
solutions, not just IT- or IS development solutions. Hence,
they can be addressed in terms of capabilities and for this
reason the CDD methodology is being extended for the pur-
pose of building OD ecosystems.
From the business perspective, a capability describes
what the business does that creates value for customers
[31]. It represents an organizational and/or IS design from
13
376
a result-based perspective including various dimensions
like organization’s values, goals, processes, people, and
resources. The emergence of the use of the notion of capa-
bility has the following motivations:
• In the context of business planning, capability is
becoming recognized as a fundamental component to
describe what a core business does and, in particular,
as an ability for delivering value, beneath the business
strategy [32];
• Capability supports configurability of operations on a
higher level than services and processes, and according
to changes in operational business context [19, 31].
• The Capability-driven development (CDD) approach
[19, 20] has developed an integrated methodology for
context-aware business and IT solutions. It consists of
a metamodel (see Fig. 2) and guidelines for the way of
working. The main concepts of the metamodel are pre-
sented in Table 2.
• The areas of modeling as part of CDD are enterprise
modeling (EM), context modeling, variability modeling,
adjustment algorithms, and patterns for capturing best
practices.
The background colors of model elements indicate three
focus areas of the CDD metamodel and they also reflect the
three iterations of development of this metamodel. Elements
with white background are the core components used for
capability design; they were included in the initial version
of the metamodel. Yellow elements address the context-
dependent variation aspects, and orange elements as used
for modeling specific types of run-time adjustments and their
characteristics.
The metamodel is implemented in a technical environ-
ment to enable the support for the methodology by consist-
ing of the following key components (see UML component
diagram in Fig. 3).
• Capability Design Tool (CDT) is a graphical modeling
tool for supporting the design of capability elements.
• Capability Navigation Application (CNA) is an applica-
tion that makes use of the models (capability designs)
created in the CDT to monitor the capability context by
receiving the values of measurable properties (MP in
Fig. 3) and handle run-time capability adjustments.
• Capability Context Platform (CCP) is a component for
distributing context data to the CNA.
• Capability Delivery Application (CDA) represents the
existing business applications that are used to support the
capability delivery. This can be a custom-made system,
or a configured standard system such as an ERP system.
The CNA communicates or configures the CDA to adjust
for changing data contexts during capability design and
13
J. Kampars et al.
delivery. Monitoring of defined KPIs facilitates capabil-
ity refinement and pattern updating.
More information about the architecture of the CDD envi-
ronment is available in Sandkuhl and Stirna [21].
3 Using CDD for engineering OD‑based
applications
Many organizations are reluctant to use OD due to a lack
of information on how to find the data, as well as because
some data are not available in a fully machine-readable form.
It is also a common case that data may not be up to date
and not offered with rich or efficient API [34]. Organiza-
tions should know which data they need for fulfilling their
business goals, as well as they should have an IS capable
to fetch real-time OD as soon as it changes and act upon it.
Developing custom-made solutions for this on a case-by-
case basis is inefficient. If multiple OD providers with their
own proprietary APIs would exist, this would significantly
complicate the data integration task since point-to-point
integration would be necessary. Moreover, in case of API
changes, the OD integration solution would also need to
be changed. The current state is that OD providers often do
not commit to establishing the needed technical infrastruc-
ture and rich APIs for data query and retrieval. A practical
requirement would be that data pull and data push be sup-
ported for the purpose of greater flexibility. On the side of
OD users, they are reluctant to invest in OD solutions that
seem to be unstable, the inner working of which are hard to
investigate, and their implementation requires considerable
own development.
With such challenges, a key to widen OD publishing and
usage is the role of a mediator—a broker or a marketplace,
that would simplify the daily tasks of the OD provider and
the OD user by providing extra services for both of them.
Table 3 summarizes the requirements for managing OD from
the perspectives of provider, user, and broker that were elic-
ited based on the literature review in Sect. 2.
3.1 CDD metamodel extension for Open Data
The CDD approach simplifies the process of transforma-
tion of enterprise IS into context-aware systems that can be
adjusted according to the current parameters of a situation.
Integration and interpretation of contextual (often exter-
nal) data is supported by components of the CDD environ-
ment, namely the CCP and the CNA. According to the CDD
methodology, the existing business IS, denoted Capability
Delivery Application, would only need to provide an API
for adjusting its business logic via the CNA when required
by changes in the contextual situation.
Extending organizational capabilities with Open Data to support sustainable and dynamic… 377

Fig. 2  CDD metamodel [33]

13
378 J. Kampars et al.

Table 2  The key concepts of the CDD metamodel

Concept Description

Capability Capability is the ability and capacity that enable an enterprise to achieve a business Goal in a certain context (repre-
sented by Context Set)
KPI Key Performance Indicators (KPIs) are measurable properties that can be seen as targets for achievement of Goals
Context Set Context Set describes the set of Context Elements that are relevant for design and delivery of a specific Capability
Context element range Context Element Range specifies boundaries of permitted values for a specific Context Element and for a specific Con-
text Set
Context element A Context Element is representing any information that can be used to characterize the situation of an entity
Measurable property Measurable Property is any information about the organization’s environment that can be measured
Context element value Context Element Value is a value of a specific Context Element at a given run-time situation. It can be calculated from
several Measurable Properties
Goal Goal is a desired state of affairs that needs to be attained. Goals can be refined into subgoals forming a goal model.
Goals should be expressed in measurable terms such as KPI
Process Process is a series of actions that are performed in order to achieve a particular result. A Process supports Goals and has
input and produces output in terms of information and/or material. When initiated a process is perceived to consume
resources
Pattern Patterns are reusable solutions for reaching business Goals under specific situational contexts. The context defined for
the Capability (Context Set) should match the context in which the Pattern is applicable
Process variant Process variant is a part of the Process, which uses the same input and delivers the same outcome as the Process in a
different way
Adjustment Capability Delivery Application (e.g., business application) is adjusted according to current contextual situation as part
of the capability. ScheduledAdjustment checks the capability context based on a predefined schedule (e.g., see whether
a condition is met once a day) while EventBasedAdjustment can be triggered as soon as the corresponding data is
received (e.g., update dynamic traffic sign when external temperature falls below °C)

Fig. 3  Components of the CDD environment

Open Data is one of the candidate data sources when
contextual situation needs to be identified because it can
be based on many parameters that are available as OD, e.g.,
weather, traffic, pricing, public records. In terms of the CDD
terminology, OD units that can be seen as raw data become
Measurable Property and Context Element values, which can
be used for aggregations and calculations. Such calculations
are then used in capabilities for deciding on adjustments and
in patterns for triggering the adjustments. Business logic
included in Capabilities and Patterns provide code-level
examples on how OD can be used. Such capability design
could be seen as mashups of Open Data services that are
developed in a top-down fashion considering business goals
and existing processes. If they are made public, they could
contribute to a wider adoption of OD. Furthermore, if a
business solution of a company relies on OD and OD-based
pattern originating from a third party, the dependencies and
potential risks need to be modeled. These needs for basing
capability-driven solutions on OD are not directly supported
in the regular CDD methodology and hence its metamodel
and method support need extensions. The rest of this section
presents an extended version of the CDD metamodel con-
taining concepts needed for incorporating OD in capability
designs (see Fig. 4). The concepts are explained in Table 4.

13
Extending organizational capabilities with Open Data to support sustainable and dynamic… 379

Table 3  Summary of requirements for provisioning and using Open Data

Role Requirements

Provider Publish datasets in a machine-readable format in real time or near-real time

Create ontology for reuse and publish metadata
Make sure no privacy-sensitive data is published
Ensure consistent data model and communicate any changes with OD broker
User Define business goals to identify the external data types needed by capabilities
Classify data types as the elements of a capability context
Find a matching OD and finalize the definition of the capability context according to available OD
Connect to the API service to enable machine-to-machine interoperability with OD broker
Fetch and use data in the pace needed, and as the data changes
Evaluate the quality of the data, such as completeness, and provide feedback
Share knowledge on OD use with other OD users through an OD broker
Broker/marketplace Provide data publishing API for OD providers
Provide a rich API for OD users supporting both data pull and push, including various ways to
query the data and to subscribe to subsets of data
Provide permanent storage of all OD and its related metadata
Create an OD catalog as a list of rich datasets available in an OD initiative, including supporting
services such as information management and the metadata
Provide data preprocessing and anonymization as-a-service for OD providers
Provide data preprocessing and integration as-a-service for OD users
Provide a portal (platform) as an online front-end for users to access all resources available under a
data initiative, including the data catalog, a knowledge base, technical support and feedback

Fig. 4  Extended CDD metamodel with components for representing Open Data sources

13
380 J. Kampars et al.

Table 4  Concepts of the OD extension of the CDD metamodel

Concept Description

Legal entity Legal Entity is any legal entity or physical person that owns data, which can be published as OD, or possesses
knowledge on OD usage. Legal Entity can use OpenData or OpenKnowledge, or it can choose to share OpenData
and OpenKnowledge with other Business Entities
OpenDataCandidate OpenDataCandidate is a generalization of ContextElement, MeasurableProperty and ContextIndicator of which can
be made public as OpenData. OpenDataCandidate is owned by a specific Legal Entity and can be used in Open-
KnowledgeCandidate entities (e.g., Capability or Capability DeliveryPattern)
Graphical representation ContextIndicator contains a graphical representation of a context element, thus supporting sharing OD together with
respective visualizations. These items are to be published in the Capability Context Platform and would be made
publicly available for OD Context Elements
OpenData Once published OpenDataCandidate (e.g., ContextElement or Measurable Property) becomes OpenData. It is
published in the CDD Cloud environment, which serves the role of a broker or OD marketplace. OpenData has
associated metadata, it does not contain any privacy-sensitive data, and it is used by a Legal Entity
Metadata OpenData and OpenKnowledge entities must have associated metadata in order to be published
CDD cloud environment Acts as mediator between OD user and OD provider by providing the needed services (see Table 3). OpenKnowl-
edge and OpenData entities are published in CDD Cloud environment [35]. CDD Cloud Environment also
provides value calculation of Context Elements, aggregating the data in near-real time and changing the levels of
abstraction as necessary
MultiDimensionalValue A value that has at least one Dimension and at least one Measure. Dimensions hold values that are not typically
used for aggregations like various IDs or timestamps, while measures are numeric values that are subject to aggre-
gation. As an example—a weather data MultiDimensionalValue would have Dimensions—time, place ID and
Measures—temperature, humidity, wind speed. MeasurableProperty Value and ContextElement Value are both
specializations of MultiDimensionalValue. An example of a MultiDimensionalValue is given in Table 13
Dimension MultiDimensionalValue contains of dimensions and measures (see MultiDimensionalValue for more information).
An example of a Dimension is given in Table 13
Measure MultiDimensionalValue contains of dimensions and measures (see MultiDimensionalValue for more information).
An example of a Measure is given in Table 13
Measurable property value Measurable Property has a Measurable Property Value, which is a specialization of a MultiDimensionalValue.
Although Measurable Property Value and Context Element Value are structurally similar, the former one is asso-
ciated with lower levels of abstraction, while the latter one could have higher granularity and data aggregation as
part of the value calculation logic. The value calculation tasks are performed in the CDD Cloud Environment
OpenKnowledgeCandidate OpenKnowledgeCandidate is a generalization of Capability DeliveryPattern and Capability of which can be made
public as OpenKnowledge. OpenKnowledgeCandidate is owned by a specific Legal Entity and can use OpenDa-
taCandidate. It can be based on another OpenKnowledgeCandidate instance (e.g., an open capability published by
one Legal Entity can be used to create a specialized capability version for another Legal Entity)
OpenKnowledge Once published, OpenKnowledgeCandidate becomes OpenKnowledge. It exemplifies the use of OpenData and is
used by a Legal Entity

Elements from the previous versions of CDD metamodel
(see Fig. 2) are shown with white background, while OD
related extensions are displayed using green background.
To emphasize the OD metamodel extension and to improve
model readability, not all elements from the original meta-
model are shown in Fig. 4.
3.2 Open Data and knowledge ecosystem
perspective
The metamodel provides concepts for modeling capabili-
ties on top of OD and OD ecosystems. The models should
be able to represent inter-entity and intra-entity data and
knowledge dependencies. Specific models introduced are
OD ecosystem diagram, OD transfer map, Open Knowledge
transfer map, as well as Open Data and Open knowledge
catalogs. Capability and capability delivery pattern elements
model knowledge artifacts because they contain best prac-
tices of carrying out certain business services and using OD.
Such an approach is based on the principle of pattern-based
knowledge management [36, 37].
The notation used in the OD ecosystem model is summa-
rized in Table 5. It contains Capability, Capability delivery
pattern, Measurable property, and Context element, which
are placed in entity (natural or legal person) boundaries and
are connected indicating inter- or intra-organizational data
and knowledge transfer.
According to the metamodel, capability can be supported
by Capability delivery pattern, and it can be based on capa-
bility published by other legal entity. It can use data from
context elements. If capability is based on another capability,
inherited patterns as well as data and knowledge flows can
be omitted from the model; however, they are shown in the
data and knowledge dependency matrixes.

13
Extending organizational capabilities with Open Data to support sustainable and dynamic…
Table 5  Open Data and knowledge ecosystem diagram notation
Notation
Legal enty name
Capability delivery pattern can use data from context
elements. It can also be based on other capability delivery
pattern. If so, inherited data and knowledge flows can be
omitted from the model; however, they are shown in the data
and knowledge dependency matrixes.
Measurable properties and context elements contain data.
Typically, a context element value is calculated by using
one or several measurable properties, although it can also
be measured by another context element that has been pub-
lished by another OD provider entity.
In a real case of a capability-based business solution,
there would be several legal entities, providing various OD
entities, including a large number of data points at run-time,
based on which capabilities would be designed. Each legal
entity models its capabilities according to the CDD nota-
tion using CDT tool, where it is indicated whether measur-
able properties, context elements, capabilities or patterns
become Open Data and open knowledge. The full eco-
system model is generated automatically according to the
notations in Table 5 using individual capability models and
information available in the cloud-based CPR, where open
capabilities and patterns are published. Whether a specific
381
Description
Legal entity boundaries are indicated using dashed line. The name of the
corresponding legal entity is given in the top middle
The top section contains element type and number (e.g., Capability 1). Capa-
bility name is given in the middle sector. If it is private, there is a lock icon
in the bottom right part
The top section contains element type and number (e.g., Pattern 1). Pattern
name is given in the middle sector. If it is private, there is a lock icon in the
bottom right part
The top section contains element type and number (e.g., Measurable prop-
erty 1). Measurable property name is given in the middle sector. If it is
private, there is a lock icon in the bottom right part
The top section contains element type and number (e.g., Context element 1).
Context element name is given in the middle sector. If it is private, there is
a lock icon in the bottom right part
Dashed lines indicate knowledge dependencies
Solid lines indicate data dependencies
model element can be seen by a legal entity is dictated by the
openness of the particular element (e.g., whether it is OD or
not) and its owner (e.g., whether the legal entity viewing the
ecosystem model owns the particular element). As an exam-
ple, a legal entity can navigate ecosystem model and view
OD and open knowledge elements published by other legal
entities, links between them and its own private knowledge
and data elements (ones that have not been made publicly
available). A legal entity cannot view details for an element
that is owned by another legal entity and that has not been
made publicly available. Therefore, the full ecosystem model
is filtered according to legal entity’s access level before it
can be viewed.
Tables 6 and 7 show templates for Open Data and Open
Knowledge catalogs. The contents of these are generated
automatically using the data available in the cloud-based
CPR, and they can be used by legal entities to identify useful
OD and open knowledge entities as well as data depend-
encies between them. The contents of both catalogs are
made entirely publicly available in cloud-based CPR envi-
ronment. Open Data Catalog ­ODC and Open Knowledge
Catalog ­OKC contain a full list of published measurable
13
382 J. Kampars et al.

Table 6  Template of Open Data catalog Open Knowledge transfer map (OKM) (see Table 9) is
Legal entity Open Data Related open Description
used to show relations between open knowledge providers
knowledge and users, and it can be expressed as OKM = {{lea, ­OKi,
­leb}, …, {lec, ­OKi, ­led}}, where l­ ea provides open knowledge
lei odi OKi ­OKi for legal entity ­leb, ­lec provides open knowledge ­OKj for
… … … legal entity l­ ed, {lea, ­leb, ­lec, ­led} ∈ LE, ­OKi ∪ OKj ∈ PP ∪ CP.
lej odj OKj Legal entity cannot serve as a knowledge provider for itself,
and therefore, OKM ∩ {lea, ­OKi, ­lea} = Ø. If a legal entity
uses a capability or a pattern provided by another legal
Table 7  Template of Open Knowledge catalog
entity, it automatically becomes dependent on the Open Data
Legal entity Open knowl- Relevant Open Description that the specific knowledge item uses and it must be reflected
edge Data
in the Open Data transfer map, therefore it is advised to fill
lei oki ODi the Open Knowledge transfer map between the Open Data
… … … transfer map.
lej okj ODj The contents of OKM and ODM are generated automati-
cally using data available in the cloud-based CPR where
they are made publicly available. These can be used to locate
useful OD and knowledge items or to get an overall evalu-
properties ­MPP, = {mp1, ­mp2, …, m ­ pn}, context elements
ation of the particular ecosystem (e.g., which are the most
­CEP = {ce1, ­ce2, …, c­ en}, capabilities C ­ P = {c1, ­c2, …, c­ n},
prominent knowledge and data contributors).
patterns ­PP = {p1, ­p2, …, ­pn}, their corresponding legal enti-
ties LE = (le1, ­le2, …, ­len) and interdependencies.
3.3 Cloud‑based capability‑driven Open Data
More specifically, O ­ D C = {{od i, ­l e i, ­O K i}, …, {od j,
architecture
­lej, ­OKj}}, where {odi, ­odj} ∈ MPP ∪ CEP, {lei, ­lei} ∈ LE,
­OKi ∪ OKj ∈ CP ∪ PP, ­odi an Open Data item published by
In order to provide functionality needed for the envisioned
legal entity l­ ei and referenced in open knowledge O ­ Ki, ­odj an
OD ecosystem, the initial CDD environment architecture
Open Data item published by legal entity l­ ej and referenced
developed in the CaaS project [20] was extended and
in open knowledge ­OKj.
exemplified with a potential application as part of a road
Similarly ­O K C = {{ok i , ­l e i , ­O D i }, …, {ok j , ­l e j ,
maintenance use case. Figure 5 contains a UML compo-
­O D j }}, where {ok i , ­o k j } ∈ P P ∪ C P, {le i , ­l e i } ∈ LE,
nent diagram of the CDD architecture components, while
­ODi ∪ ODj ∈ MPP ∪ CEP, ­oki an open knowledge item pub-
Fig. 6 reuses the notation from Table 5 and shows the asso-
lished by legal entity ­lei and using Open Data ­ODi, ­okj an
ciated data and knowledge flows. The proposed architec-
open knowledge item published by legal entity ­lej and using
ture emphasizes use of real-time OD; however, it could be
Open Data ­ODj.
further extended to import accumulated OD that could be
Open Data transfer map (ODM) (see Table 8) is used
used to enrich the real-time OD with extra features (e.g.,
to show relations between Open Data providers and users
determining the closest main road for a set of GPS coor-
and it can be expressed as ODM = {{lea, ­ODi, ­leb}, …, {lec,
dinates). Road weather station data provider, Mobile road
­ODi,led}}, where ­lea provides Open Data ­ODi for legal entity
sensing provider, Microsoft Dynamics ERP system, Han-
­leb, ­lec provides Open Data ­ODj for legal entity ­led, {lea,
saworld ERP System are external systems. The remaining
­leb, ­lec, ­led} ∈ LE, ­ODi ∪ ODj ∈ MPP ∪ CEP. Legal entity can-
components are part of the CDD cloud environment. The
not serve as an Open Data provider for itself, and therefore,
main difference from architecture given in Fig. 3 is addi-
ODM ∩ {lea, ­ODi, ­lea} = Ø.
tional interfaces in the Capability Context Platform that
are used for publishing and retrieving publicly available

Table 8  Template of Open Data Open Data providers

transfer map
Open Data users lea leb … lec led
lea – – – –
leb ODi – – –
… … … … …
lec – – –
led – – – ODj

13
Extending organizational capabilities with Open Data to support sustainable and dynamic…
Table 9  Template of Open Open Knowledge providers
Knowledge transfer map
Open Knowledge users
lea
leb
… …
lec
led
Context Element values. The following acronyms are
used throughout this section: MP—Measurable property,
CE—Context element, P—Capability delivery pattern,
C—Capability, CNA—Capability Navigation Application,
CCP—Capability Context Platform, CPR—Capability Pat-
tern Repository, CDA—Capability Delivery Application,
CDT—Capability Design Tool.
The example case used to demonstrate the components
of the cloud-based CDD Open Data architecture is that of
the Latvian Autoroad Maintainer (LAM). The case is further
extended and elaborated in Sect. 5, which concentrates more
on the ecosystem perspective. The LAM is a legal entity pro-
viding road maintenance on main national roads in Latvia.
The LAM has a data source—Mobile road sensor, which
is part of its local infrastructure. Using a custom adapter,
which has been specifically designed for the data provider,
it publishes multidimensional values of MP Mobile road
sensing via the Measurable property data publish interface
provided by CCP. The near-real-time data is published in a
data push manner—the data source adapter posts it to the
Fig. 5  Cloud-based CDD architecture for OD
383
lea leb … lec led
– – – –
OKi – – –
… … …
– – – –
– – – OKj
CCP as soon as new data becomes available. MP Mobile
road sensing is part of LAM’s private workspace. It is not
being made available to other legal entities due to privacy
concerns. MP Mobile road sensing data is used to calcu-
late the value of a Context Element CE Driving conditions
on main roads in the private LAM’s workspace within the
cloud-hosted CNA. For this purpose, the CNA uses Measur-
able property data retrieval interface provided by the CCP.
During the CE value calculation, the granularity of the data
is changed, and it no longer contains privacy-sensitive data,
which is why the LAM has chosen to publish it as OD in
the public section of the CCP via Context element publish
interface. Value recalculation is performed in near-real time
in a data pull manner. The LAM uses data from CE Driving
conditions on main roads as part of its CP Reactive road
maintenance, which supports C Main road maintenance. P
Reactive road maintenance contains a generalized code-level
example and documentation on how information about driv-
ing conditions can be used for providing reactive road main-
tenance. This pattern is made available as open knowledge
13
384
Latvian Autoroad Maintainer
Capability 1 supported Paern 1
by
Reacve road
Main road
maintenance maintenance
uses
Measurable property 1 Context element 1
Driving condions
Mobile road sensing measured on main roads
by
Fig. 6  Open Data and knowledge ecosystem for CDD OD architecture example case
and is published in the cloud-hosted CPR using Capability
pattern and model publishing interface. C Main road main-
tenance is private and it is concerned with triggering road
maintenance operations in the ERP system of the LAM,
namely Hansaworld (example of a CDA). The Hansaworld
ERP needs to expose a Capability adjustment interface, so
that it can be adjusted when necessary from the cloud-based
CNA. Hansaworld is hosted in local infrastructure of the
LAM and only a small subset of the original data needs to be
processed by it, since the majority of the computing tasks is
performed by the cloud-based environment. This approach
allows to separate concerns of data interpretation and data-
driven adjustments and also allows to avoid extensive real-
time data processing by systems which were not originally
designed for this purpose.
The CPR exposes Capability and pattern performance
data interface for publishing KPI (key performance indica-
tors) to support performance evaluation of open capabilities
and patterns. In this case, the quality of the P Reactive road
maintenance is measured by the level of legislation conform-
ance (legislation regulates how much time the road main-
tenance companies have before they have to perform road
maintenance operations due to current weather conditions,
e.g., A+ class main roads need to be cleaned in 2 h at most).
Jelgava Municipality (JM), who is another actor in the
given OD ecosystem, owns local road weather stations that
publish the multidimensional values of MP Jelgava weather
stations through Measurable property data publish interface
exposed by the CCP. This MP is made available as OD for
third parties.
Jelgava Road Maintainer (JRM, a commercial entity
performing road maintenance within the Jelgava Munici-
pality) uses MP Jelgava weather stations to calculate the
13
J. Kampars et al.
Jelgava Road Maintainer
Paern 2 Capability 2
based supported
on Reacve road by Regional road
maintenance maintenance
Context element 2
uses
Driving condions
on Jelgava roads
measured by
Jelgava Municipality
Measurable property 2
Jelgava weather
staons
value of CE Driving conditions on Jelgava roads, which is
private. The calculation tasks are performed by the cloud-
based CNA, while cloud-based CCP acts as broker. To
implement C Regional road maintenance, the JRM reuses
publicly available P Reactive road maintenance (previ-
ously published in the CPR via Capability and pattern
model retrieval and publishing interface by the LAM) and
extends it with the use of CE Driving conditions on Jel-
gava’s roads. Since the pattern depends on CE Driving
conditions on main roads, the corresponding values are
retrieved from the public section of the cloud-hosted CCP
(Context element data retrieval interface) together with
the values of MP Jelgava weather stations (Measurable
property data retrieval interface).
During run-time, road maintenance operations are
initialized in the ERP system of the Jelgava Road Main-
tainer, namely Microsoft Dynamics NAV (an example of
a CDA), based on values of CE Driving conditions on
Jelgava roads and CE Driving conditions on main roads.
This ERP system is hosted in local infrastructure of the
legal entity (OD user) and through Capability adjustment
interface it receives from the cloud-based CNA only the
subset of the data that it needs react upon. Similarly, as
with C Main road maintenance, KPI data regarding the
level of legislation conformance is sent back to the CPR
via the Capability and pattern performance data interface.
Aggregated values of the capability KPIs are used to cal-
culate the performance of the patterns to which they are
related [38]. The performance data is part of the metadata
that is available in CPR.
The cloud-based CPR is used to consolidate usage related
data and metadata. It has a user interface in which users can
manually rank data and knowledge items as well as provide
Extending organizational capabilities with Open Data to support sustainable and dynamic…
other types of feedback. In this example, users from LAM
and Jelgava Road Maintainer provide feedback for P Reac-
tive Road Maintenance. Model elements from the CPR can
be imported into the CDT using its Capability and pattern
model retrieval and publishing interface, where they can be
used to build capabilities and patterns which are then pub-
lished and executed in the CNA via the Capability publish
interface.
3.4 Application during CDD design and run‑time
Capabilities are designed following the CDD method com-
ponent for capability design (see [10]). This method com-
ponent consists of steps such as goal and KPI modeling,
context modeling, capability adjustment modeling, as well
as, if needed, pattern modeling. Capability design is primar-
ily supported by an Eclipse-based Capability Design Tool
(CDT, see Fig. 3). The cloud-based capability context plat-
form (CCP) acts as an OD broker and provides available
measurable properties that are related to the capability in the
capability design. Cloud-based Capability Pattern Reposi-
tory (CPR) is used to see whether there are knowledge items
that can be reused and what data they depend on.
With respect to the use of OD, a particular task that needs
to be supported is finding relevant OD that can be linked as
measurable properties on the basis of which context element
calculations can be defined to specify context elements. For
this purpose, measurable properties need to be searched
in the CDT that is integrated with the CCP. Alternatively,
search can be performed in the CPR (see Fig. 7) because it
also contains a list of measurable properties and their rela-
tions to knowledge items.
When a legal entity uses its own data, it should consider
whether it can be published as OD. In case it contains pri-
vacy-sensitive data, it should be anonymized first, which can
be done by changing its granularity through transforming
specific instances of measurable properties into a context
element (more sophisticated anonymization strategies can
also be applied if necessary). Whether OpenDataCandidate
entity becomes OpenData would be specified during design
Fig. 7  Measurable property list from the CPR
385
time in CDT by the legal entity who owns the data, which in
turn simplifies the process of publishing OD.
To reuse Open Knowledge in the form of capabilities or
patterns, the designer would need to navigate the user inter-
face of the CPR; it contains knowledge items and references
to their associated data. Example of searching for knowledge
items is shown in Fig. 8.
In the CPR, each page presenting a pattern contains a
model, related capabilities, used measurable properties,
context elements, user feedback, and pattern performance
indicator, that is calculated from the KPI values of capabili-
ties using the pattern. An example of a pattern page in the
CPR is shown in Fig. 9.
A design of a knowledge item can be imported into the
CDT where it can be modified as necessary. In case of an
OD ecosystem, if one of its legal entities decides to make its
patterns or capabilities available as Open Knowledge, other
entities would be able to specify similar capability designs
for themselves with little additional effort.
Table 10 summarizes the main activities of capabil-
ity design from the perspectives of Open Data and Open
Knowledge. At the run-time, the status of business context
and related KPIs are continuously monitored. Table 11 sum-
marizes Open Data and Open Knowledge-related capability
run-time activities.
4 Example case—intelligent transportation
systems
To illustrate the principles of the Open Data and Open
knowledge ecosystem a case of Intelligent Transportation
Systems in Latvia is analyzed. This case is motivated by
open-ended interviews with representatives from a number
of organizations involved in road maintenance [The Lat-
vian Autoroad Maintainer (LAM), The Latvian State Roads
(LSR), The Latvian Association of Local and Regional Gov-
ernments, Jelgava municipality and a company performing
maintenance on the municipal roads the city of Jelgava]
and Ministry of Environmental Protection and Regional
13
386
Fig. 8  Knowledge item search in the CPR
Development of Latvia (MEPRD), the Ministry that is
responsible for maintaining the Latvia’s Open Data portal.
The interviews took place during August 2018 and focused
on the existing situation, goals of the business entities, and
associated challenges. LAM is a focal company and addi-
tional parties were identified during elaboration of the case.
4.1 The current situation
The initial analysis was aimed at identification of its key
capabilities of the LAM. This was done using enterprise
modeling techniques. The Road maintenance capability was
identified as one of high-priority capabilities because of its
societal impact. This capability implies that the LAM should
be able to provide road maintenance for the Latvian state
main roads. Figure 10 shows a fraction of a goal model in
the CDD notation with goals and their respective KPIs. The
goal model notation of the CDD is adopted from the 4EM
method [20, 39]. It is important to note that realization of
some of the goals, such as Goal 1.1.1 Prevent road icing
requires precise up-to-date information and quick reaction.
The Road maintenance capability is delivered continu-
ally throughout the year and it can be divided into proactive
and reactive road maintenance. Proactive road maintenance
is especially important during winter, when it is important
to apply de-icing materials before black ice forms. Reac-
tive road maintenance ensures restoring proper driving
conditions in the case of a hazard (e.g., snowstorm, fallen
trees, traffic accident). Data about current and predicted
13
J. Kampars et al.
road conditions are scattered around multiple heterogene-
ous unintegrated systems and are interpreted manually by
LAM’s personnel to decide upon triggering road mainte-
nance operations. The majority of the data is owned by other
organizations like the LSR, Latvian Environment, Geology
and Meteorology Centre or specific municipalities like
Jelgava. Nonetheless, the data have not been opened yet,
due to technical challenges associated with it. In the winter
of 2018/2019, the LAM started using mobile sensors that
were installed on regional buses and would provide real-
time information about the actual driving conditions. Data
gathered by the mobile sensors are described in Table 12.
Since these data are gathered by public entities, they are
Open Data. However, the existing Latvian OD infrastructure
maintained by MEPRD is not suitable for handling highly
dynamic data and data sharing opportunities remain undis-
covered. On the other hand, investment in Open Data infra-
structure is difficult to justify since there are few usage cases.
Other legal entities like municipalities and municipal road
maintenance companies would also benefit from this data,
since routes of the regional buses also cross-municipal ter-
ritory and would provide precise data about road conditions
in locations where other data sources do not exist. Neverthe-
less, this data has not been opened due to the aforementioned
challenges and even the LAM does not have tools for auto-
matically interpreting the data in real-time.
The LSR oversees road maintenance on the main roads
of Latvia and provides smart traffic management using
smart traffic lights and dynamic traffic signs, which allow
Extending organizational capabilities with Open Data to support sustainable and dynamic…
Fig. 9  Pattern page fragment from the CPR
to adjust the maximum speed limit and display various
alerts according to the current driving conditions. A frag-
ment of the LSR’s goal model is shown in Fig. 11.
The LSR owns weather stations that are installed along
the state main roads. A screenshot from the LSR’s internal
Road Weather Information System, containing data from
the installed weather stations, is shown in Fig. 12.
Both the LSR and the LAM share a similar goal of
reviewing road related weather conditions. Therefore both
companies need to interpret the data to evaluate the driv-
ing conditions. However, no data sharing or knowledge
transfer regarding the interpretation and measures taken
occurs.
The previously described collaboration and data shar-
ing issues also occur on the municipal level. Municipali-
ties like Jelgava are also concerned with overseeing road
maintenance and smart traffic management. They own a set
387
of road weather stations, dynamic traffic lights, and traffic
signs. Road maintenance of municipal roads is performed
either by a municipality-owned company or a private legal
entity. Even if data is shared between the municipality
and the local road maintenance company, road conditions
are interpreted separately by the specific municipality (for
smart traffic management purposes) and the road mainte-
nance company (for road maintenance purposes). Lack of
usable data or inadequate data interpretation knowledge
is quite common, especially when smaller municipalities
are considered. They would benefit from the expertise and
data possessed by the LAM and the LSR; however, no data
exchange and knowledge transfer occur.
Our interviews with organizations have shown that
involved parties are interested in collaborating once they
are aware of the potential synergy; however, there is a lack
13
388 J. Kampars et al.

Table 10  Capability design from Open Data and Open Knowledge perspectives
Capability design steps Description

Identify reusable knowledge Browse the CPR to identify if any existing patterns or capabilities can be reused
Define goals Goals and KPIs are defined in the process of designing capabilities. This is done on the
basis of the existing business models as well as service level agreements with customers
and suppliers. If patterns or capabilities are reused, the goal model is modified accord-
ing to the needs of the specific legal entity
Design context elements Design new context elements or modify the existing ones inherited from reused capabil-
ity or pattern according to the envisioned capability. Consider business processes and
process variants as well as what situational properties influence variations
Find Open Data Analyze the available OD sources with respect to the KPIs and context elements. Existing
data use cases and user feedback should also be reviewed in the CPR using OD ecosys-
tem model, OD and Open Knowledge transfer maps
Implement data source adapters if necessary If own data sources are used, it might be necessary to develop an adapter for transferring
data from the source system to the CCP in near-real time
Review context elements and their calculations After all data sources, both private and open, have been identified, context element value
calculation algorithms must be specified, if necessary
Implement adjustments Implement adjustments that are triggered by a certain context situation (value of one or
multiple context elements) and perform an adjustment in the CDA. This activity could
include exposing interfaces in CDA if they are not already available
Consider publishing Open Data and Open Consider if the included measurable properties or context elements can be published as
Knowledge OD for others to use. The same applies to patterns and capabilities that are candidates
for becoming open knowledge. Provide corresponding metadata, when publishing Open
Data or open knowledge

Table 11  Capability run-time with Open Data and open knowledge

Capability delivery at run-time Description

Data retrieval
Passing data to the CNA
Calculating Context element values
Triggering adjustments
Interaction with the CDA
Review of KPIs and run-time improvements User reviews the KPIs available in the cloud-based CNA and modifies the value of adjustment
Data is retrieved from the data provider and sent to the cloud-based CCP
Data is integrated by the cloud-based CCP and sent to the cloud-based CNA
The CNA performs calculation of context element values
Event-based adjustments are triggered when matching contextual situation occurred
Execution of an adjustment usually results in interacting with the CDA (e.g., business application)
via its API
constants if necessary. Adjustment constants are used for altering context element calculations or
adjustments during run-time. If greater improvements are required, the design of the capability
is revised in the CDT according to Table 10. In case of data quality issues, new possible data
sources are identified, and feedback is left in the cloud-based CPR, e.g., showing that the par-
ticular data is not suitable for the specific capability. If data interpretation and adjustment logic
must be altered, the designer can look for more appropriate patterns or capabilities published in
the cloud-based CPR

of an adequate technological platform and guidelines for
sharing OD and knowledge about its usage.
Analysis of the interviews led to the identification of
the following challenges:
• Inappropriate technology—publishing frequently
changing data is a technically complicated task and not
supported by the existing OD platform, which is why
companies tend to publish only data sets that change
rarely.
• Unawareness—although the exchange of real-time data
in the area of Intelligent Transportation system would
benefit all parties involved (e.g., municipality would have
extra weather information from road weather stations
controlled by the LSR and the LAM), it does not occur.
Organizations are not aware of the potential synergy.
• Inefficient operation—sometimes multiple legal entities
require the same data interpretation logic (e.g., what are
the driving conditions according to available measure-
ments) though its sharing and reuse is infrequent and
unstructured.
• Adoption barriers—datasets available in the OD platform
are not used widely enough. This could be explained by
insufficient knowledge on how such data should be used

13
Extending organizational capabilities with Open Data to support sustainable and dynamic… 389

Fig. 10  LAM road maintenance goal model

Table 12  Data items gathered Column Description

by mobile road sensors owned
by LAM Latitude Latitude from GPS coordinates
Longitude Longitude from GPS coordinates
Road condition Possible values—dry, moist, wet, ice, snow, critical wet,
chemically wet
Road surface temperature Temperature °C measured on the road surface
Ambient temperature Temperature °C measured in air
Water film height The amount of water on the road 0–6000 µm
Dew point temperature Temperature °C at which water vapor starts to condensate
Relative humidity Humidity 0–100%
Ice percentage Ice percentage 0–100%
Friction Calculated friction 0–1

Fig. 11  Smart traffic manage-

ment goal model

13
390
Fig. 12  Road weather informa-
tion system of the LSR
or a large number of datasets that have little practical
value.
4.2 Design of OD‑based ecosystem
To address the aforementioned challenges, a full OD eco-
system model (see Fig. 13), which is developed according
to CDD OD extension, is created. The model shows all
parties involved in the Intelligent Transportation System
ecosystem along with their key capabilities. Identification
of context elements and measurable properties pertinent to
these capabilities shows that information exchange spans
organizational boundaries.
The city of Jelgava and its local road maintenance com-
pany have been generalized as Municipality and Regional
Road Maintenance Company (RRMC), since other munici-
palities and regional road maintenance companies have
similar challenges. The case also includes entities that did
not participate in the interviews; however, they have been
identified by the participating parties to be important to the
OD ecosystem, namely Latvian Environment, Geology and
Meteorology Centre (LEGMC), and a crowd-sourced navi-
gation service provider (CNSP), such as Waze. Data and
knowledge that are not relevant for the Intelligent Transpor-
tation System use case are omitted from the model. Links to
other OD and knowledge could exist as this is not indented
to be a closed ecosystem—OD and knowledge items can be
used by any legal entity.
The following acronyms are used throughout this sec-
tion: MP—measurable property, CE—context element, P—
capability delivery pattern, C—capability, CPR—capability
13
J. Kampars et al.
pattern repository. The model shows the Road maintenance
capability owned by the LAM as well as its patterns of pro-
active and reactive road maintenance. The proactive and
reactive road maintenance have been specified as separate
capability delivery patterns. P Proactive road maintenance
uses CE Two-hour road condition prediction, while P Reac-
tive road maintenance relies on CE Driving conditions. An
MP Mobile road sensing is based on the mobile road sensors
that are controlled by the LAM and it is published as OD.
This measurable property is an example of MultiDimension-
alValue (see Fig. 4, Table 4) where every data item consists
of multiple measures recorded at specific location given by
latitude and longitude (i.e., data dimensions) (Table 13). The
LAM has opened all of its data and knowledge items for
others to use.
The RRMC provides regional road maintenance.
According to the ecosystem model, it can view all knowl-
edge and data items of the LAM because these elements
will be made openly available and indexed by the cloud-
based CPR. The user interface of the CPR allows view-
ing individual capability and pattern models, as shown
in Fig. 8. Since the capability is almost identical to the
one published by the LAM, it can be reused and personal-
ized by the RRMC. The cloud-based environment allows
legal entities such as the LSR or the LAM to navigate the
ecosystem model and the available catalogs in the shared
CPR. They can also look for open capabilities with sub-
goals similar to the ones in their own goal model. This
would promote the identification of possible synergy
scenarios as well as facilitate data and knowledge shar-
ing. In this example, the LSR could discover additional
Extending organizational capabilities with Open Data to support sustainable and dynamic… 391

Fig. 13  Intelligent transportation systems Open Data and knowledge ecosystem

data sources such as the ones provided by the LAM, the Table 13  Data structure for the MP Mobile road sensing value
LEGMC or CNSPs. Similarly, the RRMC could learn from
Column
the LAM’ s know-how of interpreting road conditions,
which has been published as an open Reactive road main- Dimensions Latitude
tenance pattern. A context model for the LSR’s capability Longitude
Smart traffic management (following CDDs context model Measures Road condition
notation, see [20]) is given in Fig. 14 and it shows all the Road surface temperature
additional data sources. The capability uses CE Driving Ambient temperature
conditions and CE Driving speed limit, both of which are Water film height
published as OD. Similarly, MP Weather stations (data Dew point temperature
from the LSR’s controlled weather stations) is also made Relative humidity
publicly available. Ice percentage
Since on the municipality-level capability Smart traffic Friction
management is similar to the one published by the LSR,
that is available in the cloud-based CPR, it can be reused
and customized for the purposes of each municipality. Data LAM. According to the ecosystem model, weather forecast
from municipal weather stations is published as Open Data together with data from the weather radar and the weather
and, in this case, would become MP Weather Stations and stations would be published as OD while the capability
other ecosystem participants would benefit from it. Environment monitoring kept private to the LEGMC.
The LEGMC envisions the capability Environment moni- The main capability of a CNSP is Routing. This capabil-
toring. A CE Two-hour weather forecast is a part of it. It ity uses CE Driving speed limit and CE Traffic congestion,
would use a combination of a weather radar installed near which takes into account MP Driver GPS and MP Traffic
the Riga International Airport, weather stations owned by Alerts. MP Driver GPS contains privacy-sensitive data, and
the LEGMC, as well as weather stations of municipalities, therefore, it is private, while CE Traffic congestion and MP
the LSR, and data from mobile road sensing provided by the Traffic alerts are published as OD. Other legal entities cannot

13
392
Fig. 14  Context model of smart traffic management capability owned by LSR
view details about MP Driver GPS and Routing capability
as these elements are kept private by the CNSP. Thereby,
only the CNSP can see them in the ecosystem model while
other legal entities (OD users) can only access the CNSP’s
CE Traffic congestion and MP Traffic alert.
A fragment of an OD catalog, which can be generated
using the publicly available information in cloud-based
CPR, is shown in Table 14, while Table 15 contains a frag-
ment of Open Knowledge catalog. It can be used to identify
dependencies between Open Data and knowledge items. As
an example, the RRMC could investigate on which OD it
would become dependent by reusing the LAM’s capability
Road maintenance.
Maps showing OD transfer and Open knowledge transfer
are shown in Tables 16 and 17, respectively. Table 16 shows
that the LSR is a major data provider and its investment in
making OD available is justified because many members of
the ecosystem need the data. The majority of the LSR’s OD
is interpreted data such as driving conditions or maximum
allowed speed limit, which in turn relies on the OD provided
by other legal entities. This shows that a legal entity could
become a major data provided even if it does not directly
own any data sources. The use of the cloud-based environ-
ment would allow such companies to run the data interpre-
tation logic as a service without establishing a demanding
local computing infrastructure to cope with the needs of the
data users. Table 17 shows that the LAM and the LSR are
able to provide open knowledge that can be reused by the
13
J. Kampars et al.
RRMC and Municipality. Although knowledge users are not
expected to identify the suitable OD sources, they would
become dependent on the ones used by the knowledge pro-
vider. Accordingly, Municipality would require weather
station data from the LEGMC, traffic congestion data and
traffic alerts from the CNSP, and mobile road sensing data
from the LAM.
4.3 Benefits of the OD ecosystem
Application of the CDD method to the challenges of devel-
oping the Intelligent Transportation System identified in
Sect. 4.1 has a number of benefits. The proposed system
design and the lessons learned in the process allows identify-
ing the following benefits:
• The development of the model of the OD ecosystem
improves collaboration, traceability, and discoverbil-
ity, which are aspects needed for a broad OD adoption.
The Open Data and knowledge catalogs extracted from
the model improve awareness about the information and
knowledge available. In terms of discoverability, accord-
ing to the experiences of the CaaS project [20] the cloud-
based CPR assists in locating related capabilities, usable
patterns and data sources. CPR is able to index all pub-
lished models, which allows various ways of navigating
and filtering the available information. Open Data and
knowledge transfer maps can be used to visualize ecosys-
Extending organizational capabilities with Open Data to support sustainable and dynamic… 393

Table 14  A fragment of Open Data catalog

Legal entity Open Data Related open knowledge Description

LEGMC MP weather radar P Predictive road maintenance by LAM Data from weather radar
P Predictive road maintenance by RRMC installed near Riga
international airport
MP WeatherStations C Smart traffic management by LSR Data from weather
C Smart traffic management by municipality stations installed
alongside national
P Predictive road maintenance by RRMC
importance roads
P Predictive road maintenance by municipality
P Reactive road maintenance by RRMC
P Reactive road maintenance by municipality
… … … …

Table 15  Open Knowledge catalog

Legal entity Open Relevant Open Data Description
knowledge

LSR C Smart CE Driving conditions by LSR Smart traffic management capability is concerned with managing
traffic MP Weather stations by LSR dynamic traffic signs and traffic lights, displaying informational mes-
manage- sages on monitors alongside the road according to current contextual
MP Weather stations by LEGMC
ment situation
MP Mobile road sensing by LAM
MP Weather stations by municipality
MP Traffic alert by CNSP
CE Driving speed limit by LSR
CE Traffic congestion by CNSP
MP Traffic alert by CNSP
… … … …

Table 16  Open Data transfer map

Open Data providers
LEGMC Municipality CNSP LAM RRMC LSR

Open Data users LEGMC MP Weather sta- – MP Mobile road – MP Weather sta-
tions sensing tions
Municipality MP Weather sta- CE Traffic conges- MP Mobile road – CE Driving speed
tions tion sensing limit
MP Traffic alert CE Driving condi-
tions
CNSP – – – – CE Driving speed
limit
LAM CE Two-hour MP Weather sta- – – CE Driving condi-
weather forecast tions tions
MP Weather sta- MP Weather sta-
tions tions
MP Weather radar
RRMC CE Two-hour MP Weather sta- – CE Two-hour CE Driving condi-
weather forecast tions Road condition tions
MP Weather sta- prediction MP Weather sta-
tions MP Mobile road tions
MP Weather radar sensing
LSR MP Weather Sta- MP Weather sta- CE Traffic conges- MP Mobile road –
tions tions tion sensing
MP Traffic alert

13
394
Table 17  Open Knowledge transfer map
Open Knowledge providers
LEGMC Municipality
Open Knowledge users LEGMC – –
Municipality – –
CNSP – –
LAM – –
RRMC – –
LSR – –
tem-wide collaboration scenarios and the corresponding
data and knowledge transfer, which currently does not
exist.
• Based on the experiences gained in the CaaS project
[20], it is possible to ascertain that the envisioned eco-
system can be later used to configure the cloud-based
CDD environment to enact information and knowledge
exchange, which would otherwise be difficult for the indi-
vidual actors in the road maintenance sector to establish
on case-by-case basis.
• The capability-oriented way of working with OD leads to
discovery of creative solutions rather than just cataloging
available data. Among the benefits would be the aware-
ness of the municipalities that the LAM’s mobile sensors
are available for determining road conditions and how to
access this data.
• The capability-based approach would offer a technologi-
cal support for real-time data that is aimed for seamless
publishing of OD streams. It also provides data pro-
cessing as a service (e.g., calculation of CE values) in
the cloud-based environment. Business systems would
receive only the subset of data they need to act upon and
not the entire data stream, as discussed in Sect. 3.3.
• Increased efficiency for the ecosystem as a whole because
data interpretation performed as part of value calculation
for published context elements can be reused by other
legal entities by simply subscribing to the context ele-
ment value stream.
5 Discussion
The CDD enables representation of the problem domain at
several levels of abstraction: goals describe strategic inten-
sions, capabilities realize them by functional positioning
13
J. Kampars et al.
CNSP LAM RRMC LSR
– – –
– – C Smart traf-
fic manage-
ment
– – –
– – –
– C Road mainte- –
nance
P Predictive road
maintenance
P Reactive road
maintenance
– – –
of the members of the ecosystem, which in turn drives the
selection of suitable OD and knowledge entities. These are
then used to configure the data processing solution. If com-
pared to the existing enterprise architecture management
approaches and goal-driven development methods, the CDD
supports specifying the data processing algorithms and their
execution support. If compared to OD marketplaces, big data
processing, and streaming solutions, the CDD provides a
high-level abstraction layer for capturing, communication,
and configuring the data consuming and publishing solu-
tions. The proposed OD extensions and the cloud-based
architecture facilitate seamless and model-driven publish-
ing of OD and open knowledge as an integral part of an
enterprise architecture model that specifies which data and
knowledge elements are open and shared with the commu-
nity. Tasks such as data preprocessing and interpretation
(e.g., calculation of a context element value) are performed
by the cloud-based CDD environment as a service, thus
minimizing the efforts needed to become an OD publisher
or OD user. According to our interviews, manual work has to
be performed for publishing each individual batch of static
data using traditional OD platforms because data providers
are reluctant to commit to frequent data updates. Cloud-
based environments and, in this case, the CPR, simplify the
process of discovery of suitable OD and open knowledge
elements.
The envisioned OD ecosystem is the result of the joint
effort of all parties involved. The partners create their own
capability models and they use the pattern repository as a
source of capability design knowledge. Once designed capa-
bilities are published in the pattern repository, the common
model can be constructed.
Currently, it is assumed that the members of the open
ecosystem see all open elements and elements owned by
themselves. The data and knowledge catalog indicates the
Extending organizational capabilities with Open Data to support sustainable and dynamic…
usage of data and knowledge by a particular legal entity. No
additional details would be available unless the correspond-
ing legal entity has openly published the data consuming
elements. As a result, every member of the ecosystem would
have a slightly different view of the complete ecosystem
model.
The OD-based ecosystem facilities knowledge sharing
what might cause an indirect dependence on external data
providers, i.e., by reusing capability or pattern, an organiza-
tion also chooses to use the referenced data entities. How-
ever, the CDD technological platform supports late binding
and relatively simple replacement of one set of measurable
properties with another to calculate the same context ele-
ment. This way knowledge is reused at the context element
level, while application-specific measurable properties can
be used if they are available.
The proposed approach does not address sharing of
static data (e.g., spatial database containing road network)
via pull; however, the employed push approach could be
beneficial for sharing updates to relatively static data sets
as well. The execution platform based on the CDD envi-
ronment would be easily geared toward working with data
streams. The modeling approach to distinguish private and
public data and knowledge can also be used to represent
static data entities and batch processing. In such cases, the
model would be used for explorative purposes, but not for
the configuration of the executable system. The proposed
OD extension is based on the use of the OD ecosystem
architecture discussed in Sect. 3.3 and its implementation
in a cloud environment. Concerning the practical aspects
of implementation, the data users involved in the ecosys-
tem would need to upgrade their existing applications by
extending them with the elements of the CDD architecture
(Table 3). As drawback of the proposal, it is the need for
the involved actors to become acquainted with the capa-
bility-based thinking about what the business can do and
what factors influence its delivery. Sandkuhl and Stirna
[20] provide guidance for introducing CDD in organiza-
tions, but more detailed guidance for ecosystem thinking
would be needed.
To illustrate the applicability of the proposed approach,
we have modeled an OD and knowledge ecosystem of
capability-based Intelligent Transportation Systems. The
proposal is based on the interviews with key actors of the
ecosystem. From the perspective of the application case,
the OD extension to CDD addresses the following business
challenges:
• Society as a whole—if road maintenance is not per-
formed on time or information about road conditions is
not available, driving conditions may become potentially
dangerous which in turn may result in a loss of life, inju-
ries, and property damages. At the same time, excessive
395
or unnecessary use of de-icing materials damages the
environment and wastes public funds. The envisioned
solution would contribute to the involvement in the deliv-
ery of data necessary for road maintenance and traffic
management, in essence building a sense of joint owner-
ship of OD. It would lead to improved road conditions,
more precise information about road conditions, efficient
utilization of public funding, and reduced environmental
impact.
• State and municipality road management institutions—
the lack of information about road conditions and tasks
performed complicates evaluation of road maintenance
efficiency and allocation of resources to these activities.
These institutions have limited means of information
exchange to benefit from data and knowledge accumu-
lated by different institutions. The envisioned solution
would lead to more precise information for assessing the
efficiency of road maintenance actions, access to the road
maintenance and traffic management knowledge base to
improve understanding about relevant challenges and
solutions.
• Road maintenance companies—the lack of data and for-
malized decision-making mechanisms make the process
of justification of road maintenance decisions harder. The
decisions are based on extrapolating observations made
at individual points rather than by considering the whole
road network. This would be addressed by the possibility
to make data-driven decisions and further to take appro-
priate actions to deliver better services and lower costs.
• Transportation and logistics companies—the lack of
information on road conditions and traffic safety limit
their ability to route vehicles efficiently and to avoid acci-
dents. The proposed solution would allow the selection of
safe and efficient routes as well as it would provide timely
updates of road conditions and recommended speed.
• Emergency services—poor driving conditions limit their
ability to reach emergency situations on-time. The envi-
sioned solution would offer a selection of fastest routes
depending on road conditions.
• Research and innovation institutions—data siloses
make it difficult to access data to conduct research on
the prediction of road conditions and selection of road
maintenance activities, as well as to develop innovative
services. A more structured approach to OD management
and use would address this challenge.
6 Conclusions and future work
The contribution of this paper is as follows. (1) We have
analyzed how organizations are able to improve their busi-
ness capabilities by taking advantage of Open Data initia-
tives. (2) We have defined and further exemplified design
13
396
and run-time requirements as well as provided a method
extension for provisioning and using Open Data by means
of business capabilities. The motivation behind this study
lies in the fact that the success of modern organizations
heavily relies on their ability to gather different data from
their surroundings. In many cases, the requirements for data
accuracy, amount, and the pace at which it needs to be pro-
cessed are constantly increasing. Yet, despite its commonly
recognized suitability for distributing information to broad
audiences, an essential aspect for successful OD initiatives
is the need to overcome the current problems emphasized in
the introduction of this article, chiefly among which is the
need to make OD more available to business organizations.
The proposed OD extension provides benefits for both
data providers and users: Currently, data providers are not
able to fully benefit from data at their disposal because
what is published as Open Data is not sufficiently used.
The proposed ecosystem approach provides the ability to
share their Open Data while meeting privacy requirements.
The use of cloud-based CDD environment architecture
for OD and knowledge brokering simplifies publishing of
near-real-time OD and relieves provider’s technical infra-
structure of extra load. Availability of OD usage examples
in the form of open knowledge and standardized interfaces
for accessing near-real-time OD would facilitate a wider
adoption of OD by OD users and the creation of new and
innovative services; the latter being one of the driving
forces for the OD movement.
Considering the challenges for successful OD use, we
have argued that many of them could be solved by form-
ing a business ecosystem, i.e., a network of organizations
consisting of OD providers, government agencies, other
stakeholders, intermediaries, as well as OD users. They
key to such an ecosystem is that it consists of entities that
provide Open Data (OD providers), OD brokers, and those
that have business value from using it (OD users). As a
result, a multi-point exchange of OD is created and has
the potential of evolving and growing in terms of data use
and size.
The CDD methodology supports a capability-oriented
design for run-time configuring of existing software solu-
tions of organizations according to changes in the business
environment. For this reason, this study has considered
it as a possible, enterprise-wide and systematic, solution
for management of OD. The IS solutions of the organiza-
tions need to be empowered with the ability to interoper-
ate with OD sources and their APIs as presented with the
capability design and run-time guidelines in this study.
This in turn will lead to a self-sustained and increasingly
growing-in-need cycle for Open Data. We have developed
a demonstration of our proposal by applying it on the case
of designing a system for regional roads maintenance and
smart traffic management in Latvia.
13
J. Kampars et al.
Currently, our research team is working on a pilot pro-
ject with IT department of LAM to raise the level of con-
text awareness in their ERP system and provide real-time
interpretation of Waze alert feeds and road related weather
information. During later stages of the project, we plan
to approach Latvian Association of Local and Regional
Governments and regional road maintenance companies to
empirically validate the theoretical findings from Sect. 4.
Concerning future work, the functionality of the CPR
will be extended to fully address the requirements of OD
broker as documented in Table 3. It has the potential of
being used by business organizations to provide all the
tasks needed to make raw/original OD using a set of trans-
formations and API adapters compliant with the internal
data of the organizations. Furthermore, extensions that are
needed to support the processing of aggregated data in
conjunction with real-time data will also be developed.
References
1. Zeleti, F.A., Ojo, A.: Capability matrix for open data. In: Cam-
arinha-Matos, L.M., Afsarmanesh, H. (eds.) 15th Working Con-
ference on Virtual Enterprises (PROVE), pp. 498–509. Springer,
Amsterdam (2014)
2. What is Open Data? http://opend​ataha​ndboo​k.org/guide​/en/what-
is-open-data/. Accessed 12 Sept 2018
3. Martin, S., Foulonneau, M., Turki, S.: 1–5 stars: metadata on
the openness level of open data sets in Europe. In: Garoufallou,
E., Greenberg, J. (eds.) Metadata and Semantics Research, pp.
234–245. Springer, Cham (2013)
4. Manyika, J., Chui, M., Farrell, D., Van Kuiken, S., Groves, P.,
Almasi Doshi, E.: Open Data: Unlocking Innovation and Perfor-
mance with Liquid Information. McKinsey & Company, New
York (2013)
5. Carrara, W., Chan, W.S., Fischer, S., Steenbergen, E.: Creating
Value Through Open Data: Study on the Impact of Re-use of Pub-
lic Data Resources. Publications Office of the European Union,
Luxembourg (2015)
6. EU Open Data Portal Publishers. https​://data.europ​a.eu/euodp​/
data/publi​sher. Accessed 10 Sept 2018
7. Latvia’s Open Data Portal. https​://data.gov.lv/eng. Accessed 11
Mar 2019
8. Open Stockholm. https​://open.stock​holm.se/
9. Foulonneau, M., Martin, S., Turki, S.: How open data are turned
into services? In: Snene, M., Leonard, M. (eds.) Exploring Ser-
vices Science, pp. 31–39. Springer, Cham (2014)
10. Zuiderwijk, A., Janssen, M., van de Kaa, G., Poulis, K.: The
wicked problem of commercial value creation in open data eco-
systems: policy guidelines for governments. Inf. Polity 21, 223–
236 (2016)
11. Clemente, P.J., Lozano-Tello, A.: Model driven development
applied to complex event processing for near real-time open data.
Sensors (Basel) 18, 4125 (2018)
12. Bertot, J.C., McDermott, P., Smith, T.: Measurement of open gov-
ernment: metrics and process. In: 2012 45th Hawaii International
Conference on System Sciences, pp. 2491–2499 (2012)
13. Welle Donker, F., van Loenen, B.: How to assess the success of
the open data ecosystem? Int. J. Digit. Earth 10, 284–306 (2017)
14. Jurisch, M.C., Kautz, M., Wolf, P., Krcmar, H.: An interna-
tional survey of the factors influencing the intention to use open
Extending organizational capabilities with Open Data to support sustainable and dynamic…
government. In: 2015 48th Hawaii International Conference on
System Sciences, pp. 2188–2198 (2015)
15. Kaur, J., Kaur, K.: Internet of things: a review on technologies,
architecture, challenges, applications, future trends. Int J Comput
Netw Inf Secur 9, 57–70 (2017)
16. Smith, G., Ofe, H.A., Sandberg, J.: Digital service innovation
from open data: exploring the value proposition of an open data
marketplace. In: 2016 49th Hawaii International Conference on
System Sciences (HICSS), pp. 1277–1286 (2016)
17. Susha, I., Grönlund, Å., Janssen, M.: Organizational measures
to stimulate user engagement with open data. Transform. Gov.
People Process Policy 9, 181–206 (2015)
18. Lnenicka, M., Komarkova, J.: Developing a government enter-
prise architecture framework to support the requirements of big
and open linked data with the use of cloud computing. Int. J. Inf.
Manag. 46, 124–141 (2019)
19. Berziša, S., Bravos, G., Gonzalez, T.C., Czubayko, U., España,
S., Grabis, J., Henkel, M., Jokste, L., Kampars, J., Koç, H., Kuhr,
J.-C., Llorca, C., Loucopoulos, P., Pascual, R.J., Pastor, O., Sand-
kuhl, K., Simic, H., Stirna, J., Valverde, F.G., Zdravkovic, J.:
Capability driven development: an approach to designing digital
enterprises. Bus. Inf. Syst. Eng. 57, 15–25 (2015)
20. Sandkuhl, K., Stirna, J.: Capability Management in Digital Enter-
prises. Springer, Cham (2018)
21. Zdravkovic, J., Kampars, J., Stirna, J.: Using open data to sup-
port organizational capabilities in dynamic business contexts.
In: Matulevičius, R., Dijkman, R. (eds.) Advanced Informa-
tion Systems Engineering Workshops. CAiSE 2018. Lecture
Notes in Business Information Processing, vol. 316, pp. 28–39.
Springer, Cham (2018)
22. Open Data Institute: Open data means business: UK innovation
across sectors and regions: survey questions. https​://theod​i.org/
artic​le/open-data-means​-busin​ess/. Accessed 12 Sept 2018
23. Berends, J., Carrara, W., Radu, C.: Analytical report 9: the
economic benefits of open data. https​://www.europ​eanda​tapor​
tal.eu/sites​/defau​lt/files​/analy​tical​_repor​t_n9_econo​mic_benef​
its_of_open_data.pdf. Accessed 13 Mar 2019
24. Liu, X., Song, Y., Wu, K., Wang, J., Li, D., Long, Y.: Under-
standing urban China with open data. Cities 47, 53–61 (2015)
25. Berrone, P., Ricart, J.E., Carrasco, C.: The open kimono: toward
a general framework for open data initiatives in cities. Calif.
Manag. Rev. 59, 39–70 (2016)
26. Zuiderwijk, A., Janssen, M., Poulis, K., van de Kaa, G.: Open
data for competitive advantage: insights from open data use by
companies. In: Proceedings of the 16th Annual International
Conference on Digital Government Research, pp. 79–88. ACM,
New York (2015)
27. Trafiklab—together we create the future of public transport.
https​://www.inter​regeu​rope.eu/polic​ylear​ning/good-pract​ices/
item/181/trafi​klab-toget​her-we-creat​e-the-futur​e-of-publi​c-trans​
port/. Accessed 12 Mar 2019
28. Tantitharanukul, N., Osathanunkul, K., Hantrakul, K., Pramok-
chon, P., Khoenkaw, P.: MQTT-topic naming criteria of open
data for smart cities. In: 2016 International Computer Science
and Engineering Conference (ICSEC), pp. 1–6 (2016)
29. Zeleti, F.A., Ojo, A.: Competitive capability framework for
open government data organizations. In: Proceedings of the
18th Annual International Conference on Digital Government
Research, pp. 250–259. ACM, New York (2017)
30. Gong, Y., Janssen, M.: Enterprise architectures for supporting
the adoption of big data. In: Proceedings of the 18th Annual
International Conference on Digital Government Research, pp.
505–510. ACM, Staten Island (2017)
397
31. Zdravkovic, J., Stirna, J., Grabis, J.: A comparative analysis of
using the capability notion for congruent business and infor-
mation systems engineering. Complex Syst. Inf. Model. Q. 10,
1–20 (2017)
32. Ulrich, W., Rosen, M.: The business capability map: building a
foundation for business/IT alignment. https​://www.cutte​r.com/
artic​le/busin​ess-capab​ility​-map-build​ing-found​ation​-busin​essit​
-align​ment-46950​1. Accessed 12 Sept 2018
33. Grabis, J., Henkel, M., Kampars, J., Koç, H., Sandkuhl, K.,
Stamer, D., Stirna, J., Valverde, F., Zdravkovic, J.: Deliverable
5.3: the final version of capability driven development method-
ology. FP7 Project 611351 CaaS—Capability as a Service in
Digital Enterprises, Stockholm University, p. 266 (2016). https​
://doi.org/10.13140​/RG.2.2.35862​.34889​
34. Open Data Barometer. https​://opend​ataba​romet​er.org/4thed​ition​
/repor​t/. Accessed 20 Sept 2018
35. Grabis, J., Kampars, J.: Capability management in the cloud:
model and environment. In: Matulevičius, R., Dijkman, R. (eds.)
Advanced Information Systems Engineering Workshops, pp.
40–50. Springer, Cham (2018)
36. Persson, A., Stirna, J., Aggestam, L.: How to disseminate pro-
fessional knowledge in healthcare: the case of Skaraborg Hos-
pital. J. Cases Inf. Technol. 10, 41–64 (2008)
37. Stirna, J., Persson, A., Aggestam, L.: Building knowledge repos-
itories with enterprise modelling and patterns—from theory to
practice. In: BT—Proceedings of the Fourteenth European Con-
ference on Information Systems, ECIS 2006, Göteborg, Sweden,
2006. http://aisel​.aisne​t.org/ecis2​006/179 (2006)
38. Kampars, J., Stirna, J.: A repository for pattern governance sup-
porting capability driven development. In: CEUR Workshop Pro-
ceedings, pp. 1–12 (2017)
39. Sandkuhl, K., Janis, S., Anne, P., Matthias, W.: Enterprise Mod-
eling—Tackling Business Challenges with the 4EM Method.
Springer, Cham (2014)
Publisher’s Note Springer Nature remains neutral with regard to
jurisdictional claims in published maps and institutional affiliations.
Jānis Kampars is an Associate
Professor at the Faculty of Com-
puter Science and Information
Technology, Riga Technical Uni-
versity, Latvia. He obtained his
Ph.D. in 2012 in Information
Technology. His main research
areas are big data, data and
application integration, cloud
computing, and capability-driven
development. At the Institute of
Information Technology he is
responsible for applied research
in collaboration with industry.
Kampars is a lead technical
architect on the team developing
real-time data stream processing platform BaSeCaaS, which received
commercialization funding from Latvian Investment and Development
Agency. He is the author of 28 scientific publications, and 17 of them
are included in Scopus database.
13
398 J. Kampars et al.

Jelena Zdravkovic is Professor Jānis Grabis is a Professor at the

the Department of Computer and Faculty of Computer Science
Systems Sciences (DSV), at and Information Technology,
Stockholm University. She has Riga Technical University, Lat-
Ph.D. in Computer and Systems via. He obtained his Ph.D. from
Sciences at Royal Institute of the Riga Technical University in
Technology (KTH) from 2006, 2001 and worked as a Research
as well as MBA in E-commerce. Associate at the College of Engi-
Jelena’s research interests neering and Computer Science,
include enterprise modeling, University of Michigan-Dear-
requirements engineering, and born. He has published in major
capability-driven development. academic journals including
She is in the Editorial Board of OMEGA, European Journal of
Springer BISE and RE Journals, Operational Management, Inter-
as well as a regular reviewer for national Journal of Production
a number of other international Research, Computers & Indus-
journals including several of Springer, Elsevier’s Journal of Systems trial Engineering and others. He has been a guest-editor for two top
and Software and Information and Software Technology Journal, and academic journals and member of the program committee of several
IEEE Computing. Jelena has organized a number of international con- academic conferences. Grabis has co-authored a monograph on supply
ferences and workshops in the IS Engineering discipline, and she serves chain configuration published by Springer. His research interests are in
in the program committees of many of them. supply chain management, enterprise applications, and project
management.
Janis Stirna has received a degree
of Doctor of Philosophy in Com-
puter and Systems Sciences from
the Royal Institute of Technol-
ogy (KTH), Sweden in 2001 and
was awarded Associate Professor
(docent) from Jönköping Univer-
sity, Sweden in 2008. In 2015, he
was promoted to full professor at
Department of Computer and
Systems Science (DSV), Stock-
holm University. Stir na’s
research interests are enterprise
modeling methods and tools,
organizational patterns, and
model-driven development.
Stirna is an author or co-author of more than 100 research reports and
publications as well as three text books on enterprise modeling. He has
participated in 14 EU-financed research projects and has co-developed
four enterprise modeling methods, including 4EM—For Enterprise
Modeling and CDD—Capability-Driven Development. Stirna is cur-
rently vice-chair of the IFIP Working Group 8.1 Design and Evaluation
of Information Systems.

13