2015 IEEE 19th International Enterprise Distributed Object Computing Workshop

Towards the Next Generation

Service Oriented Enterprise Architecture

Ricardo J. Rabelo Ovidiu Noran Peter Bernus

Dept. of Automation and Systems IIIS CEARM & School of ICT IIIS CEARM & School of ICT
Engineering, Federal Univ. of Santa Griffith University Griffith University
Catarina, Florianopolis (SC), Brazil Brisbane, Australia Brisbane, Australia
ricardo.rabelo@ufsc.br O.Noran@griffith.edu.au P.Bernus@griffith.edu.au

result was the progression towards a broader concept called

Abstract—Emerging business models such as digital
Service-oriented Enterprise Architecture (SOEA) [5].
ecosystems involving collaborative innovation, participatory
decision-making and flexible organizational structures are set This paper employs a conceptual analytical research
to significantly affect inter- and intra-enterprise structure and approach [6] to describe how new business and technology
functionality. This has seen the appearance of increasingly paradigms continue to affect the new SOEA approach. To
complex Service-oriented Architecture (SOA) scenarios
achieve this we must integrate what is known as the ‘EA
featuring various partnership levels, increased resilience and
adaptation to tougher compliance regulations, more seamless body of knowledge’ with the knowledge base of ‘SOA as a
integration with process layers, etc. This complexity has software architecture solution’ that sprang from the need to
brought about the need to broaden the SOA paradigm, so as to move integration to a new level of abstraction.
include business, infrastructure and multi-layering, resulting Methodologically speaking, we had to create a mapping,
in an evolved concept known as Service-Oriented Enterprise using conceptual analysis and associated logical arguments,
Architecture (SOEA). This paper aims to describe the way new that demonstrate how an inherently holistic Enterprise
business and technology paradigms continue to affect the new Architecture (EA) framework and related practices apply to
SOEA approach and how the inherently holistic Enterprise the SOA problem domain and thereby support the emerging
Architecture (EA) frameworks and related practices can
complex dynamic, multi-layered and value-chained service-
support the emerging complex dynamic, multi-layered and
value-chained service-based scenario. based scenario.
Section II provides an introduction to EA and describes
Keywords: Enterprise Architecture; Service-Oriented and justifies the framework selected for the research.
Architecture; Service-Oriented Enterprise Architecture
Section III contains a presentation of SOA-related concepts
I. INTRODUCTION and their transition to a SOEA. Section IV depicts new
SOEA aspects brought up and challenges related to the role
The need for enterprises to survive, adapt and
of the emerging Digital Business Ecosystem. Section V
successfully compete in the context of significant business
exemplifies how EA can assist to tackle current SOEA
model changes brought about by the advent of new Internet
questions, by focusing on a particular area (service life
technologies such as Cloud Computing and the Internet of
cycle). Section VI presents conclusions and further work.
Things are increasingly shifting the emphasis on the
management, rather than ownership of ICT resources [1]. II. ENTERPRISE ARCHITECTURE: ENDEAVOUR AND
Emerging business models such as digital ecosystems [2-4] ARTEFACTS
involving collaborative innovation, participatory decision-
The EA domain is still in development and there is no
making and flexible organizational structures are to change
widely accepted definition [7]. While often EA is believed
inter- and intra-enterprise structures and functionality.
to be limited to the Information Technology aspect, EA is in
All these factors have contributed to the appearance of fact a holistic change management paradigm that bridges
increasingly complex Service-oriented Architecture (SOA) management and engineering best-practice, providing the
scenarios featuring several levels of partnerships, increased “[…] key requirements, principles and models that describe
resilience and adaptation to tougher compliance regulations, the enterprise's future state. […] EA comprises people,
more seamless integration with process layers, etc. With this processes, information and technology of the enterprise, and
complexity has come the realization of the need to broaden their relationships to one another and to the external
the service-oriented paradigm beyond the initial software- environment” [8]. This EA definition reinforces the view of
centric extent, to include business and infrastructure and enterprises as socio-technical systems [9] with voluntaristic
multi-layering, so that services of different layers can be people [10] in a complex organizational, political and
interconnected in order to provide higher level services. The behavioural context [11-13]. Thus, EA should be capable of

978-1-4673-9331-7/15 $31.00 © 2015 IEEE 91

DOI 10.1109/EDOCW.2015.34
providing a supporting environment integrating all collaboration [37], in sustainability [38] and building
necessary aspects in a life cycle-based set of models [14] organizational preparedness for mergers & acquisitions [39].
ensuring the consistency and sustainability of complex
In section V we shall use selected viewpoints belonging
systems-of-systems (such as enterprises) transformation
to the modelling framework of the main component of
projects.
GERAM, namely GERA (Generalized Enterprise Reference
According to [15], a framework is “[…] a set of Architecture, see Fig.1) in order to illustrate how EA
assumptions, concepts, values, and practices that constitutes artefacts can assist the SOEA endeavour in the creation and
a way of viewing reality.” Architectural frameworks management of services by exploring the interplay of the
typically provide tools and methodologies to manage scale various stakeholders (as defined in ISO42010 [16]).
and complexity so as to abstract from the typically high Importantly, the modelling constructs derived from the
level of detail and thus bring enterprise design tasks into GERA framework allow an essential aspect, namely life
focus and produce usable architectural descriptions [16]. If cycle, to permeate the entire SOEA effort and to express the
we accept that, in view of its proposed definition above, EA often overlooked life history concept (see section V).
represents a holistic ontology of change, it follows that an Generic
Views
EA Framework (EAF) is an essential enabler towards Partial
Particular
Partial level of Formalism used
making sense of the complex universe of discourse GERA Modelling in the Business Model
describing EA-specific endeavours such as SOEA. Thus, Framework Instantiation P M

organizations may use EAFs in order to construct their own, Identification

