Towards the Next Generation Service Oriented ...

Download PDF
3 downloads 22408 Views 580KB Size Report
Comment
software architecture solution' that sprang from the need to move integration to a ..... enabling distributed business processes and better interoperability among ...
Copyright. Citation Information: Rabelo, R., Noran, O., Bernus, P. (2015) Towards the Next Generation Service Oriented Enterprise Architecture, 7th Workshop on Service Oriented Enterprise Architecture for Enterprise Engineering (SOEA4EE) , Adelaide, Australia

Towards the Next Generation Service Oriented Enterprise Architecture Ricardo J. Rabelo

Ovidiu Noran

Peter Bernus

Dept. of Automation and Systems Engineering, Federal Univ. of Santa Catarina, Florianopolis (SC), Brazil [email protected]

IIIS CEARM & School of ICT Griffith University Brisbane, Australia [email protected]

IIIS CEARM & School of ICT Griffith University Brisbane, Australia [email protected]

Abstract—Emerging business models such as digital ecosystems involving collaborative innovation, participatory decision-making and flexible organizational structures are set to significantly affect inter- and intra-enterprise structure and functionality. This has seen the appearance of increasingly complex Service-oriented Architecture (SOA) scenarios featuring various partnership levels, increased resilience and adaptation to tougher compliance regulations, more seamless integration with process layers, etc. This complexity has brought about the need to broaden the SOA paradigm, so as to include business, infrastructure and multi-layering, resulting in an evolved concept known as Service-Oriented Enterprise Architecture (SOEA). This paper aims to describe the way new business and technology paradigms continue to affect the new SOEA approach and how the inherently holistic Enterprise Architecture (EA) frameworks and related practices can support the emerging complex dynamic, multi-layered and value-chained service-based scenario.

result was the progression towards a broader concept called Service-oriented Enterprise Architecture (SOEA) [5].

Keywords: Enterprise Architecture; Service-Oriented Architecture; Service-Oriented Enterprise Architecture

Section II provides an introduction to EA and describes and justifies the framework selected for the research. Section III contains a presentation of SOA-related concepts and their transition to a SOEA. Section IV depicts new SOEA aspects brought up and challenges related to the role of the emerging Digital Business Ecosystem. Section V exemplifies how EA can assist to tackle current SOEA questions, by focusing on a particular area (service life cycle). Section VI presents conclusions and further work.

I. INTRODUCTION The need for enterprises to survive, adapt and successfully compete in the context of significant business model changes brought about by the advent of new Internet technologies such as Cloud Computing and the Internet of Things are increasingly shifting the emphasis on the management, rather than ownership of ICT resources [1]. Emerging business models such as digital ecosystems [2-4] involving collaborative innovation, participatory decisionmaking and flexible organizational structures are to change inter- and intra-enterprise structures and functionality. All these factors have contributed to the appearance of increasingly complex Service-oriented Architecture (SOA) scenarios featuring several levels of partnerships, increased resilience and adaptation to tougher compliance regulations, more seamless integration with process layers, etc. With this complexity has come the realization of the need to broaden the service-oriented paradigm beyond the initial softwarecentric extent, to include business and infrastructure and multi-layering, so that services of different layers can be interconnected in order to provide higher level services. The

This paper employs a conceptual analytical research approach [6] to describe how new business and technology paradigms continue to affect the new SOEA approach. To achieve this we must integrate what is known as the ‘EA body of knowledge’ with the knowledge base of ‘SOA as a software architecture solution’ that sprang from the need to move integration to a new level of abstraction. Methodologically speaking, we had to create a mapping, using conceptual analysis and associated logical arguments, that demonstrate how an inherently holistic Enterprise Architecture (EA) framework and related practices apply to the SOA problem domain and thereby support the emerging complex dynamic, multi-layered and value-chained servicebased scenario.

II. ENTERPRISE ARCHITECTURE: ENDEAVOUR AND ARTEFACTS The EA domain is still in development and there is no widely accepted definition [7]. While often EA is believed to be limited to the Information Technology aspect, EA is in fact a holistic change management paradigm that bridges management and engineering best-practice, providing the “[…] key requirements, principles and models that describe the enterprise's future state. […] EA comprises people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment” [8]. This EA definition reinforces the view of enterprises as socio-technical systems [9] with voluntaristic people [10] in a complex organizational, political and behavioural context [11-13]. Thus, EA should be capable of

providing a supporting environment integrating all necessary aspects in a life cycle-based set of models [14] ensuring the consistency and sustainability of complex systems-of-systems (such as enterprises) transformation projects. According to [15], a framework is “[…] a set of assumptions, concepts, values, and practices that constitutes a way of viewing reality.” Architectural frameworks typically provide tools and methodologies to manage scale and complexity so as to abstract from the typically high level of detail and thus bring enterprise design tasks into focus and produce usable architectural descriptions [16]. If we accept that, in view of its proposed definition above, EA represents a holistic ontology of change, it follows that an EA Framework (EAF) is an essential enabler towards making sense of the complex universe of discourse describing EA-specific endeavours such as SOEA. Thus, organizations may use EAFs in order to construct their own, shared meanings of change-related SOEA concepts by ‘weaving’ EA artefacts into the fabric of their own preexisting, path-dependent concepts of SOEA-related change. In exploring the ways EA artefacts can assist SOEA we have chosen to use a generic high-level, ‘meta’-EAF called the Generalized Enterprise Reference Architecture and Methodology (GERAM), which is part of ISO15704:2005 [17]. GERAM represents the abstraction of several ‘historical’ AFs such as PERA [18], CIMOSA [19] and GRAI [20]. Its capability to integrate and subsume mainstream AFs’ (Zachman [21], TOGAF [22], DoDAF [23], FEAF [24], ARIS [25], etc.) artefacts that may be required for specific EA endeavours has also been documented [26-28]. Thus, GERAM provides a structured repository (‘shopping list’) out of which relevant viewpoints and artefacts can be selected based on the needs of concrete (SO)EA scenarios and be connected according to a set of basic rules, to build specific methodologies (e.g. [29]). The wide applicability of GERAM as an overarching, non-prescriptive (‘light-weight’ [30]) AF has allowed its involvement in conjunction with systems thinking and system-of-systems paradigms to address several major challenges faced by society today. For example, GERAM has been used to create Virtual Enterprises (VEs) and Virtual Organizations – VOs [31]) for bidding for projects [32] and for after sales services [33]. In the standards community, GERAM has been proposed as an essential tool in discovering gaps and overlaps in the areas covered by various standards and building an intelligent repository underlying an expert system enabling improved and sustainable interoperability of standards [34]. Other examples are the use of GERAM to support discovery of the areas and level of environmental management integration [35] and in emergency management, to improve the effectiveness and resilience of the command and control and emergency response teams [36]. GERAM and systems thinking principles have also been applied in lifecyclecentric analysis and design of healthcare interoperability and

