SciELO - Scientific Electronic Library Online

 
 número35Avaliação de Ferramentas BPM: Uma Análise Comparativa de Soluções ComerciaisSuporte Tecnológico para o Auxílio do Professor na Avaliação segundo à BNCC índice de autoresíndice de assuntospesquisa de artigos
Home Pagelista alfabética de periódicos  

Serviços Personalizados

Journal

Artigo

Indicadores

Links relacionados

  • Não possue artigos similaresSimilares em SciELO

Compartilhar


RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação

versão impressa ISSN 1646-9895

RISTI  no.35 Porto dez. 2019

https://doi.org/10.17013/risti.35.86-100 

ARTIGOS

Gestão da arquitetura empresarial na governação de microsserviços

Enterprise architecture management in microservice governance

Carlos Roberto Pinheiro 1, Sérgio Guerreiro 2,3, André Vasconcelos 2,3

1 Universidade Aberta, Lisboa, Portugal; carlos.guti@gmail.com

2 Instituto Superior Técnico, University of Lisbon, Av. Rovisco Pais 1, 1049-001 Lisbon, Portugal; sergio.guerreiro@tecnico.ulisboa.pt, andre.vasconcelos@tecnico.ulisboa.pt

3 INESC-ID, Rua Alves Redol 9, 1000-029 Lisbon, Portugal


 

RESUMO

A arquitetura de microsserviços é um estilo arquitetural para construção de sistemas distribuídos através de um conjunto de pequenos serviços autónomos. Este trabalho investiga os fatores relevantes acerca da arquitetura de microsserviços na perspetiva da Gestão da Arquitetura Empresarial (GAE) e propõe uma arquitetura padrão representada em ArchiMate, que suporta a função de planear e manter a arquitetura atualizada. Esta arquitetura padrão define, (i) princípios e contexto de governação, (ii) uma estrutura genérica para constituição das equipas, e (iii) uma arquitetura de referência contendo padrões tecnológicos. A proposta visa atender ao papel da gestão da arquitetura empresarial através da governação descentralizada e suportar as equipas de microsserviços de modo menos intrusivo e restritivo possível. A proposta arquitetural é avaliada por intermédio da realização de entrevistas e de um inquérito aplicado a profissionais de diferentes áreas de negócio.

Palavras-chave: Gestão da Arquitetura Empresarial; Arquitetura Empresarial Adaptativa; Arquitetura de Microsserviços; SOA


 

ABSTRACT

Microservice architecture is an architectural style to building distributed systems through a set of small standalone services. This paper investigates the relevant factors about the microservices architecture from the perspective of Enterprise Architecture Management (EAM) and proposes a reference architecture represented in ArchiMate, which supports the function of planning and keeping the architecture up to date. This reference architecture defines, (i) governance principles and context, (ii) a generic team building structure, and (iii) an architecture model containing technology standards. The proposal aims to address the role of enterprise architecture management through decentralized governance and to support microservice teams in the least intrusive and restrictive way possible. The architectural proposal is evaluated through interviews and a survey applied to professionals from different business areas.

Keywords: Enterprise Architecture Management; Adaptive Enterprise Architecture; Microservice Architecture; SOA.


 

1. Introdução

A arquitetura de microsserviços é um estilo arquitetural para a construção de sistemas distribuídos baseados em microsserviços. Embora os microsserviços sejam componentes que individualmente apresentem uma baixa complexidade, os sistemas baseados em microsserviços são altamente complexos devido à heterogeneidade de tecnologia, volatilidade e alta granularidade dos componentes (Bogner & Zimmermann, 2016a). Apesar desta complexidade, é importante gerir e garantir o alinhamento e a integração entre a modelação destes sistemas e a gestão da arquitetura empresarial (Cabrera et al, 2015), por fatores como, o controlo da proliferação de tecnologias, a eficiência e eficácia dos sistemas de informação, o valor gerado para o negócio da organização, a coordenação do desenvolvimento arquitetural entre diferentes áreas da organização, e outros. Assim, procuramos identificar o que deve ser observado e documentado na arquitetura empresarial ao adotar-se uma arquitetura de microsserviços com base no TOGAF (The Open Group, 2018) e modelar estes fatores em ArchiMate (The Open Group, 2017). Este modelo pode servir como uma referência para a arquitetura de microsserviços, procurando garantir a rastreabilidade entre a arquitetura empresarial e a arquitetura de microsserviços. Para atingir este objetivo, são identificados os aspetos da arquitetura de microsserviços que são relevantes para a gestão da arquitetura empresarial e como devem ser descritos num modelo organizacional, a fim de garantir a gestão das dependências entre os componentes arquiteturais, sua eficiência e eficácia. E finalmente, este artigo, propõe-se também descrever estes aspetos em ArchiMate.

