=Paper=
{{Paper
|id=Vol-2408/paper8
|storemode=property
|title=The Role of Enterprise Architecture Management to Govern Microservice Architecture Adoption
|pdfUrl=https://ceur-ws.org/Vol-2408/paper8.pdf
|volume=Vol-2408
|authors=Carlos Pinheiro,André Vasconcelos,Sérgio Guerreiro
|dblpUrl=https://dblp.org/rec/conf/eewc/PinheiroVG19
}}
==The Role of Enterprise Architecture Management to Govern Microservice Architecture Adoption==
https://ceur-ws.org/Vol-2408/paper8.pdf
The role of Enterprise Architecture Management to
Govern Microservice Architecture adoption
Carlos Pinheiro1 and André Vasconcelos2,3, Sergio Guerreiro2,3
1 Universidade Aberta, Lisboa, Portugal
2 Instituto Superior Técnico, University of Lisbon, Av. Rovisco Pais 1, 1049-001 Lisbon,
Portugal
3 INESC-ID, Rua Alves Redol 9, 1000-029 Lisbon, Portugal
1701005@estudante.uab.pt, andre.vasconcelos@tecnico.ulisboa.pt,
sergio.guerreiro@tecnico.ulisboa.pt
Abstract. Microservice Architecture (MSA) is an architectural style that aims to build a software
application as a set of small services independently deployable. When adopting MSA, companies
must drive some aspects that impact the organizational efficiency in order to guarantee: (i) the
strategic benefits of the initiative; (ii) promote the best resources usage; and (iii) separate the
essential decisions to enterprise architecture management (EAM) delegating other aspects to
microservice teams. This paper assesses the relevant factors about MSA from the EAM view in
order to propose an ArchiMate metamodel which enables enterprise architecture (EA) governance
of MSA.
Keywords: Enterprise Architecture Management, Adaptive Enterprise Architecture, Adaptable
Enterprise Architecture, Microservice Architecture, SOA
1 Introduction
Microservices are components that individually present low complexity, however, a
microservice-based systems architecture becomes highly complex due to its
heterogeneity of technology, volatility and high granularity [1]. Despite this
complexity, it is important to manage the alignment and integration between the
modeling of MSA based systems and the EA needs due to several factors, such as
planning business capabilities, guaranteeing right investment levels, controlling costs,
and ensuring compliance with the EA principles and needs. This paper investigates the
relevant factors about microservice architecture (MSA) from the EAM perspective and
design a metamodel based on TOGAF and ArchiMate to visually govern these aspects.
Therefore, it aims to contribute to the development of enterprise architecture (EA) body
of knowledge.
2 Background
Enterprise Architecture is widely covered in SOA, however the implications over
microservice constraints require new views to accommodate the challenge of driving
MSA implementation without blocking innovations. Also, the Open Group has already
developed a Microservice Reference Architecture [2], but at a high level and not
presented in ArchiMate. In Table 1 we summarize the most important MSA
characteristics to EAM.
Table 1. Main characteristics of MSA related to EAM
Characteristic Description
Consists of the idea that a single team autonomously manages the entire
Decentralized
microservice life cycle, including data governance [2]. However,
Governance governance at EA level is still needed, but it should not be intrusive.
Multiple instances of the microservice can be created automatically in
parallel, thus allowing to increase or decrease the number of instances
Scalability according to demand [2][3]. It Implies that infrastructure costs will be
vdddolatile, and these costs should be monitored and controlled at EA
level.
A microservice exposes a well-defined communication interface (API)
Well-Defined with a published contract, which is exposed through an API gateway or
Interface API proxy [2] [3]. As the API gateway is a cross component it must be
governed at enterprise level.
Despite the high autonomy of microservices teams, EAM still needs to support teams
on cross issues of services but playing a more consultative role than in traditional IT. It
focuses on making recommendations instead of allowing or disallowing certain
architectural decisions while still supporting cross-microservice architecture
development, keeping track of permanent changes in IT architecture and providing
information to enable cost transparency.
3 Proposal
Based on The Open Group MSA Governance Framework [2], we propose a diagram to
clarify the concerns of EA and Microservice governance scopes, showed in Fig. 1. The
idea is that any governance object that emerges should update this figure to visually
guide what should be governed by EAM and what should not.
Fig. 1. Principles and Governance Scopes (Adapted from [2])
To help the microservice team to choose the best technology to implement their
needs, the EAM model provides a catalog of some important technologies which
consider their relevance when it comes to knowledge and costs managements. Fig. 2 is
an adaptation of the model proposed by The Open Group [4] enriched by some other
aspects provided by Yale et al. [3]. It exemplifies artifacts that represent governance
recommendations or requirements for microservices, observing that everything inside
of inner architecture is just a recommendation for microservices, aiming to avoid the
risks in having too many technologies, but without restricting the innovation.
Fig. 2. Enterprise Microservice Reference Architecture
Keeping in mind that it is desirable to delegate as many decisions as possible to the
microservice team, we propose the matrix in Fig. 3 which defines the responsibilities
of governance roles over each architectural property.
Fig. 3. Governance Scope Matrix
In this matrix the lines represent the governance concerns identified in Fig. 1.
Principles and Governance Scopes (Adapted from [2])), and the columns architectural
components and their relations identified in Fig. 2. Enterprise Microservice Reference
Architecture). The cells indicate if the principal responsibility resides in Enterprise
Team Governance (ET), autonomously in the Microservice Team (MT), or in the
Microservice team within enterprise Restrictions or Recommendation (MR).
4 Conclusions and Future Work
The proposed solution resulted in an ArchiMate model defining principles, governance
responsibilities, and a technology architecture view for MSA at EAM level. However,
the assumptions made for the development of this paper regarding the existence of the
difficulty for companies to maintain the alignment between MSA and EAM in relation
to IT governance, as well as the aspects discussed and addressed to the EAM in the
context of this paper, still need confirmation. Lastly, the model proposed should be
applied and evaluated in a real case, and other theoretical strategies can be investigated
to validate and enrich the solution.
Acknowledgments
This work was supported by national funds through Fundação para a Ciência e a
Tecnologia (FCT) with reference UID/CEC/50021/2019 and by the European
Commission program H2020 under the grant agreement 822404 (project QualiChain).
References
[1] J. Bogner and A. Zimmermann, “Adaptable digital enterprise architecture with
microservices,” in 10th Advanced Summer School on Service Oriented Computing,
2016, pp. 59–61.
[2] M. Balakrushnan, Somasundram ; Mamnoon, Ovace ; Bell, John ; Currier, Benjamin ;
Harrington, Ed ; Helstrom, Brian ; Maloney, Peter ; Martins, “Microservices
Architecture.” The Open Group, San Francisco, CA, USA, 2016.
[3] Yale Yu, H. Silveira, and M. Sundaram, “A microservice based reference architecture
model in the context of enterprise architecture,” in 2016 IEEE Advanced Information
Management, Communicates, Electronic and Automation Control Conference
(IMCEC), 2016, pp. 1856–1860. doi:10.1109/IMCEC.2016.7867539
[4] “The SOA Source Book - Microservices Architecture,” The Open Group, 2016. .
http://www.opengroup.org/soa/source-book/msawp/index.htm