Enterprise Architecture Management System

GRUPO AITEC Enterprise Architecture Management System Solução de gestão para Arquiteturas Empresariais Unidade Arquitetura Empresarial Agosto de 2010

Índice 1 Introdução... 3 1.1 Porquê automatizar Blueprints?... 3 1.2 Automatização de Blueprints... 4 1.3 Análises de impacto e conformidade... 4 1.4 Como o EAMS fornece resposta a estas questões?... 6 1.5 Os circuitos de governação... 6 1.6 Metodologia KyE... 7 1.6.1 O AS IS e o TO BE dos Blueprints... 7 1.6.2 O processo de Gestão e Governação dos Blueprints... 8 2 Enterprise Architecture Management System... 9 2.1 Descrição Funcional... 9 2.1.1 Geração automática... 9 2.1.2 Aplicação de Filtros... 10 2.1.3 Introdução de Dados... 11 2.1.4 Geração de Documentos e Relatórios... 11 2.1.5 Importação e exportação de informação... 12 2.2 Tipos de Blueprint... 13 2.3 Parametrização... 16 2.4 Análises e Matrizes Temporais... 17 2.5 Integração com o System Architect... 19 2.6 Requisitos... 19 Whitepaper EAMS Agosto de 2010 Pag. 2

1 INTRODUÇÃO O Enterprise Architecture Management System (EAMS) é uma solução para gestão de arquiteturas empresariais, que tem como princípio básico a automatização para redução de esforço em projetos. Este documento apresenta uma solução que surge com o intuito de auxiliar a manutenção da Arquitectura Empresarial de uma organização. É necessário para a empresa que exista um conjunto de documentos que a descrevam, que esses mesmos documentos estejam actualizados e que o esforço para os produzir ou actualizar seja marginal. O EAMS tem como base a integração com o System Architect (SA). Através das interfaces de extensibilidade, disponibilizadas pela ferramenta de gestão de Arquitecturas Empresariais, tira partido das principais características do repositório e da componente de modelação. Com base no SA é possível garantir um conjunto de requisitos referentes a tal informação e disponibilizar a capacidade de mapear manualmente a arquitectura. O EAMS acrescenta a este modelo a capacidade de automatizar a geração e actualização dos diagramas. Estas mesmas capacidades garantem que a informação está sempre actual e consistente. Para descrever o panorama empresarial com recurso a esta solução está associado um Metamodelo que define a estrutura e semântica, dos dados e as suas relações. Com base neste modelo encontram-se definidas um conjunto de vistas adequado ao modelo geral de governação associado. Dentro de este modelo existem mais ciclos de governação. A definição dos modelos e o Metamodelo são definidos pela Metodologia KyE. 1.1 PORQUÊ AUTOMATIZAR BLUEPRINTS? A visão clássica das iniciativas de Arquitectura Empresarial, e de modelação das diversas perspectivas das Organizações, está centrada na manutenção de um determinado conjunto de Vistas Arquitecturais, Blueprints, através de elevado esforço manual dos colaboradores, que consomem uma grande fatia do tempo a efectuar a modelação de toda a informação e apenas uma pequena parte a gerar e comunicar as análises e relatórios, que são grande parte do valor real associado a este tipo de iniciativas. Por outro lado, mesmo após estar construído o repositório de arquitectura da Organização, é necessário mantê-lo actualizado, e este é um dos principais factores de influência para o insucesso de iniciativas de arquitectura. Este facto deve-se, não só ao esforço associado à actualização manual, geralmente centrado num pequeno conjunto de colaboradores, encarados como elementos causadores de entropia no trabalho quotidiano, mas também por ser complexo identificar os momentos exactos de captura de informação os quais dependem dos ciclos de vida reais das Organizações. O Enterprise Architecture Management System (EAMS) pretende não só ser uma solução para a questão de como produzir Blueprints de arquitectura com reduzido esforço e Whitepaper EAMS Agosto de 2010 Pag. 3