Identification
Management
Management Id
and Control
shared meanings of change-related SOEA concepts by Concept
and Control
Cust Service
Concept Product or Service C
‘weaving’ EA artefacts into the fabric of their own pre-
Requirements
existing, path-dependent concepts of SOEA-related change. Requirements Software
Software
R
Prelim. design Hardware
Prelim. design Hardware PD
In exploring the ways EA artefacts can assist SOEA we Design Simplify
Design
DD
have chosen to use a generic high-level, ‘meta’-EAF called Detailed design
Detailed design
Resource
Resource
Organisation
the Generalized Enterprise Reference Architecture and Implementation
Implementation
Organisation
Information I
Information
Function
Methodology (GERAM), which is part of ISO15704:2005 Operation
Function
Op
[17]. GERAM represents the abstraction of several Operation
Decommission D
‘historical’ AFs such as PERA [18], CIMOSA [19] and Decommission Machine
HumanMachine
GRAI [20]. Its capability to integrate and subsume LC phases Human

mainstream AFs’ (Zachman [21], TOGAF [22], DoDAF The Modelling Framework of GERA
[23], FEAF [24], ARIS [25], etc.) artefacts that may be
Fig. 1. GERA modelling framework showing a selection of viewpoints
required for specific EA endeavours has also been orthogonal to the life cycle dimension and the creation of the
documented [26-28]. Thus, GERAM provides a structured modelling construct used in section V.
repository (‘shopping list’) out of which relevant viewpoints
and artefacts can be selected based on the needs of concrete III. SERVICE-ORIENTED ARCHITECTURE AND SERVICE-
(SO)EA scenarios and be connected according to a set of ORIENTED ENTERPRISE ARCHITECTURE
basic rules, to build specific methodologies (e.g. [29]). An accepted view of Service Oriented Architecture
The wide applicability of GERAM as an overarching, (SOA) appears to be that of an architectural style espousing
non-prescriptive (‘light-weight’ [30]) AF has allowed its the concepts of services (packaged functions) and of
involvement in conjunction with systems thinking and consumer(s), as a foundation to construct the functionality
system-of-systems paradigms to address several major of an enterprise [40-42]. Services are provided and
challenges faced by society today. For example, GERAM consumed based on contracts, offering enhanced
has been used to create Virtual Enterprises (VEs) and manageability and can be provided using (mostly) Web
Virtual Organizations – VOs [31]) for bidding for projects Service technologies that may be outsourced or even be
[32] and for after sales services [33]. In the standards accessed on-demand, e.g. ‘Software as a Service (SaaS)’.
community, GERAM has been proposed as an essential tool The SOA concept originates in the modular, object-oriented
in discovering gaps and overlaps in the areas covered by and component-based software development paradigms.
various standards and building an intelligent repository However, the lack of adequate supporting and realization
underlying an expert system enabling improved and infrastructure has in the past hindered its adoption [43].
sustainable interoperability of standards [34]. Other After several standardisation efforts and the typical phases
examples are the use of GERAM to support discovery of the of vendor hype and unrealistic expectations, and recovery
areas and level of environmental management integration from the disillusionment phase, SOA technology has
[35] and in emergency management, to improve the reached the plateau of productivity, although, as also shown
effectiveness and resilience of the command and control and in this paper, the concept of SOA is still evolving [44].
emergency response teams [36]. GERAM and systems The expected SOA benefits have been variously
thinking principles have also been applied in lifecycle- classified in the relevant literature as technical, economic
centric analysis and design of healthcare interoperability and and strategic [45], IT, process and strategy [46], or business

92
and IT [47]. Several stages have also been distinguished in ‘next generation’ SOEA requires including additional
achieving SOA maturity [48], and the relation between SOA viewpoints so as to reach its full potential.
and EA have also been quite often explored, with varying Partnerships Deployment & ICT SOA &
degrees of success (e.g. [48-51]). & vendors
dimension
Service Provision Implementation
models dimension & standards
Services
life cycle
dimension dimension
It must be also noted, however, that many SOA Services
Infrastructure
initiatives have failed or achieved results below what was & hardware
typology
dimension
expected and advocated by vendors [40,50,53-56]. Main dimension

reasons have been as follows: i) Business: insufficient EA life cycle

dimension
vision about how SOA can support business agility; lack of
Governance
proper business models; lack of a SOA roadmap; lack of dimension
SOEA endeavor

vision about the benefits to achieve with SOA and related Financial,
Revenues,
Return on Investment. ii) Technical: complex integration Regulatory SOA Scope
Compliance
and security, services granularity, vendors locked-in dimension Services Performance
(OASIS, 2005)

software components and technologies; low training level of Management Human Services management Indicators
dimension dimension dimension dimension
people involved; inadequate approaches for integrating
legacy systems; services having to respond to different QoS Fig. 2. Important viewpoints of a SOEA endeavour
and SLAs requirements; iii) Organizational: business
processes not properly understood and services not duly Thus, in Fig.2 the authors depicted, in addition to the
identified; lack of use of adequate SOA development OASIS framework, an extended (although perhaps not
methodologies; lack of proper governance policies for complete) list of viewpoints proposed to be involved in a
considering SOA and services life cycles. iv) Project SOEA endeavour. As can be seen (and detailed in Section
management: inadequate management regarding SOA IV), several dimensions have to be considered but also
complexity, leading to difficulty to measure and evaluate harmonized – not only targeting the SOEA execution, but its
development progress; high costs and delays. v) Cultural: entire life cycle. This means different and complementary
low reuse practices; unorganized catalogues; proliferation of levels of management, including related governance. Beside
services; weak integration between the business/process and this, currently the human dimension of services appears to be
IT levels. under-represented, even though humans are a crucial element
to support the execution of diverse services both in SOEA
Attempts to tackle such shortcomings have led to the projects and in the services created by them.
maturing and increased complexity of SOA efforts, resulting
in the expansion of the paradigm to include business, The entire SOEA environment should be managed as
applications & data, platform, and infrastructure in a multi- well in the context of its own life cycle. For example, the
layered manner. This transition to a wider SOEA [50, 58] OASIS framework (see three dimensions in Fig.2) depicts an
has been interpreted in various ways; thus, some authors ecosystem whose life cycle should be appropriately dealt
(e.g. [59]) used ‘SOEA’ to describe an EA implemented in a with in order to sustain the SOEA effort’s own lifecycle.
SOA style that, once implemented, becomes a competitive Implementing SOA requires a deep change in the way
asset enabling modularity, reusability, agility and improved organizations designed and managed IT so as to support their
Quality of Service (QoS). business activities. Initially dedicated to the development of
Accordingly, SOEA has broadened the scope of SOA services tailor-designed and bound to specific enterprise
systems: some authors see such systems being formed as a business applications and very much focused on the IT
composition of service layers, i.e., Baas (Business-as-a- dimension, SOA projects have gradually evolved to wider
Service), SaaS (Software-as-a-Service), PaaS (Platform-as-a- sharing environments. In these environments groups of
Service) and IaaS (Infrastructure-as-a-Service) [40]. services could support various enterprise applications, but
this design was still constrained by static binding and local
The OASIS framework [60] is one of the first to express service-catalogues, software development practices and
this wider perspective, seeing SOA as an architectural model interoperability policies [61,62].
influenced not only by IT, but also by the business
dimension, and by what they called ‘external dimension’ – in Requirements for business process agility and business
other words, something that cannot be treated as a computing level partnerships made companies rethink the strategic role
asset disconnected from companies’ businesses and IT can play in enterprise competitiveness and sustainability.
strategies, from external institutions (e.g. providers) and The increasing availability of IT services worldwide allowed
supporting artefacts (e.g. legal regulations). It is relevant that companies to extend the scope of their system architecture
EA is positioned in a central position of the OASIS and include services provided by digital ecosystems. In
framework, binding these three dimensions (Fig.2). support, new IT-level processes, tools and systems emerged,
enabling distributed business processes and better
However, when considering the more recent movements interoperability among heterogeneous systems/ devices,
within the so-called service oriented economy and business leading to concepts as inter-organizational Enterprise Service
ecosystems, even this framework seems incomplete. Thus, a Bus (ESB) and Event Driven Architecture (EDA) [63].