collaboration [37], in sustainability [38] and building organizational preparedness for mergers & acquisitions [39]. In section V we shall use selected viewpoints belonging to the modelling framework of the main component of GERAM, namely GERA (Generalized Enterprise Reference Architecture, see Fig.1) in order to illustrate how EA artefacts can assist the SOEA endeavour in the creation and management of services by exploring the interplay of the various stakeholders (as defined in ISO42010 [16]). Importantly, the modelling constructs derived from the GERA framework allow an essential aspect, namely life cycle, to permeate the entire SOEA effort and to express the often overlooked life history concept (see section V). Views Partial level of GERA Modelling Framework Identification Identification

Concept

Concept

Requirements Requirements Prelim. design Prelim. design Design Design Detailed design Detailed design Implementation Implementation Operation Operation Decommission Decommission

LC phases

Generic Partial Particular

Instantiation

Formalism used in the Business Model P

M

Management Management and Control and Control Cust Service Product or Service Software Software Hardware Hardware Simplify Resource Resource Organisation Organisation Information Information Function Function

Machine HumanMachine Human

Id C R PD DD I Op D

The Modelling Framework of GERA

Fig. 1. GERA modelling framework showing a selection of viewpoints orthogonal to the life cycle dimension and the creation of the modelling construct used in section V.

III. SERVICE-ORIENTED ARCHITECTURE AND SERVICEORIENTED ENTERPRISE ARCHITECTURE An accepted view of Service Oriented Architecture (SOA) appears to be that of an architectural style espousing the concepts of services (packaged functions) and of consumer(s), as a foundation to construct the functionality of an enterprise [40-42]. Services are provided and consumed based on contracts, offering enhanced manageability and can be provided using (mostly) Web Service technologies that may be outsourced or even be accessed on-demand, e.g. ‘Software as a Service (SaaS)’. The SOA concept originates in the modular, object-oriented and component-based software development paradigms. However, the lack of adequate supporting and realization infrastructure has in the past hindered its adoption [43]. After several standardisation efforts and the typical phases of vendor hype and unrealistic expectations, and recovery from the disillusionment phase, SOA technology has reached the plateau of productivity, although, as also shown in this paper, the concept of SOA is still evolving [44]. The expected SOA benefits have been variously classified in the relevant literature as technical, economic and strategic [45], IT, process and strategy [46], or business

and IT [47]. Several stages have also been distinguished in achieving SOA maturity [48], and the relation between SOA and EA have also been quite often explored, with varying degrees of success (e.g. [48-51]). It must be also noted, however, that many SOA initiatives have failed or achieved results below what was expected and advocated by vendors [40,50,53-56]. Main reasons have been as follows: i) Business: insufficient vision about how SOA can support business agility; lack of proper business models; lack of a SOA roadmap; lack of vision about the benefits to achieve with SOA and related Return on Investment. ii) Technical: complex integration and security, services granularity, vendors locked-in software components and technologies; low training level of people involved; inadequate approaches for integrating legacy systems; services having to respond to different QoS and SLAs requirements; iii) Organizational: business processes not properly understood and services not duly identified; lack of use of adequate SOA development methodologies; lack of proper governance policies for considering SOA and services life cycles. iv) Project management: inadequate management regarding SOA complexity, leading to difficulty to measure and evaluate development progress; high costs and delays. v) Cultural: low reuse practices; unorganized catalogues; proliferation of services; weak integration between the business/process and IT levels. Attempts to tackle such shortcomings have led to the maturing and increased complexity of SOA efforts, resulting in the expansion of the paradigm to include business, applications & data, platform, and infrastructure in a multilayered manner. This transition to a wider SOEA [50, 58] has been interpreted in various ways; thus, some authors (e.g. [59]) used ‘SOEA’ to describe an EA implemented in a SOA style that, once implemented, becomes a competitive asset enabling modularity, reusability, agility and improved Quality of Service (QoS). Accordingly, SOEA has broadened the scope of SOA systems: some authors see such systems being formed as a composition of service layers, i.e., Baas (Business-as-aService), SaaS (Software-as-a-Service), PaaS (Platform-as-aService) and IaaS (Infrastructure-as-a-Service) [40]. The OASIS framework [60] is one of the first to express this wider perspective, seeing SOA as an architectural model influenced not only by IT, but also by the business dimension, and by what they called ‘external dimension’ – in other words, something that cannot be treated as a computing asset disconnected from companies’ businesses and strategies, from external institutions (e.g. providers) and supporting artefacts (e.g. legal regulations). It is relevant that EA is positioned in a central position of the OASIS framework, binding these three dimensions (Fig.2). However, when considering the more recent movements within the so-called service oriented economy and business ecosystems, even this framework seems incomplete. Thus, a