complexidade? mas também para a questão de como manter os Blueprints de arquitectura abrangentes e actuais?. 1.2 AUTOMATIZAÇÃO DE BLUEPRINTS Um Blueprint de Arquitectura é uma Vista específica que contém a representação de um conjunto mínimo de artefactos estritamente necessários para dar resposta a um conjunto limitado de questões. A solução EAMS tem como principal característica a capacidade de todos os Blueprints transmitirem, com a aplicação de um esforço marginal, toda a informação essencial garantindo paralelamente a consistência desta. Porém esta abordagem não retira a capacidade de parametrização dos Blueprints, permitindo que seja possível adequar a informação transmitida às necessidades quer da Organização, quer do viewpoint em causa. Sobre cada um dos Blueprints é depois possível aplicar um conjunto de filtros e análises verificando parâmetros como o número de elementos, acções, dependências entre artefactos, valores das propriedades, entre outra informação visual ou textual que esteja associada aos elementos presentes nos Blueprints cuja informação textual se encontra armazenada no repositório base. As Vistas podem ser construídas com recurso a ferramentas de modelação ou de geração automática, produzidas em forma textual ou visual. Neste último caso é de realçar a capacidade de actualizar Vistas já existentes de modo acumulativo (não destrutivo). No seguimento do circuito associado à governação de projectos IT exemplifica-se a divisão dos diversos Blueprints consoante o sujeito e universo de análise, sendo que cada uma das Vistas é adequada a determinada fase dos projectos e respectivo conjunto de stakeholders. Todas as Vistas pretendem responder a um conjunto bem definido de questões que traduzem o objectivo das mesmas e dos seus stakeholders. Para o caso do Contexto de Projecto, o Blueprint respectivo pretende analisar questões como: Quais as Aplicações que são afectadas por outros Projectos? Quais os Processos impactados por este Projecto? Quais as Plataformas de Integração usadas no Projecto? 1.3 ANÁLISES DE IMPACTO E CONFORMIDADE Os filtros permitem colocar questões semânticas sobre os artefactos presentes nos Blueprints gerados, identificando as relações existentes e valores de propriedades de cada artefacto. Os Filtros têm três tipos: Conformidade; Operação. Por exemplo, para um filtro de Operação, a análise é efectuada em torno de um único sujeito de análise e são assinalados todos os elementos do Blueprint que são afectados por acções deste. Whitepaper EAMS Agosto de 2010 Pag. 4

Quais os artefactos criados, actualizados, acedidos ou eliminados pelo Projecto? Whitepaper EAMS Agosto de 2010 Pag. 5

1.4 COMO O EAMS FORNECE RESPOSTA A ESTAS QUESTÕES? O paradigma do EAMS assenta na automatização da geração dos diversos Blueprints necessários para uma iniciativa de Arquitectura Empresarial. Esta automatização é efectuada com base na informação textual (propriedades) de cada artefacto presente no repositório de arquitectura. O EAMS permite que a própria captura desta informação textual seja efectuada com esforço marginal, disponibilizando conectores de importação de informação que permitem a obtenção de informação de outros sistemas da Organização. Por outro lado as próprias análises e filtros realizados sobre cada um dos Blueprints são automatizados nesta solução através de wizards que permitem definir os critérios de análise e filtragem, tudo com base na informação associada aos artefactos e nas relações existentes entre eles. A integração nos diversos circuitos que constituem o ciclo de vida das organizações é o que permite manter o repositório abrangente e actualizado, capturando informação de sistemas externos e estabelecendo os timings e responsabilidades exactos em que cada colaborador de dado perfil orgânico deve actualizar informação no repositório, fazendo uso de templates simples ou navegando directamente no repositório através de uma interface Web. Todos estes mecanismos e circuitos permitem que as Organizações construam os seus repositórios de Arquitectura de uma forma incremental, enriquecendo o seu próprio AS IS que pode depois ser explorado através Blueprints e análises globais. 1.5 OS CIRCUITOS DE GOVERNAÇÃO Os circuitos de governação são o elemento que permite manter o repositório de Arquitectura Empresarial actualizado e coerente, tendo por base uma integração fina com os ciclos de vida das Organizações, identificando: o contributo que cada perfil pode ter em termos de inputs de informação para o repositório, os interesses de Vistas e análises de cada stakeholder e os eventos ou milestones nos quais deve existir actualização da informação. Um bom exemplo de ciclo de vida das Organizações, que obrigatoriamente deve ser usado para criação dos circuitos de governação da Arquitectura Empresarial, é o ciclo de vida dos projectos IT. Todos os projectos IT devem ser alvo de uma análise de conformidade da sua arquitectura face ao AS IS actual, a possíveis impactos com outros projectos e tendo em conta a Arquitectura de Referência da Organização. Devem ser identificados os pontos-chave onde a informação do projecto deve ser actualizada e aprovada do ponto de vista de arquitectura: aprovação do projecto em fase de análise, pontos de revisão efectuados ao longo de milestones importantes de cada projecto, revisão global em fase de entrada em produção. Devem ainda ser identificados os perfis e sistemas que enriquecem o repositório de informação: gestor de projecto, arquitecto de área, e outros. Whitepaper EAMS Agosto de 2010 Pag. 6