93
 IV. A CONTEMPORARY SOEA SCENARIO At the SOEA Solution level, customers can own or have
The emerging concept of Digital Business Ecosystem access to as many SOEA solutions as required, depending on
(DBE) [2-4] promotes an open, pervasive, collaborative and chosen deployment and access modes. This may include
networked business environment of organizations and different companies as users (e.g., supply chain members can
professionals that interact and join efforts to form VOs to be share the same service in collaborative production planning).
able to add value throughout the life cycles of software- and Providers may be involved in more than one SOEA solution
other services. From the business standpoint, a SOEA and simultaneously serve several customers, within different
‘solution’ (from the viewpoint of a specific enterprise) is business models, throughout the diverse stages and phases of
seen as a very flexible business process creation effort the given SOEA solution’s life.
offering better business agility. From the IT viewpoint the At the Client level, the SOEA solution’s services can
‘solution’ is the result of an ‘on-the-fly’ composition of interact with humans and other systems (whether service-
distributed services from providers that best match the based or traditional software packages e.g. corporate
functional and non-functional business requirements [61,62]. Enterprise Resource Planning (ERP) systems). Human
However, to achieve this, providers may need to be clients (end users) can be involved in various process
combined into networks to ensure they abide by business, activities, accessing those using different stationary and
legal and other compliance requirements [55]. Thus, DBE mobile devices (Device level). At the Interface level (be it
represents a new challenge for the current SOEA concept. graphical or merely textual), systems can provide adaptive or
A SOEA solution typically involves a variety of machine pre-defined interfaces per type of device. These interfaces
(software and hardware) and human service entities and may themselves also be created as services.
respective providers, as generically illustrated in Fig.3. Note: The Process level is the layer where business processes
in current literature there exists a diversity of SOEA ‘stacks’ are modelled, executed and managed. Thanks to the
and terminology, featuring various levels of abstraction, integrative vision with SOA technologies, Business Process
however, most typically overlook the non-technological Management systems have been gradually adopted by
aspects (e.g. [53, 57]). companies as a supporting technology. In the SOEA context,
it is assumed that companies use Business Process
Management (BPM)-like systems to define, find, select and
bind the (software and other) services required by processes.
The execution of the business processes by the bound
services and legacy applications should be organized at the
Coordination level (including some level of interoperability
management). Several tools (which can also be seen as
services) provide such support, like ESB and dedicated
middleware (e.g., to access real-time information from
manufacturing equipment), which in turn can involve
systems of other companies (e.g., suppliers and financial
partners). Orchestration / choreography and smart dynamic
services discovery and composition are some of the other
auxiliary mechanisms that can assist in this task.
The VO level corresponds to services that have been
created to execute the functions required by business
processes associated with a given SOEA solution. Such
services can be internal (developed or available in the
company repository) or external – offered by service
providers from the DBE (see bold circles in Fig.3),. These
VO services may be fully or partially automated.
The Wrapping level represents the set of services made
available by the DBE’s members to be used in any
composition. This acts as a virtualization over the members’
Fig. 3. SOEA Stack enriched with DBE
registered services, described (e.g., via semantics agreements
or mappings) and exposed as public for external
A SOEA solution can be deployed at and accessed from
consumption. Services can be entirely decoupled, but some
both customers’ and providers’ sites. However, these
internal partnerships among DBE members may exist so as
stakeholders typically have different perspectives in terms of
to provide ‘micro solutions’ for frequent customer needs.
required levels of management, QoS and life cycle.
This level assumes that services are sufficiently prepared to
interoperate in a composition. For example, services should