‘next generation’ SOEA requires including additional viewpoints so as to reach its full potential. ICT Partnerships Deployment & & vendors Service Provision Implementation dimension models dimension & standards dimension Infrastructure & hardware dimension

SOA & Services life cycle dimension

Services typology dimension

EA life cycle dimension Governance dimension Financial, Revenues, Regulatory Compliance dimension

SOEA endeavor

Services Management Human Services management dimension dimension dimension

SOA Scope (OASIS, 2005) Performance Indicators dimension

Fig. 2. Important viewpoints of a SOEA endeavour

Thus, in Fig.2 the authors depicted, in addition to the OASIS framework, an extended (although perhaps not complete) list of viewpoints proposed to be involved in a SOEA endeavour. As can be seen (and detailed in Section IV), several dimensions have to be considered but also harmonized – not only targeting the SOEA execution, but its entire life cycle. This means different and complementary levels of management, including related governance. Beside this, currently the human dimension of services appears to be under-represented, even though humans are a crucial element to support the execution of diverse services both in SOEA projects and in the services created by them. The entire SOEA environment should be managed as well in the context of its own life cycle. For example, the OASIS framework (see three dimensions in Fig.2) depicts an ecosystem whose life cycle should be appropriately dealt with in order to sustain the SOEA effort’s own lifecycle. Implementing SOA requires a deep change in the way organizations designed and managed IT so as to support their business activities. Initially dedicated to the development of services tailor-designed and bound to specific enterprise business applications and very much focused on the IT dimension, SOA projects have gradually evolved to wider sharing environments. In these environments groups of services could support various enterprise applications, but this design was still constrained by static binding and local service-catalogues, software development practices and interoperability policies [61,62]. Requirements for business process agility and business level partnerships made companies rethink the strategic role IT can play in enterprise competitiveness and sustainability. The increasing availability of IT services worldwide allowed companies to extend the scope of their system architecture and include services provided by digital ecosystems. In support, new IT-level processes, tools and systems emerged, enabling distributed business processes and better interoperability among heterogeneous systems/ devices, leading to concepts as inter-organizational Enterprise Service Bus (ESB) and Event Driven Architecture (EDA) [63].

IV. A CONTEMPORARY SOEA SCENARIO The emerging concept of Digital Business Ecosystem (DBE) [2-4] promotes an open, pervasive, collaborative and networked business environment of organizations and professionals that interact and join efforts to form VOs to be able to add value throughout the life cycles of software- and other services. From the business standpoint, a SOEA ‘solution’ (from the viewpoint of a specific enterprise) is seen as a very flexible business process creation effort offering better business agility. From the IT viewpoint the ‘solution’ is the result of an ‘on-the-fly’ composition of distributed services from providers that best match the functional and non-functional business requirements [61,62]. However, to achieve this, providers may need to be combined into networks to ensure they abide by business, legal and other compliance requirements [55]. Thus, DBE represents a new challenge for the current SOEA concept. A SOEA solution typically involves a variety of machine (software and hardware) and human service entities and respective providers, as generically illustrated in Fig.3. Note: in current literature there exists a diversity of SOEA ‘stacks’ and terminology, featuring various levels of abstraction, however, most typically overlook the non-technological aspects (e.g. [53, 57]).

At the SOEA Solution level, customers can own or have access to as many SOEA solutions as required, depending on chosen deployment and access modes. This may include different companies as users (e.g., supply chain members can share the same service in collaborative production planning). Providers may be involved in more than one SOEA solution and simultaneously serve several customers, within different business models, throughout the diverse stages and phases of the given SOEA solution’s life. At the Client level, the SOEA solution’s services can interact with humans and other systems (whether servicebased or traditional software packages e.g. corporate Enterprise Resource Planning (ERP) systems). Human clients (end users) can be involved in various process activities, accessing those using different stationary and mobile devices (Device level). At the Interface level (be it graphical or merely textual), systems can provide adaptive or pre-defined interfaces per type of device. These interfaces may themselves also be created as services. The Process level is the layer where business processes are modelled, executed and managed. Thanks to the integrative vision with SOA technologies, Business Process Management systems have been gradually adopted by 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.

Fig. 3. SOEA Stack enriched with DBE

A SOEA solution can be deployed at and accessed from both customers’ and providers’ sites. However, these stakeholders typically have different perspectives in terms of required levels of management, QoS and life cycle.

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’ registered services, described (e.g., via semantics agreements or mappings) and exposed as public for external consumption. Services can be entirely decoupled, but some internal partnerships among DBE members may exist so as to provide ‘micro solutions’ for frequent customer needs. This level assumes that services are sufficiently prepared to interoperate in a composition. For example, services should

use standard interfaces and protocols, be somehow certified in terms of development quality and trustworthiness, etc. This wrapping must also consider the internal architecture of services so as to decide which level or kind of wrapping can be done: if a given service has been natively developed with a multi-tenancy vision or in the 3-Tier model, its presentation, process and data layers are also decoupled and may be wrapped either separately or by considering this requirement. Depending on the internal implementation model, the service’s components and infrastructure (e.g. its execution container and a database) may also be included. The Services level is the most elementary layer of a DBE. This is a virtualization over all member services, and may include components internally used by the services., This may include services internally registered and not exposed as public (but may be in the future, depending on company strategy). Services can be of many types [40,50], such as application-, processes-, infrastructure-, governance-, security-, integration & interoperability-, shop floor-, realtime-, database-, data mining services, etc. In general terms, these can be categorized as BaaS (Business-as-a-Service), SaaS (Software-as-a-Service), PaaS (Platform-as-a-Service) and IaaS (Infrastructure-as-a-Service) [40]. Note that this level also involves human-executed services, which are essential in real SOEA projects (in various life cycle phases, including operation), but usually under-represented in the literature. The Organization level represents the DBE’s members allowed to provide services to SOEA solutions under various business models. As explained in section II, an organization can be described and modelled in a number of perspectives from the EA point of view. Types of actors include individual software developers, software-houses, professionals, etc., as well as infrastructure providers, e.g. Telecom companies. The sustainability of DBE membership depends on many factors and tends to require diverse supporting management structures (formal / comprehensive governance models, common code of ethics, etc.). The Physical level corresponds to all computing resources and data sources that support the execution and the provision of services along their life cycle. The SOEA stack shown in Fig.3 essentially shows the technological side of SOA. However, the human element of services and the management side of that SOEA scenario are just as important and complex. There are a number of aspects to manage: the DBE, DBE members, SOA solutions as business applications, SOA solutions as VO alliances, the individual software services, human services (e.g. helpdesk, local integrations, ESB configurations, etc.), the DBE’s services inventory (including infrastructure, software/legacy components and versioning), Service Level Agreements, ICT infrastructures, existing partnerships, customer experience, levels and types of governance, and the adopted business-, billing-, taxation- and revenue models.