1.6 METODOLOGIA KYE A metodologia KyE visa produzir e manter Blueprints da arquitectura do IT de uma organização abrangentes e actualizados com reduzidos esforço e custos de operação. Esta metodologia fundamenta-se num conjunto de pressupostos: Ambiente de produção gerido e entradas em produção controladas. Ao nível da Arquitectura, as alterações ao ambiente de produção resultam de projectos de IT. Os projectos de IT são planeados e orçamentados. 1.6.1 O AS IS E O TO BE DOS BLUEPRINTS Para além de cenários exploratórios e análises What-If, os projectos em execução, (isto é, os projectos que ainda não colocaram os artefactos que estão a produzir no ambiente de produção) são o TO BE de facto do IT de uma organização. Na metodologia KyE, os artefactos têm marcas temporais que permitem distinguir o momento em que o artefacto está planeado e o momento em que está/entra em produção Os artefactos planeados fazem parte do TO BE. Os artefactos em execução fazem parte do AS IS. Quando um projecto é iniciado, os artefactos que o projecto irá produzir são marcados como planeados, fazendo parte do TO BE. Quando um projecto coloca os artefactos que produziu no ambiente de produção, estes passam a fazer parte do AS IS. A mesma análise pode ser feita para a eliminação de artefactos. Existe uma data planeada e existe uma data de eliminação. O TO BE do IT não inclui os artefactos cuja eliminação está planeada, embora estes permaneçam no AS IS enquanto não forem efectivamente eliminados. A metodologia KyE permite análises AS IS e TO BE relativamente a uma determinada data passada e/ou futura. O AS IS do IT numa data futura deverá incluir todos artefactos do AS IS actual aos quais são: Adicionados todos os artefactos que estão planeados entrarem em produção antes dessa data. Por omissão a data de entrada em produção de um artefacto é a data de conclusão do projecto que o está a produzir. Retirados todos os artefactos que estão planeados serem eliminados antes dessa data. Por omissão a data de eliminação de um artefacto é a data de conclusão do projecto que o está a eliminar. Whitepaper EAMS Agosto de 2010 Pag. 7

1.6.2 O PROCESSO DE GESTÃO E GOVERNAÇÃO DOS BLUEPRINTS O processo de gestão e governação dos Blueprints considerado na metodologia KyE integra-se em três actividades fundamentais e determinantes na arquitectura do IT de uma organização: A Governação do IT, o qual é entendido como a confluência e a gestão integradas de três áreas: o A gestão de portfolio dos projectos, incluindo a sua a prioritização e análise de dependências. o A gestão de alto nível do IT, com objectivos a estratégicos, objectivos a médio prazo e objectivos operacionais de natureza diversa, como os custos, a eficiência, a qualidade, fiabilidade, entre outros. o A permanente gestão com o negócio na satisfação das suas necessidades em tempo útil. A Gestão de Projectos de IT. o Este é o processo ou a metodologia de gestão usada na gestão de projectos de IT, incluindo o processo da passagem a produção dos resultados do projecto. O Arquitectar o IT. o Estas são as actividades onde se arquitecta ou desenha o IT, quer globalmente, quer pontualmente, em cada projecto de IT. Enquadra-se nas actividades de arquitectar ou desenhar globalmente a explicitação de princípios arquitecturais que, por omissão, devem ser sistematicamente aplicados e/ou as decisões de criar/evoluir/descontinuar sistemas ou aplicações. O processo de governação inclui assim o conjunto de intervenientes que participam nos processos e actividades descritas nos itens anteriores. O processo de governação tem que ser desenhado caso a caso, de forma a integrar-se nas respectivas actividades. A figura seguinte ilustra os intervenientes que tradicionalmente estão envolvidos no processo de governação e gestão dos Blueprints. ILUSTRAÇÃO 1 - CIRCUITO DE GOVERNAÇÃO. Whitepaper EAMS Agosto de 2010 Pag. 8

