Arquiteturas dos sistemas de informação

Nos dias de hoje, as organizações assumem que a presença do binómio SI/TI é indispensável para o suporte das suas atividades, pelo que o seu investimento nesta componente tecnológica tem aumentando. Com a rápida proliferação de SI/TI nas organizações, tornou-se mais complexo gerir esta vasta quantidade de recursos tecnológicos, pelo que as organizações sentiram assim a necessidade de construírem uma estrutura lógica de alto nível de abstração, comum, facilmente compreendida por todos, e que permitisse controlar a gestão destes recursos, através da definição das interfaces e ligações (caso existam) de todos os componentes, alinhando-os através de uma visão holística de negócio, surgindo assim as ASI (L. Rodrigues, 2007).

O aparecimento das ASI está intimamente relacionado com o conceito tradicional e original de arquitetura que remonta há alguns séculos atrás e que se encontra associado à Engenharia Civil (arte/ciência de construir edifícios), referindo-se ao estilo e forma a utilizar no desenho e construção de edifícios. A partir desta interpretação, uma arquitetura pode ser definida como sendo um plano para a construção de algo, no qual estão presentes os componentes de uma determinada realidade, que se enquadram e reúnem num todo, de modo a satisfazer determinadas necessidades funcionais/artísticas (Kim & Everest, 1994).

30

Apesar da definição de arquitetura previamente descrita, esta não é a única comummente aceite, uma vez que não existe um entendimento global, o que acarreta algum nível de subjetividade tanto a nível teórico como a nível prático, devido à forma como cada autor o interpreta (Hoogervorst, 2004). Assim, para Sowa e Zachman (1992), uma arquitetura é uma entidade que se encontra em constante evolução e constitui uma forma de observar com detalhe a lógica da organização sem perder a noção da escala. Quanto a Luckam, Vera e Meldal (2000), sugerem que uma arquitetura deve funcionar como um esquema descritivo que dispõe os diferentes componentes de uma determinada realidade e ao mesmo tempo explicita a forma como estes se conjugam, acomodam e relacionam entre si.

A aplicação deste conceito no âmbito dos SI/TI levou à criação das ASI, cuja definição também é variável entre autores. Segundo Zachman (1987), uma das principais figuras de referência na área das ASI, define que este tipo de arquiteturas é composto pelas perspetivas associadas aos dados, funções, redes, pessoas, tempo e motivação, que constituem outras tantas arquiteturas aditivas e complementares. Para Butler (1996), uma ASI trata-se de um modelo dinâmico e flexível que permite visualizar o relacionamento entre a organização e o binómio SI/TI, permitindo e facilitando a coerência dos processos de tomada de decisão. A definição proposta por Amaral e Varajão (2007) é uma das mais abrangentes, pois reitera que uma ASI trata-se do resultado da visão global de um SI, que incorpora a arquitetura da informação complementada com a descrição da TI para o seu suporte, a identificação das aplicações e serviços necessários ao suporte dos processos organizacionais e a definição da atividade de desenvolvimento de aplicações e serviços.

Anteriormente, ao longo da revisão bibliográfica, foi referida a importância de existir um alinhamento entre a estratégia de negócio e a estratégia de SI/TI. Assim, também ao nível das arquiteturas, a componente tecnológica e a componente dos negócios devem estar relacionadas e representadas na mesma arquitetura, surgindo as AE, que têm despertado o interesse tanto no meio empresarial (Winter & Fischer, 2006), como no meio académico (com destaque para as IES) (Kappelman, McGinnis, Pettite & Sidorova, 2008).

À semelhança do que acontece com as definições das arquiteturas referidas anteriormente, também na definição de AE não existe um consenso generalizado, muito devido à sua utilização em diferentes contextos e devido aos diferentes pontos de vista dos autores (D. Chen, Doumeingts & Vernadat, 2008; Winter & Fischer, 2006). Da análise efetuada por L. Rodrigues (2014) a mais de 30 definições identificadas na literatura, foi possível constatar que as AE podem, em diferentes contextos, ser entendidas como: uma planta (blueprint); uma

31

descrição da organização; a arquitetura da organização; uma taxonomia; um método; um processo; uma função; uma ferramenta; um recurso; uma prática de gestão; uma estratégia; ou inclusive uma disciplina.