Management considerations include technical (quality, performance, trustworthiness, security, reliability, etc.) and non-technical (costs, reputation, customer satisfaction, usability, maintainability, etc.) qualities, as well as the respective performance indicators (quantitative and qualitative) for each aspect, possibly organised according to some strategic management best practice models, e.g. [64]. This management in turn has processes to be executed and they are also constrained by a governance model (a metamanagement). The management horizons are: Strategic (decide service portfolios, customers, market, partners, etc.); Tactical (handle given SOEA solutions individually and their services, involved partners, etc.); Operational (monitor at individual services level or group of inter-related services); and Real-time (e.g., observation of infrastructures and QoS, or necessary intervention). Such management activities (of DBE, DBE members, etc.) cannot be limited to the operation phase of the respective entities’ life cycles. As in any collaborative ecosystem, other life cycle phases are just as crucial [65], as each service aspect should be previously prepared (at a required level of preparedness), which takes time. Once prepared, each aspect should be properly made available, i.e. created and launched into the environment, so as to start operating or be ready for use. During the operation stage every entity has its own life cycle, e.g. it can evolve. This evolution can be triggered and carried out autonomously or handled by humans. When seen as a whole, all such evolutions can make the DBE itself evolve, or more drastically, change its basic profile or identity (metamorphosis). New entities come and existing entities may go, so there are repeated (phases of) commissioning & decommissioning. Finally, considering all this intrinsic DBE dynamics, the DBE has to handle its own long-term sustainability. Therefore, a DBE also has a life cycle to be managed, following a governance model (which is a facet of management from the EA point of view). Regarding all the issues above, it happens that the business model vision also needs to be re-evaluated, as SOEA solutions can be dynamically composed, with software and human-provided services being involved in the solution, and having variable roles in the diverse stages and phases of services, of VOs, the SOEA solutions and the DBE itself. The multi-layered and dynamic nature of all relationships among the involved entities and actors should be considered in the simultaneous value chains created. V. THE EA PERSPECTIVE ON NEXT GENERATION SOEA Embarking on the use of SOEA as an architecting principle to achieve better business agility is a strategic enterprise transformation endeavour. As alluded to in Section IV, the change can have extensive effect both on multiple internal levels of the enterprise of interest, and externally. Therefore a systematic coverage of all these complex aspects is of value.

A major aspect of this section is how the life cycle concept espoused by the proposed EA approach permeates the entire service creation and use scenario. This is important, because an architectural solution to a business problem (such as may be created by the extensive use of a service-oriented style of EA) must be sustainable and viable throughout the life of the target enterprise(s), and of other relevant (e.g. DBE) participants. Importantly, according to ISO15704 [17] there are in fact two concepts related to what literature generally calls lifecycle. The first concept is atemporal and represents the life-cycle proper - defined as the set of life cycle process / activity types depicting the enterprise entity in question in a Business Service End User En ty (SBU)

Creator of Composite Business Service (CCBS)

Owner Organisa ons of External Services

Composite Business Service En ty(ies)

Business Ecosystem Broker(s)

decreasing order of abstraction (from the high level definition of the business identity, through the business concept definition, requirements definition and specification, architectural design, detailed design, building and releasing into operation, to the operation of the entity and its decommissioning – see vertical dimension in Fig. 1). The second concept is temporal, describing when the instances of these life-cycle activities are performed (often repeatedly); this is called in ISO15704 a life history dimension. Significantly, there is no predefined sequence between life-cycle activity types; only mutual constraints exist among them (e.g. the architectural solution must be consistent with the business concept).

2

Infrastructure & Pla orm Pla orm Service Providers Service En es

External Service En es (SW & Data)

2’ 1

1’

3’ 3

Project(s) to Create Composite Business Service(s)

Infra‐structure 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 be represented so as to be able to define all necessary actions for a successful definition of a SOEA, we take the viewpoint of a ‘Creator of a Composite Business Service’ and build an illustrative example. Thus, Fig. 4 is an initial representation of the life-cycle relationships among i) this enterprise’s strategic management, ii) the Project(s) it initiates to create a composite business service(s), iii) the (composite) service entity(ies) – SEs - created by these projects, and iv) the strategic business unit (SBU), which from the current point of view is identified in Fig.4 as the End User Entity of the composite business service. (This SBU may be an internal or external client to this enterprise.) Notationally (and according to ISO15704), arrows may model operational interactions among entities (shown dashed), or represent the fact that the entity at the origin of the arrow performs those life cycle activities at which the arrow points (shown as solid arrows), and can be either lifecycle activities of another entity, or of the entity itself. Figure 4 is a so-called dynamic business model of the typical structure represented in Fig.3 (a ‘reference model’ in ISO15704 terms). It must be noted, however, that Fig.3 only represents the IT performing the service, with the humans