2 ENTERPRISE ARCHITECTURE MANAGEMENT SYSTEM Este capítulo retrata as principais funcionalidades da ferramenta, alguns conceitos associados e requisitos. 2.1 DESCRIÇÃO FUNCIONAL 2.1.1 GERAÇÃO AUTOMÁTICA A automatização da geração de vistas é a principal funcionalidade da solução. Este ciclo divide-se em três etapas: 1. Obtenção de informação do SA de acordo com a especificação do Blueprint definido no EAMS. 2. Aplicação do algoritmo geométrico de alocação à informação adquirida. 3. Invocação do SA para criação ou actualização do diagrama. Os dados necessários para a geração das vistas são mantidos pelo repositório do SA. O modelo de dados usado é definido pelo EAMS. Estes dados podem ser introduzidos via SA ou através de um dos métodos referidos mais adiante neste capítulo. Como resultado de uma geração é possível obter um diagrama no SA, que corresponde à representação visual do Blueprint, ou descrição textual da vista. A geração dos Blueprints pode ser feita através de dois métodos, construção da vista sem ter em conta se existiam versões anteriores ou actualização de versões existentes. A primeira abordagem é destrutiva baseando-se somente nos algoritmos geométricos. Caso exista uma versão anterior do Blueprint esta é descartada e a geração é, como no caso de não existir tal versão, feita de raiz. A disposição dos elementos presentes no diagrama é determinada de acordo com os mecanismos base e outras parametrizações que o utilizador possa definir nas opções da solução. Numa perspectiva não destrutiva o utilizador é dotado de maior flexibilidade. Este pode construir uma base para o diagrama definindo tanto a disposição dos elementos como também outras propriedades gráficas. Este processo pode também ser aplicado a Blueprints que foram geradas de automaticamente e que a posteriori foram ajustadas de acordo com as necessidades. Deste modo é possível tirar partido da garantia que a informação apresentada é actual e consistente, mas permite que o utilizador não fique limitado à colocação standard dos componentes do diagrama. Na ocorrência de um elemento presente numa versão anterior da vista ter sido eliminado este é devidamente assinalado para ser possível identificar essa mesma alteração. Whitepaper EAMS Agosto de 2010 Pag. 9

2.1.2 APLICAÇÃO DE FILTROS Sobre Blueprints geradas automaticamente ou qualquer diagrama definido é possível efectuar análises mais detalhadas com recurso a filtros de conformidade ou de operações. Um filtro de conformidade consiste na identificação de um conjunto de instâncias, de um ou mais tipos de artefacto, que tenham uma ou mais propriedades de acordo com os parâmetros definidos pelo utilizador. Customer Insight Customer Analytics SAS Insight & Performance Performance Management Business and Resourse Planning IBM Business Planner Resource Availability Checker Websphere Channel Analytics Business Intelligence Call Center Solution Business Architecture System Architect Operational Excellence Marketing ERP Marketeer Analytics Platform Business Activity Monitoring Websphere System Architect Human Resources ERP Business Intelligence EAI Business Process Analytics Reuters Market Information Bloomberg Internal Knowledge Sharer System Architect Business Intelligence EAI Websphere Workflow ILUSTRAÇÃO 2 - EXEMPLO DE FILTRO DE CONFORMIDADE APLICADO A UM BLUEPRINT DE GOVERNAÇÃO DE APLICAÇÕES. ILUSTRAÇÃO 3 - INTERFACE DE PARAMETRIZAÇÃO DE FILTROS DE CONFORMIDADE. Um filtro de operações é aplicado no âmbito de um projecto e reflecte que acções, impostas pelo projecto, afectam os elementos do Blueprint. Cada tipo de operação tem uma ilustração distinta. Whitepaper EAMS Agosto de 2010 Pag. 10