94
use standard interfaces and protocols, be somehow certified Management considerations include technical (quality,
in terms of development quality and trustworthiness, etc. performance, trustworthiness, security, reliability, etc.) and
This wrapping must also consider the internal architecture of non-technical (costs, reputation, customer satisfaction,
services so as to decide which level or kind of wrapping can usability, maintainability, etc.) qualities, as well as the
be done: if a given service has been natively developed with respective performance indicators (quantitative and
a multi-tenancy vision or in the 3-Tier model, its qualitative) for each aspect, possibly organised according to
presentation, process and data layers are also decoupled and some strategic management best practice models, e.g. [64].
may be wrapped either separately or by considering this This management in turn has processes to be executed and
requirement. Depending on the internal implementation they are also constrained by a governance model (a meta-
model, the service’s components and infrastructure (e.g. its management). The management horizons are: Strategic
execution container and a database) may also be included. (decide service portfolios, customers, market, partners, etc.);
Tactical (handle given SOEA solutions individually and their
The Services level is the most elementary layer of a DBE.
services, involved partners, etc.); Operational (monitor at
This is a virtualization over all member services, and may
individual services level or group of inter-related services);
include components internally used by the services., This
and Real-time (e.g., observation of infrastructures and QoS,
may include services internally registered and not exposed as
or necessary intervention).
public (but may be in the future, depending on company
strategy). Services can be of many types [40,50], such as Such management activities (of DBE, DBE members,
application-, processes-, infrastructure-, governance-, etc.) cannot be limited to the operation phase of the
security-, integration & interoperability-, shop floor-, real- respective entities’ life cycles. As in any collaborative
time-, database-, data mining services, etc. In general terms, ecosystem, other life cycle phases are just as crucial [65], as
these can be categorized as BaaS (Business-as-a-Service), each service aspect should be previously prepared (at a
SaaS (Software-as-a-Service), PaaS (Platform-as-a-Service) required level of preparedness), which takes time.
and IaaS (Infrastructure-as-a-Service) [40]. Note that this
Once prepared, each aspect should be properly made
level also involves human-executed services, which are
available, i.e. created and launched into the environment, so
essential in real SOEA projects (in various life cycle phases,
as to start operating or be ready for use. During the operation
including operation), but usually under-represented in the
stage every entity has its own life cycle, e.g. it can evolve.
literature.
This evolution can be triggered and carried out
The Organization level represents the DBE’s members autonomously or handled by humans. When seen as a whole,
allowed to provide services to SOEA solutions under various all such evolutions can make the DBE itself evolve, or more
business models. As explained in section II, an organization drastically, change its basic profile or identity
can be described and modelled in a number of perspectives (metamorphosis). New entities come and existing entities
from the EA point of view. Types of actors include may go, so there are repeated (phases of) commissioning &
individual software developers, software-houses, decommissioning. Finally, considering all this intrinsic DBE
professionals, etc., as well as infrastructure providers, e.g. dynamics, the DBE has to handle its own long-term
Telecom companies. The sustainability of DBE membership sustainability. Therefore, a DBE also has a life cycle to be
depends on many factors and tends to require diverse managed, following a governance model (which is a facet of
supporting management structures (formal / comprehensive management from the EA point of view).
governance models, common code of ethics, etc.).
Regarding all the issues above, it happens that the
The Physical level corresponds to all computing business model vision also needs to be re-evaluated, as
resources and data sources that support the execution and the SOEA solutions can be dynamically composed, with
provision of services along their life cycle. software and human-provided services being involved in the
solution, and having variable roles in the diverse stages and
The SOEA stack shown in Fig.3 essentially shows the
phases of services, of VOs, the SOEA solutions and the
technological side of SOA. However, the human element of
DBE itself. The multi-layered and dynamic nature of all
services and the management side of that SOEA scenario are
relationships among the involved entities and actors should
just as important and complex. There are a number of aspects
be considered in the simultaneous value chains created.
to manage: the DBE, DBE members, SOA solutions as
business applications, SOA solutions as VO alliances, the V. THE EA PERSPECTIVE ON NEXT GENERATION SOEA
individual software services, human services (e.g. helpdesk,
Embarking on the use of SOEA as an architecting
local integrations, ESB configurations, etc.), the DBE’s
principle to achieve better business agility is a strategic
services inventory (including infrastructure, software/legacy
enterprise transformation endeavour. As alluded to in
components and versioning), Service Level Agreements, ICT
Section IV, the change can have extensive effect both on
infrastructures, existing partnerships, customer experience,
multiple internal levels of the enterprise of interest, and
levels and types of governance, and the adopted business-,
externally. Therefore a systematic coverage of all these
billing-, taxation- and revenue models.
complex aspects is of value.

95
 A major aspect of this section is how the life cycle decreasing order of abstraction (from the high level
concept espoused by the proposed EA approach permeates definition of the business identity, through the business
the entire service creation and use scenario. This is concept definition, requirements definition and
important, because an architectural solution to a business specification, architectural design, detailed design, building
problem (such as may be created by the extensive use of a and releasing into operation, to the operation of the entity
service-oriented style of EA) must be sustainable and viable and its decommissioning – see vertical dimension in Fig. 1).
throughout the life of the target enterprise(s), and of other The second concept is temporal, describing when the
relevant (e.g. DBE) participants. instances of these life-cycle activities are performed (often
repeatedly); this is called in ISO15704 a life history
Importantly, according to ISO15704 [17] there are in
dimension. Significantly, there is no predefined sequence
fact two concepts related to what literature generally calls
between life-cycle activity types; only mutual constraints
lifecycle. The first concept is atemporal and represents the
exist among them (e.g. the architectural solution must be
life-cycle proper - defined as the set of life cycle process /
consistent with the business concept).
activity types depicting the enterprise entity in question in a

Creator of Composite Business Service Owner Organisa ons Pla orm Infrastructure & Pla orm
Business Service (CCBS) End User En ty (SBU) of External Services Service En es Service Providers

Composite
Business External Service
Business Service En es
Ecosystem En ty(ies) (SW & Data)
Broker(s) 2
2’
1’
1

3’
3

Project(s) to Create Composite Infra-structure

Business Service(s) Service En es
Fig. 4. A dynamic business model of the typical structure represented in Fig.3, depicting the life cycles of entities

As an example of how the scenario depicted in Fig.3 can shown being only the end users. In reality, SEs are broader
be represented so as to be able to define all necessary in scope than the layers in Fig.3; e.g., if viewed at the
actions for a successful definition of a SOEA, we take the Requirements life cycle phase level (see vertical dimension
viewpoint of a ‘Creator of a Composite Business Service’ in Fig.1), service processes include all activities performed
and build an illustrative example. Thus, Fig. 4 is an initial by the entity, no matter whether these will be done by
representation of the life-cycle relationships among i) this humans or by machines (software plus hardware), and the
enterprise’s strategic management, ii) the Project(s) it same is true of the management and control processes of the
initiates to create a composite business service(s), iii) the service. If viewed at the architectural design life cycle phase
(composite) service entity(ies) – SEs - created by these level, the components of the SE include software, hardware
projects, and iv) the strategic business unit (SBU), which and humans involved in the service and in its management
from the current point of view is identified in Fig.4 as the and control, but permitting that some service- and service-
End User Entity of the composite business service. (This management activities may be performed by external SEs.
SBU may be an internal or external client to this enterprise.)
This discussion pertains to the operation of the service
Notationally (and according to ISO15704), arrows may and of the management of a SE. However, in general, one
model operational interactions among entities (shown must give account of all life cycle processes of any entity,
dashed), or represent the fact that the entity at the origin of meaning to understand (or determine) who or what is
the arrow performs those life cycle activities at which the responsible for performing these life-cycle processes.
arrow points (shown as solid arrows), and can be either life-
In Figure 4, a service is represented as an entity (SE)
cycle activities of another entity, or of the entity itself.
that, as it operates, supports the operation of some other
Figure 4 is a so-called dynamic business model of the entity (e.g. the service user). This is shown as arrow 1 in
typical structure represented in Fig.3 (a ‘reference model’ in Fig.4. Arrow 1’ shows that the management of the service
ISO15704 terms). It must be noted, however, that Fig.3 only interacts with the management of the end user, e.g.,
represents the IT performing the service, with the humans providing evidence & undertaking corrections regarding