shown being only the end users. In reality, SEs are broader in scope than the layers in Fig.3; e.g., if viewed at the Requirements life cycle phase level (see vertical dimension in Fig.1), service processes include all activities performed by the entity, no matter whether these will be done by humans or by machines (software plus hardware), and the same is true of the management and control processes of the service. If viewed at the architectural design life cycle phase level, the components of the SE include software, hardware and humans involved in the service and in its management and control, but permitting that some service- and servicemanagement activities may be performed by external SEs. This discussion pertains to the operation of the service and of the management of a SE. However, in general, one must give account of all life cycle processes of any entity, meaning to understand (or determine) who or what is responsible for performing these life-cycle processes. In Figure 4, a service is represented as an entity (SE) that, as it operates, supports the operation of some other entity (e.g. the service user). This is shown as arrow 1 in Fig.4. Arrow 1’ shows that the management of the service interacts with the management of the end user, e.g., providing evidence & undertaking corrections regarding

service levels / quality of service. These operational relationships should exist across multiple levels between service users and service providers. A SE may be holonic [66], whereupon all resources (except for an assumed ubiquitous infrastructure) are part of the entity: this includes humans and machines, software and hardware – everything necessary to provide the service and to manage the service (represented in Fig. 4 and subsequent figures as the left- and right hand sides of the ‘chocolate bar’ and its modelling constructs defined in Fig. 1). The opposite can also be true, if the SE is a VO or VE [30]: ad extremum such an entity is virtual, because all of its activities are in fact performed (contributed to the VO’s processes) by external entities, and the VO has no resources of its own. In practice we assume that SEs entities are hybrid (holonic and virtual are the two extremes). A SE, that is to remain viable on its own, must be able to perform all of its own life cycle processes (arrow loop v of SE ‘B’ in Fig.5), with some of these possibly carried out by outside provider entities enlisted by the SE itself. The conditions of viability are [67] that the SE must have: i) operational (including real time, if relevant) & tactical management capability to maintain adequate performance of business processes that constitute the service (e.g., to maintain quality of service to satisfy SLAs), and ii) strategic management capability responsible for instigating any change necessary for the long term survival of the SE. Service User Entity

Owner  Organisation of Service

1’

Project to Change Service

v ’  1

Service User Entity

Service Entity A

1’

1

Service Entity B

v

Fig. 5. Two ways to sustain a SE (viable service models)

Not every SE needs to be viable on its own, provided all of its life cycle processes are taken care of. E.g., arrow loop v of SE ‘A’ in Fig.5 illustrate a service owner (a company providing the service and owning the SE) being responsible for making strategic decisions about the SE’s change.

Note that SE ‘A’ shown in Fig. 5 has only operational management, such as BPM and IT service management [68,69]; strategic change is the responsibility of the Owner Organization. Thus, the SE is only viable due to the owner organization, not in itself. As opposed to this, the SE ‘B’ in Fig.5 has all levels of management (operational, tactical and strategic) covering all of its life cycle processes, and therefore the SE is in itself a viable system. Some management functions of these SEs, e.g., various BPM and IT services management functions, may be repeated across several SEs and could be provided by a shared process management / IT services management SE (based on ISO/IEC20000 [68] / ITIL [69]). For example, the management of each service should (potentially) be able to design, and from time to time update, the process by which the service function is provided. As an analogy, the vision that business process owners design, analyse, test and release into operation new processes is similar to the transformation that took place when typists were replaced by text editors that all end users could use. In other words, BPM and IT service management capability (including the associated skills and tools) is part of the management of services. The significance of this is that BPM is not a separate ‘business layer’ above the layers of services, but is a parallel management process that exists as part of every service. When an enterprise endeavours to create services out of services – some being sourced externally and some internally – it essentially creates VOs by relying on some (loosely- or tightly associated) network of providers. As a consequence, the methodologies for Collaborative Networks and VOs [31,70,71] apply to the case of creating and maintaining a SOEA of the business. A. Alignment of Services with the Business Strategy 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 the service, answer many questions (see below), and can be used to develop the principles that guide the solution:  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)?  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?  Who (what entities) should be involved in the implementation of the vision?  When and where should the implementation of the service happen (timing) and why?  How do existing technology and technology trends compare? How mature is present technology? Is the vision feasible? (Strategic programs may start before technology matures, but use a staged approach.)

 Financial aspect: Does the service provision’s financial model change? Are investment needs understood?  Do product / service / market related opportunities or issues exist (e.g. quality, source, legal, stability …)?  What are the risks that can derail the implementation of the vision and how to address them?)  Resources and capabilities of the CCBS (see Fig. 4) influencing the vision’s feasibility (existing / missing / envisioned human-, logistics-, IT resources/capabilities). B. Services and Business Strategy Interdependencies This model shows that to create a composite service, the CCBS must define the Identity and the Business Concept of the business SE, and the tasks of that entity (high level requirements). The Business Concept includes the vision, strategic goals the service must satisfy, key performance indicators of the service, and the principles and policies that guide the Solution Architect to ensure that the solution satisfies the business strategy of the CCBS. All of these are derived as a specialization and concrete representation of the business concept of the CCBS, including principles that must be satisfied, such as legal and compliance. As part of the process (arrow 2 in Fig.4), the CCBS would normally perform a number of strategic analyses. 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 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 solution that fits the business strategy / intent. Technology principle: the ERP vendor's solution architect must make choices that are consistent with the 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 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 the attractiveness of the platform overrides lock-in fears'. 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 companies and end users. Thus, 'the solution must be viable and attractive for the new roles and associated skills / knowledge, for end users and consulting companies'. Quality principle: introducing an ERP in the cloud service must, for all ERP functionality, deliver the same or better quality of delivery and user experience compared to in-house ERP. The ERP vendor's solution architect must prove that the proposed solution satisfies this principle. Systemic principles: Regarding availability, reliability, maintainability, scalability, etc. ( ‘ilities’). ‘The ERP vendor must decide the extent to satisfy these properties, build

