Service-Oriented Architecture (SOA) is an architecture paradigm for designing large software systems [BBL12]. The idea is that IT functionalities are offered as services to users within and outside of the enterprise [Kel11]. This approach fosters better alignment between business and IT [Buc+09].
SOA Foundations
The basic concept of service-oriented architecture (SOA) is to introduce a new layer of abstraction between the business and the IT of an organization [Buc+09]. This new layer consists of services [Buc+09]. According to [Men07], a service is defined as being “[...] a self-contained and stateless business function which is accessible through a standardized, implementation neutral interface.” . A service can be of different granularity ranging from simple database calls up to aggregated services like a service for billing an order [Buc+09]. Further, a service is a black box to its consumers [11b], since all implementation details are encapsulated and the only information about the service is provided via a service agreement [Fuh13b].
An abstract example of a SOA infrastructure is illustrated in Figure 1. The SOA infrastructure is implemented using a process engine [PTS10]. The lowest layer of services in the process engine reuses the basic functionalities provided by the existing applications of an organization [PTS10]. Within the process engine, four different different layers of services are portrayed, where each services consists of orchestrated services of the layer below. Lastly, the only service layer that the users actually interact with, is the highest layer of the process engine [PTS10] representing cumulated services which directly enable business capabilities [SLI08].
Figure 1: Abstract illustration of a SOA infrastructure based on a process engine. [Based on: M. Postina, J. Trefke, and U. Steffens. “An ea-approach to develop soa viewpoints.” In: Enterprise Distributed Object Computing Conference (EDOC), 2010 14th IEEE International. 2010, pp. 37–46.]
Summarizing, SOA means that functionalities which support business processes are no longer provided directly by business applications, but instead by services [Buc+09]. This enables application landscapes to be structured according to the business of an organization [Hes+07] and therefore to improve the understanding between business and IT [Buc+09].
As already mentioned, advantages of SOA are the alignment [PTS10; BBL12] and the improved communication and understanding between business and IT [Buc+09]. Further, the reusability of services reduces costs, since duplication of functionalities is prevented [Buc+09]. Additionally, the concept of self-contained services which can be combined flexibly enables fast reactions to business changes [Buc+09, SLI08] and therefore agile business support [PTS10]. Finally, the concept of loose coupling stabilizes the IT landscape since outages and performance fall-offs become locally isolated [BBL12].
Prerequisites for the successful implementation of a SOA is the availability of standardized and documented business processes to enable potential for reuse of the services [Buc+09]. In addition, an accounting method for running and using a service is needed. This is not trivial, since several organizational units can use a certain service. Therefore measures for billing like e.g. the number of usages need to be defined [Buc+09]. Lastly, one of the major challenges is the growing number of services and the increasing amount of service interdependencies [PTS10]. To manage such a growing service landscape, suitable concepts and tools need to be implemented [PTS10].
Summarizing, strong governance of service representation and implementation is needed for a successful implementation and operation of a SOA [11b].
One methodology for SOA introduction and evolution is Quasar [PTS10] developed by Capgemini and now available in its current version Quasar 3.0 [Eng+12]. The basic idea of the approach is to define domains grouping functional-logical components [Hes+07]. These domains form the domain model of the organization [Hes+07], which can be interpreted as a high level business architecture [Buc+09]. By assigning services to each of the identified domains, the service landscape is organized and the definition of services with overlapping functionality is avoided [Buc+09].
To enable a SOA, the physical applications providing the services need to be integrated using an appropriate integration infrastructure [Hes+07]. One possible approach to enable this integration is the use of an enterprise service bus (ESB) [SLI08]. An ESB presents a universal mechanism to interconnect all services of an organization while ensuring security, reliability, performance and scalability [Men07]. This makes ESBs an ideal backbone for implementing a SOA [Men07].
The relationship between EAM and SOA is bilateral. On the one hand, the EAM function of an organization enables a SOA transformation by providing the information necessary to define functions the right way [Buc+09] and by managing the transformation of the enterprise architecture to a SOA [Fuh13a]. On the other hand, EAM has to adapt to the new challenges imposed by a SOA, meaning that concepts and methodologies have to be modified to handle the upcoming complex service landscapes [PTS10].
Sources:
|
[11b] |
TOGAF® Version 9.1, an Open Group Standard. Standard. The Open Group, 2011. |
|
[BBL12] |
S. Bente, U. Bombosch, and S. Langade. Collaborative Enterprise Architecture: Enriching EA with Lean, Agile, and Enterprise 2.0 Practices. Elsevier, Inc., 2012. |
|
[Kel11] |
W. Keller. TOGAF 9.1 Quick Start Guide for IT Enterprise Architects. Tech. rep. Wolfgang W. Keller, 2011. |
|
[Buc+09] |
S. Buckl, A. M. Ernst, J. Lankes, F. Matthes, and C. M. Schweda. State of the Art in Enterprise Architecture Management - 2009. Tech. rep. München, Germany: Technische Universität München, Chair for Informatics 19 (sebis), 2009. |
|
[Men07] |
F. Menge. “Enterprise service bus.” In: Free and open source software conference. Vol. 2. Aug. 2007, pp. 1–6. |
|
[Fuh13b] |
K. Fuhrer. “Business-SOA und technische Integration: Migrationsschritte zur Servicelandschaft.” In: Business Technology (bt) Magazin 2 (2013). |
|
[PTS10] |
M. Postina, J. Trefke, and U. Steffens. “An ea-approach to develop soa viewpoints.” In: Enterprise Distributed Object Computing Conference (EDOC), 2010 14th IEEE International. 2010, pp. 37–46. |
|
[SLI08] |
S. Stein, J. Lauer, and K. Ivanov. “ARIS method extension for business-driven SOA.” In: Wirtschaftsinformatik 50(6) (2008), pp. 436–444. |
|
[Hes+07] |
A. Hess, B. Humm, M. Voss, and G. Engels. “Structuring software cities a multidimensional approach.” In: 11th IEEE International Enterprise Distributed Object Computing Conference (EDOC), 2007. IEEE. 2007, pp. 122–129. |
|
[Eng+12] |
G. Engels, M. Kremer, T. Nötzold, T. Wolf, K. Prott, J. Hohwiller, A. Hofmann, A. Seidl, D. Schlegel, and O. Nandico. Quasar 3.0 - A situational approach to Software Engineering. Berlin: Capgemini Deutschland, 2012. |
|
[Fuh13a] |
K. Fuhrer. “Architecturmanagement: Migrationsschritte zur Servicelandschaft, SOA-Transformation.” In: Business Technology (bt) Magazin 1 (2013). |