Alguns autores consideram que uma AE deve permitir descrever tanto os componentes relacionados com o binómio SI/TI (e.g. sistemas de informação, infraestrutura tecnológica de suporte, aplicações, protocolos, interfaces, bases de dados), como os componentes associados ao negócio (e.g. missão, visão, estratégias, informação, políticas, atividades, processos de negócio) (Šaša & Krisper, 2011; Winter & Fischer, 2006). Sob o ponto de vista de Correia e Silva (2007), uma AE é definida como o modelo da organização que especifica como as suas partes são decompostas em componentes individuais funcionais e como eles interagem entre si. Com a utilização crescente deste tipo de arquiteturas, e dada a falta de consenso sobre os conceitos e terminologias associados, o Institute of Electrical and Eletronics Engineers (IEEE (2000) redigiu a norma P1471, para a identificação, análise e comparação de abordagens mais utilizadas, materializando-se como meta-referencial onde são apresentados e discutidos os principais conceitos e referenciais associados às ASI, assim como as boas práticas para a construção, análise e manutenção de uma arquitetura deste tipo. Sucintamente, esta norma especifica: 1) uma ASI deve abordar todos os stakeholders (partes interessadas) de um sistema; 2) as descrições de arquitetura (representações de sistemas) devem ser multi-vista, i.e., uma vista isolada não consegue captar todas as preocupações dos stakeholders; e 3) a noção de ponto de vista e vista, onde um ponto de vista identifica um conjunto de preocupações e representações/técnicas de modelação para representação dessas preocupações na arquitetura, enquanto que a vista é o resultado da aplicação de um ponto de vista a um sistema em particular. Algum tempo mais tarde, a norma P1471 foi aceite pela International Organization for

Standardization (ISO (2007), sendo criada a ISO/IEC 42010:2007, cuja última atualização foi

em 2011 (ISO/IEC 42010:2011). Neste caso, esta ISO surgiu para ajudar na fundamentação do que são as AE, assumindo as conceções feitas pela norma P1471, definindo assim estas arquiteturas fundamentalmente como a conceção de um sistema considerando o seu ambiente, componentes, a relação entre componentes (e a relação destes com o ambiente) e os princípios orientadores para a sua conceção e evolução. Esta ISO especifica ainda os conteúdos exigidos para as descrições de arquitetura, introduzindo ainda pontos de vista de arquitetura, referenciais e linguagens de modelação convencionais na construção deste tipo de descrições.

As AE devem permitir representar os diversos aspetos da organização que são designados como perspetivas, domínios, camadas, dimensões ou sub-arquiteturas. Como é

32

possível verificar na Figura 4, tipicamente numa organização as quatros sub-arquiteturas mais comuns de serem encontradas são (Hafner & Winter, 2008; Rohloff, 2008): 1) Arquitetura do Negócio: representa as estratégias e os componentes relacionados com o ambiente dos negócios, tendo em conta regras e processos; 2) Arquitetura das Aplicações: representa as principais aplicações necessárias para suportar a gestão dos dados/informação, bem como as atividades organizacionais; 3) Arquitetura Tecnológica: representa a infraestrutura tecnológica necessária para o suporte das aplicações e identifica as suas interdependências; e 4) Arquitetura dos dados ou da informação: representa a vista de alto nível dos requisitos de informação, assim como a estrutura dos processos, funções e atividades que permitem efetuar a gestão eficiente destes recursos, sustentando de forma coordenada o desenvolvimento a longo prazo das aplicações da organização. É ainda de notar que a Arquitetura dos Dados ou da Informação, a Arquitetura Tecnológica e a Arquitetura das Aplicações são frequentemente agrupadas e dispostas nas ASI.

Figura 4 - Quatro principais sub-arquiteturas de uma AE

Para que seja possível retirar benefícios das AE, estas necessitam de possuir determinadas propriedades como (Bernard, 2012; Chorafas, 2016; Khayami, 2011): 1) alinhada com o negócio: deve basear-se nos objetivos estratégicos da organização e nas informações provenientes do negócio; 2) flexibilidade: deve permitir efetuar adaptações sempre que haja mudanças na realidade da organização, sem que para isso afete a existência da arquitetura; 3) compatibilidade: deve incorporar um conjunto de standards, de modo a garantir um funcionamento harmonioso entre todos os componentes e tecnologias utilizadas; 4) funcional: deve responder aos requisitos e necessidades da organização; 5) simplicidade: deve ser facilmente percebida por todos os intervenientes da organização, para que estes estejam comprometidos desde a sua implementação até à sua manutenção; 6) realismo: deve ter em

33

conta todos os recursos organizacionais disponíveis, traduzindo a realidade do ambiente organizacional; e 7) manutenibilidade: deve permitir efetuar operações de integração, teste e manutenção dos sistemas.