systems that comply, and define processes that manage and guarantee these in service level agreements’. Legal and compliance principles: the solution must be proven to comply with relevant standards and legal policies for all jurisdictions from where the service would be provided and where the service will be consumed. Such definition of strategic intent can also be utilized to derive non-functional requirements. If the flexibility and composability of services is important, then the CCBS may require that services be designed using advanced design techniques (e.g., axiomatic design [72]), but the CCBS must have the capability to define such architecture principles! The CCBS can then create a Project, with a mandate to cover the requirements specification, architectural and detailed design, and building of the new service. The CCBS can define the project’s mandate and scope, and set up the management of the project (arrow 2’ in Fig.4), while project management, as it operates, can design the rest of the project (arrow 3’ in Fig.4). If there are multiple such projects, the CCBS may create a strategic program to coordinate these (not shown in Fig.4, for clarity). Accordingly the Project will cover the requisite life cycle processes of the composite service (arrow 3 in Fig.4). Composite Service

Project to create Composite Business Service

Project to renew Composite Business Servic

CCBS

Component Services (SaaS, PaaS, IaaS)

Project(s) to create Service(s)

Service Provider(s)

Fig. 6. Synchronisation problems between stages of service evolution (version releases). Horizontal axis shows time with life cycle activities instantiated; vertical axis shows life cycle processes of involved entities.

C. Complexity management. Figure 6 presents a combined view of the life cycle process instances projected on a time dimension. This model stresses the fact that service combination has an important temporal aspect: the design and projected life of a service not only depends on the services it may combine, but crucially it depends on the synchronization of the life stages of underlying services. Thus, each service has its own life

history, consisting of sequences of events that are ‘macroprocesses’ (for example ‘operation’ includes a set of service- and operational management processes, but at the same time there may exist an active ‘continuous improvement (evolution)’ process, and in parallel a ‘major transformation’ may also be performed). To manage the life history of a composite service, there is a minimum knowledge and trust needed of projected life histories of the component services. Without coordinating these dependencies and complex relationships among version releases of combined services (shown as continuous arrows in Fig.6), the composite service’s integrity is jeopardised. It is only through mandated architectural design principles that this complexity can be reduced to manageable levels (e.g., by requiring that service versions be available for set amounts of time, and at least one or more previous versions be maintained for a set period).

[2]

[3]

[4]

[5]

[6]

[7]

[8]

The VE / VO / Collaborative Networked Organisations research community has developed an extensive set of methodological tools and techniques that can be used for the associated preparedness building, network building and opportunity utilisation [70]. They were mostly used in the manufacturing industry for creating collaboratively offered virtual service organisations [33, 73], but the principles are the same when applied to the IT community.

[9]

In case of a composite service depends on several essential services, network creation and preparedness building is essential (see DBE management in Section IV). Effectively, the DBE is yet another entity, composed of a network of providers and would typically contain one or more network brokers (not shown in Fig.6 for brevity).

[14]

VI. FINAL CONSIDERATIONS AND FURTHER WORK Notwithstanding setbacks typical to all developing approaches, SOA has matured and gradually evolved into SOEA. However, in the context of disrupting changes brought about by emerging technologies and paradigms such as DBEs, SOEA needs to evolve further. This paper argued that (and tried to exemplify how) EA, through its approach and artefacts, is an essential enabler of this evolution. Thus, EA’s rich repository of viewpoints (including a pervasive life cycle aspect and essential life history representation) able to reflect all stakeholders, its capacity to represent the human aspect, deal with management vs. product and identify the relations between entities along their entire lives can significantly assist the SOEA endeavour in coping with these new challenges. ACKNOWLEDGMENT

[10] [11] [12] [13]

[15] [16] [17]

[18] [19] [20]

[21] [22] [23] [24] [25]

This work has been partially supported by CNPq – The Brazilian Council for Research and Scientific Development. REFERENCES [1]

F.J. Mata, W.L. Fuerst, and J.B. Barney, “Information technology and sustained competitive advantage: a resource-based analysis,” MIS Quarterly, vol. 19, Dec. 1995, p. 487-505.

[26]

[27]

