![](bg5.png)
(SOC) in particular enables reuse and modularization
by encapsulating functionalities in implementation-
independent services. Service-oriented concepts
have already provided significant steps towards more
flexible enterprise software systems within compa-
nies (Frischbier and Petrov, 2010). However, they
are not yet ready for unanticipated changes across
company borders and do not yet provide the self-
monitoring capabilities needed (Frischbier et al.,
2011).
Therefore we advocate to combine pull-based
building blocks with push-based building blocks op-
erating on streams of information. In contrast to pull-
based building blocks, event-based systems (EBS) do
not rely on persistent data but work on continuous
flows of event objects. Event objects represent in-
formation on meaningful changes in the environment
disseminated by event-producers and consumed by
event-consumers. With the information itself defin-
ing the participating subsystems, event-driven build-
ing blocks easily adjust to changes in the environ-
ment. Using complex event processing (CEP) and
rule engines to react according to given (or learned)
rules, event-based systems transform patterns of in-
formation into functionality. Today, event-based sys-
tems are primarily used in the context of business
intelligence to quickly gain knowledge and react on
it (Castellanos et al., 2010; Buchmann et al., 2010).
The fabric acts as a coordinator and handles
the information flow between emergent components,
emergent systems and legacy systems. Therefore, it is
able to: i) balance components’ different expectations
regarding quality of service (QoS) and quality of in-
formation (QoI) in a distributed way; ii) handle differ-
ent semantics of the exchanged information; and iii)
allow for anonymous introspection and monitoring of
components (cf. (R6)).
The two main challenges from an architectural
point of view are: i) integrating pull- and push-based
building blocks into emergent components; ii) en-
abling the fabric to connect emergent components and
legacy systems while allowing for minimal-inversive
introspection and seamless monitoring at runtime
even across company borders.
4.2 BPM & Governance Perspective
Supporting rapid business model prototyping while
keeping models synchronized (R1), (R3)-(R5). Engi-
neering EESS is strictly correlated with BPM. Having
a closer look at the phases and overlying processes
of BPM shows that today the life-cycle phases (i.e.,
process strategy, design, implementation, execution
and controlling) are supported individually by soft-
ware tools using distinct methods and technologies.
Integrating them is difficult if not impossible. Engi-
neering EESS, however, requires a seamless process
of process management where strategy-defining mod-
els and methods are aligned with those for design-
ing business processes. Thus it is of vital importance
to procure interoperability within the BPM life-cycle
by developing integrated models, methods and trans-
formation tools to allow for emergence between the
BPM software components. Already implemented
digital process models must be easily transform- and
(re)implementable when new emergent components
are added to the EESS. For this purpose, EESS need
modular and flexible capabilities to track the dynam-
ically implemented processes even if they span com-
pany borders. Business processes, however, are the
core assets of any company and none of them is in-
terested in sharing valuable process experience with
other companies without compensation. Thus, soft-
ware providers have to act as mediators between dif-
ferent business processes - not only inside a business
line but also between different industries.
EESS need to be open for third-party extensions
at a larger scale than today while consumers and
providers may not necessarily know about each other
beforehand. Therefore, an integrated governance and
compliance model needs to span all existing types
of used software building blocks (e.g., business pro-
cesses, services in SOC, or entities in EBS). As we
cannot assume a central authority to control the evo-
lution of EESS, governance and compliance models
have to: i) allow all parties to integrate services into
an open EESS without impairing the quality of exist-
ing configurations; ii) prevent dependencies on exter-
nal processes to compromise a constant level of qual-
ity for information and services.
Linking runtime and design-time information us-
ing feedback (R1), (R3)-(R6). EESS are continuously
evolving as they react to changes in their environment.
Thus, development has to take uncertainty into ac-
count as neither the final relationships to other entities
nor the final requirements may be known at design-
time. This calls for a strong feedback loop between
runtime and design-time: The monitoring of systems
and components at runtime that allows for a compar-
ison between de-facto and expected behavior. Thus,
methodology has to focus on selecting, adapting, ex-
tending, composing and testing emergent components
to form emergent systems based on that feedback
without violating required levels of quality. Espe-
cially components being partly deployed and systems
in different life-cycle stages have to be considered.
Typically, changes to EESS require a detailed picture
and governance process on the application landscape
EmergenceasCompetitiveAdvantage-EngineeringTomorrow'sEnterpriseSoftwareSystems
185