Esta pesquisa propõe um modelo abstrato viável que resolve a dificuldade de representar os aspetos relevantes da arquitetura de microsserviços ao nível da arquitetura empresarial por meio de artefactos inovadores, contribuindo para novos conhecimentos sobre como projetar os sistemas baseados na arquitetura de microsserviços. Design Science Research Methodology (DSRM) (Hevner & Chatterjee, 2010) foi a metodologia escolhida para esta investigação.

O documento está organizado da seguinte forma. A secção 2 apresenta a revisão de literatura. Na secção 3 detalha-se a proposta para a gestão da arquitetura empresarial na governação de microsserviços. De seguida, na secção 4, relata-se a avaliação que foi executada sobre a proposta. Finalmente, a secção 5 conclui o trabalho e identifica o trabalho futuro a ser desenvolvido neste domínio.

2. Revisão de literatura

Para identificar o estado da arte, fizemos uma revisão sistemática através de Research Gate, Google Scholar e AIS e-library com a chave: ("Enterprise Architecture Management” OR "Adaptive Enterprise Architecture” OR "Adaptable Enterprise Architecture”) AND (Microservice* OR SOA), na qual aplicamos sucessivos critérios de eliminação de publicações fora dos objetivos da pesquisa ou de origem predatória. A Tabela 1 mostra uma visão quantitativa desse processo.

 

 

Por fim, a análise dos conteúdos das 39 publicações restantes somadas a algumas de pesquisas exploratórias resultou na seleção de 18 contribuições.

Microsserviços são pequenos serviços autónomos, publicáveis de forma independente (Newman, 2015). O tema microsserviços tem despertado um grande interesse, mas ainda se encontra na infância académica, razão pela qual a maioria dos artigos é caracterizada por questões relacionadas a soluções no nível tecnológico e de infraestrutura (Francesco, Malavolta, & Lago, 2017). Isso reforça a importância em investigar características relacionadas à comunicação entre arquitetos e outras partes interessadas no nível corporativo. Identificámos algumas questões e dificuldades na gestão da arquitetura empresarial relatadas na literatura. A autonomia das equipas de microsserviços reduzem a necessidade de comunicação no nível corporativo, o que dificulta a sincronização de estratégias corporativas (Lenarduzzi & Sievi-Korte, 2018). É difícil determinar claramente o contexto e a granularidade dos microsserviços (Soldani, Tamburri, & Van Den Heuvel, 2018). A falta de clareza na definição do contexto do microsserviço e da definição da responsabilidade pelos microsserviços favorece a duplicação de funções e leva a ineficiências (Yale Yu, Silveira, & Sundaram, 2016). Ademais, é difícil manter as equipas treinadas e a coordenação entre equipas (Salah, Jamal Zemerly, Chan Yeob Yeun, Al-Qutayri, & Al-Hammadi, 2016).

No contexto da arquitetura empresarial, a inovação nos sistemas de informação assume papel estratégico em resposta ao contexto de extrema competitividade (Abreu, Carvalho, & Rocha, 2018). Por outro lado, os sistemas de informação são amplamente cobertos pelo TOGAF e ArchiMate, bem como os serviços por SOA. No entanto, as implicações sobre as restrições impostas pela arquitetura de microsserviços exigem novas visões para acomodar o desafio de governar a sua adoção sem bloquear inovações. Considerando que a arquitetura empresarial deve ser aberta e flexível, permitindo escolhas ágeis de tecnologia, infraestrutura e outos (Fernandes, 2018), juntamos duas abordagens que se complementam. Uma top-down, com base no TOGAF para planear a arquitetura; e outra bottom-up baseada na composição de minidescrições arquiteturais proposta por Bogner & Zimmermann (2016a), que complementa o modelo e permite capturar algumas decisões atualizando a visão da arquitetura empresarial a partir da implementação e evolução dos microsserviços. The Open Group também desenvolveu uma arquitetura de referência de microsserviços (Balakrushnan et al., 2016), mas em um nível alto, não modelado em ArchiMate e considerando apenas cenários green-field, onde todos os aspetos podem ser geridos sem preocupações sobre legados. No entanto, não suporta uma solução para organizações que são altamente reguladas e que adotarão esta arquitetura em um cenário brown-field, de coexistência com grandes estruturas legadas e normas rígidas.

3. Proposta

Apesar da arquitetura de microsserviços promover a governação descentralizada, é importante manter o alinhamento organizacional e estratégico, otimizando investimentos e controlando custos em Tecnologias da Informação (TI). Neste trabalho, buscamos ampliar as referências existentes agregando três elementos chave: (i) uma abordagem para modelar as visões corporativas da arquitetura de microsserviços; (ii) uma visão detalhada do sistema composta por minidescrições arquiteturais que permite manter os modelos arquiteturais atualizados; (iii) e uma arquitetura de referência modelada em ArchiMate. Os principais aspetos identificados estão listados na Tabela 2.

 

 

Para delimitar os contextos da governação dos microsserviços (Figura 1), consideramos dois princípios fundamentais da governação no nível corporativo ou no nível da equipa de microsserviços. (i) A governação dos microsserviços na arquitetura empresarial deve ser mantida mínima e não intrusiva; (ii) uma única equipa tem total responsabilidade por um microsserviço.

 

 

A arquitetura de microserviços requer uma estrutura organizacional que suporte a visão de produto. Na Figura 2, os principais papéis da estrutura proposta são o arquiteto empresarial, o Product Owner e o arquiteto do microserviço. O arquiteto empresarial tem a responsabilidade de manter os modelos arquiteturais integrados e manter o conjunto de requisitos e recomendações do nível corporativo para os microserviços. Estes três papéis participam do quadro de governação corporativa a fim de manter o alinhamento das questões transversais da arquitetura.

 

 

Para ajudar a equipa de microsserviços a escolher a melhor tecnologia para as suas necessidades, o modelo corporativo deve fornecer um catálogo de tecnologias, que consideram a sua relevância quanto a gestão de conhecimento e custos. A Figura 3 é uma adaptação do modelo proposto por Balakrushnan et al., (2016) enriquecido por alguns outros aspetos descritos por Yale Yu, Silveira, & Sundaram (2016). Nele são representadas recomendações ou requisitos de tecnologias para microsserviços, observando que dentro da Arquitetura Interna é uma recomendação visando evitar os riscos potenciais do excesso de tecnologias, mas sem restringir a inovação.

 

 

Um microsserviço é parte de um sistema “produto”, mas observamos que as fronteiras entre as diferentes capacidades de negócio e sistemas podem não ser claras (Soldani et al., 2018). Assim, propomos uma matriz CRUD (Figura 4) para identificar agrupamentos de informação e definir os produtos. Esta matriz determina o contexto inicial para os microsserviços.

 

 

Tendo como norte que é desejável delegar tantas decisões quanto possível à equipa de microsserviços, propõe-se a matriz da Figura 5, que define as responsabilidades sobre a governação de cada aspeto arquitetural. Nesta matriz, as linhas representam as preocupações de governação e as colunas os componentes arquiteturais. As células indicam se a responsabilidade principal reside na Equipa de TI corporativa (ET), autonomamente na Equipa de Microsserviço (EM), ou na equipa de Microsserviço, mas limitadas por Recomendações empresariais (MR).

 

 

Uma vez que uma equipa tem o controlo sobre a governação dos microsserviços, é necessário manter o modelo de arquitetura empresarial atualizado. Para isso, usamos um modelo de minidescrições arquiteturais em ArchiMate (Figura 6).

 

 

Estas minidescrições são utilizadas para que as mudanças no microsserviço sejam capturadas e atualizem automaticamente o modelo de arquitetura empresarial, garantindo que a visão corporativa tenha sempre a informação mais atual possível. Na camada M3 é descrito a linguagem utilizada para modelar as visões arquiteturais dos microsserviços. Na camada M2 são representadas a arquitetura de referência e restrições corporativas. Ela descreve as principais tecnologias e padrões que a arquitetura de microsserviços deve seguir e um link para o catálogo de tecnologias disponíveis. A camada M1 é uma visão da arquitetura de cada microsserviço descrevendo os microsserviços com informações resultantes das escolhas sobre as opções disponíveis na arquitetura empresarial e detalha aspetos de implementação como, regras de negócio, entidades informacionais, modelos de eventos, serviços de aplicações e interfaces consumidas. A camada M0 regista informações de execução, como monetização e custos por uso.

4. Avaliação

Esta secção descreve a avaliação e os resultados alcançados na solução dos problemas de investigação (Peffers, Tuunanen, Rothenberger, & Chatterjee, 2007)

Observamos a necessidade de se governar alguns aspetos da arquitetura de microsserviços no nível empresarial e identificamos questões e dificuldades relatadas na literatura. Notamos a mudança do papel da gestão da arquitetura empresarial, de um papel restritivo para um consultivo, visando apoiar as equipas em questões transversais, rastrear mudanças na arquitetura empresarial e assegurar transparência de custos e gestão de riscos. Para apoiar o novo papel da gestão da arquitetura empresarial propusemos um modelo com algumas visões arquiteturais complementar a outras propostas. Procuramos fornecer uma abordagem para delimitar o contexto dos produtos de microsserviços, o que ajuda a escolha da equipa responsável pelos produtos e também uma visão para manter visualmente um catálogo de tecnologias no nível empresarial, além de uma proposta para manter o modelo de arquitetura empresarial atualizado a partir da evolução de cada microsserviço.

Para confirmar a utilidade e uso da solução por arquitetos no contexto da arquitetura de microsserviços, realizámos um questionário seguido de entrevistas com profissionais especialistas que fazem parte de equipas de microsserviços, com foco em avaliar o contributo da solução na mitigação dos riscos corporativos. Ao correlacionar a solução aos riscos corporativos, temos evidências objetivas sobre o contributo da solução para a gestão da arquitetura empresarial, provando a sua eficácia e relevância. Nestas entrevistas, seguimos uma dinâmica onde apresentámos aos entrevistados as questões de pesquisa, os problemas identificados e a solução proposta. Em seguida, pedimos que respondessem ao questionário a fim de confirmar as perceções se os aspetos apresentados eram de facto ligados aos riscos listados, o quanto eles concordavam com isso, e se a solução proposta como um todo contribui para mitigação de cada risco. No final, concluímos as entrevistas pedindo-lhes um feedback aberto visando identificar o que funcionou melhor e entender o que não funcionou tão bem. Os riscos estão listados em baixo e melhor descritos adiante nesta secção.

1. Risco de reduzir a flexibilidade/agilidade da TI na entrega ao negócio

2. Risco de aumentar o custo de formação

3. Risco de aumentar o custo de licenciamento

4. Risco no controlo do custo da infraestrutura de TI

5. Risco de exposição à falta de suporte

6. Risco de uso inadequado de soluções de TI

7. Risco de reduzir o nível de reutilização do serviço

8. Risco de não conformidade com normas de segurança

9. Risco de não conformidade com normas reguladoras externas

Para confirmar que os problemas identificados estão relacionados com as preocupações corporativas, correlacionamos estes riscos aos objetivos de TI descritos no COBIT (2012). Os riscos identificados e suas relações com os objetivos de TI são explicados em seguida.

1.Reduzir a flexibilidade/agilidade da TI

Apesar dos benefícios das decisões descentralizadas sobre a melhor tecnologia para cada caso, a diversidade descontrolada de tecnologias tem impactos negativos na agilidade da TI, uma vez que pode reduzir a mobilidade dos recursos humanos. Além disso, a falta de mobilidade pode impactar a motivação dos profissionais de TI. Também pode impedir o uso otimizado de ativos e recursos de TI. Outro papel importante da TI é apoiar as inovações de negócio, no entanto, manter o conhecimento e a expertise nessas tecnologias torna-se mais difícil e isso pode impactar as iniciativas para as inovações de negócios. Ademais, a descentralização permite utilizar soluções específicas para resolver problemas locais, no entanto, sua utilização pode ser inadequada numa visão corporativa.

2. Aumento do custo de formação

A diversidade descontrolada de tecnologias pode aumentar o custo de formação. O risco de aumentar o custo da capacitação das pessoas em nossa visão está relacionado à transparência do custo, aos benefícios e riscos de cada tecnologia. Escolher uma nova tecnologia para resolver um problema que já foi resolvido usando a tecnologia existente na empresa implica a perda de agilidade para as equipas, que têm que amadurecer na nova tecnologia. Este aspeto também está relacionado a não otimizar recursos e ativos de TI. Além disso, pode impactar negativamente o conhecimento e expertise necessária para apoiar as inovações de negócios e para manter a competência e motivação do pessoal de negócio e TI.

3. Aumento do custo de licenciamento

A diversidade de tecnologias para a mesma finalidade pode aumentar o custo das licenças, o custo de infraestruturas na nuvem, e a dificuldade de gerenciá-los. Assim, pode dificultar a realização dos benefícios pretendidos pelos investimentos em TI e complicar a gestão do portfólio de serviços. Embora essa diversidade permita uma racionalização de custos do uso da nuvem, o custo efetivo de gerenciar as licenças pode ficar oculto, implicando na falta de transparência de custos de TI e dificuldade de otimizar o uso de ativos e recursos de TI.

4. Aumento do custo da infraestrutura de TI

A diversidade pode causar um aumento ou falta de controlo sobre o custo do uso de recursos de infraestrutura em nuvem. O que pode dificultar a realização dos benefícios esperados dos investimentos em TI. Se não for claramente controlado, pode interferir na transparência dos riscos e impactar a infraestrutura de processamento em caso de falta de orçamento suficiente para suportar incrementos de infraestrutura, bem como pode afetar a otimização dos recursos de TI.

5. Exposição à falta de suporte.

Escolhas completamente autônomas podem levar à escolha de tecnologias que não são suficientemente robustas para garantir a continuidade, como tecnologias que podem ser descontinuadas ou abandonados pela comunidade. Pode ser mais difícil recrutar pessoas com conhecimento na tecnologia, ou interessadas em aprendê-la, implicando em dificuldades para gerenciar e motivar o pessoal de TI, bem como, em risco à continuidade dos negócios. As escolhas de tecnologias abandonadas ou com comunidade pequena podem ocultar o custo gasto internamente para manter o suporte no nível de TI. Este tipo de situações soa como um possível uso inadequado da solução tecnológica e também afetam a agilidade de TI, pois provavelmente a equipa terá que investigar os problemas sem ajuda parceiros especializados. Sem ninguém para recorrer, nenhum perito e apoio comunitário, os profissionais da organização podem se deparar com um sentimento de impotência para resolver problemas e isso pode impactar a motivação desses profissionais.

6. Uso inadequado da solução de TI.

A escolha autónoma da tecnologia pode levar a escolhas inapropriadas do ponto de vista da integração com outras aplicações corporativas. Por exemplo, o uso de um protocolo de comunicação que outras aplicações e parceiros não estejam prontos integrar. Claramente este risco está relacionado ao uso inadequado de soluções tecnológicas. Possivelmente, também implica em dificuldade na otimização de ativos e recursos de TI e por fim, acaba por reduzir a agilidade de TI.

7. Redução do nível de reutilização do serviço.

Reutilização é um princípio e um benefício importante do SOA e contribui para a agilidade da TI. A má definição do contexto de microsserviços pode levar a serviços duplicados, contribuindo para ineficiências na gestão de custos e de capacidade de TI. Um baixo nível de reutilização implica o uso não otimizado de recursos e os custos de manutenção de dois serviços podem ficar escondidos.

8. Não conformidade com as políticas de segurança corporativas.

Quanto maior a diversidade de tecnologias para o mesmo propósito, maior a dificuldade de gerir e mitigar possíveis vulnerabilidades de segurança da informação. Implica na falta de transparência dos riscos, uma exposição à segurança da informação e a outras políticas internas.

9. Não conformidade com as políticas regulatórias.

Por exemplo, uma regra reguladora pode determinar que os registos de dados devem ser imutáveis e armazenados por um determinado período de tempo em um determinado ambiente. Um exemplo é em contabilidade, onde uma vez registado um evento, não pode mais ser alterado, apenas compensado. Este risco é relacionado à conformidade da TI e ao suporte para o cumprimento das normas regulatórias. Além disso, é importante perceber a transparência deste risco, seu custo e benefícios em mitigá-lo. Ademais, a não-conformidade com normas reguladoras pode resultar em um uso inadequado da informação.

Questionário e Entrevistas

O questionário foi desenvolvido a partir dos nove riscos identificados. Para cada risco foram aplicadas duas questões utilizando uma escala Likert de 5 pontos, procurando confirmar a existência do risco e o quanto o modelo apresentado mitiga o risco. Dez profissionais de TI participaram das entrevistas, todos parte de equipas de microsserviços, de quatro organizações diferentes, descritas a seguir: uma empresa especializada em ferramentas de CRM com forte presença no mercado de shopping centers no Brasil que está reconstruindo seus produtos em uma arquitetura de microsserviços, visando escalabilidade e mudança em seu modelo de negócios de licenciamento anual para cobrança por uso; duas empresas fazem parte do maior grupo de mass media da América Latina e utilizam intensamente microsserviços para suportar o grande número de leitores móveis e online, sendo uma responsável pelo jornal de maior circulação no Brasil e outra responsável pela publicação de um grande número de revistas; e uma empresa de consultoria especializada em APIs e microsserviços classificada como líder na Forrester e visionária no Gartner com uma grande base de clientes em áreas como bancos, seguros, pagamentos e outros.

Resultados

Avaliamos o quanto os participantes concordavam com a análise de riscos apresentada partir de uma escala Likert de 1 a 5, onde 1 significa o não reconhecimento da existência de risco a nível empresarial e seus impactos e 5 total reconhecimento do risco e seus impactos a nível empresarial. E depois o quanto concordavam que a solução demonstrada ajuda a resolver os riscos num grau de concordância a partir da escala Likert de 1 a 5, onde 1 significa que a solução não contribui para mitigar o risco associado e 5 significa o total reconhecimento de que a solução apresentada contribui para a mitigação do risco e seus impactos. O resultado é mostrado nos gráficos box plot da Figura 7 e da Figura 8.

 

 

 

Na Figura 7 podemos observar a distribuição no reconhecimento de risco, enquanto na Figura 8 a distribuição do reconhecimento da utilidade da solução na mitigação destes riscos. Estes gráficos descartam os outliers, que apresentam respostas muito discrepantes e poderiam distorcer a análise. A partir do gráfico da avaliação de riscos (Figura 7) podemos notar que a menor variação e o maior valor correspondem ao risco em aumentar o custo de formação e ao risco relacionado com a falta de suporte, seguido pelo risco de reduzir a flexibilidade/agilidade da TI e da não conformidade com normas regulatórias. Assim, conclui-se que esses riscos têm maior reconhecimento entre os entrevistados. Enquanto as maiores variações estão relacionadas ao risco de aumento no custo de licenciamento e de uso inadequado de soluções de TI, indicando menor concordância entre os entrevistados. No entanto, analisando a faixa ocupada entre o primeiro e o terceiro quartil percebemos que todos os riscos identificados foram reconhecidos. Os maiores riscos para essas organizações, aumentar o custo de formação e falta de suporte, apontam para uma forte preocupação quanto ao domínio efetivo das tecnologias utilizadas. Esses dois riscos alertam para dificuldades na resolução de problemas nessas tecnologias, reduzindo a velocidade de entrega de soluções, o que reforça o terceiro risco na classificação, o de reduzir a flexibilidade/agilidade da TI.

O gráfico da avaliação da solução (Figura 8) confirma que a proposta ajuda a mitigar todos os riscos identificados, uma vez que todos os riscos tiveram pontuações elevadas quando desconsiderando os outliers. As menores variações são relativas à mitigação dos riscos na redução da flexibilidade/agilidade e na exposição à falta de apoio, indicando maior consenso entre os participantes. Além disso, este consenso está na faixa mais alta, o que demonstra que o maior impacto em termos de mitigação de risco está relacionado com estes dois riscos. Por outro lado, as maiores variações estão relacionadas com a mitigação de aumento do custo de licenciamento e da redução do nível de reutilização de serviços. Neste caso, há diferenças entre perceções do contributo da solução para a mitigação destes riscos. Embora encontremos menos consenso sobre esses riscos, eles ainda estão numa faixa elevada. A menor contribuição está relacionada com o aumento no custo de formação, que está longe do valor máximo, portanto, este é o ponto mais fraco em relação à perceção da utilidade da solução. Controlar os custos de formação, por sua vez, está diretamente ligado à preocupação com a gestão do conhecimento e o domínio efetivo das tecnologias utilizadas, diagnosticadas na análise de riscos.

Ao final, foi solicitado aos participantes feedback aberto focando a análise na perceção dos riscos, de como o modelo poderia contribuir para as suas organizações e as razões que os levam a não concordar com a solução em termos de contributo para a redução dos riscos quando respondido um grau inferior a 5. Algumas considerações foram feitas nesta fase. A probabilidade de um microsserviço aumentar o custo da licença, bem como os custos de infraestrutura e de uso da nuvem, relacionados aos riscos 3 e 4, podem ser baixos, considerando a capacidade de aumentar ou diminuir automaticamente a quantidade de instâncias de microsserviços. Sobre o risco relacionado ao uso inadequado da solução de TI, o argumento de que as escolhas autônomas podem dificultar a integração a outras aplicações corporativas, pode ter baixa probabilidade e impacto, porque os microsserviços comunicam através de diferentes requisitos técnicos para a integração e facilmente evoluem se uma nova interface for necessária. A duplicação de funções e a eventual redução da reutilização pode ser aceitável em favor da agilidade das mudanças e não ter de conciliar interesses de diferentes contextos. Por exemplo, um microsserviço responsável pelos dados do "produto" parece ser reutilizável, mas quando o levamos para o contexto de um assinante de TV paga, ele terá um universo de dados e operações distintos de um produto do contexto de uma revista de papel. Embora a entidade pareça a mesma, para contextos diferentes pode não ser verdade. Em geral, modelo foi considerado útil, principalmente por apresentar luz sobre as preocupações corporativas e outros insights para a adoção da arquitetura de microsserviços. O modelo apresentado não resolve totalmente o risco de duplicação de funções e microsserviços, embora contribua para o nível de reutilização ao definir um contexto para o sistema de microsserviço. Também não consegue resolver a granularidade de cada microsserviço, uma vez que o contexto é definido em um nível ainda alto. A empresa de CRM demonstrou menor preocupação com custos de licenciamento e suporte, preferindo utilizar tecnologias gratuitas e de código aberto, sendo muito sensíveis ao custo da infraestrutura. Já as empresas do grupo de mass media, demonstraram maior preocupação com a falta de suporte e a conformidade com as normas internas e externas. Essas diferenças mostram como os riscos têm pesos diferentes para cada organização, embora tenham sido considerados importantes.

5. Conclusões e trabalho futuro

Com o objetivo de apoiar a Gestão da Arquitetura Empresarial na condução dos aspetos mais relevantes sobre a arquitetura de microsserviços, desenvolvemos um modelo em ArchiMate contento os princípios, as responsabilidades de governação, os contextos delimitadores de produtos, uma estrutura de equipa e uma visão de arquitetura de tecnologias para microsserviços. Este modelo permite manter os requisitos e recomendações da arquitetura empresarial para as equipas de microsserviços, bem como manter atualizadas as informações sobre os microsserviços, a fim de prover transparência de custos e equilíbrio quanto aos benefícios da governação descentralizada. O modelo proposto aborda aspetos que as outras referências isoladamente não abrangem, além de dois gaps não cobertos por nenhuma das outras referências, tais como, um método para definir o contexto e tamanho de um sistema baseado em microsserviços e um modelo para manter um catálogo de tecnologias, capaz de evitar a anarquia tecnológica.

Por fim, a análise de impacto da arquitetura de microsserviços sobre os riscos empresariais reforça a necessidade de suporte da arquitetura empresarial acerca de temas envolvendo mais de um sistema/equipa no nível corporativo. Esta análise pode ajudar as empresas que desejam adotar a arquitetura de microsserviços, bem como outros investigadores a refletir sobre como lidar com estes aspetos e riscos.

Apesar da viabilidade demonstrada, a união de duas abordagens diferentes, uma top-down para planear a arquitetura e outra para atualizar o modelo por uma perspetiva bottom-up, não apresenta uma solução fluída. Assim, para o trabalho futuro, persistem algumas lacunas, como na gestão do conhecimento, que ainda não está explícito na modelo proposto. Ademais, ainda parece haver muitas responsabilidades compartilhadas entre a governação no nível corporativo e a governação no nível dos microsserviços. Este não foi o foco desta investigação, mas certamente abre um ponto de discussão sobre os benefícios reais em manter cada especto na governação empresarial ou delegá-lo à equipa de microsserviços. As premissas feitas para o desenvolvimento desta investigação sobre a existência da dificuldade das organizações em manter o alinhamento entre as arquiteturas empresarial e de microsserviços, bem como os aspetos discutidos, merecem mais investigação. Ainda, um método automatizado de recolha de dados para atualizar o modelo pode ser investigado, conforme proposto por Bogner & Zimmermann (2016a). E por fim, o modelo proposto deve ser aplicado e avaliado em casos reais para enriquecer a solução com experiências em diferentes domínios.

 

REFERÊNCIAS

Abreu, A., Carvalho, J. V., & Rocha, Á. (2018). New challenges of information systems in the current context of organizations. RISTI - Revista Iberica de Sistemas e Tecnologias de Informacao, 2018(30), ix. Doi: https://doi.org/10.17013/risti.30.0         [ Links ]

Balakrushnan, S., Bell, J., Currier, B., Packard, H., Harrington, E. E., Helstrom, B., … & Martins, M. (2016). Microservices Architecture. Retrieved from The Open Group website: https://publications.opengroup.org/white-papers/soa/w169         [ Links ]

Bogner, J., & Zimmermann, A. (2016a). Adaptable digital enterprise architecture with microservices. In 10th Advanced Summer School on Service Oriented Computing, 59-61. Retrieved from https://publikationen.reutlingen-university.de/frontdoor/index/index/docId/1384         [ Links ]

Bogner, J., & Zimmermann, A. (2016b). Towards Integrating Microservices with Adaptable Enterprise Architecture. In Proceedings - IEEE International Enterprise Distributed Object Computing Workshop, EDOCW. Doi: https://doi.org/10.1109/EDOCW.2016.7584392         [ Links ]

COBIT (2012). A Business Framework for the Governance and Management of Enterprise IT. Retrieved from http://www.isaca.org/cobit/pages/default.aspx         [ Links ]

Drews, P., Schirmer, I., Horlach, B., & Tekaat, C. (2017). Bimodal Enterprise Architecture Management: The Emergence of a New EAM Function for a BizDevOps-Based Fast IT. In IEEE 21st International Enterprise Distributed Object Computing Workshop (EDOCW), 57-64. Doi: https://doi.org/10.1109/EDOCW.2017.18         [ Links ]

Fernandes, S. (2018). New challenges in is: The increasing importance of cyber-physical processes. RISTI - Revista Iberica de Sistemas e Tecnologias de Informacao, 2018(30), 51-61. Doi: https://doi.org/10.17013/risti.30.51-61         [ Links ]

Fowler, M., & Lewis, J. (2014). Microservices - A definition of this new architectural term. Retrieved November 20, 2019, from ThoughtWorks website: https://martinfowler.com/articles/microservices.html        [ Links ]

Francesco, P. Di, Malavolta, I., & Lago, P. (2017). Research on Architecting Microservices: Trends, Focus, and Potential for Industrial Adoption. In 2017 IEEE International Conference on Software Architecture (ICSA), 21-30. Doi: https://doi.org/10.1109/ICSA.2017.24         [ Links ]

Hevner, A. R., & Chatterjee, S. (2010). Design Research in Information Systems: Theory and Practice. In Springer (Vol. 2). Doi: https://doi.org/10.1007/978-1-4419-6108-2

Lenarduzzi, V., & Sievi-Korte, O. (2018). On the negative impact of team independence in microservices software development. In Proceedings of the 19th International Conference on Agile Software Development Companion - XP ’18, 1-4. Doi: https://doi.org/10.1145/3234152.3234191         [ Links ]

Newman, S. (2015). Building microservices: Designing Fine-Grained Systems. Sebastopol, CA, EUA: O’Reilly Media.

Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A Design Science Research Methodology for Information Systems Research. Journal of Management Information Systems, 24(3), 45-77. Doi: https://doi.org/10.2753/mis0742-1222240302         [ Links ]

Salah, T., Zemerly, M.J., Chan, C.Y., Al-Qutayri, M., & Al-Hammadi, Y. (2016). The evolution of distributed systems towards microservices architecture. In 2016 11th International Conference for Internet Technology and Secured Transactions (ICITST), 318-325. Doi: https://doi.org/10.1109/ICITST.2016.7856721         [ Links ]

Soldani, J., Tamburri, D. A., & Van Den Heuvel, W.-J. J. (2018). The pains and gains of microservices: A Systematic grey literature review. Journal of Systems and Software, 146, 215-232. Doi: https://doi.org/10.1016/j.jss.2018.09.082         [ Links ]

The Open Group (2017). ArchiMate® 3.0.1 Specification. The Open Group Standard. Retrieved from http://pubs.opengroup.org/architecture/archimate3-doc/         [ Links ]

The Open Group (2018). The TOGAF® Standard, Version 9.2. Retrieved February 16, 2019, from https://publications.opengroup.org/standards/togaf/c182         [ Links ]

Yale, Yu, Silveira, H., & Sundaram, M. (2016). 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), 1856-1860. Doi: https://doi.org/10.1109/IMCEC.2016.7867539         [ Links ]

 

Agradecimentos

Este trabalho foi parcialmente suportado por fundos nacionais através da Fundação para a Ciência e a Tecnologia (FCT) com a referência UID/CEC/50021/2019 e pela Comissão Europeia no programa H2020 sobre o acordo de contrato 822404 (projecto QualiChain).

 

Recebido/Submission: 19/07/2019

Aceitação/Acceptance: 21/10/2019

Creative Commons License Todo o conteúdo deste periódico, exceto onde está identificado, está licenciado sob uma Licença Creative Commons