A construção das AE não é um processo simples e os problemas e as dificuldades surgem em três áreas críticas, nomeadamente: na modelação, na implementação e na manutenção (Kaisler, Armour & Valivullah, 2005; Magalhaes, Zacarias & Tribolet, 2007). Ao nível da modelação alguns dos principais problemas identificados passam: pela dificuldade em obter uma visão global dos SI/TI e outros recursos disponíveis; pelo esforço considerável requerido para a construção da arquitetura em termos de tempo e recursos; perigo das dependências técnicas se sobreporem às prioridades de negócio; dificuldade na escolha dos dados e aplicações que devem existir, assim como as suas dependências; standards a serem adotados. Ao nível da implementação, as principais adversidades passam: pela dificuldade na comunicação devido ao facto destas arquiteturas possuírem um elevado nível de abstração; excessiva complexidade que este tipo de projetos tende a acarretar; pela dificuldade na validação dos produtos obtidos; e dificuldade em compreender os relacionamentos entre as funções de negócio e a componente de SI/TI. Ao nível da manutenção, o principal problema advém das rápidas mudanças a que as organizações estão sujeitas, o que faz com que aumente a pressão para manter estas arquiteturas atualizadas.

Apesar dos problemas e adversidades que possam surgir aquando do desenvolvimento, implementação e manutenção de uma AE são muitos os benefícios que as organizações podem retirar da sua utilização, podendo ser destacados como principais o aumento da capacidade para resposta à mudança, a otimização dos processos de tomada de decisão, a melhoria da colaboração e comunicação, a redução de custos (sobretudo de SI/TI) e a promoção do alinhamento entre a estratégia de negócio e a estratégia dos SI/TI (Schmidt & Buxmann, 2011; Tamm, Seddon, Shanks & Reynolds, 2011). Para além destes principais benefícios, outros podem ser identificados como: a melhoria dos processos de negócio; melhoria do desempenho dos SI; adequação das TI aos requisitos dos SI; a melhoria ao nível da integração dos sistemas; o aumento do Return on Investment (ROI) e a adequação do investimento em SI/TI; menor desperdício de tempo e dinheiro em projetos que não cumprem os objetivos da organização; o aumento da rapidez no desenvolvimento de novos sistemas; maior flexibilidade dos processos de negócio; e o aumento da segurança dos sistemas (Chorafas, 2016; Niemi, 2006; L. Rodrigues, 2014; Zachman, 1987).

34

Com o intuito de assegurar os benefícios identificados e evitar alguns dos principais problemas destacados, surge a necessidade de existir a Gestão de Arquitetura Empresarial (GAE), cuja principal função passa por permitir que uma organização evolua em função dos objetivos definidos para a AE, objetivos esses que devem estar alinhados com as estratégias organizacionais. Segundo Buckl et al. (2011), esta função pode ser decomposta em cinco atividades: 1) visionar: definição da arquitetura ideal que satisfaça a estratégia de negócio e a estratégia de SI/TI; 2) documentar: conceção de um conjunto de artefactos que documentem a arquitetura atual; 3) planear: definição de planos que possam ser utilizados em projetos que façam através do cumprimento de requisitos façam a transição para a arquitetura desejada; 4) analisar: comparação dos diferentes estados da arquitetura com o intuito de definir a próxima evolução; e 5) aplicar: fornecer artefactos arquiteturais que possam ser utilizados para orientar, guiar e influenciar os restantes processos de gestão.

A construção e gestão de uma AE exibe um alto nível de complexidade, pelo que alguns autores têm sugerido referenciais que permitam apresentar e fornecer uma estrutura lógica que permita classificar e organizar a informação de uma organização e assim mitigar a complexidade inerente a estes processos. Assim, um referencial para uma AE deverá permitir identificar toda a informação necessária para a conceção de uma arquitetura deste tipo, utilizar uma estrutura lógica para organizar os diferentes tipos de informação (tendo em conta a relação entre os diferentes tipos de informação e as diferentes perspetivas dos stakeholders), definir as descrições de arquiteturas e propor um método a ser utilizado para tudo isto (Schekkerman, 2004).

Alguns dos principais referenciais que podem ser destacados pela notoriedade e destaque que alcançaram no âmbito das AE são: Arquitetura de Computadores (preocupações meramente tecnológicas) de Nolan (1983); Arquitetura da Informação da IBM (1984), posteriormente explorado por Amaral e Varajão (2007); o Referencial de Zachman (1987) (um dos primeiros referenciais propostos e que rapidamente se tornou uma referência devido à sua simplicidade e facilidade de compreensão); o Enterprise Architecture Planning (EAP) proposto por Spewak e Hill (1992); o Integrated Architecture Framework (IAF) desenvolvido pela Capgemini (2007); o Federal Enterprise Architecture Framework (FEAF) desenvolvido pelo CIOCouncil (2001); e por último o The Open Group Architecture Framework (TOGAF) do TheOpenGroup (2009), que atualmente é dos referenciais mais utilizados tanto a nível académico como empresarial.

35