2.1.3 INTRODUÇÃO DE DADOS A colocação de informação no repositório pode ser feita através dos mecanismos disponibilizados pelo SA ou através da importação de ficheiros via EAMS. O System Architect permite a inserção de dados através do BackOffice ou interface Web, neste último podendo ser parametrizados Web Services. Adicionalmente pode ser definido um processo Extract, Transform, and Load (ETL) para integrar com outras aplicações ou plataformas. ILUSTRAÇÃO 4 - IMPORTAÇÃO E EXPORTAÇÃO DE INFORMAÇÃO. 2.1.4 GERAÇÃO DE DOCUMENTOS E RELATÓRIOS É possível gerar automaticamente Documentos de Arquitectura, em formato Microsoft PowerPoint, que tenham como sujeito ou um projecto ou uma aplicação, por exemplo. Este tipo de documento apresenta uma descrição tanto textuais como gráfica de um conjunto de entidades ou Blueprints referente ao ciclo de governação vigente. O relatório Power Point pode ser aplicado a qualquer tipo de entidade parametrizada em seu metamodelo. Isto é um recurso extremamente importante e útil para reduzir consideravelmente o esforço de geração manual de documentos. Whitepaper EAMS Agosto de 2010 Pag. 11

2.1.5 IMPORTAÇÃO E EXPORTAÇÃO DE INFORMAÇÃO A solução em conjunto disponibiliza mecanismos de importação e exportação dos dados do repositório. As transferências são efectuadas com recursos a ficheiros XML e Commaseparated values (CSV). Qualquer uma das operações pode ser feita de acordo com duas orientações. O ficheiro pode ser referente a um tipo de definição ou específico a um Blueprint. No caso específico da importação de definições é possível escolher que regras aplicar durante o processo: Introdução de novas definições: Só somente adicionadas novas definições e as respectivas propriedades. Actualização destrutiva: São actualizadas todas as definições e propriedades referidas no ficheiro. Os que não estiverem presentes no ficheiro são eliminados do repositório. Actualização não destrutiva: Os valores presentes nas propriedades das definições presentes no ficheiro são adicionados. Caso existam valores no repositório não referenciados no ficheiro não são apagados. Actualização valores de propriedades em falta: O objectivo desta opção de importação é completar os dados já existentes no repositório do SA. Se as definições já existirem no repositório, apenas serão preenchidos os valores das propriedades que ainda não tiverem qualquer valor no repositório. Se as propriedades já tiverem algum valor atribuído não serão substituídas pelos valores presentes no ficheiro. Se as definições não existirem, serão criadas. Para maiores informações sobre o módulo de importação da informação do EAMS, consultar o guia do usuário disponível no package da documentação. Whitepaper EAMS Agosto de 2010 Pag. 12

2.2 TIPOS DE BLUEPRINT O EAMS disponibiliza um conjunto de mapas padrão, que responde à várias questões. Tais mapas são totalmente configuráveis e outros novos podem ser adicionados por parametrização. Abaixo um conjunto de tipos de mapas pré-configurados no produto, divididos em categorias que também podem ser configuradas. ILUSTRAÇÃO 5 CATEGORIAS E TIPOS DE BLUEPRINTS PRÉ-CONFIGURADOS NO EAMS Tipo Orgânicos de Aplicações Contexto de Projecto Contexto de Aplicação Integração Descrição Os Blueprints Orgânicos se envolvem em torno de um único conceito, explicitando a sua estrutura hierárquica de acordo com uma determinada classificação ou por agrupamento com conceitos lógicos. O conceito principal deste tipo de Blueprints neste caso é a aplicação, mas poderia ser aplicado a vários outros conceitos. No topo da hierarquia surgem os domínios aplicacionais que podem ter vários níveis de profundidade. Encapsulado por estes, estão as soluções que, são por sua vez o elemento agregador das aplicações. Identifica quais os principais elementos relacionados com um projecto. Os artefactos relacionados são: Processos de Negócio; Entidades Informacionais; Plataformas de Integração; Stakeholders; Aplicações; Projectos Relacionados. Identifica quais os principais elementos relacionados com uma dada aplicação. Os artefactos relacionados são: Processos de Negócio; Entidades Informacionais; Plataformas de Integração; Stakeholders; Aplicações; Repositórios. As Blueprints de integração visam explicitar tanto as integrações existentes como as respectivas comunicações. A análise é feita ao nível do componente. Este Blueprint tem cinco tipos principais de componentes: Whitepaper EAMS Agosto de 2010 Pag. 13