96
service levels / quality of service. These operational Note that SE ‘A’ shown in Fig. 5 has only operational
relationships should exist across multiple levels between management, such as BPM and IT service management
service users and service providers. [68,69]; strategic change is the responsibility of the Owner
Organization. Thus, the SE is only viable due to the owner
A SE may be holonic [66], whereupon all resources
organization, not in itself. As opposed to this, the SE ‘B’ in
(except for an assumed ubiquitous infrastructure) are part of
Fig.5 has all levels of management (operational, tactical and
the entity: this includes humans and machines, software and
strategic) covering all of its life cycle processes, and
hardware – everything necessary to provide the service and
therefore the SE is in itself a viable system.
to manage the service (represented in Fig. 4 and subsequent
figures as the left- and right hand sides of the ‘chocolate Some management functions of these SEs, e.g., various
bar’ and its modelling constructs defined in Fig. 1). The BPM and IT services management functions, may be
opposite can also be true, if the SE is a VO or VE [30]: ad repeated across several SEs and could be provided by a
extremum such an entity is virtual, because all of its shared process management / IT services management SE
activities are in fact performed (contributed to the VO’s (based on ISO/IEC20000 [68] / ITIL [69]). For example, the
processes) by external entities, and the VO has no resources management of each service should (potentially) be able to
of its own. In practice we assume that SEs entities are design, and from time to time update, the process by which
hybrid (holonic and virtual are the two extremes). the service function is provided. As an analogy, the vision
that business process owners design, analyse, test and release
A SE, that is to remain viable on its own, must be able to
into operation new processes is similar to the transformation
perform all of its own life cycle processes (arrow loop v of
that took place when typists were replaced by text editors
SE ‘B’ in Fig.5), with some of these possibly carried out by
that all end users could use. In other words, BPM and IT
outside provider entities enlisted by the SE itself. The
service management capability (including the associated
conditions of viability are [67] that the SE must have: i)
skills and tools) is part of the management of services. The
operational (including real time, if relevant) & tactical
significance of this is that BPM is not a separate ‘business
management capability to maintain adequate performance of
layer’ above the layers of services, but is a parallel
business processes that constitute the service (e.g., to
management process that exists as part of every service.
maintain quality of service to satisfy SLAs), and ii) strategic
management capability responsible for instigating any When an enterprise endeavours to create services out of
change necessary for the long term survival of the SE. services – some being sourced externally and some
internally – it essentially creates VOs by relying on some
Service Owner Service (loosely- or tightly associated) network of providers. As a
User Organisation User
Entity of Service Entity consequence, the methodologies for Collaborative Networks
and VOs [31,70,71] apply to the case of creating and
maintaining a SOEA of the business.
1’ Project to
Change A. Alignment of Services with the Business Strategy
Service Service definition (arrow 2 in Fig.4) must include the
definition of the service’s business model (a vision,
answering how the service will produce value). The
business model will guide the more detailed definition of
v’ 1 1’ the service, answer many questions (see below), and can be
used to develop the principles that guide the solution:
1 Service Service
Entity A Entity B • List stakeholders and their products & services
• Why is change necessary and what is to change?
• What is the value proposition of the planned service (for
the listed stakeholders)?
v • Will there be any change in the relationship between
stakeholders as a result of the proposed change?
• Will there be any change in terms of the financial /
economic / competitive position of stakeholders?
Fig. 5. Two ways to sustain a SE (viable service models) • Who (what entities) should be involved in the
implementation of the vision?
Not every SE needs to be viable on its own, provided all of • When and where should the implementation of the
its life cycle processes are taken care of. E.g., arrow loop v′ service happen (timing) and why?
of SE ‘A’ in Fig.5 illustrate a service owner (a company • How do existing technology and technology trends
providing the service and owning the SE) being responsible compare? How mature is present technology? Is the
for making strategic decisions about the SE’s change. vision feasible? (Strategic programs may start before
technology matures, but use a staged approach.)

97
• Financial aspect: Does the service provision’s financial systems that comply, and define processes that manage and
model change? Are investment needs understood? guarantee these in service level agreements’.
• Do product / service / market related opportunities or
Legal and compliance principles: the solution must be
issues exist (e.g. quality, source, legal, stability …)?
proven to comply with relevant standards and legal policies
• What are the risks that can derail the implementation of for all jurisdictions from where the service would be
the vision and how to address them?) provided and where the service will be consumed.
• Resources and capabilities of the CCBS (see Fig. 4)
influencing the vision’s feasibility (existing / missing / Such definition of strategic intent can also be utilized to
envisioned human-, logistics-, IT resources/capabilities). derive non-functional requirements. If the flexibility and
composability of services is important, then the CCBS may
B. Services and Business Strategy Interdependencies require that services be designed using advanced design
This model shows that to create a composite service, the techniques (e.g., axiomatic design [72]), but the CCBS must
CCBS must define the Identity and the Business Concept of have the capability to define such architecture principles!
the business SE, and the tasks of that entity (high level
requirements). The Business Concept includes the vision, The CCBS can then create a Project, with a mandate to
strategic goals the service must satisfy, key performance cover the requirements specification, architectural and
indicators of the service, and the principles and policies that detailed design, and building of the new service. The CCBS
guide the Solution Architect to ensure that the solution can define the project’s mandate and scope, and set up the
satisfies the business strategy of the CCBS. All of these are management of the project (arrow 2’ in Fig.4), while project
derived as a specialization and concrete representation of management, as it operates, can design the rest of the
the business concept of the CCBS, including principles that project (arrow 3’ in Fig.4). If there are multiple such
must be satisfied, such as legal and compliance. As part of projects, the CCBS may create a strategic program to
the process (arrow 2 in Fig.4), the CCBS would normally coordinate these (not shown in Fig.4, for clarity).
perform a number of strategic analyses. Accordingly the Project will cover the requisite life cycle
processes of the composite service (arrow 3 in Fig.4).
We illustrate (with a representative list) how principles
can guide services design. We use the example of an ERP
vendor intending to create ERP cloud services. There exist Composite Service
generic principles (important and available in textbooks and
standards, guidelines, laws, professional literature), we need
specific principles that help the architect find and select a Project to create Project to renew
Composite Business Service Composite Business Servic
solution that fits the business strategy / intent.
Technology principle: the ERP vendor's solution
architect must make choices that are consistent with the CCBS
vendor's business goal and intent: e.g., 'use non-proprietary
PaaS to create a cloud offering' – maybe so that end users
are not locked in and therefore are happy to move to this Component Services (SaaS, PaaS, IaaS)
vendor's cloud, or the opposite: 'develop proprietary
platform, with performance, functionality and security or
other benefits, even at the expense of lock-in, ensuring that Project(s) to create
the attractiveness of the platform overrides lock-in fears'. Service(s)