Briscoe, G., De Wilde, P. “Digital Ecosystems: Evolving serviceoriented architectures”. in Conference on Bio Inspired Models of Network, Information and Computing Systems. IEEE Press, 2006. Bishop, J. “Increasing participation in online communities: A framework for human-computer interaction”. Computers in Human Behavior (Elsevier Science Publishers) 2007, vol23(4), pp1881–1893. Nachira, F., Nicolai, A., Dini, P., Le Louarn, M., Leon, L.R. Digital Business Ecosystems http://www.digital-ecosystems.org/book/debook 2007.html. 2007 Haki, M. K., Forte, M. W. Service Oriented Enterprise Architecture Framework, Proceedings 6th World Congress on Services, Miami (US), 2010, pp. 391 – 398 Jarvinen, P. H., “Research Questions Guiding Selection of an Appropriate Research Method”. Proceedings European Conference on Information Systems, paper 26, 2000. Mentz, J, Van der Merwe, Alta, & Kotze, Paula. “A Comparison of Practitioner and Researcher Definitions of Enterprise Architecture using an Interpretation Method”. In Advances in Enterprise ISII, C. Møller & S. Chaudhry (Eds.), CRC Press, 2012, p. 11-26 Gartner Research. IT Glossary. 2012. http://www.gartner.com/ technology/it-glossary/enterprise-architecture.jsp. Pava, C., Managing New Office Technology, An Organisational Strategy. New York: Free Press. 1983. McGregor, D., The Human Side of Enterprise. New York: McGrawHill. 1960. Markus, M.L., Power, politics, and MIS implementation. Communications of the ACM, 1983, vol. 26, p. 430-444. Keen, P.G.W. and M. Scott Morton, Decision Support Systems: An Organisational Perspective. Reading, Mass.: Addison-Wesley. 1978. Iivari, J., A Paradigmatic Analysis of Contemporary Schools of IS Development. Eur. J. Information Systems, 1991, vol.1(4):249-272. Ross, J.W., Weill, P., Robertson, D. Enterprise architecture as strategy: creating a foundation for business execution. Harvard Business School Press, 2006. The American Heritage Dictionary of the English Language. 5th Ed.: Houghton Mifflin Harcourt. 2011. ISO/IEC. ISO/IEC 42010:2007: Recommended Practice for Architecture Description of Software-Intensive Systems, 2007. ISO/IEC. Annex A: GERAM, ISO/IS 15704:2000/Amd1:2005: Industrial automation systems - Requirements for enterprise-reference architectures and methodologies, 2005. Williams, T.J., “The Purdue Enterprise Reference Architecture”. In Computers in Industry, 1994. vol. 24(2-3): p. 141-158. CIMOSA Association, CIMOSA - Open System Architecture for CIM,. Technical Baseline, ver. 3.2. Private Publication. 1996. Doumeingts, G., B. Vallespir, and D. Chen, GRAI Grid Decisional Modelling, in Handbook on Architectures of Information Systems, P. Bernus, K. Mertins, and G. Schmidt (Eds). , Springer Verlag: Heidelberg. 1998, p. 313-339. Zachman, J.A., A Framework for Information Systems Architecture. IBM Systems Journal, 1987, vol. 26(3), p. 276-292 The Open Group, The Open Group Architecture Framework, (TOGAF 8.1.1 - 'The Book') v8.1.1. 2006. DoD Architecture Framework Version 2.02. US Department of Defense,2010 US Federal CIO Council. Federal Enterprise Architecture Framework .http://www.itpolicy.gsa.gov/mke/archplus/fedarch1.pdf., 2006. Scheer, A.-W., “ARIS - House of Business Engineering”. In Handbook of Life Cycle Engineering - concepts, models and technologies, A. Molina, A. Kusiak, and J. Sanchez, (Eds). Kluwer Publishers, 1998. Noran, O. A Mapping of Individual Architecture Frameworks (RAI, PERA, C4ISR, CIMOSA, Zachman, ARIS) on GERAM. Handbook on Enterprise Architecture. Berlin : Springer, 2003, pp.65-210. Saha, P., A Synergistic Assessment of the Federal Enterprise Architecture Framework against GERAM (ISO15704:2000), in

[28]

[29]

[30]

[31] [32]

[33]

[34] [35]

[36] [37]

[38]

[39]

[40] [41] [42] [43]

[44]

[45]

[46]

[47]

[48]

Enterprise Systems Architecture in Practice, P. Saha, (Ed.), 2007, IDEA Group: Hershey, USA. Pp.1-17. Saha, P., Analyzing the Open Group Architecture Framework (TOGAF) from the GERAM perspective, in The Open Group Architecture Forum, TOGAF White Papers. 2004, www.opengroup. org/architecture/wp. Noran, O., A Meta-methodology for Collaborative Networked Organisations: Creating Directly Applicable Methods for Enterprise Engineering Projects. Saarbrücken: VDM Verlag Dr. Müller. 2008 Bernus, P., Noran, O., Molina, A. “Enterprise Architecture: Twenty Years of the GERAM Framework”. in Annual Reviews in Control, 39: 83-93. 2015. Afsarmanesh, H., Camarinha, M. Processes and foundations for virtual organizations. U.S.A.: Kluwer Academic Publishers. 2004 Karvonen, I. et al (Eds) Global Engineering and Manufacturing in Enterprise Networks GLOBEMEN. VTT Symposium, 2003, vol.224. Helsinki : VTT Technical Research Centre of Finland Vesterager, J., Bernus, P., Larsen, L.B., Pedersen, J.D., Tølle, M. Use of GERAM as Basis for a Virtual Enterprise Framework Model. In Mo, J., Nemes, L. (Eds) Global Engineering, Manufacturing and Enterprise Net- works (DIISM2000) Kluwer. 2000, pp75-82 Noran, O. Achieving a Sustainable Interoperability of Standards. Annual Reviews in Control. 2012, vol. 36(2), pp. 327-337 Noran, O., “Engineering the Sustainable Business: An Enterprise Architecture Approach”. In Coherency Management: Architecting the Enterprise for Alignment, Agility, and Assurance, G. Doucet, J. Gotze, and P. Saha, Ed. International EA Institute. 2009, pp. 179-210 Noran, O., Bernus, P. Effective Disaster Management: An interoperability Perspective. LNCS. 7046, 2011, pp.112-121. Noran, O., Panetto, H. Modelling a Sustainable Cooperative Healthcare: An Interoperability-driven Approach. LNCS. 8186, 2013, pp. 238-249. Franco dos Reis Alves, D., Campos, R., Bernardi de Souza, F. “GERAM: Building Sustainable Enterprises”. 6th IFAC Conference on Management and Control of Production and Logistics (MCPL13), 2013, Fortaleza, Brazil. Vaniya, N., Bernus, P., Noran, O. “Examining Potentials of Building M&A Preparedness”. in Proc. 15th Int. Conf. Enterprise Information Systems. 2013, Vol 3. Setubal : SCITEPRESS. Pp.201-212 Papazoglou, M. P. Web Services & SOA, Principles and Technology. Pearson. 2012. Krafzig, D., Banke, K., Slama, D.: Enterprise SOA. Service-oriented architecture best practices. Prentice-Hall, Upper Saddle River. 2006. Erl, T.: Service-oriented architecture. Concepts, technology, and design. Prentice-Hall, Upper Saddle River (6th print) 2006. Schönherr, M. Connecting EAI-Domains via SOA - Central vs. Distributed Approaches to Establish Flexible Architectures. In P. Bernus, et al. (Eds.), Knowledge Sharing in the Integrated Enterprise. Toronto / Canada: Kluwer Academic Publishers, 2004, pp. 111-113 Erickson, J., Siau, K. Web Services, Service Oriented Computing and Service Oriented Architecture: Separating Hype from Reality. Journal of Database management, vol. 19(3), 42-54, 2008. Viering, G., Legner, C., and Ahlemann, F. “The (Lacking) Business Perspective on Soa–Critical Themes in SOA Research”. In Proceedings of Wirtschaftsinformatik, 2009, pp. 45-54. Becker, A., Buxmann, P., and Widjaja, T. “Value Potential and Challenges of Service-Oriented Architectures - a User and Vendor Perspective”. In Proceedings of the 17th European Conference on Information Systems (ECIS 2009). (2009) Yoon, T., and Carter, P. “Investigating the Antecedents and Benefits of SOA Implementation: A Multi-Case Study Approach". Procs of 13th Americas Conference on Information Systems, 2007, pp. 1-11. Hirschheim, R., Welke, R., and Schwarz, “A. Service-Oriented Architecture: Myths, Realities,and a Maturity Model”. In MIS Quarterly Executive (9:1), 2010, pp. 37 -48.