Impacto participantes; plataformas; aplicações; componentes; mensagens. Os componentes executam-se directamente sobre uma plataforma e estão associados a uma ou mais aplicações. Nesta vista os componentes são envoltos pela aplicação correspondente que por sua vez está contida na plataforma associada ao componente. As mensagens são trocadas entre componentes. O impacto de projecto apresenta-se como um derivado do universal parametrizado de modo a ilustrar artefactos associados a projectos e identificar as dependências entre dois ou mais projectos. TABELA 1 - ALGUNS EXEMPLOS DE BLUEPRINTS. Business Processes Informational Entities Business Processes Informational Entities Architecture Management Project Portfolio Mngmt Operational Risk Architecture Artifact IT Project Risk Architecture Management IT Governance ITIL Processes Architecture Artifact Application Network Node IT Governance Resource Application Interface Project Portfolio Mngmt Credit Request Enterprise Location Interface Policy IT Project Resource Server Risk Server Platforms Application Repositories Oracle 10.NET Framework 3.5 SP1 Architecture Repository Project Database Platforms.NET Framework Oracle 10 3.5 SP1 Project EA Initiative Risk Assessment Projects EAI Project Office 2007 SP1 SQL Server 2005 SP2 Owner André Sampaio Risk DB Application Catalogue Office 2007 SP1 SQL Server 2005 SP2 Armando Vieira Stakeholders João Almeida CMDB Project PSO Project WebServices Websphere Middleware Catalogue CMDB Websphere WebServices Pedro Sousa André Sampaio Business Objects Windows Forms Windows Forms José Lima System Architect Application Catalogue Applications CMDB DOORS Project Suite DOORS CMDB Applications Application Catalogue System Architect Project Suite ILUSTRAÇÃO 6 - BLUEPRINT DE CONTEXTO DE APLICAÇÃO ILUSTRAÇÃO 7 BLUEPRINT DE CONTEXTO DE PROJECTO COM FILTRO DE OPERAÇÕES. ILUSTRAÇÃO 8 BLUEPRINT DE IMPACTO DE PROJECTO Whitepaper EAMS Agosto de 2010 Pag. 14

Platforms Websphere System Architect Client Presentation Web Wizard Interface Interface PAD Generator Risk Assessor Platforms System Architect Client Presentation Web Interface Wizard Interface.NET Framework 3.5 SP1 Forms Interface.NET Framework 3.5 SP1 PAD Generator Windows Forms Windows Forms XP SP1 Backoffice Module Business Client Manager Websphere Backoffice Module Business Core Core Data Proxy Tivoli DOORS Drawing Manager Excel Exploratory Module XP SP1 Drawing Manager Excel Exploratory Module SQL Server 2005 SP2 App Catalogue Integration Integration CMDB Integration Tivoli CMDB Integration Integration DOORS Integration Office 2007 SP1 DOORS Integration Project Mngmt Integration DOORS Project Mngmt Integration Business Objects SA Integrator ALM Integrator Module Data EA Repository SQL Server 2005 SP2 Office 2007 SP1 Data EA Repository ILUSTRAÇÃO 9 BLUEPRINT DE ESTRUTURA DE APLICAÇÃO EAMS. ILUSTRAÇÃO 10 BLUEPRINT DE ESTRUTURA DE APLICAÇÃO EAMS NO ÂMBITO DE UM PROJECTO COM FILTRO DE OPERAÇÕES. Risk Analyst use reports Business Objects Risk Assessor.NET Framework 3.5 SP1 Open ALM presentation ALM Integrator risk data Windows Forms Drawing Manager EA and risk data risk data Core Open ALM Core system architect EA data risk data System Architect Client SQL Server 2005 SP2 System Architect Open ALM Data Proxy EA data EA Repository Asset Liability Repository ILUSTRAÇÃO 11 BLUEPRINT DE INTEGRAÇÃO DE APLICAÇÃO COM FILTRO DE OPERAÇÕES. Whitepaper EAMS Agosto de 2010 Pag. 15

2.3 PARAMETRIZAÇÃO Existe um conjunto de configurações possíveis que o utilizador pode definir. A solução usa definições do System Architect para estabelecer essas mesmas parametrizações. O utilizador pode definir quais as relações que quer ver identificadas num Blueprint, fazer alterações quanto à disposição gráfica dos elementos ou mesmo alterar componentes da notação como a cor. O exemplo seguinte é referente um Blueprint de Contexto de Projecto, seleccionado na primeira imagem, em que se especifica algumas propriedades no ecrã direito. ILUSTRAÇÃO 12 - PARAMETRIZAÇÃO DE UM BLUEPRINT. Adicionalmente é permitido usar ficheiros para guardar estas configurações como no caso dos Filtros. De modo a evitar a repetição de um conjunto de passos, cada vez que se deseja executar uma análise complexa, podemos simplesmente importar e reutilizar um filtro. ILUSTRAÇÃO 13 - EXEMPLO DE IMPORTAÇÃO DE UM TEMPLATE DE FILTRO. Whitepaper EAMS Agosto de 2010 Pag. 16

