Qualidade da arquitetura empresarial: estudo de caso envolvendo o LeanIX e o ServiceNow CMDB

Universidade do Minho Escola de Engenharia Ana Beatriz Martins da Costa Qualidade da Arquitetura Empresarial: Estudo de caso envolvendo o LeanIX e o ServiceNow CMDB junho de 2022 Qualidade da Arquitetura Empresarial: Estudo de caso envolvendo o LeanIX e o ServiceNow CMDB Ana Beatriz Martins da Costa UMinho | 2022 Ana Beatriz Martins da Costa (85844) Qualidade da Arquitetura Empresarial: Estudo de caso envolvendo o LeanIX e o ServiceNow CMDB junho de 2022 Dissertação de Mestrado Mestrado Integrado em Engenharia e Gestão de Sistemas de Informação Trabalho efetuado sob a orientação do/da/de Professor Doutor Miguel Abrunhosa Brito DIREITOS DE AUTOR Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho Atribuição-NãoComercial CC BY-NC https://creativecommons.org/licenses/by-nc/4.0/ v AGRADECIMENTOS A conclusão do Mestrado Integrado em Engenharia e Gestão de Sistemas de Informação assinala o final de uma das fases mais desafiantes e estimulantes da minha vida. Percorrer este caminho só foi possível com o suporte, energia e força de várias pessoas, a quem dedico especialmente este projeto de vida. Por esse motivo, gostaria de expressar a minha gratidão às pessoas que apoiaram e possibilitaram a conclusão dos objetivos a que me propus ao longo destes anos: Ao meu orientador, Professor Doutor Miguel Abrunhosa Brito, pela motivação, disponibilidade e apoio, agradeço a orientação exemplar e única, marcada por um elevado e rigoroso nível científico, visão crítica e oportuna que contribuiu de forma determinante para o desenvolvimento e conclusão desta dissertação. A todos os professores do Departamento de Sistemas de Informação da Universidade do Minho pela partilha de conhecimento e ideias durante estes anos. À Deloitte Portugal pela oportunidade de realizar o meu estágio de dissertação na empresa e por me ter fornecido todo o apoio necessário à concretização do presente documento. À Inês Afonso Carvalho pelo apoio e por me mostrar o caminho nos momentos em que me senti perdida na elaboração deste projeto de dissertação. À minha família, especialmente aos meus pais, Maria Rosa e Júlio Costa, ao meu irmão, João Pedro, e aos meus avós, pelo apoio incondicional, pelo carinho e por me terem proporcionado a melhor educação possível. À minha tia, Maria do Sameiro, por ser como uma segunda mãe para mim. Ao João Miguel, acima de tudo pelo apoio incondicional, paciência e motivação, por estar a meu lado e por ter acreditado sempre em mim. Aos meus irmãos do curso pela amizade, força e companheirismo ao longo destes cinco anos. Em especial agradecer por não terem desistido de mim numa das piores fases da minha vida, razão pela qual lhes estou eternamente grata. Por fim, um agradecimento a todos os que, de uma forma ou de outra, contribuíram para que a minha caminhada fosse concluída com sucesso. A todos, O meu enorme obrigada. vi DECLARAÇÃO DE INTEGRIDADE Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio, nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas conducente à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho. vii RESUMO Qualidade da Arquitetura Empresarial: Estudo de caso envolvendo o LeanIX e o ServiceNow CMDB A presente dissertação é resultado de um estágio profissional realizado na Deloitte Portugal, com vista à conclusão do Mestrado Integrado em Engenharia e Gestão de Sistemas de Informação. O tema no qual esta dissertação se debruçou foi sobre a Arquitetura Empresarial e o problema que lhe deu origem remete à falta de qualidade da arquitetura empresarial, derivada da desatualização das arquiteturas das organizações. A qualidade da arquitetura empresarial é garantida quando esta se encontra constantemente atualizada. Sem uma manutenção e atualização contínua das arquiteturas, a AE não contém informação necessária para refletir o estado atual da organização e, consequentemente, a integridade da AE não é assegurada. Este trabalho de estágio utilizou como objetivo/estratégia de investigação a metodologia Design Science Rresearch (DSR). O foco deste projeto de investigação centrou-se numa tecnologia de Arquitetura Empresarial, a LeanIX, tendo sido realizada a observação do estado atual da tecnologia, de forma a identificar causas que limitam o seu funcionamento e propor sugestões de melhoria para mitigação, pelo menos parcial, dessas causas. Assim sendo, foram sugeridas propostas de melhoria através de um conjunto de protótipos de solução, construídos de acordo com a vista que proponho. Espera-se que, com a implementação de todas as sugestões de melhoria, haja uma maior manutenção e atualização da arquitetura e, consequentemente, uma melhoria contínua dos processos, um aumento da produtividade, uma redução de custos, entre outros. O objetivo do documento e do trabalho realizado passou por pressupor que, com as propostas de melhoria sugeridas, será possível contribuir para uma maior manutenção e atualização da arquitetura, o que contribuirá para uma melhor qualidade da arquitetura empresarial. Como resultados da tese, foi possível constatar que as propostas de melhoria apresentadas como solução contribuem para a resolução parcial do problema. Para a sua resolução completa, é necessária a integração de todos os sistemas da organização com a arquitetura. viii Tais evidências foram comprovadas por profissionais que certificaram o valor e viabilidade da solução. Palavras chave: Arquitetura Empresarial; LeanIX; Manutenção da AE; Qualidade da AE; ServiceNow. ix ABSTRACT Enterprise Architecture Quality: A case study involving LeanIX and ServiceNow CMDB This dissertation is the result of a professional internship conducted at Deloitte Portugal, to complete the Integrated master’s in engineering and Information Systems Management. The theme on which this dissertation was focused was Enterprise Architecture and the problem that gave rise to it refers to the lack of quality of the enterprise architecture, derived from the outdated architectures of the organizations. The quality of the enterprise architecture is guaranteed when it is constantly updated. Without continuous maintenance and updating of the architectures, the EA does not contain the necessary information to reflect the current state of the organization and, consequently, the integrity of the EA is not assured. This internship work used case study as the research objective/strategy. The focus of this research project was centered on an Enterprise Architecture technology, LeanIX, and the current state of the technology was observed in order to identify causes that limit its operation and to propose improvement suggestions to mitigate, at least partially, those causes. Therefore, improvement proposals were suggested through a set of solution prototypes, built according to the view I propose. It is expected that, with the implementation of all the suggestions for improvement, there will be a greater maintenance and updating of the architecture and, consequently, a continuous improvement of the processes, an increase in productivity, a reduction in costs, among others. The objective of the document and the work done was to assume that, with the suggested improvement proposals, it will be possible to contribute to a greater maintenance and updating of the architecture, which will contribute to a better quality of the EA. As results of the thesis, it was possible to see that the improvement proposals presented as a solution contribute to the partial resolution of the problem. For its complete resolution, it is necessary the integration of all systems of the organization with the architecture. Such evidences were proven by professionals that certified the value and viability of the solution. Keywords: Enterprise Architecture; LeanIX; Maintenance of EA; Quality of EA; SeviceNow. xvi LISTA DE TABELAS Tabela 1 - Benefícios de Arquitetura Empresarial sintetizados a partir da literatura ............. 14 Tabela 2 - Evolução da Arquitetura Empresarial ...................................................................... 20 1 1. INTRODUÇÃO Neste capítulo é apresentado o âmbito da presente dissertação. Primeiramente, é realizado um breve enquadramento (1.1) e apresentação da motivação e problema para a sua realização (1.2), seguindo-se a apresentação dos objetivos (1.3), da abordagem metodológica (1.4) e, por fim, apresentação da estrutura do presente documento (1.5). 1.1 Enquadramento As organizações são constituídas por diferentes unidades de negócio, uma grande variedade de processos, informação, pessoas, ferramentas, estratégias e outros componentes difíceis de observar globalmente, mesmo pelos profissionais mais experientes. No atual panorama empresarial, graças à crescente complexidade que se tem verificado no ecossistema de negócios, existe a necessidade de as organizações se transformarem de forma a prosperarem no futuro. Devido às rápidas e constantes mudanças das condições ambientais, quer ao nível das inovações tecnológicas, com a introdução de novos modelos de negócio, quer pelas crescentes expectativas dos clientes, ou pela imposição de novas regulamentações, existe a necessidade inevitável de se gerir cenários complexos de negócio e das tecnologias nas organizações. A Arquitetura Empresarial (AE) pode mostrar-se um bom aliado neste objetivo por ser usualmente utilizada como instrumento na gestão das atividades diárias de uma organização e no desenvolvimento futuro. Estas atividades desenvolvidas pelas organizações dependem fortemente de sistemas de informação (SI) para o tratamento de informação e, consequentemente das Tecnologias de Informação (TI). Através da posse de um modelo de Arquitetura Empresarial, é possível ter uma visão global da informação na organização, o que facilita e auxilia a comunicação dos stakeholders e a colaboração entre as diversas partes. A AE deve ser vista como uma ferramenta indispensável para o planeamento, gestão e alinhamento estratégico da própria organização, já que viabiliza uma maior capacidade de inovação, transformação, serviços especializados, qualidade superior dos produtos, bem como uma melhor relação com os seus clientes. 2 A redução de custos, a digitalização e automatização de tarefas e processos, uma maior eficiência, o aumento da produtividade, a redução de riscos, a promoção do crescimento e uma maior adaptabilidade são alguns dos objetivos que as organizações procuram alcançar com a obtenção e utilização de uma arquitetura empresarial, contudo a posse de uma AE por si só não garante benefícios à organização, pelo que se aconselha a organização a conhecer o verdadeiro valor da AE. Para que a arquitetura empresarial faça o seu trabalho e acrescente valor à organização, é necessário que toda a informações, dados, processos, arquiteturas e tecnologias estejam em sincronia com o negócio, o que significa que estes necessitam de estar constantemente atualizados, o que requer uma manutenção constante da arquitetura empresarial. É neste sentido, e com foco nas ferramentas de AE e ITSM, que o presente trabalho de investigação se debruça. 1.2 Motivação e Problema O modelo que vai ser proposto no âmbito da presente dissertação surgiu da preocupação evidenciada pela organização no qual esta dissertação foi realizada, a Deloitte Portugal, fornecedora de serviços de auditoria e garantia, consultoria, consultoria financeira e consultoria de riscos e impostos. Atendendo à perspetiva empresarial, a Deloitte proporciona aos seus clientes suporte e completo envolvimento através de uma mistura diligente e bem concebida de talentos humanos. As suas três propostas de valor são acessibilidade, inovação e estatuto devido a uma vasta gama de opções de serviço, mentalidade de melhoria contínua e flexibilidade nos pedidos dos clientes. Quanto ao problema, e tendo em consideração as ferramentas que suportam a Arquitetura Empresarial, antigamente utilizavam-se ferramentas bastante desintegradas e estáticas e, hoje em dia, ainda é possível encontrar organizações que fazem uso das mesmas. Estas ferramentas estáticas não permitem a modelação/construção de diagramas de forma eficiente, nem sequer estão integradas com as soluções de tecnologia (ex. CMDB). Para que a AE apoie a organização, ela tem de ser “viva”, isto é, tem de estar integrada em tempo real com as informações que vem do lado da tecnologia, caso contrário a AE deixa de ter 3 relevância, visto que, como não é atualizada, não fornece informação relevante e, consequentemente, não adiciona valor a quem a usa. Com isto em mente, e de modo a expor a importância que uma manutenção e atualização constante da arquitetura empresarial detém numa organização ao fornecer suporte a uma melhor e mais acertada tomada de decisão, irá ser proposto o desenvolvimento de um modelo de integração entre soluções/ferramentas que não se encontram integradas e que, por isso, não comunicam entre si, de modo a compreender se isso permite contribuir para o problema da desatualização das arquiteturas e consequentemente, para a mitigação do risco de incoerência de dados/informação. Deste modo, pretende-se que, com base numa correta gestão da AE, os arquitetos contribuam para a decisão, transmitindo se de facto determinada alteração faz sentido, identificando melhorias e situações de riscos para que, no caso da existência das mesmas, se possa agir atempadamente. Assim, as organizações são capazes de construir uma visão holística da sua estratégia, processos, informações e ativos de TI para dar suporte a um ambiente de TI mais eficiente e seguro. 1.3 Objetivos do Projeto O principal objetivo da presente dissertação passa por conceber um modelo para a manutenção e atualização das arquiteturas e que garanta a qualidade e coerência dos dados e da informação. Por outras palavras, trata-se de desenvolver uma solução que permita assegurar uma constante manutenção e atualização da Arquitetura Empresarial, visto que, se o domínio das aplicações, domínio no qual se vai intervir, permanecer continuamente atualizado, o domínio dos dados segue o mesmo caminho e, consequentemente, a camada ou domínio estratégico possui todos os dados e informações necessários à tomada de decisões acertada e que beneficiará a organização. Com o propósito de garantir que o objetivo principal desta dissertação é concretizado, são identificados quatro sub-objetivos: • Estudar e selecionar as ferramentas de suporte existentes de Arquitetura Empresarial (AE) e Gestão de Serviços de TI (ITSM); • Conceber e propor a arquitetura para uma solução; 4 • Integrar as ferramentas de Arquitetura Empresarial e ITSM selecionadas após estudo; • Identificar os benefícios e validar a proposta de arquitetura de solução desenvolvida. Deste modo, é expectável que numa primeira fase, através de uma pesquisa intensa por informações relevantes ao tema, se consiga exibir a importância de se manter toda a informação circulante na organização atualizada, para que a arquitetura empresarial consiga fornecer soluções corporativas eficientes. Só assim esta irá conseguir potencializar o negócio, proporcionar um crescimento lucrativo e a execução da estratégia organizacional estabelecida de forma consistente. 1.4 Metodologia Para o desenvolvimento da presente dissertação foram seguidas as orientações do Design Science Research (DSR), devido ao facto da respetiva abordagem metodológica se caracterizar por um conjunto de técnicas de análise e perspetivas para a pesquisa na área de Sistemas de Informação (SI) (Iivari & Venable, 2009), bem como por estar equacionada a criação de um artefacto tecnológico (A. R. Hevner et al., 2004). Segundo Hevner et al. (2004), esta metodologia é normalmente utilizada em duas abordagens de investigação distintas, para construir ou para avaliar, das quais os resultados são extraídos sob a forma de constructos, modelos, métodos e/ou instâncias de determinado artefacto. A. Hevner et al. (2020) afirma ainda que o DSR é um procedimento de pesquisa para produzir uma construção inovadora destinada a resolver problemas enfrentados no mundo real. Assim, a metodologia DSR é frequentemente utilizada como instrumento para a construção de artefactos que têm em vista a solução de problemas de cariz prático, em ambiente real, conduzindo à criação de conhecimento. Na imagem seguinte é possível visualizar o processo metodológico e as respetivas sequência de etapas, sugerida por (Peffers et al., 2007), da metodologia DSR. 5 Figura 1 - Modelo de metodologia do processo DSR Adaptado de (Peffers et al., 2007) Como é possível verificar na Figura 1, um projeto de DSR apresenta seis etapas. Este processo inicia-se com a fase de “Identificação do Problema e Motivação”. Nesta fase, o foco passa por identificar o problema em estudo e para o qual se pretende apresentar uma solução, bem como apresentar a motivação para a pesquisa, sendo assim apresentada uma justificação para o trabalho de dissertação que irá ser realizado. Esta fase encontra-se endereçada na secção 1.2 do capítulo 1 e no capítulo 7. A segunda fase, correspondente à “Definição dos objetivos da solução” encontra-se na secção 1.3 do capítulo 1 e esta, tal como o próprio nome indica, diz respeito à definição dos objetivos, definição que ocorreu com base na exploração do problema identificado na fase anterior. A fase seguinte, “Conceção e desenvolvimento” irá, num primeiro momento, traduzir-se na exploração do tema da Arquitetura Empresarial, presente no capítulo 2 e 3, correspondente à Revisão da Literatura e à “Atualidade da Arquitetura Empresarial”, e, posteriormente, no estudo e seleção das ferramentas a utilizar para proceder à integração. Selecionadas as ferramentas a utilizar, proceder-se-á conceção da proposta da arquitetura para uma solução. O estudo e seleção das ferramentas encontra-se nos capítulos 4, 5 e 6. A conceção da proposta da arquitetura para uma solução encontra-se no capítulo 8. Ainda nesta fase, será realizado um artigo, com vista à exploração do tema principal desta dissertação: A Qualidade da AE. 6 Na quarta fase, correspondente à “Demonstração” irão ser realizadas algumas apresentações, a profissionais com experiência e conhecimento na temática da Arquitetura Empresarial. Nessas apresentações serão exibidos os protótipos criados para a solução proposta. Tais protótipos poderão ser visualizados na presente dissertação, no capítulo 8. A penúltima fase, corresponde à “Avaliação” e, com base na proposta de solução desenvolvida, será necessário efetuar uma avaliação dos resultados obtidos, isto é, uma validação da proposta, e verificar se o objetivo principal da investigação é atingido. Esta fase será validada com base na opinião de alguns dos profissionais que assistiram às apresentações da fase anterior e que responderam a um questionário. As respostas a este questionário encontram-se no final do capítulo 8. A última fase, correspondente à “Comunicação” consistirá em demonstrar a pesquisa feita ao longo destes meses, pela produção e amostra do documento de dissertação e do conhecimento obtido durante a produção do mesmo. 1.5 Estrutura do trabalho Nesta secção é apresentada, de forma breve e sintetizada, a organização e o conteúdo deste documento de dissertação, o qual é composto por 9 capítulos. O Capítulo 1 corresponde à Introdução, e procura descrever, clarificar e justificar o trabalho, os seus objetivos e a sua relevância. É constituído por cinco secções, sendo estas o Enquadramento (1.1), a Motivação e Problema do projeto (1.2), os Objetivos do projeto (1.3), a Metodologia (1.4) e a Estrutura do documento (1.5). Quanto ao Capítulo 2, este alberga a Revisão da literatura, cujo propósito é analisar o que existe na literatura sobre as temáticas em análise nesta dissertação. O capítulo é composto por 1 secção, no qual esta é alusiva à Arquitetura Empresarial (2.1). A conceção do capítulo 3 procura dar a conhecer a atualidade da AE. O capítulo é composto por 1 secção, no qual esta é alusiva ao Alinhamento e dependências entre os diversos domínios da AE (3.1). O capítulo 4 e 5 corresponde ao estudo das ferramentas de AE e ITSM efetuado. Já o capítulo 6 tem como objetivo providenciar os benefícios decorrentes da integração entre ITSM e AE, 7 sendo visível no subcapítulo 6.1 as ferramentas escolhidas para o estudo de caso que se iria realizar. O capítulo 7 relativo à contextualização do problema pretende complementar o subcapítulo 1.2, no qual é apresentada a motivação e o problema do projeto. Assim, neste sétimo capítulo, o objetivo passou por ir à raiz do problema, para que se pudesse ter uma melhor e maior compreensão do mesmo, com base no contexto empresarial em que este surge e se desenrola. O capítulo é composto por 3 secções, sendo estas o “Papel do Arquiteto Empresarial e necessidade da existência do mesmo nas organizações” (7.1), a “Necessidade da existência de uma Arquitetura Empresarial atualizada” (7.2) e “Ferramentas de Gestão da Arquitetura Empresarial” (7.3). Quanto ao capítulo 8, este alberga a Solução e apresenta o trabalho prático de conceção da arquitetura de solução realizado. Neste capítulo é apresentado o Caso de Uso: Integração entre as ferramentas LeanIX e ServiceNow CMDB (8.1), a configuração da integração que foi necessária realizar entre as ferramentas LeanIX e ServiceNow (8.2), a solução proposta (8.3) e, por fim, uma secção alusiva à avaliação da solução proposta (8.4). O capítulo 9 procura concluir o trabalho de dissertação, descrevendo a importância do trabalho efetuado, as lições aprendidas, bem como possíveis trabalhos futuros são apontados. No fim do capítulo são também apresentadas as limitações e obstáculos que foram necessários superar durante a execução do trabalho. Por último, é apresentado uma secção referente às Referências Bibliográficas que foram utilizadas para compreender as diversas temáticas abordadas ao longo da dissertação. 8 2. REVISÃO DE LITERATURA Este capítulo tem como principal objetivo fazer uma revisão bibliográfica acerca das diversas temáticas que servirão de base a esta dissertação. Em primeiro lugar, será apresentada uma breve contextualização do que é Arquitetura Empresarial, evidenciando o contexto histórico, a evolução da AE e os seus domínios, os desafios e benefícios da implementação de uma AE nas organizações, a qualidade da AE, terminando com a importância da manutenção e atualização da AE. 2.1 Arquitetura Empresarial A arquitetura empresarial é normalmente usada como instrumento na gestão das operações diárias de uma empresa e no desenvolvimento futuro. Mudanças rápidas das condições ambientais, como inovações tecnológicas, modelos de negócios recém-surgidos, ou imposições regulatórias tornam a mudança continua, e o desenvolvimento de novos Sistemas de Informação (SI) inevitáveis para a maioria das organizações contemporâneas (Schilling, 2018). Os Sistemas de Informação de uma organização devem ser projetados de forma a permitir que os subsistemas interajam perfeitamente uns com os outros. Sem um plano ou uma arquitetura para orientar o desenvolvimento, os sistemas de uma empresa irão crescer organicamente num nível de complexidade que se torna difícil de gerir e que pode atrapalhar as operações da empresa (Gomes, 2013). Para gerir a complexidade de qualquer organização, é necessário que haja uma arquitetura. Segundo (Meepung et al., 2021), uma arquitetura refere-se aos elementos de um sistema (estrutura, rede, software e hardware). Por outro lado, de acordo com a definição da (ISO/IEC/IEEE (2011), a arquitetura engloba os conceitos ou propriedades fundamentais de um sistema no seu ambiente, incorporados nos seus elementos, relacionamentos e nos princípios do seu design e evolução. 9 Empresa é qualquer conjunto de organizações que têm um conjunto de metas/objetivos e/ou uma única linha de fundo (The Open Group, n.d.). A arquitetura ao nível global da organização é normalmente referida como Arquitetura Empresarial. Definições e padrões para Arquitetura Empresarial (AE) têm sido inconsistentes há mais de 35 anos (Halawi et al., 2019). AE é vista, por um lado, como um tópico de TI, e por outro, é vista como um modelo de negócio e um assunto de estratégia, particularmente na literatura de gestão (Syynimaa, 2018). O Open Group Architecture Framework (TOGAF) apresenta a AE como uma metodologia genérica, mas as descrições das habilidades de AE enfatizam claramente as competências de TI (The Open Group, 2018). Na vida real, a AE inclui quase sempre TI (Walrad et al., 2014). AE cria ligações entre arquiteturas de negócios e arquiteturas de TI e verifica a sua integridade (Helfert et al., 2013); também identifica processos de negócios, aplicações, dados e tecnologia (Strano & Rehmani, 2007) e é um meio de mudança organizacional (Sousa et al., 2011). Na verdade, a AE apoia os executivos em relação à estratégia ideal, fornecendo uma orientação sobre o que é necessário para atingir as metas de negócios. (Gellweiler, 2020). 2.1.1 Evolução da Arquitetura Empresarial Quando se fala em Arquitetura Empresarial (AE) e segundo Kotusev (2016), é muito comum associar a sua origem ao trabalho pioneiro de John Zachman, sendo este frequentemente referido como o “pai” de AE e, ainda, como aquele que criou a Zachman Framework que teria proporcionado o avanço e criado a disciplina de AE, fornecendo as bases para todas as subsequentes frameworks e metodologias de AE. Contudo, os méritos pela criação da disciplina de AE não podem ser completamente atribuídos a John Zachman, dado que, de acordo com o Enterprise Architecture Book Knowledge (EABOK), o estudo de AE começou na década de 1960 e nasceu a partir da análise de vários manuscritos arquitetónicos sobre o Planeamento de Sistemas de Negócios (BSP) do professor Dewey Walker. Zachman, aluno de Walker, ajudou-o a analisar e a estruturar toda a documentação e, em 1987, publicou “A Framework for Information Systems”, no IBM Systems Journal. A framework de Zachman surgiu como forma de dar resposta ao aumento da tecnologia de negócios que se verificava especialmente na década de 1980, quando os sistemas de computadores estavam a começar a ocupar um espaço no local de trabalho das pessoas, 16 (2011) afirmam ainda que, com uma AE de alta qualidade, os resultados obtidos contribuem diretamente para o desempenho organizacional, incluindo menor custos, aumento de receita, diferenciação competitiva, decisões mais precisas, agilidade estratégica, entre outros. Van den Berg et al. (2019) por sua vez, afirma que, a utilização da AE aumenta a qualidade das decisões de investimento em TI e que a maturidade da AE é um indicador de qualidade. O objetivo da maturação de uma prática de AE é aumentar o seu desempenho e eficácia ao atingir uma maior maturidade (Meyer et al., 2011). De acordo com os estudos realizados por van den Berg et al. (2019), estes revelam que as organizações com maior qualidade de AE são as que apresentam maior maturidade e que fazem uso de mais artefactos de AE na preparação de decisões. Segundo Ylimäki et al. (2007), a qualidade da arquitetura empresarial é garantida quando esta se encontra em conformidade com os requisitos de negócio estabelecidos, se encaixa no propósito da organização e, ainda, quando esta satisfaz as necessidades dos stakeholders. 2.1.5 Manutenção e Atualização da Arquitetura Empresarial Os modelos de AE oferecem suporte às metas organizacionais, criando mais transparência, mensurabilidade e consistência (Fischer et al., 2007). Consequentemente e de forma a assegurar uma vantagem competitiva, (Gao, 2001) afirma que os modelos de AE devem permanecer atualizados e refletir o estado atual das estruturas e processos organizacionais. Consequentemente, os modelos AE precisam de manutenção regular (Lankhorst, 2017), um processo tão importante como o seu desenvolvimento original (Gao, 2001). Isso requer processos para gestão e comunicação da AE em geral e, em particular, um design organizacional específico que garanta a integridade e consistência dos modelos de AE ao longo do tempo (Fischer et al., 2007). Desta forma, de modo a assegurar uma vantagem competitiva, as organizações necessitam que as suas arquiteturas estejam constantemente sincronizadas com o seu negócio, ou seja, estas têm de estar sempre atualizadas, o que requer uma manutenção e atualização contínua destas arquiteturas. Tendo como base a definição de manutenção proposta pelo Institute of Electrical and Electronics Engineers (1990), Davoudi & Aliee (2009) definiram a capacidade de manutenção da AE como a facilidade com que os componentes da AE podem ser modificados para corrigir 17 falhas, melhorar o desempenho ou outros atributos, ou adaptar-se a um ambiente alterado. Por outros termos, o custo do impacto das alterações em qualquer componente da AE para outros componentes da AE deve ser o menor possível. De modo a proporcionar uma melhor compreensão da definição proposta por Davoudi & Aliee (2009), estes apresentaram uma definição mais detalhada da manutenção da AE nas diferentes camadas da AE: • Camada de negócios – A manutenção da AE nesta camada corresponde à facilidade com que os componentes estratégicos e as funções e processos empresariais podem ser modificados para corrigir falhas, melhorar o desempenho ou outros atributos, ou adaptar-se a um ambiente alterado; • Camada de dados – A manutenção da AE nesta camada é equivalente à facilidade com que os componentes de dados, incluindo entidades de dados, estruturas de dados físicos, dicionários de dados, documentos e etc., podem ser modificados para corrigir falhas, melhorar o desempenho ou outros atributos, ou adaptar-se a um ambiente alterado; • Camada de aplicações – A manutenção da AE nesta camada diz respeito à facilidade com que um sistema ou componente de software pode ser modificado para corrigir falhas, melhorar o desempenho ou outros atributos, ou adaptar-se a um ambiente alterado. A diferença entre a chamada capacidade de manutenção e a capacidade de manutenção do software é que o contexto da capacidade de manutenção da EA na camada de aplicação é mais amplo do que a capacidade de manutenção do software. Na manutenção de software, o impacto de alterações de componentes de software a outros componentes dentro do software ou diretamente relacionados com o software são considerados, mas na manutenção da EA na camada de aplicação, devem ser considerados todos os tipos de impactos de alterações de componentes de software dentro da empresa; • Camada tecnológica – A manutenção da EA nesta camada corresponde à facilidade com que os componentes tecnológicos, incluindo estruturas de rede, protocolos de rede e infraestruturas de software e hardware, etc., podem ser modificados para corrigir falhas, melhorar o desempenho ou outros atributos, ou adaptar-se a um ambiente alterado. 18 Davoudi & Aliee (2009) concluem afirmando que uma tática para uma melhor manutenção da AE em todas as camadas é proporcionar a rastreabilidade entre diferentes componentes de diferentes camadas, de modo a que, sempre que qualquer componente muda, os componentes relacionados são também atualizados corretamente e que isto pode ser automatizado pelas ferramentas da AE e as suas instalações de rastreabilidade. Segundo Gao (2001), a AE deve permanecer atualizada, caso contrário não passa de mais um plano bem-intencionado para melhorar a organização e que poderá estar a limitar as capacidades da mesma para cumprir os seus objetivos e alcançar a sua missão. Este afirma ainda que a AE deve refletir o impacto das mudanças em curso na função empresarial e na tecnologia na empresa e, por sua vez, apoiar o planeamento de capital e a gestão de investimentos para acompanhar essas mudanças. Consequentemente, isto só é possível se cada componente da AE estiver atualizado. 19 3. ATUALIDADE DA ARQUITETURA EMPRESARIAL Atualmente, as estratégias modernas de AE continuam a apostar na definição de um plano e estratégias para suportar o negócio e o crescimento tecnológico, sendo esta especialmente útil em grandes organizações que apostam na transformação digital e na inovação dos seus negócios, pelo facto de AE se concentrar em reunir processos e aplicações para formar um ambiente mais integrado. A centralização das organizações está a ser substituída pelo aparecimento de organizações descentralizadas e federadas, o que pode indicar uma maior aposta na colaboração entre indivíduos, departamentos e organizações. Isto significa que, apesar de existir uma figura central, esta vai concentrar-se apenas em garantir que existe um alinhamento entre o projeto de AE e os objetivos da organização. Desta forma, as restantes atividades são processadas pelos trabalhadores e estes são incentivados e partilhar informações com diferentes equipas e departamentos, havendo uma maior comunicação, interoperabilidade e coordenação de esforços entre os diversos departamentos das organizações. 20 Tabela 2 - Evolução da Arquitetura Empresarial Em 2011 a Gartner previu que em 2021, a maioria das empresas utilizaria a AE como parte integrante do planeamento de negócios e, a verdade é que, estamos em 2022 e a arquitetura empresarial assume cada vez mais um papel importante na vida das organizações, já não sendo utilizada apenas como uma função de suporte. A arquitetura empresarial apresenta atualmente uma função estratégica e é responsável por projetar uma arquitetura de informação inteligente que oferece suporte à digitalização, transformação e inovação dos negócios. O futuro da arquitetura empresarial passa pela entrega de perceções holísticas e significativas através da entrega de dados e informações precisas e relevantes, relatórios abertos e flexíveis e análises inteligentes que deverão suportar a tomada de decisões em tempo real. A centralização das informações numa única fonte de dados deverá ser algo a adotar, por proporcionar, não só a localização de gargalos e limitações, mas também transparência dentro das organizações. Isto tudo, combinado com uma resolução ágil de problemas, criará um impacto significativo nas organizações, e irá tornar a arquitetura empresarial uma forma de gestão interna. Arquitetura Empresarial (AE) 1990-2000’s Arquitetura Empresarial Atualmente e no futuro Paradigma Equipa AE Programa de AE Organização Altamente centralizada Descentralizada e federada Âmbito Apenas TI Negócios e TI Missão Tecnologia Standard Transformação e Inovação dos Negócios e TI Abordagem Análise e Modelação Resolução ágil de problemas Controlo Governança estritamente restrita Governança mínima e Orientação máxima Objetivo Arquitetura Transformação e Inovação Impacto Mínimo Máximo 21 3.1 Alinhamento e dependências entre os diversos domínios da AE O alinhamento e as dependências dos diferentes domínios da arquitetura empresarial são visíveis na Fig.3, onde é possível verificar que a Arquitetura de Negócios suportada pela Arquitetura de Dados/Informação, determina a Arquitetura de Aplicações, que por sua vez é suportada pela Arquitetura Tecnológica ou de Infraestrutura. De acordo com Mannmeusel (2012) e Fragen, (n.d.), uma capacidade de negócio ou business capability é uma abstração de uma função de negócio e responde à questão "o que é que uma empresa precisa de ser capaz de fazer para ter sucesso?". Uma capacidade de negócio pode ainda ser definida como um bloco de construção funcional da arquitetura de negócios que suporta o modelo e a estratégia de negócios. Define, também, a capacidade de a organização realizar com sucesso uma atividade de negócios única. Os resultados de negócio e as capacidades de negócio são os principais blocos de construção desta nova arquitetura empresarial. Quanto mais complexa é uma organização, mais essencial é compreender-se o contexto da mesma. Este contexto é-nos fornecido pelas capacidades de negócios, ou pelo Mapa de Capacidades, dado que estas representam as atividades mais importantes da organização. Figura 3 - Alinhamento e dependências dos diferentes domínios da arquitetura empresarial 22 As capacidades de negócio estão relacionadas com as aplicações que as suportam. Várias aplicações podem ser mapeadas para uma determinada capacidade de negócio e uma aplicação pode ser utilizada para suportar várias capacidades de negócios. Esse procedimento cria uma visualização das ligações entre arquitetura de negócios e a arquitetura de aplicações. Assim, a divisão da organização em domínios da arquitetura empresarial é fundamental devido ao ambiente complexo que se verifica na mesma e, deste modo é possível conhecerse todos os componentes da organização, como estes se relacionam uns com os outros e com o meio ambiente e a partir daí gerar informações relevantes que irão suportar as decisões estratégicas. 23 4. FERRAMENTAS QUE SUPORTAM A ARQUITETURA EMPRESARIAL Com vista a atender às necessidades existentes na organização, a AE necessita de utilizar arquiteturas com requisitos exigentes. Contudo, estes só podem ser atendidos se os arquitetos tiverem uma forma adequada de especificar arquiteturas e um conjunto de design e estruturação técnicas à sua disposição, apoiadas pelas ferramentas certas. Projetadas para apoiar, não só os arquitetos empresariais, mas também os stakeholders de negócio e TI, as ferramentas de arquitetura empresarial são aplicações de software que suportam a tomada de decisões estratégicas e táticas ao conectarem e recolherem informações entres os diversos domínios de uma organização (negócios, informações, soluções e tecnologias). Através do planeamento, análise, design e execução estrategicamente orientados, estas aplicações fornecem uma disciplina de planeamento estratégico que conduz a resultados de negócios direcionados. Devido ao armazenamento, estruturação, análise e apresentação de informações relacionadas à arquitetura empresarial, estas aplicações auxiliam no processo de decisão relativamente a possíveis investimentos e desenvolvimento de soluções de TI, viabilizando o sucesso dos negócios. Para manter a relevância no mercado, existem 5 casos de uso ou características que a Gartner (2021) considera que as aplicações de AE devem possuir para que estas apoiem os profissionais de AE: • Capturar, estruturar, analisar e apresentar modelos – Os profissionais da AE precisam de modelar capacidades de negócios futuras e atuais, processos e regras, informações, recursos, ecossistemas, aplicações, produtos e serviços; • Apoiar mudanças, transformação e otimização – Os arquitetos empresarias planeiam e acompanham a mudança, e as aplicações devem facilitar o desenvolvimento de novos serviços e produtos, bem como apoiar aquisições, fusões e desinvestimentos; • Avaliar e gerir um portfólio de TI em evolução – Entregar valor de negócios significa projetar serviços, gerir portfólios de TI e arquitetura de soluções, orientar projetos de tecnologia, otimização de custos/receitas e mitigação de riscos; • Gestão de arquitetura corporativa – Para atender à procura dos stakeholders, os fornecedores de aplicações de AE necessitam de fornecer um conjunto ágil e convincente de serviços e gerir os conhecimentos e recursos à sua disposição; 24 • Inovação – Ajudar as organizações a procurar e aproveitar tendências emergentes e tecnologias digitais com suporte a métodos e ferramentas estruturados, flexíveis e iterativos. A Gartner disponibiliza todos os anos um quadrante mágico concebido por especialistas para o mercado de ferramentas de AE. Este quadrante baseia a sua avaliação em 15 critérios, sendo que dois desses critérios se referem a funções do produto ou serviço e os outros 13 critérios se focam na capacidade de os fornecedores atenderem aos requisitos do mercado. Figura 4 - Quadrante Mágico para ferramentas de Arquitetura Empresarial Fonte: Gartner, 2021, p.5. Tal como é possível observar na Fig.4, existem diversas ferramentas de AE que se distinguem uma das outras devido às suas características únicas. Seguidamente, irei dar a conhecer três dessas ferramentas, realçando alguns dos seus pontos fortes, bem como alguns pontos fracos 25 ou cuidados que cada aplicação deve ter, se eventualmente quiser melhorar a sua posição no mercado. • BiZZdesign O BiZZHoriZZon do Bizzdesign, ferramenta líder no Quadrante Mágico da Gartner, é uma plataforma de SaaS que opera predominantemente ao nível dos setores financeiro e governamentais, e a sua presença observa-se essencialmente na Europa, Médio Oriente e África, e está a ganhar terreno na América do Norte. Esta aplicação auxilia as organizações ao garantir o sucesso dos seus investimentos, bem como o sucesso de iniciativas de transformação e gestão de risco. Para além disso, o suporte a decisões de funções específicas, a manutenção aprimorada de dados através da automatização de processos e o foco contínuo na arquitetura de segurança, são outras características que tornam esta aplicação tão requisitada nos dias de hoje. A migração que ocorreu em 2021 do BiZZHoriZZon para uma arquitetura distribuída em cloud elevou a disponibilidade e resiliência da aplicação, possibilitou um maior número de atualizações e ofereceu uma maior configurabilidade e extensibilidade. Para além deste ponto forte, a Gartner (2021) evidencia ainda as parcerias feitas com especialistas do setor de AE e a inovação verificada devido ao investimento numa nova equipa de pesquisa de experiência de cliente, que resultou num aumento de rendimento de ideação, prototipagem, teste e validação de novas ideias. A presença geográfica limitada, os preços complexos praticados pela BiZZdesign, o suporte operacional limitado e a relação entre a modelação e a análise, que deveria ser mais uniforme, são apontadas como pontos fracos e que devem ser melhorados. • Ardoq O Ardoq, fundado em 2013, fornece uma solução SaaS dinâmica em cloud e baseada em dados. Encontra-se estabelecida essencialmente na América do Norte e na EMEA, com forte presença nos setores público, financeiro e energético. Apresenta-se essencialmente como uma ferramenta de documentação e visualização baseada em dados que possui como objetivo a unificação dos negócios e TI. Devido à capacidade de organização de dados não estruturados, esta ferramenta exibe cada vez mais um papel importante nas organizações. De acordo com a Gartner (2021), os pontos fortes desta solução são a otimização da experiência 32 ITSM, é sigla para Information Technology Service Management, e que significa Gestão de Serviços de Tecnologias de Informação. ITSM concentra-se na definição, gestão e entrega de serviços de TI para dar suporte às metas de negócio de uma empresa e às necessidades dos clientes. O ITSM é amplo, abrangendo o planeamento, entrega, suporte e segurança de TI. Em contraste com as abordagens tradicionais orientadas às tecnologias para as operações de TI, o ITSM é uma disciplina para serviços de TI orientados a processos e definidos pelo cliente, e é um movimento em direção à gestão de TI ‘como um negócio’ (Winniford et al., 2009). Os prestadores de serviços operacionais de TI devem planear e assegurar constantemente a qualidade dos serviços e o relacionamento com o cliente, de modo a garantir a entrega de valor das operações de TI ao mesmo. Posto isto, é possível compreender que a Gestão de Serviços de TI é um conjunto de fluxos de trabalho e ferramentas que servem para desenvolver, fornecer, gerir e suportar, de forma adequada, os serviços de TI e que o bom funcionamento e sucesso de uma empresa ou organização está diretamente relacionado com uma correta e eficiente Gestão dos Serviços de TI. As Tecnologias de Informação tornaram-se um mecanismo de entrega de serviços fundamental para todas as organizações e, o rápido crescimento das empresas de tecnologia e dos recursos tecnológicos originou, de um modo geral, a estruturação de boas práticas, para orientar a gestão de serviços de tecnologia, tendo-se estas revelado fundamentais para assegurar a qualidade, rendimento, economia e produtividade nas empresas. O ITIL, Information Technology Infrastructure Library, é uma estrutura que descreve as melhores práticas em gestão de serviços de TI, provenientes dos setores internacionais público e privado. Fornece uma estrutura de orientação abrangente, prática e comprovada para estabelecer um sistema de gestão de serviços de TI, incentivando a consistência e melhoria contínua para empresas que usam serviços habilitados para TI (Introductory Overview of ITIL ® 4 i ITIL ® OFFICIAL PUBLISHER Introductory Overview of ITIL ® 4, 2020). O foco na medição e melhoria contínua da qualidade do serviço de TI entregue, ocorre tanto da perspetiva da empresa, como da perspetiva do cliente (Cartlidge et al., n.d.). A framework ITIL, destacou-se, não só pela sua capacidade de adaptação a diversas realidades de negócios, bem como por descrever tarefas, processos e procedimentos aplicados à gestão de serviços de TI. Estes recursos permitem às empresas integrar as TI com a estratégia da 33 empresa e, ainda que vá ocorrendo uma entrega de valor, enquanto se vão mantendo os níveis de competência e qualidade. A framework permite ainda estabelecer as linhas de base para que se possa planear, implementar, avaliar, e mostrar que tudo aquilo que foi executado até ao momento, está de acordo com o que foi previamente planeado e estipulado. A tecnologia é parte integrante dos processos de TI, mas não deve necessariamente ser o foco principal (ServiceNow, n.d.-b). Como resultado da abrangência de ITSM a objetivos de negócio que não os objetivos tradicionais de TI, este melhora a eficiência de modo geral e faz-lho das seguintes formas: • Gestão de incidentes (Incident Management); • Gestão de problemas (Problem Management); • Gestão de mudanças e lançamentos (Change and release management); • Gestão de nível de serviço (Service-level management); • Gestão de solicitações (Request management); • Gestão de configurações (Configuration management); • Gestão de melhoria contínua (Continual improvement management); • Fluxo de trabalho e Gestão de Talentos (Workflow and talent management). Tal como mencionado anteriormente, a abordagem estratégica para a gestão de TI, ITSM, foca-se na entrega de valor ao cliente e, por descrever os processos e as ferramentas que as equipas de TI utilizam para gerir os serviços de TI, de uma ponta à outra da organização, esta abrange todas as tecnologias de informação dentro de uma determinada organização. Deste modo, o ITSM define claramente os papéis e responsabilidades de cada indivíduo e departamento e, de acordo com a ServiceNow e no que toca aos serviços de TI, permitindo, entre muitos aspetos, uma melhoria da experiência do utilizador, consolidação dos serviços de TI, um aumento da produtividade, uma redução de custos e uma maior satisfação por parte do cliente (ServiceNow, n.d.-b). 5.2 CMDB Hoje em dia, a maioria das organizações é completamente dependente das TI para lhes permitir alcançar as suas visões, estratégias e objetivos de negócios (Na-Lampang & Vatanawood, 2017). Para conseguir assegurar estas conquistas, é crucial gerir corretamente 34 os serviços de TI e, por este motivo, o ITSM tornou-se um dos problemas mais críticos enfrentados pelas organizações modernas. Segundo o ITIL, a CMDB (Configuration Management Database) constitui a base para uma gestão eficaz e eficiente dos serviços de TI (Jelliti et al., 2010). A CMDB é o núcleo de todo o sistema ITSM, fornecendo informação para suportar todos os processos ITSM (Wu, 2014). Wu (2014) defende ainda que um bom ITSM depende de uma CMDB bem construída, contudo, na prática, muitos projetos CMDB sofrem de mau planeamento, operação deficiente e manutenção inadequada, o que dificulta drasticamente a eficácia do ITSM, ou seja, sem uma CMDB eficaz, torna-se difícil compreender e gerir os principais ativos e recursos de TI no ambiente de TI. Uma CMDB é uma base de dados utilizada por uma organização para armazenar informação sobre ativos de hardware e software, comummente referidos com itens de configuração (CIs). A CMDB funciona como um repositório de dados que, não só armazena informação sobre os bens e ativos (CIs) existentes na organização, mas também sobre as suas relações com diferentes CIs. Compreender como cada CI se integra com outras CIs é fundamental para compreender, gerir e informar sobre os serviços prestados à organização. À medida que uma organização insere mais CIs no sistema e se torna mais complexa, a CMDB torna-se um recurso mais forte para prever mudanças dentro da organização (Tzanavara et al., 2019). Uma CMDB fornece uma visão organizada dos dados de configuração e um meio de examinar esses dados a partir de qualquer perspetiva desejada (Tzanavara et al., 2019). Desta forma, a CMDB promove uma maior visibilidade e transparência sobre toda a infraestrutura e serviços, permitindo uma identificação de falhas mais rápida e eficaz. Uma outra vantagem é que, quando é necessária uma mudança, a equipa pode dar uma vista de olhos à CI que necessita de alteração e compreender como esta está relacionada com os outros serviços. A manutenção da CMDB e dos seus registos (CIs) é assegurada pelo processo de Gestão da Configuração. Assim, a Gestão da Configuração deve identificar, registar e reportar todos os componentes de TI, bem como fornecer um modelo lógico da infraestrutura ou de um serviço através da identificação, controlo, manutenção, e verificação das versões do inventário das CI na CMDB (Correia & Abreu, 2009). Os profissionais de TI utilizam o ServiceNow CMDB para trazer visibilidade ao seu panorama de TI, para que possam concentrar a sua atenção na tomada de decisões baseadas em factos 35 e no fornecimento de serviços de TI críticos para o negócio, que potenciem a empresa. Dado que a CMDB é parte integrante de uma organização, esta pode fornecer uma enorme proposta de valor para apoiar decisões a todos os níveis de atividade. Outro aspeto que se deve salientar quanto à importância da CMDB, é que esta possui todos os componentes que formam a AE, pelo que se esta não estiver atualizada, não é possível haver uma AE de suporte confiável. Assim, é possível compreender a importância que uma CMDB atualizada tem nas organizações, visto que, se esta permanecer constantemente atualizada, irá melhorar drasticamente a capacidade de prestação de serviços. 36 6. BENEFÍCIOS DECORRENTES DA INTEGRAÇÃO ENTRE AE E ITSM Um dos benefícios percebidos do uso das TI é o aumento da precisão e rapidez da informação que ajudou muito as operações de uma instituição ou organização (Hermanto & Supangat, 2018). Embora o ITSM e a AE sejam ambos abordagens de gestão e orientados para o negócio, têm um enfoque diferente (Gama et al., 2015). Segundo Sousa et al. (2013), a AE resume os componentes relevantes numa organização, a forma como estão relacionados, e como se relacionam e trabalham em conjunto numa arquitetura diferente e com visões diferentes, enquanto que ITSM é um modelo de referência com uma abordagem integrada para a prestação eficaz e eficiente de serviços de TI, proporcionando um melhor alinhamento de TI com as necessidades das organizações, com redução de custos e riscos. Para além das dificuldades associadas à governação de ambas as iniciativas, se os projetos de AE e ITSM forem desenvolvidos em paralelo, em determinada organização, as respetivas equipas trabalham de forma independente, não partilhando conhecimento, o que se traduz numa duplicação de investimentos em recursos e esforços, perdendo sinergias e aumentando os custos. De acordo com (Radhakrishnan, 2008) existem diversos benefícios decorrentes da colaboração entre as equipas de EA e ITSM, sendo alguns destes benefícios os seguintes: • Aprendizagem organizacional – as duas equipas podem aprender uma com a outra e assim ter um maior impacto na sua empresa (tanto o lado empresarial como o lado informático da sua empresa); • Evitar a duplicação de esforços - não se quer que ambas as equipas desenvolvam a arquitetura ITSM em paralelo sem conhecerem o esforço da outra equipa; • Reutilização da documentação e outras saídas - as saídas do Processo AE são úteis como entradas do Processo ITSM e vice-versa; • A comunicação e colaboração constantes são necessárias para a troca de informações e conhecimentos. A formação cruzada entre as duas equipas pode ajudar na colaboração a um nível mais profundo e na melhoria do moral (mantê-los entusiasmados com o seu trabalho); 37 • A colaboração através de conjuntos de ferramentas integrados pode ajudar a desenvolver e manter uma visão consistente dos Processos e Serviços Empresariais (AE) e dos Processos e Serviços de TI (ITSM); • A arquitetura-alvo da AE e de ITSM pode ser planeada e implementada com um método coordenado e integrado. 6.1 Integração entre LeanIX e ServiceNow CMDB Para gerir e melhorar eficazmente os sistemas de TI e a própria AE, é imperativo saber exatamente o que está a ser utilizado no ambiente de TI da organização, bem como é essencial haver um acesso a dados de configuração atuais e precisos. Com as informações atualizadas em tempo real na CMDB do ServiceNow, as decisões ficam mais fáceis de tomar, especialmente as que concernem à análise de impacto do serviço, gestão de ativos, conformidade e gestão de configuração. Com isto em mente, o LeanIX e o ServiceNow são as duas soluções escolhidas como exemplo para explorar a resolução do problema da desatualização da AE, tendo em conta que são duas das soluções líderes de mercado nas suas áreas, com base no estudo de ferramentas efetuado e por se complementarem, permitindo um fluxo transparente de dados entre os dois sistemas. A integração entre o LeanIX e o ServiceNow CMDB alinha as operações e a tomada de decisões estratégicas usando uma integração automática e bidirecional (Moné, n.d.). As arquiteturas devem ser desenvolvidas e geridas numa ferramenta de arquitetura empresarial, tal como o LeanIX, que abranja a organização e que, consequentemente, alimente a área de operações de TI com informação sobre o ciclo de vida de cada aplicação, etc. O ServiceNow, é o sistema operacional responsável por alimentar o LeanIX com desempenho e emitir estatísticas para fornecer uma imagem clara e abrangente da organização. Esta imagem permitirá à camada de gestão tomar melhores decisões de investimento estratégico, tecnológico e empresarial. Devido a esta integração, os arquitetos empresariais têm a oportunidade de mitigar a obsolescência da tecnologia, isto é, identificar tecnologias em fim de vida e as suas dependências, o que permite reduzir o risco de incidentes de TI, evitar custos adicionais e a existência de uma maior proteção contra ataques de segurança. Os arquitetos empresariais podem também aproveitar a análise flexível dos ciclos de vida e os seus impactos no cenário 38 de aplicações para ajustar o roteiro das TI. A adoção mais rápida de tecnologias modernas e a geração de insights e relatórios poderosos e precisos são outros dos benefícios percebidos desta integração entre o LeanIX e o ServiceNow CMDB e que beneficia os arquitetos e a organização. A ServiceNow Store (n.d.) revela que a integração permite que exista uma queda de 80% nos incidentes de TI, ao identificar tecnologias sem suporte e as suas dependências e acredita ainda que, com a integração e colaboração entre as duas tecnologias, a produtividade das equipas pode ser aumentada em cerca de 25%. É de notar que, embora já existam benefícios decorrentes de uma integração entre estas tecnologias, ainda há um longo caminho a percorrer que será abordado nos capítulos seguintes e que o presente trabalho procura endereçar. 39 7. CONTEXTO DO PROBLEMA 7.1 Papel do Arquiteto Empresarial e necessidade da existência do mesmo nas organizações Nas organizações existe muito uma tendência de se pensar numa solução antes de se lidar com o problema e compreender a sua origem. Esta tendência incita, muitas vezes, ao uso de uma abordagem bottom-up - pensando de baixo para cima -, que, embora seja uma abordagem rápida e prática, impulsiona a organização a focar-se no que é alcançável e pragmático, em oposição ao que é realmente ideal e desejável. Isto faz com que o foco seja manter a situação atual, ao invés de se construir algo novo e melhor para o futuro da organização. Seguindo uma abordagem top-down, muito mais do que pensar na solução, é pensar primeiro no que a solução tem de oferecer aos clientes e os serviços que esta tem de providenciar internamente. Não esquecendo que a Arquitetura Empresarial trata, essencialmente, dentro das suas duas categorias (Business Architecture e Enterprise Architecture) da definição do problema e do caminho para chegar à solução, uma das grandes dificuldades observadas nas organizações remete para a falta de recursos como arquitetos empresariais que consigam definir e identificar problemas da organização e possuir uma visão abrangente da mesma, recorrendo a uma combinação entre a abordagem top-down e a abordagem bottom-up, que os permite ter uma visão holística. Ao encarar o estado atual da organização e tendo em conta o estado futuro desejado, o papel do arquiteto passa por propor soluções criativas e inovadoras, mas pragmáticas e viáveis, que vão ao encontro dos requisitos específicos do negócio. Assim, recorrendo a uma combinação entre ambas as abordagens, não se perde o foco no negócio, na missão, visão e modo de funcionamento da organização, conseguindo-se obter uma maior agilidade, dirigindo-se mais facilmente à era digital da AE. 40 De forma resumida, pode entender-se que a proposta de valor de um grande arquiteto empresarial é a sua capacidade analítica e o seu conhecimento de negócio, o que se traduz facilmente nas seguintes ações: • Criar KPI's e consequente medição da performance atual com base nos mesmos, de modo a definir um roadmap que permita atingir o estado futuro desejado; • Identificar qual é a verdadeira fonte de uma "deficiência" organizacional e qual é a maneira mais simples e bem-sucedida de eliminar a mesma; • Desenvolver a arquitetura empresarial para ajudar os stakeholders a tomarem decisões complexas. Posteriormente, os arquitetos ajudam os stakeholders a criar as mudanças que melhoram as organizações. 7.2 Necessidade da existência de uma Arquitetura Empresarial atualizada Atualmente, diversas organizações falham na introdução de novas ofertas de produtos e/ou serviços por ignorarem os impactos na organização, devido à falta de informação. Devido à falta de uma visão holística, as organizações acabam por se focar, quase sempre, nas alterações evidentes em processos e atividades, definindo, inclusive, que software será utilizado. Contudo, acabam por ignorar completamente o modo como os dados serão integrados com o que está “a funcionar” na aplicação e, também, a infraestrutura que precisa ser suportada. Com tudo isto em mente, a arquitetura empresarial é importante, pois produz artefactos que conseguem indicar, por exemplo, que processos de negócios seriam impactados por determinada alteração e/ou atualização de uma capacidade de negócio. Ou ainda, que aplicações são necessárias para o funcionamento de uma determinada capacidade de negócio, departamento e quais fontes de dados devem ser preservadas, integradas ou atualizadas. Quando a organização precisar de providenciar algum produto ou serviço, deve olhar para as capacidades de negócio, pois quando for necessário escolher que aplicação ou aplicações vão ser necessárias para concretizar determinado processo de negócio, este terá sido definido com base nas capacidades de negócio. 41 A integração em tempo real com as informações que vem do lado da tecnologia e dos diversos sistemas da organização é fundamental para que se mantenha a Arquitetura Empresarial “viva”. Sem esta integração, a AE não permanece atualizada, o que impossibilita o fornecimento de informação relevante aos arquitetos empresariais e à camada estratégica. Consequentemente, a AE deixa de ter valor, visto que não apoia a organização, nem contribui para a tomada de decisões complexas e importantes. Figura 5 - Modelo de dados da AE e os vários sistemas existentes na organização Se não houver uma atualização e manutenção constante da informação que circula nos vários sistemas (ITSM, BPM, EAP, BI, PPM…) com a arquitetura, esta irá acabar por falhar em contribuir para antecipar problemas, riscos, estratégia, entre outros. Na figura 5, é possível verificar alguns dos imensos sistemas existentes na organização, os quais devem permanecer continuamente atualizados, para que o problema da desatualização da arquitetura não se verifique. 48 Figura 15 - Passo 5 da criação da aplicação no ServiceNow Posteriormente, no LeanIX, na secção “Inventory”, e aplicando-se o filtro “Application”, são exibidos todos os Factsheets existentes de Aplicações. Pesquisando pela aplicação criada no ServiceNow (Teste_App), é possível encontrá-la. Acedendo a esta aplicação é possível visualizar que a integração entre o LeanIX e o ServiceNow se encontra ativa, aparecendo esta a verde. 1. Clicar em “Inventory”; 2. Filtrar por “Application”; 3. Clicar em “Teste_App”; 4. Verificar que a integração com o ServiceNow se encontra ativa. Figura 16 - Passos 1,2 e 3 da visualização, no LeanIX, da aplicação criada no SN 49 Figura 17 - Passo 4 da visualização, no LeanIX, da aplicação criada no SN 8.3 Solução proposta Para endereçar o problema da desatualização da arquitetura, a solução proposta encontra-se dividida em três partes: • Para responder ao primeiro problema identificado no LeanIX, nomeadamente, a impossibilidade de ver os impactos das atualizações de aplicações noutras aplicações (dependentes), a solução proposta envolve a visualização, em diagramas, dos impactos de uma alteração nas aplicações dependentes; • Para responder às situações de risco criadas pela falta de visibilidade sobre as modificações em aplicações que colocam em perigo toda a organização, a segunda parte da solução proposta implica a introdução de parâmetros ou regras operacionais, através da lógica; • A melhoria ou evolução da Technology Risk Management dashboard e a criação de notificações e alertas automáticos que surgem em situações de risco e na existência de modificações nas aplicações, fazem parte da solução global, que irá ser apresentada na terceira parte. 50 Figura 18 - Proposta de solução 8.3.1 Solução – Parte I Quando determinada aplicação é alterada no ServiceNow CMDB, há uma replicação ou atualização automática dessa alteração no LeanIX. Contudo, quando uma aplicação é alterada, seja por motivos de atualização por necessidade de mudança da mesma, ou por erro humano, essa alteração pode ter impacto noutras aplicações (parent ou child) ou noutros componentes e não há nenhuma notificação ou sistema de controlo que permita alertar para, por exemplo, uma possível colisão, falha, ou para determinado fator de risco. Com isto em mente, a primeira parte da solução corresponde à visualização, em diagramas, dos impactos de uma alteração em aplicações dependentes. O esperado é que, com a integração entre o LeanIX e o ServiceNow, sempre que ocorrer uma alteração numa aplicação no ServiceNow CMDB, e se aceder a um diagrama no LeanIX que contenha a aplicação modificada, a aplicação modificada deve surgir vermelho e as aplicações ou componentes dependentes (parent e child) modificados devem surgir a laranja. Com a introdução desta nova funcionalidade, o objetivo é que o arquiteto possa assim verificar o impacto da alteração na aplicação no sistema organizacional circundante. 51 8.3.2 Solução – Parte II A segunda parte da solução surgiu devido à ausência de um sistema de alerta para controlar e/ou monitorizar a existência de possíveis SPOFs (Single Points of Failure) ou para a falta de redundância e disponibilidade e fiabilidade num sistema. A segurança é uma prioridade para qualquer organização. Embora a tecnologia traga imensos benefícios às organizações, ela também as expõe aos mais diversos riscos de segurança. Uma arquitetura empresarial permite obter um quadro geral da situação da organização e é a partir dessa visão geral que se pode planear a segurança da mesma. Todas as empresas possuem níveis diferentes de criticidade, níveis diferentes de SLA, disponibilidade, redundância e confiabilidade, que devem ser controlados para que a organização possa funcionar em pleno. Com isto em mente, a segunda parte da solução corresponde à introdução no LeanIX de parâmetros ou regras operacionais, através de lógica. Figura 19 - Visualização dos impactos em diagramas 52 Com a introdução destas regras operacionais, pretende-se criar um sistema de alerta para controlar a existência de falhas, pela criação de regras/parâmetros de segurança para aplicações críticas. O objetivo é avaliar desvios ou situações de risco que possam comprometer o sistema e toda a organização e, ainda, mapear o risco, através de lógica, relativamente a situações de risco, e utilizar os dados que existem para rapidamente fazer flags ou notificar o arquiteto de que existem coisas que não estão de acordo com a definição de standards que foi feita a nível de enterprise. Com base nos dados que a aplicação contém, o LeanIX poderia assim dar ao utilizador indicadores gerais da situação de segurança. A figura exibida acima (Fig.20), representa a criação de uma nova funcionalidade que permita a definição de parâmetros para aplicações críticas. Aquando da atribuição da característica de aplicação crítica a determinada aplicação (Fig.21), esta irá seguir os parâmetros estabelecidos, caso contrário, será gerado um alerta (Fig.22). Figura 20 - Regras de segurança para aplicações críticas 53 Com a criação desta nova funcionalidade, através de um alerta ou notificação, o arquiteto pode ver quais os parâmetros que não estão a ser cumpridos e que podem ter impacto nos sistemas e na organização. Figura 21 - Atribuição da característica "Aplicação crítica" Figura 22 - Alerta gerado em situações de perigo 54 8.3.3 Solução – Parte III Em modo de contextualização, na ferramenta LeanIX, os “to-dos”, ou “novas tarefas” representam uma funcionalidade disponibilizada para que o utilizador possa atribuir tarefas a outros utilizadores, bem como receber e trabalhar em tarefas que lhe tenham sido atribuídas. Quanto aos to-dos, já é possível fazer a atribuição de to-dos e visualizar os mesmos na dashboard, através da atribuição de pessoas responsáveis pelos fact sheets (fig.23). Contudo, tal como é possível visualizar na fig.24, o processo de atribuição de tarefas (to-dos) não ocorre de forma automática, pelo que é ainda um processo manual, tal como é possível verificar na imagem seguinte. Dashboar Figura 23 - Processo de atribuição de responsáveis pelos fact sheets 55 E o problema é que, sempre que ocorre uma alteração em determinada aplicação, por exemplo, não existe um alerta automático que possa notificar o arquiteto de que houve alterações e que este deve verificar os impactos dessas alterações em aplicações ou componentes dependentes. Figura 24 - Processo manual de atribuição de to-dos 56 Para resolver esta questão, as notificações poderiam aparecer como pop-up ou então na dashboard, na zona dos “my to-dos”, tendo por base um sistema de flag e assim garantir-seia a qualidade da informação. Adicionando um subscritor a determinada aplicação e atribuindo a determinada pessoa o role de “Application Owner”, este ficaria responsável pela manutenção da aplicação e, no caso de ocorrer alguma alteração numa aplicação, apareceria uma notificação nos “My-to-dos” para o arquiteto ir verificar a aplicação, pois este é o application owner dessa aplicação. Com isto em mente, a terceira e última parte da solução envolve a melhoria ou evolução da dashboard “Technology Risk Management (TRM)”, na plataforma LeanIX, para que, sempre que ocorrer uma situação de risco ou alguma modificação numa aplicação, sejam automaticamente criados notificações e alertas que sinalizem o utilizador responsável pelas mesmas para: • Potenciais situações de riscos que possam comprometer o sistema; • Alterações realizadas em aplicações e necessidade da visualização dos impactos das mesmas nos diversos componentes do sistema. A dashboard proposta deverá incluir as seguintes funcionalidades: • Critical Alerts * – Zona onde poderia ser fornecida a informação de quantos alertas críticos foram gerados na ausência do utilizador; • Notifications * – Notificações gerais sobre o sistema; • Last Sucessful Synchronization with CMDB * – Secção responsável pela disponibilização de informação acerca da última sincronização com a ServiceNow CMDB, sendo possível uma sincronização em tempo real através do botão "Sync"; • Subscribed Fact Sheets * – Divisão que contém todos os facts Sheets que o utilizador subscreve; • My to-dos * – Secção da dashboard responsável por alertar o utilizador das tarefas que lhe foram atribuídas, por ter subscrito determinado fact sheet. Nesta secção irão aparecer alertas automáticos sempre que uma determinada aplicação for alterada, para que o arquiteto possa ver os impactos dessa modificação. Ao ir verificar os 57 impactos dessa alteração, o utilizador deverá ser redirecionado para um diagrama de impactos (diagrama mencionado na primeira parte da solução). • Last Updates * – Divisão que contém informação acerca dos últimos fact Sheets que foram acedidos e/ou atualizados. Nesta divisão, os fact sheets atualizados apareceriam a uma cor diferente dos restantes fact sheets, pois, atualmente, o que acontece é que sempre que um fact sheet é acedido, esse aparece nos “Latest Updates”, mesmo que não tenham sido feitas quaisquer alterações; • Latest Updates need checking * – Secção que contém os fact sheets que requerem atenção do utilizador, devido a potenciais situações de risco. As funcionalidades que apresentam um “*” no final, representam funcionalidades novas e propostas, e que, por isso, não existem atualmente no LeanIX. O objetivo da melhoria da dashboard TRM é que se possa encontrar num só local, todas as informações e alertas sobre situações que possam comprometer o sistema e, consequentemente, a organização. Figura 25 - Dashboard Technology Risk Management 64 possível a obtenção de dois meses de acesso à tecnologia LeanIX. Tendo isto em conta foi mencionado que, mesmo apesar destas adversidades, foi possível a identificação de problemas importantíssimos da tecnologia e conceber uma resposta aos mesmos. • Mencionaram ainda que a solução apresentada toca em “dores” sentidas pelos clientes e mesmo pela equipa de developers, pelo que decidiram marcar uma reunião com a equipa de product development, para que se pudesse ter a oportunidade de apresentar as propostas de melhoria e compreender ainda melhor o seu valor. Marcada a reunião com a equipa de product development, chegou o momento de apresentar a solução ao Bhagirath Bhardwaj, product manager da LeanIX. Este afirmou que: • A solução apresenta “bastante potencial” e estava totalmente de acordo que a solução traria os benefícios mencionados no subcapítulo 8.4 referente aos “benefícios da solução proposta”; • A funcionalidade que permite a visualização dos impactos em aplicações e/ou componentes dependentes possui uma grande relevância e não é somente relevante para a integração entre o LeanIX e o ServiceNow, confirmando que deveria ser algo implementado a todos os sistemas e integrações da organização; • Achou a primeira – visualização dos impactos de alterações em aplicações dependentes – e a segunda parte - introdução de parâmetros ou regras operacionais, através de lógica – muito “valiosas”, mas demonstrou particularmente interesse pela terceira parte da solução – evolução da dashboard TRM. As suas palavras para descrever a dashboard foram “completamente perfeita”, confirmando que esta precisava definitivamente de melhorias. De todas as funcionalidades apresentadas na dashboard, realçou o seu favoritismo pela “sincronização em tempo real com a CMDB”, afirmando que, embora seja algo que se “possa fazer manualmente nas definições da ferramenta, é muito valioso para o cliente possuir esta funcionalidade na dashboard, visto que assim é possível dar update aos dados e informação em tempo real e, inclusive, saber quão atualizada está a informação no momento”. O feedback fornecido pela Inês Carvalho Afonso, consultora de negócios e profissional responsável pelo acompanhamento desta dissertação, e que esteve presente durante todas as reuniões de apresentação da solução foi o seguinte: 65 • Considera que a solução pode melhorar significativamente a gestão de EA e, consequentemente, o próprio negócio das organizações; • A solução proposta consegue contribuir para a resolução do problema exposto (arquiteturas desatualizadas), contribuindo para uma gestão proativa de AE; • Considera ainda que seria muito interessante, num trabalho futuro, ver esta solução implementada com um caso de estudo/piloto, para explorar/determinar os impactos de utilizar esta solução numa dada organização. Tiago Garrido, consultor sénior da Deloitte Portugal e utilizador recente da ferramenta, também acompanhou o desenvolvimento da solução e, pelo que foi possível verificar na sua resposta ao questionário: • Considerou a solução útil e valiosa; • De entre os benefícios que este achou que a solução poderia providenciar, salientou três, nomeadamente a diminuição da realização de tarefas manuais, devido há implementação de notificações automáticas, a visualização dos impactos de uma alteração nas aplicações e/ou componentes dependentes que deverá permitir a identificação e mitigação de possíveis riscos que possam surgir com a alteração de uma aplicação e, por fim, o surgimento de informação com maior qualidade que irá beneficiar a organização devido à tomada de decisões com base em informações e dados mais atuais e adequados. Ao questionário respondeu ainda um outro profissional, após a reunião com a equipa de product development da LeanIX. Embora não se saiba a sua identidade, este possui mais de 3 anos de experiência na ferramenta e considera a solução interessante e com valor. O questionário realça ainda que, apesar de este(a) não saber se atualmente tais propostas são passíveis de implementação, a sua implementação beneficiaria o trabalho dos arquitetos empresariais ao contribuir proactivamente para a estratégia e gestão de risco, e forneceria informação com maior qualidade que proporcionaria processos de decisão mais claros e, consequentemente, uma melhor tomada de decisões. Em jeito de conclusão, com a apresentação da solução a profissionais com conhecimento na tecnologia LeanIX, foi possível validar o valor e a viabilidade da solução, tendo ainda sido possível verificar que o problema identificado e que deu origem à presente solução se 66 encontra a ser discutido. A sua resolução é algo que tem estado a ser endereçada e discutida pela LeanIX, pelo que a proposta de solução apresentada aos membros da equipa da LeanIX, e principalmente à equipa de product development, suscitou muito interesse e admiração. Foi, portanto, possível concluir que, embora a proposta de solução apresente valor, neste momento a sua implementação ainda não é exequível, visto que a ferramenta ainda não se encontra capacitada para uma implementação deste género. 67 9. CONCLUSÕES A finalidade do presente capítulo é demonstrar e sintetizar as principais conclusões deste trabalho de dissertação. Neste capítulo são ainda apresentadas algumas recomendações para trabalhos futuros, bem como as principais dificuldades encaradas ao longo do período de dissertação. Foi identificado, como problema geral e transversal a todo o trabalho, a falta de qualidade da arquitetura empresarial, derivada da desatualização das arquiteturas que, por sua vez, se encontra relacionada com o modo como a gestão da manutenção é realizada. A falta de atualização da arquitetura empresarial e consequente incoerência de informação e dados que circula nos diversos sistemas da organização, leva a que sejam tomadas decisões que não conduzem as organizações ao sucesso ambicionado. Deste modo, e com vista a que haja uma maior gestão da qualidade da arquitetura empresarial, foi feito um estudo de caso que teve como objetivo evidenciar que, com uma maior atualização e manutenção da arquitetura empresarial, seria possível providenciar uma maior qualidade da arquitetura empresarial. Para isto, fez-se uso do use case da integração entre o ServiceNow CMDB e o LeanIX. A proposta de uma série de melhorias à tecnologia LeanIX, teve como objetivo evidenciar que, com as funcionalidades propostas, e uma maior atenção por parte dos arquitetos empresariais a possíveis situações de colisão e/ou risco que possam comprometer o sistema, a informação circulante nos diversos sistemas, encontra-se atualizada e pronta para ser utilizada, dando suporte a uma melhor e mais acertada tomada de decisões. No que diz respeito aos objetivos inicialmente traçados, estes foram atingidos na sua totalidade, tendo conseguido validar o valor da solução com diferentes profissionais ligados à área de arquitetura empresarial e à tecnologia LeanIX. Contudo, e por não ter sido possível a sua execução, a implementação das melhorias propostas era algo que também se gostaria de ter efetuado. É de ter em atenção que para explicar o problema da desatualização da arquitetura e demonstrar o valor da solução proposta, foi utilizado o exemplo do use case da integração entre o ServiceNow CMDB e o LeanIX, contudo é necessário que se atualizem todos os 68 componentes e consequentemente a arquitetura para que o problema seja realmente resolvido. Deste modo, como trabalhos futuros, sugere-se que sejam analisadas todas as propostas de melhoria desenvolvidas ao longo deste trabalho e era desejável desenvolver e testar as propostas de melhoria para obter mais resultados e verificar o valor real da solução. Assim, a curto e médio prazo sugere-se a implementação das propostas de melhoria entre o ServiceNow CMDB e o LeanIX, de forma a proporcionar uma maior atualização, manutenção e, consequentemente, maior qualidade da arquitetura empresarial. Já a longo prazo, o esperado é que se proceda com regularidade à atualização de todos os sistemas da organização. Este trabalho de dissertação teve como principais limitações a falta de validação dos resultados deste estudo, etapa esta que não foi realizada tal como seria previsto, pelo ao facto de nem todos os profissionais terem querido dar o seu testemunho quanto ao valor da solução proposta. Outra dificuldade encontrada, e esta evidenciada durante o período de janeiro a março de 2022, foi o acesso ao ambiente da tecnologia LeanIX, que atrasou o andamento do trabalho. Embora o tempo definido para o período de estágio tenha sido inicialmente estipulado entre setembro de 2021 e junho de 2022, só foi possível a iniciação do trabalho de dissertação em janeiro de 2022. Este percalço deveu-se essencialmente à alteração do tema no qual a tese se iria de debruçar, o que originou uma reorganização do trabalho já feito até à data e uma nova procura por informação referente ao tema e a ferramentas. Outra dificuldade encontrada, e esta evidenciada durante o período de janeiro a março de 2022, foi o acesso ao ambiente da tecnologia LeanIX, que atrasou o andamento do trabalho. Com base numa ótica mais pessoal, o estágio realizado e todo o trabalho desenvolvido foi bastante interessante e enriquecedor, dado que o tema abordado era um tema desconhecido e que proporcionou me um grande prazer investigar. Adicionalmente, o estágio apoiou o culminar do meu percurso académico e serviu de ponte para o mundo profissional. 69 BIBLIOGRAFIA Brown, T. (2004). The value of Enterprise Architecture. Ru.Nl, 1–7. Cartlidge, A., Ashley, X.-S., Hp, H., Rudd, C., Macfarlane, I., Windebank, J., Stuart, S., & Hp, R. (n.d.). The IT Infrastructure Library An Introductory Overview of ITIL® V3. Correia, A., & Abreu, F. B. (2009). Integrating IT service management within the enterprise architecture. 4th International Conference on Software Engineering Advances, ICSEA 2009, Includes SEDES 2009: Simposio Para Estudantes de Doutoramento Em Engenharia de Software, 553–558. https://doi.org/10.1109/ICSEA.2009.87 Davoudi, M. R., & Aliee, F. S. (2009). Characterization of enterprise architecture quality attributes. Proceedings - IEEE International Enterprise Distributed Object Computing Workshop, EDOC, 131–137. https://doi.org/10.1109/EDOCW.2009.5332004 De Vries, M., & Van Rensburg, A. C. J. (2008). Enterprise architecture - New business value perspectives. South African Journal of Industrial Engineering, 19(1), 1–16. https://doi.org/10.7166/19-1-103 Fischer, R., Aier, S., & Winter, R. (2007). A federated approach to enterprise architecture model maintenance. Proceedings of the 2nd International Workshop on Enterprise Modelling and Information Systems Architectures - Concepts and Applications, EMISA 2007, April 2014, 9–22. https://doi.org/10.18417/emisa.2.2.2 Forrester. (2011). The Forrester Wave TM : Enterprise Architecture Management Suites , Q2 2011. Reproduction, 2,3. Fragen, H. S. (n.d.). Enterprise Architecture Deliverables Welche Ergebnisse liefert Enterprise Architecture ? Teil 1, 1–11. Gama, N., Sousa, P., & Mira, M. (2015). A case of integration between ITIL and TOGAF. Complementary Proceedings of the Workshops TEE, 1408(TEE 2015), 1–15. Gao. (2001). A Practical Guide to Federal Enterprise Architecture. Public Law, 1(February 2001), 112. http://www.citeulike.org/group/15536/article/9666776 Gellweiler, C. (2020). Connecting enterprise architecture and project portfolio management: A review and a model for IT project alignment. International Journal of Information Technology Project Management, 11(1), 99–114. https://doi.org/10.4018/IJITPM.2020010106 Gomes, R. (2013). Methodology for building and maintaining enterprise architectures in small and medium enterprises. Halawi, L., McCarthy, R., & Farah, J. (2019). Where We Are With Enterprise Architecture. Journal of Information Systems Applied Research, 12(3), 4. Helfert, M., Doucek, P., & Maryška, M. (2013). The “Enterprise Architect” – A New Approach to Business Informatics Management. Quality Innovation Prosperity, 17(1), 67–87. https://doi.org/10.12776/qip.v17i1.171 Hermanto, A., & Supangat. (2018). Integration of EA and IT service to improve performance at higher education organizations. MATEC Web of Conferences, 154, 8–11. https://doi.org/10.1051/matecconf/201815403008 Hevner, A., Brocke, J. vom, & Maedche, A. (n.d.). Design Science Research. Cases - Google Livros. Retrieved February 11, 2022, from https://books.google.pt/books?id=qdXDwAAQBAJ&pg=PA1&hl=pt-PT&source=gbs_toc_r&cad=3#v=onepage&q&f=false Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design Science in Information Systems 70 Reasearch. MIS Quarterly, 28(1), 75–105. https://doi.org/10.1007/BF01205282 Hu, Y., Zhang, Y., Guo, H., Chong, L. Y., Zhang, C., & Zhang, Y. (2016). Effects of substrate on the domains and electrical properties of epitaxial graphene formed on on-axis C-face 4HSiC. Journal of Materials Science: Materials in Electronics, 27(7), 7595–7602. https://doi.org/10.1007/s10854-016-4742-8 Iivari, J., & Venable, J. (2009). Action research and design science research - Seemingly similar but decisively dissimilar. 17th European Conference on Information Systems, ECIS 2009, January. Institute of Electrical and Electronics Engineers. (1990). IEEE Standard Glossary of Software Engineering Terminology. Office, 121990(1), 1. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=159342 Introductory Overview of ITIL ® 4 i ITIL ® OFFICIAL PUBLISHER Introductory Overview of ITIL ® 4. (2020). www.tsoshop.co.uk ISO/IEC/IEEE (2011. (1982). Systems and software engineering – Architecture description. ISO/IEC/IEEE FDIS 42010:2011. International Organization for Standardization, Geneva., 16(4), 319–321. https://doi.org/10.1007/BF01077867 Jelliti, M., Sibilla, M., Jamoussi, Y., & Ghezala, H. Ben. (2010). A model based framework supporting ITIL Service IT Management. Lecture Notes in Business Information Processing, 50 LNBIP, 208–219. https://doi.org/10.1007/978-3-642-13051-9_18 Kotusev, S. (2016). The History of Enterprise Architecture: An Evidence-Based Review. Journal of Enterprise Architecture, 12(1), 29–37. Lange, M., Mendling, J., & Recker, J. (2016). An empirical analysis of the factors and measures of Enterprise Architecture Management success. European Journal of Information Systems, 25(5), 411–431. https://doi.org/10.1057/ejis.2014.39 Lankhorst, M. M. (2017). Enterprise architecture at work: Modelling, communication and analysis, fourth edition. In Enterprise Engineering Series. Mannmeusel, T. (2012). Management von Unternehmensarchitekturen in der Praxis: Organisatorische Herausforderungen in mittelständischen Unternehmen. Analyse Und Gestaltung Leistungsfähiger IS-Architekturen, 35–57. https://doi.org/10.1007/978-3642-27700-9_2 Masuda, Y., Shirasaka, S., & Yamamoto, S. (2016). Integrating mobile IT/Cloud into enterprise architecture: A comparative analysis. Pacific Asia Conference on Information Systems, PACIS 2016 - Proceedings, June. Meepung, T., Wannapiroon, P., & Nilsook, P. (2021). Transition Elements, Enterprise Architecture for Digital Entrepreneurial University. Proceedings - 2021 Research, Invention, and Innovation Congress: Innovation Electricals and Electronics, RI2C 2021, 167–175. https://doi.org/10.1109/RI2C51727.2021.9559833 Meyer, M., Helfert, M., & O’Brien, C. (2011). An analysis of enterprise architecture maturity frameworks. Lecture Notes in Business Information Processing, 90 LNBIP, 167–177. https://doi.org/10.1007/978-3-642-24511-4_13 Moné, L. (n.d.). How IT Service Management and EA Go Together. ServiceNow. Retrieved February 2, 2022, from https://www.leanix.net/en/blog/how-it-service-managementand-ea-go-together Morganwalp, J. M., & Sage, A. P. (2004). Enterprise architecture measures of effectiveness. International Journal of Technology, Policy and Management, 4(1), 81–94. https://doi.org/10.1504/IJTPM.2004.004569 71 Na-Lampang, N., & Vatanawood, W. (2017). Development of an ontology-based configuration management system. Proceedings of the 8th International Conference on Electronics, Computers and Artificial Intelligence, ECAI 2016. https://doi.org/10.1109/ECAI.2016.7861164 Niemi, E., & Pekkola, S. (2020). The Benefits of Enterprise Architecture in Organizational Transformation. Business and Information Systems Engineering, 62(6), 585–597. https://doi.org/10.1007/s12599-019-00605-3 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. https://doi.org/10.2753/MIS0742-1222240302 Radhakrishnan, R. (2008). Enterprise Architecture & IT Service Management - ITSM Frameworks and Processes and their Relationship to EA Frameworks and Processes. April. Rumapea, S. A., & Sitohang, B. (2018). Quality framework for quality assuring enterprise architecture model. Proceedings of the 2017 4th International Conference on Computer Applications and Information Processing Technology, CAIPT 2017, 2018-Janua, 1–5. https://doi.org/10.1109/CAIPT.2017.8320740 Schilling, R. D. (2018). Theories to Understand the Dynamic Nature of Enterprise Architecture. Proceedings - IEEE International Enterprise Distributed Object Computing Workshop, EDOCW, 2018-Octob, 153–161. https://doi.org/10.1109/EDOCW.2018.00030 ServiceNow. (n.d.-a). Products by Category - ServiceNow. Retrieved December 28, 2021, from https://www.servicenow.com/products-by-category.html ServiceNow. (n.d.-b). What is ITSM? - IT Service Management - ServiceNow. Retrieved January 29, 2022, from https://www.servicenow.com/products/itsm/what-is-itsm.html ServiceNow Store. (n.d.). Retrieved June 22, 2022, from https://store.servicenow.com/sn_appstore_store.do#!/store/application/27430063db3 a1b00bac3d8c0cf961952 Shanks, G., Gloet, M., Asadi Someh, I., Frampton, K., & Tamm, T. (2018). Achieving benefits with enterprise architecture. Journal of Strategic Information Systems, 27(2), 139–156. https://doi.org/10.1016/j.jsis.2018.03.001 Simon, D., Fischbach, K., & Schoder, D. (2014). Enterprise architecture management and its role in corporate strategic management. Information Systems and E-Business Management, 12(1), 5–42. https://doi.org/10.1007/s10257-013-0213-4 Sousa, P., Gabriel, R., Tadao, G., Carvalho, R., Sousa, P. M., & Sampaio, A. (2011). Enterprise transformation: The Serasa Experian case. Lecture Notes in Business Information Processing, 89 LNBIP(September), 134–145. https://doi.org/10.1007/978-3-642-233883_7 Sousa, P., Gama, N., & Mira, M. (2013). Integrating Enterprise Architecture and IT Service Management. Building Sustainable Information Systems. https://doi.org/10.1007/978-14614-7540-8 Strano, C., & Rehmani, Q. (2007). The role of the enterprise architect. Information Systems and E-Business Management, 5(4), 379–396. https://doi.org/10.1007/s10257-007-00531 Syynimaa, N. (2018). Enterprise architecture: To business or not to business? That is the question! ICEIS 2018 - Proceedings of the 20th International Conference on Enterprise Information Systems, 2(Iceis 2018), 623–631. https://doi.org/10.5220/0006685106230631 72 Tamm, T., Seddon, P. B., Shanks, G., & Reynolds, P. (2011). How does enterprise architecture add value to organisations? Communications of the Association for Information Systems, 28(1), 141–168. https://doi.org/10.17705/1cais.02810 The Open Group. (n.d.). TOGAF in the Enterprise. Retrieved February 3, 2022, from http://www.opengroup.org/public/arch/p1/enterprise.htm The Open Group. (2018). The TOGAF® Standard, Version 9.2. The Open Group, 504. Tzanavara, K., Patel, M., Patil, S., Chauhan, M., & Wang, Y. (2019). Clark Digital Commons Service Now : CMDB Research. School of Professional Studies. van den Berg, M., Slot, R., van Steenbergen, M., Faasse, P., & van Vliet, H. (2019). How enterprise architecture improves the quality of IT investment decisions. Journal of Systems and Software, 152, 134–150. https://doi.org/10.1016/j.jss.2019.02.053 Walrad, C. C., Lane, M., Jeffrey, W., & Hirst, D. V. (2014). Architecting a profession. IT Professional, 16(1), 42–49. https://doi.org/10.1109/MITP.2013.4 Winniford, M. A., Conger, S., & Erickson-Harris, L. (2009). Confusion in the ranks: IT service management practice and terminology. Information Systems Management, 26(2), 153– 163. https://doi.org/10.1080/10580530902797532 Wu, M.-S. (2014). The Benefit and Cost Factors of CMDB Implementations: An Investigation of three Organizations in Taiwan. Procedia - Social and Behavioral Sciences, 147, 64–69. https://doi.org/10.1016/j.sbspro.2014.07.104 Ylimäki, T., Niemi, E., & Hämäläinen, N. (2007). Enterprise architecture compliance: The viewpoint of evaluation. ECIME 2007: European Conference on Information Management and Evaluation, Ecime, 409–418.