[49] Noran, O., Bernus, P. “Service oriented architecture vs. enterprise architecture: competition or synergy?”, LNCS 5333, R. Meersman, Z. Tari, and P. Herrero (Eds.) 2008, Berlin :Springer. pp304-312 [50] Erl, T. Next Generation SOA: A Real-World Guide to Modern Service-Oriented Computing, Prentice Hall. 2014. [51] Knippel, R. Service Oriented Enterprise Architecture. Master of IT Thesis, University of Copenhagen, 2005. [52] Ayed, A, Rosemann, M.; Fielt, E., Korthaus, A. “Enterprise Architecture And The Integration Of Service-Oriented Architecture”. PACIS 2011 Proceedings. Paper 16. 2011 [53] Cheliah, P. R., Winterberg, T., Trops B., Normann, H., Maier, B., Utschig-Utschig, C, Erl T. "Next Generation SOA - A Real-World Guide to Modern Service-OrientedComputing. Prentice-Hall, 2014. [54] Gu, Qing, Lago, P. On Service-Oriented Architectural Concerns and Viewpoints, Proceedings of the European Conference on Software Architecture, Cambridge, 2009, pp. 289-292 [55] Luthria, H., Rabhi, F. A.. “Service-Oriented Architectures: Myth or Reality?” IEEE Software, 2012, Vol 12, pp. 46-52 [56] Lewis, G. A.; Smith, D. B.; Kontogiannis, K. A research agenda for service-oriented architecture (SOA): Maintenance and Evolution of Service-Oriented Systems, CMU/SEI-2010-TN-003, 2010. [57] Oracle. Right from the Start: SOA Lifecycle Governance, http://www.oracle.com/us/products/middleware/soa/soa-lifecyclegovernance-wp- 1971496.pdf. 2012 [58] Assmann, M., Engels, G. “Transition to Service-Oriented Enterprise Architecture” in R. Morrison, D. Balasubramaniam, and K. Falkner (Eds.): ECSA 2008, LNCS 5292, 2008, pp.346–349 [59] Grigoriu, A. SOA, BPM, EA, and SOEA. http://www.bptrends .com/publicationfiles/12-07-ART_Service_Oriented_Enterprise_ Architecture-Grigoriu-final-Use.pdf, 2007. [60] OASIS. A Methodology for Service Architectures https://www.oasisopen.org/committees/download.php/15071. 2005 [61] Souza, A. P.; Rabelo, R. J. “A Dynamic Services Discovery Model for better Leveraging BPM and SOA Integration”. In Int. J. of Information Systems in the Service Sector, 2015, vol. 7, pp. 1-21 [62] Picard, W., Paszkiewicz, Z., Strykowski, S., Wojciechowski, R., “Application of the SOA at the Inter-Organizational Level”, In Studies in Computational Intelligence / Advanced SOA Tools and Applications, 2014, vol. 499, pp. 125-201 [63] IBM. http://www.ibm.com/developerworks/library/ws-soa-eda-esb/ [64] Kaplan, R. S. Conceptual Foundations of the Balanced Scorecard, Harvard Business School, http://www.hbs.edu/faculty/ Publication Files/10-074.pdf. 2010 [65] Rabelo, R J., Bernus, P. “A Holistic Model of Building Innovation Ecosystems”. In 15th IFAC Symposium on Information Control in Manufacturing. Ottawa, Canada, 2015, pp. 1-8. [66] Rodriguez, S, Gaud, N., Hillaire, V., Galland, S., Koukam, A. An Analysis and Design Concept for Self organization in Holonic Multiagent systems. In Brueckner, S., Hassas, S., Jelasity, M, Yaminds, D. (Eds.) 4th ESOA 2006, Berlin: Springer. 2007, pp15-27. [67] Beer, S. The Viable System Model: Its Provenance, Development, Methodology and Pathology. The Journal of the Operational Research Society. 1984, vol. 35(1), pp.7-25 [68] ISO/IEC 20000-1:2011 Service management system requirements. [69] ITIL V3. www.axelos.com/best-practice-solutions/itil/what-is-itil [70] Camarinha-Matos, L., et al., “Collaborative networked organizations – Concepts and practice in manufacturing enterprises”. In Computers and Industrial Engineering, 2009, vol. 57(1), pp. 46-60. [71] Molina, A., Panetto, H., Chen, D., Whitman, L., Chapurlat, V., Vernadat, F. “Enterprise integration and networking: challenges and trends”. In Studies in Informatics and Control. 2007, vol. 16 (4), pp. 353-368. [72] Suh, N.P. Complexity: Theory and Applications. Oxford U. Pr. 2005. [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 Ecommerce. Novel solutions and practices for a global networked economy. Amsterdam: IOS Press, 2001, pp. 846–852.