Human Resource principle: the shift in responsibilities

when the ERP system moves to the cloud, results in a
change in the required knowledge and skills in consulting Service Provider(s)
companies and end users. Thus, 'the solution must be viable
and attractive for the new roles and associated skills /
Fig. 6. Synchronisation problems between stages of service evolution
knowledge, for end users and consulting companies'. (version releases). Horizontal axis shows time with life cycle activities
Quality principle: introducing an ERP in the cloud instantiated; vertical axis shows life cycle processes of involved entities.
service must, for all ERP functionality, deliver the same or
C. Complexity management.
better quality of delivery and user experience compared to
in-house ERP. The ERP vendor's solution architect must Figure 6 presents a combined view of the life cycle
prove that the proposed solution satisfies this principle. process instances projected on a time dimension. This model
stresses the fact that service combination has an important
Systemic principles: Regarding availability, reliability, temporal aspect: the design and projected life of a service
maintainability, scalability, etc. ( ‘ilities’). ‘The ERP vendor not only depends on the services it may combine, but
must decide the extent to satisfy these properties, build crucially it depends on the synchronization of the life stages
of underlying services. Thus, each service has its own life

98
history, consisting of sequences of events that are ‘macro- [2] Briscoe, G., De Wilde, P. “Digital Ecosystems: Evolving service-
processes’ (for example ‘operation’ includes a set of oriented architectures”. in Conference on Bio Inspired Models of
Network, Information and Computing Systems. IEEE Press, 2006.
service- and operational management processes, but at the
[3] Bishop, J. “Increasing participation in online communities: A
same time there may exist an active ‘continuous framework for human-computer interaction”. Computers in Human
improvement (evolution)’ process, and in parallel a ‘major Behavior (Elsevier Science Publishers) 2007, vol23(4), pp1881–1893.
transformation’ may also be performed). [4] Nachira, F., Nicolai, A., Dini, P., Le Louarn, M., Leon, L.R. Digital
Business Ecosystems http://www.digital-ecosystems.org/book/de-
To manage the life history of a composite service, there book 2007.html. 2007
is a minimum knowledge and trust needed of projected life [5] Haki, M. K., Forte, M. W. Service Oriented Enterprise Architecture
histories of the component services. Without coordinating Framework, Proceedings 6th World Congress on Services, Miami
(US), 2010, pp. 391 – 398
these dependencies and complex relationships among
[6] Jarvinen, P. H., “Research Questions Guiding Selection of an
version releases of combined services (shown as continuous Appropriate Research Method”. Proceedings European Conference
arrows in Fig.6), the composite service’s integrity is on Information Systems, paper 26, 2000.
jeopardised. It is only through mandated architectural design [7] Mentz, J, Van der Merwe, Alta, & Kotze, Paula. “A Comparison of
principles that this complexity can be reduced to Practitioner and Researcher Definitions of Enterprise Architecture
manageable levels (e.g., by requiring that service versions using an Interpretation Method”. In Advances in Enterprise ISII, C.
Møller & S. Chaudhry (Eds.), CRC Press, 2012, p. 11-26
be available for set amounts of time, and at least one or
[8] Gartner Research. IT Glossary. 2012. http://www.gartner.com/
more previous versions be maintained for a set period). technology/it-glossary/enterprise-architecture.jsp.
The VE / VO / Collaborative Networked Organisations [9] Pava, C., Managing New Office Technology, An Organisational
Strategy. New York: Free Press. 1983.
research community has developed an extensive set of
[10] McGregor, D., The Human Side of Enterprise. New York: McGraw-
methodological tools and techniques that can be used for the Hill. 1960.
associated preparedness building, network building and [11] Markus, M.L., Power, politics, and MIS implementation.
opportunity utilisation [70]. They were mostly used in the Communications of the ACM, 1983, vol. 26, p. 430-444.
manufacturing industry for creating collaboratively offered [12] Keen, P.G.W. and M. Scott Morton, Decision Support Systems: An
virtual service organisations [33, 73], but the principles are Organisational Perspective. Reading, Mass.: Addison-Wesley. 1978.
the same when applied to the IT community. [13] Iivari, J., A Paradigmatic Analysis of Contemporary Schools of IS
Development. Eur. J. Information Systems, 1991, vol.1(4):249-272.
In case of a composite service depends on several [14] Ross, J.W., Weill, P., Robertson, D. Enterprise architecture as
essential services, network creation and preparedness strategy: creating a foundation for business execution. Harvard
building is essential (see DBE management in Section IV). Business School Press, 2006.
Effectively, the DBE is yet another entity, composed of a [15] The American Heritage Dictionary of the English Language. 5th Ed.:
Houghton Mifflin Harcourt. 2011.
network of providers and would typically contain one or
[16] ISO/IEC. ISO/IEC 42010:2007: Recommended Practice for
more network brokers (not shown in Fig.6 for brevity). Architecture Description of Software-Intensive Systems, 2007.
[17] ISO/IEC. Annex A: GERAM, ISO/IS 15704:2000/Amd1:2005:
VI. FINAL CONSIDERATIONS AND FURTHER WORK Industrial automation systems - Requirements for enterprise-reference
Notwithstanding setbacks typical to all developing architectures and methodologies, 2005.
approaches, SOA has matured and gradually evolved into [18] Williams, T.J., “The Purdue Enterprise Reference Architecture”. In
Computers in Industry, 1994. vol. 24(2-3): p. 141-158.
SOEA. However, in the context of disrupting changes
[19] CIMOSA Association, CIMOSA - Open System Architecture for
brought about by emerging technologies and paradigms CIM,. Technical Baseline, ver. 3.2. Private Publication. 1996.
such as DBEs, SOEA needs to evolve further. This paper [20] Doumeingts, G., B. Vallespir, and D. Chen, GRAI Grid Decisional
argued that (and tried to exemplify how) EA, through its Modelling, in Handbook on Architectures of Information Systems, P.
approach and artefacts, is an essential enabler of this Bernus, K. Mertins, and G. Schmidt (Eds). , Springer Verlag:
evolution. Thus, EA’s rich repository of viewpoints Heidelberg. 1998, p. 313-339.
(including a pervasive life cycle aspect and essential life [21] Zachman, J.A., A Framework for Information Systems Architecture.
IBM Systems Journal, 1987, vol. 26(3), p. 276-292
history representation) able to reflect all stakeholders, its
[22] The Open Group, The Open Group Architecture Framework,
capacity to represent the human aspect, deal with (TOGAF 8.1.1 - 'The Book') v8.1.1. 2006.
management vs. product and identify the relations between [23] DoD Architecture Framework Version 2.02. US Department of
entities along their entire lives can significantly assist the Defense,2010
SOEA endeavour in coping with these new challenges. [24] US Federal CIO Council. Federal Enterprise Architecture Framework
.http://www.itpolicy.gsa.gov/mke/archplus/fedarch1.pdf., 2006.
ACKNOWLEDGMENT [25] Scheer, A.-W., “ARIS - House of Business Engineering”. In
Handbook of Life Cycle Engineering - concepts, models and
This work has been partially supported by CNPq – The technologies, A. Molina, A. Kusiak, and J. Sanchez, (Eds). Kluwer
Brazilian Council for Research and Scientific Development. Publishers, 1998.
[26] Noran, O. A Mapping of Individual Architecture Frameworks (RAI,
REFERENCES PERA, C4ISR, CIMOSA, Zachman, ARIS) on GERAM. Handbook
[1] F.J. Mata, W.L. Fuerst, and J.B. Barney, “Information technology and on Enterprise Architecture. Berlin : Springer, 2003, pp.65-210.
sustained competitive advantage: a resource-based analysis,” MIS [27] Saha, P., A Synergistic Assessment of the Federal Enterprise
Quarterly, vol. 19, Dec. 1995, p. 487-505. Architecture Framework against GERAM (ISO15704:2000), in