2.4 ANÁLISES E MATRIZES TEMPORAIS Especificando propriedades do tipo Data nos objectos presentes nas várias entidades e diagramas do System Architect é possível depois uma usar uma análise através de barra de tempo para verificar a evolução de um conjunto de artefatos ao longo do tempo. Esta análise pode ser feita com base em duas propriedades: Effective Date (data em que o objecto se tornou válido para a Organização, por exemplo entrada em produção de uma aplicação) e In Service Date (data em que o objecto deixou de ser válido para a Organização, por exemplo a data em que uma determinada aplicação foi descontinuada). A sequência de imagens apresentadas em baixo exemplifica a utilização da barra temporal para a análise da evolução da TI, neste caso apresenta-se a evolução temporal das integrações de determinada aplicação, à medida que vão entrando em produção resultado de projectos do IT. Esta funcionalidade é disponibilizada pelo EAMS Viewer. ILUSTRAÇÃO 14 - BARRA TEMPORAL COM APLICAÇÃO DA VISUALIZ AÇÃO DE 31-01-07 A 30-12-2011. ILUSTRAÇÃO 15 SITUAÇÃO DO CONTEXTO DA APLICAÇÃO BILL CALCULATION EM 03/07/08. Whitepaper EAMS Agosto de 2010 Pag. 17

ILUSTRAÇÃO 16 EVOLUÇÃO DO CONTEXTO DA APLICAÇÃO PARA 30-12-2011. Pelas duas ilustrações acima, podemos observar as mudanças que ocorreram de 03/07/2008 a 30/12/2011, as datas escolhidas para este exemplo de análise. Isto é importante para saber o portfolio passado, atual e futuro da organização, quer to tocante aos sistemas, ou a componentes de TI, ou a processos. A partir da data prevista de implantação de um determinado sistema, é possível evoluir na barra do tempo e desta forma acompanhar qual a situação que a TI ou empresa estaria se aquele planejamento fosse de fato implementado. É essencial conseguir identificar e representar a evolução da organização desde o AS IS ao TO BE no mesmo repositório, de modo a ser possível analisar o real impacto que o aparecimento de novos projetos pode introduzir. Isto implica em analisar, por exemplo, quando determinado sistema será descontinuado e quais projetos podem ser impactados por isso. Com a Visão Temporal somada aos recursos matriciais conseguimos identificar qual o estado de qualquer artefato dentre as fases de seu ciclo de vida. ILUSTRAÇÃO 17 MATRIZ TEMPORAL DAS APLICAÇÕES POR TIPO DE PROJETO. Whitepaper EAMS Agosto de 2010 Pag. 18

2.5 INTEGRAÇÃO COM O SYSTEM ARCHITECT O EAMS actua directamente sobre o System Architect (BackOffice) via Common Object Model (COM) Interoperability estabelecendo uma relação simbiótica onde ambas as ferramentas usufruem das funcionalidades uma da outra. Por sua vez os clientes FrontOffice têm acesso ao repositório do SA que é gerido conjuntamente com o EAMS. ILUSTRAÇÃO 18 - EXEMPLO DE INTERACÇÃO COM O REPOSITÓRIO. 2.6 REQUISITOS Os requisitos de hardware são ditados pelas necessidades associadas aos seguintes requisitos de software. Microsoft Windows XP ou Microsoft Vista Microsoft Office Word 2007 Microsoft Office PowerPoint 2007 Microsoft Office Excel 2007 Microsoft.NET Framework 3.5 IBM Telelogic System Architect 10 ou superior Para maiores informações sobre o produto, consulte o site www.link.pt/eams Aitec Brasil R Luigi Galvani, 200 Cj 112 Brooklin São Paulo-SP info@aitecbrasil.com.br www.aitecbrasil.com.br Whitepaper EAMS Agosto de 2010 Pag. 19