99
 Enterprise Systems Architecture in Practice, P. Saha, (Ed.), 2007, [49] Noran, O., Bernus, P. “Service oriented architecture vs. enterprise
IDEA Group: Hershey, USA. Pp.1-17. architecture: competition or synergy?”, LNCS 5333, R. Meersman, Z.
[28] Saha, P., Analyzing the Open Group Architecture Framework Tari, and P. Herrero (Eds.) 2008, Berlin :Springer. pp304-312
(TOGAF) from the GERAM perspective, in The Open Group [50] Erl, T. Next Generation SOA: A Real-World Guide to Modern
Architecture Forum, TOGAF White Papers. 2004, www.opengroup. Service-Oriented Computing, Prentice Hall. 2014.
org/architecture/wp. [51] Knippel, R. Service Oriented Enterprise Architecture. Master of IT
[29] Noran, O., A Meta-methodology for Collaborative Networked Thesis, University of Copenhagen, 2005.
Organisations: Creating Directly Applicable Methods for Enterprise [52] Ayed, A, Rosemann, M.; Fielt, E., Korthaus, A. “Enterprise
Engineering Projects. Saarbrücken: VDM Verlag Dr. Müller. 2008 Architecture And The Integration Of Service-Oriented Architecture”.
[30] Bernus, P., Noran, O., Molina, A. “Enterprise Architecture: Twenty PACIS 2011 Proceedings. Paper 16. 2011
Years of the GERAM Framework”. in Annual Reviews in Control, [53] Cheliah, P. R., Winterberg, T., Trops B., Normann, H., Maier, B.,
39: 83-93. 2015. Utschig-Utschig, C, Erl T. "Next Generation SOA - A Real-World
[31] Afsarmanesh, H., Camarinha, M. Processes and foundations for Guide to Modern Service-OrientedComputing. Prentice-Hall, 2014.
virtual organizations. U.S.A.: Kluwer Academic Publishers. 2004 [54] Gu, Qing, Lago, P. On Service-Oriented Architectural Concerns and
[32] Karvonen, I. et al (Eds) Global Engineering and Manufacturing in Viewpoints, Proceedings of the European Conference on Software
Enterprise Networks GLOBEMEN. VTT Symposium, 2003, vol.224. Architecture, Cambridge, 2009, pp. 289-292
Helsinki : VTT Technical Research Centre of Finland [55] Luthria, H., Rabhi, F. A.. “Service-Oriented Architectures: Myth or
[33] Vesterager, J., Bernus, P., Larsen, L.B., Pedersen, J.D., Tølle, M. Use Reality?” IEEE Software, 2012, Vol 12, pp. 46-52
of GERAM as Basis for a Virtual Enterprise Framework Model. In [56] Lewis, G. A.; Smith, D. B.; Kontogiannis, K. A research agenda for
Mo, J., Nemes, L. (Eds) Global Engineering, Manufacturing and service-oriented architecture (SOA): Maintenance and Evolution of
Enterprise Net- works (DIISM2000) Kluwer. 2000, pp75-82 Service-Oriented Systems, CMU/SEI-2010-TN-003, 2010.
[34] Noran, O. Achieving a Sustainable Interoperability of Standards. [57] Oracle. Right from the Start: SOA Lifecycle Governance,
Annual Reviews in Control. 2012, vol. 36(2), pp. 327-337 http://www.oracle.com/us/products/middleware/soa/soa-lifecycle-
[35] Noran, O., “Engineering the Sustainable Business: An Enterprise governance-wp- 1971496.pdf. 2012
Architecture Approach”. In Coherency Management: Architecting the [58] Assmann, M., Engels, G. “Transition to Service-Oriented Enterprise
Enterprise for Alignment, Agility, and Assurance, G. Doucet, J. Architecture” in R. Morrison, D. Balasubramaniam, and K. Falkner
Gotze, and P. Saha, Ed. International EA Institute. 2009, pp. 179-210 (Eds.): ECSA 2008, LNCS 5292, 2008, pp.346–349
[36] Noran, O., Bernus, P. Effective Disaster Management: An [59] Grigoriu, A. SOA, BPM, EA, and SOEA. http://www.bptrends
interoperability Perspective. LNCS. 7046, 2011, pp.112-121. .com/publicationfiles/12-07-ART_Service_Oriented_Enterprise_
[37] Noran, O., Panetto, H. Modelling a Sustainable Cooperative Architecture-Grigoriu-final-Use.pdf, 2007.
Healthcare: An Interoperability-driven Approach. LNCS. 8186, 2013, [60] OASIS. A Methodology for Service Architectures https://www.oasis-
pp. 238-249. open.org/committees/download.php/15071. 2005
[38] Franco dos Reis Alves, D., Campos, R., Bernardi de Souza, F. [61] Souza, A. P.; Rabelo, R. J. “A Dynamic Services Discovery Model
“GERAM: Building Sustainable Enterprises”. 6th IFAC Conference for better Leveraging BPM and SOA Integration”. In Int. J. of
on Management and Control of Production and Logistics (MCPL13), Information Systems in the Service Sector, 2015, vol. 7, pp. 1-21
2013, Fortaleza, Brazil.
[62] Picard, W., Paszkiewicz, Z., Strykowski, S., Wojciechowski, R.,
[39] Vaniya, N., Bernus, P., Noran, O. “Examining Potentials of Building “Application of the SOA at the Inter-Organizational Level”, In
M&A Preparedness”. in Proc. 15th Int. Conf. Enterprise Information Studies in Computational Intelligence / Advanced SOA Tools and
Systems. 2013, Vol 3. Setubal : SCITEPRESS. Pp.201-212 Applications, 2014, vol. 499, pp. 125-201
[40] Papazoglou, M. P. Web Services & SOA, Principles and Technology. [63] IBM. http://www.ibm.com/developerworks/library/ws-soa-eda-esb/
Pearson. 2012.
[64] Kaplan, R. S. Conceptual Foundations of the Balanced Scorecard,
[41] Krafzig, D., Banke, K., Slama, D.: Enterprise SOA. Service-oriented Harvard Business School, http://www.hbs.edu/faculty/ Publication
architecture best practices. Prentice-Hall, Upper Saddle River. 2006. Files/10-074.pdf. 2010
[42] Erl, T.: Service-oriented architecture. Concepts, technology, and [65] Rabelo, R J., Bernus, P. “A Holistic Model of Building Innovation
design. Prentice-Hall, Upper Saddle River (6th print) 2006. Ecosystems”. In 15th IFAC Symposium on Information Control in
[43] Schönherr, M. Connecting EAI-Domains via SOA - Central vs. Manufacturing. Ottawa, Canada, 2015, pp. 1-8.
Distributed Approaches to Establish Flexible Architectures. In P. [66] Rodriguez, S, Gaud, N., Hillaire, V., Galland, S., Koukam, A. An
Bernus, et al. (Eds.), Knowledge Sharing in the Integrated Enterprise. Analysis and Design Concept for Self organization in Holonic Multi-
Toronto / Canada: Kluwer Academic Publishers, 2004, pp. 111-113 agent systems. In Brueckner, S., Hassas, S., Jelasity, M, Yaminds, D.
[44] Erickson, J., Siau, K. Web Services, Service Oriented Computing and (Eds.) 4th ESOA 2006, Berlin: Springer. 2007, pp15-27.
Service Oriented Architecture: Separating Hype from Reality. Journal [67] Beer, S. The Viable System Model: Its Provenance, Development,
of Database management, vol. 19(3), 42-54, 2008. Methodology and Pathology. The Journal of the Operational Research
[45] Viering, G., Legner, C., and Ahlemann, F. “The (Lacking) Business Society. 1984, vol. 35(1), pp.7-25
Perspective on Soa–Critical Themes in SOA Research”. In [68] ISO/IEC 20000-1:2011 Service management system requirements.
Proceedings of Wirtschaftsinformatik, 2009, pp. 45-54.
[69] ITIL V3. www.axelos.com/best-practice-solutions/itil/what-is-itil
[46] Becker, A., Buxmann, P., and Widjaja, T. “Value Potential and
Challenges of Service-Oriented Architectures - a User and Vendor [70] Camarinha-Matos, L., et al., “Collaborative networked organizations
Perspective”. In Proceedings of the 17th European Conference on – Concepts and practice in manufacturing enterprises”. In Computers
Information Systems (ECIS 2009). (2009) and Industrial Engineering, 2009, vol. 57(1), pp. 46-60.
[71] Molina, A., Panetto, H., Chen, D., Whitman, L., Chapurlat, V.,
[47] Yoon, T., and Carter, P. “Investigating the Antecedents and Benefits
Vernadat, F. “Enterprise integration and networking: challenges and
of SOA Implementation: A Multi-Case Study Approach". Procs of
13th Americas Conference on Information Systems, 2007, pp. 1-11. trends”. In Studies in Informatics and Control. 2007, vol. 16 (4), pp.
353-368.
[48] Hirschheim, R., Welke, R., and Schwarz, “A. Service-Oriented
[72] Suh, N.P. Complexity: Theory and Applications. Oxford U. Pr. 2005.
Architecture: Myths, Realities,and a Maturity Model”. In MIS
Quarterly Executive (9:1), 2010, pp. 37 -48. [73] Vesterager, J., Bernus, P., Pedersen, J. D., & Tølle, M. “The what and
why of a virtual enterprise reference architecture”. In E-work and E-
commerce. Novel solutions and practices for a global networked
economy. Amsterdam: IOS Press, 2001, pp. 846–852.

100