AE Aulas Estado da Arte

Prévia do material em texto

Introdução
• Este capítulo fornece uma visão geral dos métodos e técnicas atualmente utilizados na arquitetura
empresarial. Naturalmente, esta descrição é um instantâneo e não podemos afirmar que seja exaustiva, uma
vez que o campo da arquitetura empresarial está a evoluir rapidamente. No entanto, fornece esta ampla
visão geral dos métodos e técnicas atuais para dar ao leitor uma impressão dos avanços neste campo.
• Em primeiro lugar, posicionamos a arquitetura empresarial em relação a uma série de padrões e práticas
recomendadas bem conhecidos na gestão geral e de TI. Em segundo lugar, descrevemos as estruturas e
métodos mais importantes para a arquitetura empresarial atualmente em uso.
• A seguir, discutiremos a orientação para o serviço, o mais importante paradigma arquitetónico que surgiu
nos últimos anos. Por fim, descrevemos uma série de linguagens relevantes para a modelação de
organizações, processos de negócio, aplicações e tecnologia.
Arquitetura Empresarial e Outros Instrumentos 
de Gestão
• A arquitetura empresarial é normalmente utilizada como um instrumento na gestão das operações diárias e
do desenvolvimento futuro de uma empresa.
• Mas como é que isto se enquadra noutras práticas e instrumentos de gestão estabelecidos?
• Aqui, descrevemos como a arquitetura empresarial se posiciona dentro do contexto da governação
corporativa e das TI, relacionando-a com uma série de melhores práticas e normas conhecidas em geral e na
gestão de TI, trataremos da relação de entrada arquitetura empresarial com algumas práticas de gestão bem
conhecidas em cada uma destas áreas:
― Gestão estratégica: o Balanced Scorecard;
― Execução da estratégia: EFQM;
― Gestão da qualidade: ISO 9001;
― Governação de TI: COBIT;
― Entrega e suporte de Serviços de TI: ITI;
― Implementação de TI: CMM e CMMI.
Arquitetura Empresarial e Outros Instrumentos 
de Gestão
• Áreas de gestão relevantes para a arquitetura empresarial.
Gestão Estratégica: Balanced Scorecard
• Kaplan e Norton (1992) introduziram o balanced scorecard (BSC) como um sistema de gestão que ajuda uma
empresa a clarificar e implementar a sua visão e estratégia. Tradicionalmente, o foco da gestão tem sido
fortemente virado para aspetos financeiros. Kaplan e Norton defendem que as medidas financeiras por si só são
inadequadas para orientar o desenvolvimento futuro de uma organização e que devem ser complementadas com
medidas relativas à satisfação do cliente, aos processos internos e à capacidade de inovar.
• O BSC sugere, por isso, visualizar uma empresa a partir de quatro perspetivas.
• A perspetiva do cliente questiona como a empresa deve aparecer aos seus clientes, com medidas como a satisfação do
cliente.
• A perspetiva financeira está focada no valor comercial criado pela empresa, envolvendo medidas como o valor para os
acionistas.
• A perspetiva dos Processos Internos de Negócio, analisa a eficácia e a eficiência das operações internas de uma empresa,
prestando especial atenção aos processos primários orientados para a missão.
• A perspetiva de Aprendizagem e Crescimento aborda a capacidade corporativa e individual de mudar e melhorar, o que é
essencial para qualquer organização com utilização intensiva de conhecimento.
• Para cada uma das quatro perspetivas, o BSC propõe uma estrutura de três camadas:
Gestão Estratégica: Balanced Scorecard
1. Missão (por exemplo, tornar-se o fornecedor preferido dos clientes);
2. Objetivos (por exemplo, fornecer novos produtos aos clientes); 
3. Medidas (por exemplo, percentagem do volume de negócios gerado por novos produtos).
• Para pôr em prática o BSC, uma empresa deve primeiro definir a sua missão, objectivos e medidas para cada
perspectiva e depois traduzi-los numa número de metas e iniciativas adequadas para atingir esses objetivos.
• O que é importante no BSC é a noção de feedback de circuito duplo. Em primeiro lugar, deve-se medir os
resultados dos processos empresariais internos e não só corrigir defeitos nessas saídas, mas também
identificar e remediara as causas desses defeitos.
• Além disso, este ciclo de feedback também deve ser instituído para os resultados das estratégias de negócio.
Medição de desempenho e a gestão por factos são centrais na abordagem do BSC.
Gestão Estratégica: Balanced Scorecard
• Se olharmos para o papel da arquitetura empresarial como instrumento de gestão, esta seria especialmente
útil dentro dos Processos Internos de Negócio na perspectiva do BSC.
• Muitas métricas operacionais podem ser ligadas a uma arquitetura empresarial bem definida e várias
análises de desempenho podem ser realizados. No entanto, a arquitetura empresarial tem uma utilização
mais ampla.
• Na perspetiva de aprendizagem e crescimento, a capacidade de uma empresa evoluir, antecipar e responder
a um ambiente em mudança é vital. Para determinar a agilidade da organização, é importante avaliar qual
poderá ser o impacto e a viabilidade de mudanças futuras. A análise de impacto de uma arquitetura
empresarial pode auxiliar nesta avaliação.
Execução da estratégia: EFQM
• Outra abordagem importante à gestão é o Modelo de Excelência da EFQM (Fundação Europeia para a
Gestão da Qualidade) (EFQM 2003). Este modelo foi introduzido pela primeira vez em 1992 como estrutura
para avaliar as candidaturas ao Prémio Europeu da Qualidade e foi inspirado no Modelo Malcolm Baldridge
nos EUA e no Prémio Deming no Japão.
• O modelo EFQM tem um âmbito muito mais vasto do que a ISO 9001. Não se concentra apenas na gestão da
qualidade, mas fornece uma visão geral da estrutura de gestão para a excelência do desempenho de toda a
organização.
• O modelo EFQM é constituído por nove critérios de excelência, cinco dos quais são “facilitadores”,
abrangendo o que uma organização faz, e quatro são “resultados”, abrangendo o que a organização alcança.
Estes critérios e as suas relações mútuas são apresentados sob a forma de diagrama. A Liderança, a Política e
a Estratégia determinam a direção e o foco da empresa; com base nisto, as Pessoas da empresa, as suas
Parcerias e Recursos e os seus Processos fazem com que isso aconteça;
Execução da estratégia: EFQM
• O Modelo de Excelência EFQM (EFQM 2003).
Execução da estratégia: EFQM
• Posicionando a arquitetura empresarial em relação ao modelo EFQM, vemos este especialmente como um
instrumento importante para os aspetos de Política e Estratégia e Processos. Com base na sua missão e
visão, uma organização determinará as políticas e estratégias necessárias para satisfazer as necessidades e
expectativas presentes e futuras das suas partes interessadas.
• Uma arquitetura empresarial é um instrumento valioso na operacionalização e implementação destas
políticas e estratégias. Em primeiro lugar, oferece uma visão geral da estrutura e do funcionamento da
empresa como um todo, criando uma visão panorâmica da sua estrutura organizacional, processos de
negócio, sistemas de informação e infraestruturas. Esta visão geral é indispensável quando se formula uma
estratégia coerente.
• Além disso, uma arquitetura empresarial ajuda a desenvolver, gerir e comunicar padrões de operação em
toda a empresa, necessários para garantir que as políticas da empresa são de facto implementadas. Por
último, ao proporcionar uma melhor compreensão dos efeitos das mudanças, é uma ajuda preciosa na
criação de roteiros para o futuro, necessários para avaliar e executar a estratégia empresarial a longo prazo.
Gestão da qualidade: ISO 9001
• A norma ISO 9001:2000 (ISO 2000) da Organização Internacional de Normalização (ISO) define critérios para uma
boa gestão da qualidade de sistema (SGQ). Com base numa política de qualidade e em metas de qualidade, uma
empresa concebe e documenta um SGQ para controlar a forma como os processos são executados. Os requisitos
da norma abrangem tudo, desde a forma como uma empresa planeia os seus processos de negócio até à forma
como são executados, medidos e melhorados.
• Partindo de requisitos gerais e globais, a norma estabelece as responsabilidadesda gestão em relação ao SGQ. Em
seguida, fornece requisitos para os recursos, incluindo pessoal, formação, instalações e ambiente de trabalho.
• As exigências sobre o que se chama "realização do produto", ou seja, os processos de negócio que realizam o
produto ou serviço da empresa são o cerne da norma. Os processos-chave, ou seja, aqueles processos que afetam
a qualidade do produto ou serviço, devem ser identificados e documentados. Isto inclui planeamento, processos
relacionados com o cliente, design, compras e controlo de processos. Por fim, são colocados requisitos para a
medição, análise e melhoria destes processos de negócios. Após a instalação do sistema de qualidade, uma
empresa pode solicitar uma auditoria por um Registador. Se estiver em conformidade com todos os critérios, a
empresa será registada na ISO 9001.
Gestão da qualidade: ISO 9001
• Embora o padrão tenha ganho a reputação de ser demasiado "pesado em documentos", isto refere-se
principalmente às suas versões anteriores de 1987 e 1994. Apesar destas críticas, o valor comercial de um
bom SGQ é universalmente reconhecido. Na Europa, as empresas industriais estão cada vez mais exigentes
quanto ao registo ISO 9001 aos seus fornecedores, e a aceitação universal como norma internacional está a
crescer.
• Olhando para a arquitetura empresarial a partir da perspetiva da gestão da qualidade em geral e da ISO
9001 em particular, vemos o seu principal contributo no design integrado, na gestão e na documentação
empresarial, processos e os seus sistemas de TI de suporte.
• Uma arquitetura empresarial bem concebida e documentada ajuda uma organização a estar em
conformidade com os requisitos ISO 9001 sobre identificação e documentação de processos; por outro lado,
a necessidade de um SGQ pode direcionar o foco para uma iniciativa de arquitetura empresarial, colocando
a ênfase nos processos e recursos que são essenciais para a qualidade do produto ou serviço da empresa.
Desta forma, a gestão da qualidade e a arquitetura empresarial formam uma combinação natural: o primeiro
preocupa-se com o que precisa de ser concebido, documentado, controlado, medido e melhorado, e o
segundo determina a forma como esses processos e recursos de alta qualidade são organizados e realizados.
Governação de TI: COBIT
• A norma COBIT (Control Objectives for Information and related Technology) para a governação das TI foi
inicialmente publicada em 1996 pela Information Systems Audit and Control Association. Já na sua terceira
edição, publicada em 2000 pelo IT Governance Institute (COBIT 2000), o COBIT, é um estrutura de controlo
de TI aceite internacionalmente que fornece às organizações “boas práticas” que ajudam na implementação
de uma estrutura de governação de TI em toda a empresa. O seu objetivo é preencher as lacunas entre os
riscos comerciais, as necessidades de controlo e as questões técnicas.
• A premissa base do COBIT é que para fornecer a informação que a organização necessita para atingir os seus
objetivos, os recursos de TI necessitam de ser geridos por um conjunto de processos naturalmente
agrupados.
• O núcleo da estrutura COBIT são os objetivos de controlo e as orientações de gestão para 34 processos de TI
identificados, que estão agrupados em quatro domínios: planeamento e organização, aquisição e
implementação, entrega e suporte, e monitoria.
Governação de TI: COBIT
• Aqui, o “controlo” é definido pelo COBIT como as políticas, procedimentos, práticas e estruturas
organizacionais concebidas para fornecer uma garantia razoável de que os objetivos de negócio serão
alcançados e que os eventos indesejados serão prevenidos ou detetados e corrigidos.
• Os objetivos de controlo podem ajudar a suportar a governação de TI dentro de uma empresa. Por exemplo,
os objetivos de controlo do processo “Assistir e aconselhar clientes de TI” consistem em estabelecer um help
desk, registo de consultas de clientes, escalonamento de consultas de clientes, monitoria de releases e
análise de tendências e relatórios.
• Para além da estrutura de objetivos de controlo, o COBIT fornece fatores críticos de sucesso para atingir o
controlo ideal sobre os processos de TI, indicadores-chave de metas, que medem se um processo de TI
cumpriu os seus requisitos de negócio, e indicadores-chave de desempenho, que definem medidas de quão
bem o processo de TI está a correr em relação ao alcance dos seus objetivos.
Governação de TI: COBIT
• O COBIT oferece também um modelo de maturidade para a governação de TI, consistindo em cinco níveis de 
maturidade:
1. Ad Hoc: Não existem processos normalizados. As abordagens ad hoc são aplicadas caso a caso.
2. Repetível: a gestão está ciente dos problemas. Estão a ser desenvolvidos indicadores de desempenho, identificadas medições
básicas, bem como métodos e técnicas de avaliação.
3. Definida: A necessidade de agir é compreendida e aceite. Os procedimentos foram normalizados, documentados e implementados.
As ideias do BSC estão a ser adotadas pela organização.
4. Gerido: Foi alcançado um entendimento completo dos problemas a todos os níveis. A excelência do processo é construída num
currículo de formação formal. É totalmente alinhado com a estratégia de negócio.
5. Otimizado: A melhoria contínua é a característica definidora. Os processos foram refinados ao nível das melhores práticas externas
com base sobre os resultados da melhoria contínua com outras organizações.
Governação de TI: COBIT
• Este modelo de maturidade assemelha-se muito ao Modelo de Maturidade de Capacidade (CMM) para o 
desenvolvimento de software e ao seu sucessor, o (CMMI).
• De acordo com o COBIT, arquiteturas bem definidas são a base para um bom ambiente de controlo interno.
Em muitas empresas, a organização de TI irá ser responsável por estabelecer e manter a arquitetura
empresarial. Enquanto o COBIT se centra na forma como se deve organizar a TI (secundária) função de uma
organização, a arquitetura empresarial centra-se nas estruturas de negócio e de TI (primárias), nos
processos, na informação e na tecnologia da empresa.
• Assim, a arquitetura empresarial constitui um complemento natural ao COBIT. Em relação aos níveis de
maturidade do COBIT, a arquitetura empresarial será, naturalmente, mais relevante no nível superior. Ao
nível repetível, pode surgir uma primeira consciencialização do valor da arquitectura, mas normalmente não
existe uma prática arquitectónica estabelecida ao nível empresarial. Só a partir do nível Definido é
reconhecido e utilizado como um instrumento importante no planeamento e gestão dos desenvolvimentos
de TI em coordenação com as necessidades do negócio.
Entrega e suporte de Serviços de TI: ITI
• O ITIL (IT Infrastructure Library) é o conjunto de melhores práticas mais amplamente aceite no domínio da
prestação de serviços de TI.
• Foi originalmente desenvolvido pelo Gabinete de Comércio do Governo do Reino Unido (OGC), para
melhorar a gestão dos serviços de TI no governo central do Reino Unido. Os objetivos da OGC eram por um
lado, criar um conjunto abrangente e consistente de melhores práticas para a gestão de serviços de TI de
qualidade e, por outro, incentivar o setor privado a desenvolver formação, consultoria e ferramentas que
suportem o ITIL.
• Ao longo dos anos, o ITIL ganhou um amplo apoio e tornou-se o padrão mundial de facto para a gestão de
serviços de TI. O grupo de utilizadores do ITIL, o IT Service Management Forum (itSMF1), promove
ativamente a troca de informações e experiências para ajudar os fornecedores de serviços de TI a gerir a
prestação de serviços.
Entrega e suporte de Serviços de TI: ITI
• O ITIL compreende uma série de documentos que fornecem orientações sobre a prestação de bons serviços
de TI e sobre as instalações necessárias para apoiar as TI.
• O ITIL tem um abordagem orientada a processos para a gestão de serviços. Fornece códigos de prática que
ajuda as organizações a estabelecer a gestão da qualidade dos seus serviços e infraestruturas de TI, onde a
"qualidade" é definida como"correspondente às necessidades do negócio e aos requisitos do utilizador à
medida que estes evoluem". O núcleo do ITIL é constituído por dois grandes grupos de processos:
― Prestação de serviços, abrangendo a gestão do nível de serviço, gestão de disponibilidade, gestão financeira para
serviços de TI, gestão de contingência de serviços de TI e gestão de capacidade;
― Suporte de serviço, abrangendo a gestão de problemas, gestão de incidentes, service desk, gestão de alterações,
gestão de versões e gestão de configuração.
Entrega e suporte de Serviços de TI: ITI
• O ITIL é complementar do COBIT. Os objetivos de controlo de alto nível do COBIT podem ser implementados
através da utilização do ITIL. O seu módulo de help desk, por exemplo, complementa e fornece detalhes
sobre o processo de help desk, incluindo o planeamento, implementação, pós-implementação, benefícios e
custos e ferramentas. Portanto, os objetivos de controlo do COBIT dizem-lhe o que fazer e o ITIL explica
como o fazer, ou seja, quais são os processos de melhores práticas para concretizar esses objetivos.
• A gestão dos ativos de TI de uma organização é essencial para o ITIL. É aqui que uma arquitetura empresarial
bem desenvolvida é muito valiosa. Fornece aos gestores de TI uma compreensão clara das aplicações e da
infraestrutura de TI, dos processos de negócio relacionados e das várias dependências entre estes domínios.
Quase todos os principais processos identificados pelo ITIL beneficiarão com isso.
Implementação de TI: CMM e CMMI
• O Capability Maturity Model for Software (Paulk et al. 1993), também conhecido por CMM e SW-CMM, é um
modelo para julgar a maturidade dos processos de engenharia de software de uma organização e fornece às
organizações as principais práticas necessárias para as ajudar a aumentar a maturidade desses processos.
• Em 2000, o SW-CMM foi atualizado para CMMI (Capabilities Maturity Model Integration), que aborda a
integração do desenvolvimento de software com outras atividades de engenharia e expande o âmbito para
abranger todo o ciclo de vida do produto, incluindo a engenharia de sistemas, desenvolvimento integrado de
produtos e processos e outsourcing de fornecedores.
• A popularidade do CMM desencadeou o desenvolvimento de uma maturidade semelhante de modelos
noutros campos, incluindo a arquitetura empresarial.
Implementação de TI: CMM e CMMI
• Nos modelos de maturidade CMMI na sua forma mais comum, existem cinco níveis de maturidade, cada um
deles uma camada na base para a melhoria contínua do processo, designados pelos números de 1 à 5
(CMMI Product Team 2002):
1. Inicial: Os processos são geralmente ad hoc e caóticos. A organização não oferece um ambiente estável. O sucesso
nestas organizações depende da competência e do heroísmo das pessoas na organização e não da utilização de
processos comprovados.
2. Gerido: Os projetos da organização garantiram que os requisitos são geridos e que os processos são planeados,
executados, medidos e controlados. No entanto, os processos podem ser bastante diferentes em cada caso
específico, por exemplo, num projeto específico.
3. Definidos: Os processos estão bem caracterizados e compreendidos, e estão descritos em normas,
procedimentos, ferramentas e métodos. Estas normas são utilizados para estabelecer consistência em toda a
organização. Os projetos estabelecem os seus processos definidos adaptando o conjunto de processos padrão da
organização de acordo com as diretrizes de adaptação.
Implementação de TI: CMM e CMMI
4. Gerido quantitativamente: os objetivos quantitativos para a qualidade e desempenho dos processos são
estabelecidos e utilizados como critérios na gestão de processos. Os objetivos quantitativos baseiam-se nas
necessidades do cliente, utilizadores finais, organização e implementadores de processos.
5. Otimização: O desempenho do processo é continuamente melhorado através de melhorias tecnológicas
incrementais e inovadoras. Quantitativo são estabelecidos objetivos de melhoria de processos para a organização,
continuamente revisto para refletir os objetivos de negócio em mudança e utilizado como critérios na gestão da
melhoria de processos.
• O CMMI fornece inúmeras orientações para avaliar a maturidade de uma organização e as melhorias
necessárias em várias áreas de processo para avançar de um nível para o seguinte. Para além desta
representação familiar em fases do modelo de maturidade em termos de níveis de maturidade consecutivos,
existe agora também uma representação contínua.
Implementação de TI: CMM e CMMI
• Em qualquer projeto de engenharia de software de dimensão substancial, a arquitetura de software
desempenha um papel importante. O contexto desta arquitetura de software pode ser fornecido por uma
arquitetura empresarial, que fornece restrições e orientações para projetos de software individuais. Assim, a
arquitetura empresarial é algo que se torna especialmente útil (ou mesmo necessário) no CMMI Nível 3 e
mais além, onde os projetos precisam de estar em conformidade com as normas e diretrizes de toda a
organização.
Métodos e Frameworks
• Para fornecer mais informações sobre os diferentes aspetos que um modelo de arquitetura empresarial
pode abranger, descreveremos uma série de estruturas de arquitetura. As estruturas de frameworks
descrevem técnicas de arquitetura identificando e relacionando diferentes pontos de vista arquitetónicos e
as técnicas de modelação a elas associadas. Não fornecem os conceitos para a modelação real, embora
algumas estruturas sejam intimamente ligado a uma linguagem de modelação específica ou conjunto de
linguagens.
• A maioria dos frameworks de arquitetura são bastante precisos ao estabelecer quais elementos devem fazer
parte de uma arquitetura empresarial. No entanto, para garantir a qualidade da arquitetura empresarial
durante seu ciclo de vida, a adoção de um determinado framework não é suficiente. As relações entre os
diferentes tipos de domínios, visões ou camadas da arquitetura devem permanecer claras, e qualquer
mudança deve ser realizada metodicamente em todos eles. Para esse propósito, vários métodos estão
disponíveis, os quais auxiliam os arquitetos em todas as fases do ciclo de vida das arquiteturas.
Métodos de Arquitetura Empresarial
• Um método de arquitetura é uma coleção estruturada de técnicas e etapas de processo para criar e manter
uma arquitetura empresarial. Os métodos geralmente especificam as várias fases do ciclo de vida de uma
arquitetura, quais entregas devem ser produzidas em cada estágio e como elas são verificadas ou testadas.
Os seguintes métodos para desenvolvimento de arquitetura valem a pena mencionar:
― Embora destinado ao desenvolvimento de software, o Rational Unified Process (RUP) (Jacobson et al. 1999) é de interesse aqui, pois
define um processo iterativo, em oposição ao processo cascata clássico, que realiza software adicionando funcionalidade à
arquitetura em cada incremento. Uma extensão em direção à arquitetura de TI empresarial é dada por McGovern et al. (2004) na
forma do Enterprise Unified Process.
― A Metodologia de Modelagem UN/CEFACT (UMM) é uma metodologia incremental de construção de processos de negócios e
modelos de informações. O escopo é intencionalmente restrito a operações de negócios, omitindo aspectos específicos da
tecnologia. O Business Collaboration Framework (BCF), que está atualmente em desenvolvimento, será uma especialização do UMM
com o objetivo de definir as trocas de informações externas de uma empresa e suas atividades comerciais subjacentes. Veja
UN/CEFACT (2004).
Métodos de Arquitetura Empresarial
― e suas atividades comerciais subjacentes. Veja UN/CEFACT (2004). – O Método de Desenvolvimento de Arquitetura TOGAF (ADM)
(veja Fig. 2.3 e Seção 2.2.4), desenvolvido pelo The Open Group, fornece um detalhado e bem descrito faseamento para o
desenvolvimento de uma arquitetura de TI. A versão 8 do TOGAF intitulada ‘Enterprise Edition’ (The Open Group 2002) fornece uma
estrutura e um método de desenvolvimentopara o desenvolvimento de arquiteturas empresariais.
Fundação Conceitual para Arquitetura: O 
Padrão IEEE 1471-2000
• Em 2000, a IEEE Computer Society aprovou o IEEE Standard 1471-2000 (IEEE Computer Society 2000), que
constrói uma base teórica sólida para a definição, análise e descrição de arquiteturas de sistemas. O IEEE
1471 foca principalmente em sistemas intensivos em software, como sistemas de informação, sistemas
embarcados e sistemas compostos no contexto da computação. O IEEE 1471 usa a metáfora da arquitetura
civil para descrever arquiteturas de sistemas de software. Nesse sentido, é semelhante à estrutura de
Zachman, embora não tente padronizar a arquitetura do sistema estabelecendo um número fixo ou a
natureza das visualizações (como no caso das 36 células da estrutura de Zachman).
• O IEEE 1471 também não tenta padronizar o processo de desenvolvimento de arquiteturas e, portanto, não
recomenda nenhuma linguagem, metodologia ou padrão de modelagem. Em vez disso, o IEEE 1471 fornece,
nos termos de uma “prática recomendada”, uma série de conceitos e termos de referência valiosos, que
refletem as “tendências geralmente aceitas na prática para descrição de arquitetura” e que “codificam
aqueles elementos sobre os quais há consenso”.
Fundação Conceitual para Arquitetura: O 
Padrão IEEE 1471-2000
Fundação Conceitual para Arquitetura: O 
Padrão IEEE 1471-2000
• Primeiro de tudo, o padrão fornece um conjunto de definições para termos-chave como adquirente,
arquiteto, descrição de arquitetura, modelos arquitetónicos, arquitetura, modelo de ciclo de vida, sistema,
parte interessada do sistema, preocupações, missão, contexto, visão arquitetónica, ponto de vista
arquitetónico. Como ideias essenciais, notamos uma separação clara entre uma arquitetura e suas
descrições de arquitetura (definidas como meios para registrar arquiteturas), e o papel central do
relacionamento entre ponto de vista arquitetónico e visão arquitetónica. O padrão também fornece uma
estrutura conceitual, que significa:
― Para explicar como os termos-chave se relacionam entre si em um modelo conceitual para descrição de arquitetura (este modelo é
mostrado na Figura a seguir e usa a notação UML para diagramas de classes);
― Para explicar o papel das partes interessadas na criação e utilização de uma descrição de arquitetura;
― Para fornecer uma série de cenários para as atividades arquitetónicas durante o ciclo de vida: arquiteturas de sistemas únicos,
arquitetura iterativa para sistemas evolutivos, arquitetura para sistemas existentes e avaliação arquitetónica.
Fundação Conceitual para Arquitetura: O 
Padrão IEEE 1471-2000
• Furthermore, the standard gives six architecture description practices:
• Documentação arquitetónica referente a informações de identificação, versão e visão geral.
• Identificação das partes interessadas do sistema e das suas preocupações, consideradas relevantes para a arquitetura.
• Seleção de pontos de vista arquitetónicos, contendo a especificação de cada ponto de vista que foi selecionado para organizar a
representação da arquitetura e as razões pelas quais foi selecionado.
• Vistas arquitetónicas correspondentes aos pontos de vista selecionados.
• Vistas arquitetónicas correspondentes aos pontos de vista selecionados.Enviar feedbackPainéis lateraisHistóricoSalvas
• Justificação arquitetónica para a seleção da arquitetura atual de entre uma série de alternativas consideradas.
Fundação Conceitual para Arquitetura: O 
Padrão IEEE 1471-2000
• O IEEE 1471 também fornece uma série de pontos de vista arquitetónicos relevantes, juntamente com as
suas especificações em termos de preocupações, linguagens e métodos de modelação e análise (ver Anexo
D da norma). É importante notar que as descrições de arquitetura que estão em conformidade com a norma
IEEE 1471 podem ser utilizadas para satisfazer os requisitos de outras normas, como o Modelo de Referência
de Processamento Distribuído Aberto (descrito na Secção 2.2.6).
A Framework de Zachman
• Em 1987, John Zachman introduziu a primeira e mais conhecida estrutura de arquitetura empresarial
(Zachman 1987), embora nessa altura se chamasse “Estrutura para a Arquitectura de Sistemas de
Informação”. O enquadramento, tal como se aplica às empresas, é simplesmente uma estrutura lógica para
classificar e/ou organizar as representações descritivas de uma empresa que sejam significativas para a
gestão da empresa, bem como para o desenvolvimento dos sistemas da empresa.
• A estrutura figura a seguir na sua forma mais simples descreve os artefactos de design que constituem a intersecção entre as funções no
processo de designess: isto é, proprietário, projectista e construtor; e as abstracções do produto: isto é, de que (material) é feito, como o
(processo) funciona e onde (geometria) os componentes são relativos entre si. Empiricamente, nas disciplinas mais antigas, alguns outros
“artefactos” eram observáveis e estavam a ser utilizadospara efeitos de âmbito e implementação. Estas funções são rotuladas de forma algo
arbitrária como planeador e subcontratado e estão incluídas noestrutura gráfica comummente apresentada.
A Framework de Zachman
A Framework de Zachman
• Desde o início da estrutura, sabia-se que existiam algumas outras abstracções de produtos porque era óbvio
que, para além do que,como e onde, uma descrição completa teria necessariamente de incluir as restantes
interrogativas primitivas: quem, quando e porquê. Estes trêsinterrogativos adicionais seriam manifestados
como três colunas adicionais de modelos que, no caso das empresas, descreveriam: quem faz que trabalho,
quando é que as coisas acontecem e porque é que são feitas várias escolhas?
• As vantagens da estrutura Zachman são que é fácil de compreender, aborda a empresa como um todo, é
definida independentemente das ferramentas ou metodologias e quaisquer problemas podem ser
mapeados para compreender onde se enquadram. Uma desvantagem importante é o grande número de
células, o que é um obstáculo à aplicabilidade prática da estrutura. Além disso, as relações entre as
diferentes células não estão tão bem especificadas. Não obstanteApesar destas desvantagens, Zachman
deve ser creditado por fornecer a primeira estrutura abrangente para a arquitetura empresarial, e o seu
trabalho ainda é amplamente utilizado.
A Framework de grupo aberto
• O Open Group Architecture Framework (TOGAF) surgiu como uma estrutura e metodologia genérica para o
desenvolvimento de arquitetura técnicaestruturas, mas evoluiu para uma estrutura e método de arquitetura
empresarial. A versão 8 do TOGAF (The Open Group 2002) é designada por ‘EnterpriseEdition’ e é dedicado
a arquiteturas empresariais.
• O TOGAF tem quatro componentes principais:
• Uma estrutura de alto nível, baseada em alguns dos principais conceitos e numa metodologia chamada Architectural Development
Method (ADM). OA estrutura considera uma arquitetura empresarial geral composta por quatro arquiteturas intimamente
relacionadas: Arquitetura Empresarial,Arquitetura de dados/informação, arquitetura de aplicações e arquitetura de tecnologia (TI). O
ADM é considerado o núcleo do TOGAF e consiste numa abordagem cíclica gradual para o desenvolvimento da arquitetura
empresarial global.
A Framework de grupo aberto
• Uma estrutura de alto nível, baseada em alguns dos principais conceitos e numa metodologia chamada Architectural Development
Method (ADM). OA estrutura considera uma arquitetura empresarial geral composta por quatro arquiteturas intimamente
relacionadas: Arquitetura Empresarial,Arquitetura de dados/informação, arquitetura de aplicações e arquitetura de tecnologia (TI). O
ADM é considerado o núcleo do TOGAF e consiste numa abordagem cíclica gradual para o desenvolvimento da arquitetura
empresarial global.
• O Continuum Empresarial TOGAF, que compreende a Arquitetura da Fundação TOGAF (que contém o Modelo de Referência Técnica,A
Base de Informação de Normas (SIB) do Open Group e a Base de Informação de Blocosde Construção (BBIB) e a Infraestrutura de
Informação Integradaestrutura Modelo de Referência. A ideia central por detrás do Enterprise Continuum é ilustrar como as
arquiteturas são desenvolvidas num continuumuum que vão desde arquiteturas fundamentais, passando por arquiteturas de
sistemas comuns e arquiteturas específicas do setor, até à arquitetura individual de uma empresa.
A Framework de grupo aberto
• The TOGAF Resource Base, a set of tools and techniques available for use in applying TOGAF and the TOGAF ADM (architecture views, business scenarios, ADML, case
studies, other architecture frameworks, a mapping of TOGAF to the Zachman framework, etc.).
A Framework de grupo aberto
• Os principais componentes da estrutura TOGAF estão descritos na Fig. 2.6. Para além destes componentes, o
TOGAF identifica uma série de visões,que devem ser modelados num processo de desenvolvimento de
arquitetura. As visões da arquitetura e os pontos de vista correspondentes enquadram-se no
seguintecategorias (a taxonomia de visualizações TOGAF está em conformidade com a norma IEEE 1471):
• Visões da Arquitetura Empresarial, que abordam as preocupações dos utilizadores do sistema e descrevem os fluxos de informação
empresarial entre as pessoasprocessos de negócio e de pessoas (por exemplo, Visão de Pessoas, Visão de Processos, Visão de
Funções, Visão de Informação de Negócio, Visão de Usabilidade, Visão de Desempenho).
• Visões de engenharia, abordando as preocupações dos engenheiros de sistemas e de software responsáveis pelo desenvolvimento e
integração de vários componentesdo sistema (por exemplo, Visão de Segurança, Visão de Engenharia de Software, Visão de Dados,
Visão de Engenharia de Sistemas, Visão de Engenharia de Comunicações).
A Framework de grupo aberto
• Visualizações de gestão empresarial, abordando as preocupações dos administradores, operadores e gestores de sistemas.
• Opiniões dos adquirentes, abordando as preocupações do pessoal de compras responsável pela aquisição de software comercial
pronto a usar (COTS)e hardware a incluir no sistema (por exemplo, The Building Blocks Cost View, The Standards View). Estas
visualizações retratam frequentemente os blocos de construção da arquitetura que podem ser adquiridos e os padrões que os blocos
de construção devem seguir.
Arquitetura orientada a modelos da OMG
• A arquitetura Orientada a Modelo (MDA) (Object Management Group Architecture Board 2001, Frankel
2003) visa proporcionar uma abordagem aberta e neutra em relação aos fornecedores para a
interoperabilidade.
• Ele baseia-se na Gestão de Objetos Padrões de modelação do grupo: a Unified Modeling Language (UML), o
Meta Object Facility (MOF) e o Common Ware House Meta-model (CWM).
• Descrições de aplicações independentes de plataforma construídos com estes padrões podem ser realizados
utilizando diferentes métodos abertos ou plataformas proprietárias de software, como o CORBA, Java, .NET,
XMI/XML e Web services.vícios.
• Atualmente, o paradigma MDA está a mudar fundamentalmente a forma como o software é desenvolvido.
MDA quer elevar o nível de abstração em que as soluções de software são especificadas pela definição de
uma estrutura suportada por uma coleção de padrões que define um padrão para a geração de código de
modelos e vice-versa. Ora, as ferramentas de desenvolvimento de software baseadas em MDA já suportam a
especificação de software em UML no lugar de uma linguagem de programação como o Java.
Arquitetura orientada a modelos da OMG
Arquitetura orientada a modelos da OMG
• Recentemente, a OMG estendeu o foco do MDA para a camada de Modelo Dependente de
Computação (CIM), na qual os aspetos comerciais de uma empresa são cobertos. O MDA
compreende agora três níveis de abstração com mapeamentos entre eles:
1. Os requisitos para o sistema são modelados num Modelo Independente de Computação (CIM), descrevendo a situação em que o
sistema será utilizado. Este modelo é por vezes chamado de modelo de domínio ou modelo de negócio. Oculta muitas ou todas as
informações sobre a utilização de sistemas automatizados de processamento de dados.
2. O Modelo Independente de Plataforma (PIM) descreve o funcionamento de um sistema, ao mesmo tempo que oculta os detalhes
necessários para uma plataforma específica. Um PIM mostra a parte da especificação completa que não muda de uma plataforma
para outra.
3. Um modelo específico de plataforma (PSM) combina as especificações no PIM com os detalhes que especificam como esse
sistema utiliza um tipo específicoda plataforma.
Arquitetura orientada a modelos da OMG
• A UML é recomendada como linguagem de modelação para PIMs e PSMs, no nível CIM. Uma linguagem para
especificação de processos de negócio já foi publicada, estando atualmente a serem desenvolvidas
linguagens para a descrição de regras de negócio e modelos de negócio. Tal como a UML, estas novas
linguagens são desenvolvidas dentro da estrutura MDA. Estes desenvolvimentos tornarão o MDA tão
relevante para a arquitetura empresarial como é agora para desenvolvimento de software.
• Uma das principais características do MDA é a noção de mapeamento. Um mapeamento é um conjunto de
regras e técnicas utilizadas para modificar um modelo de modo a obter um outro modelo. Em certas
situações restritas, pode ser possível uma transformação totalmente automática de um PIM para um PSM, e
as ferramentas desenvolvimento de software suportarão estes mapeamentos automatizados.
• Até que ponto a automatização de mapeamentos entre CIMs e PIMs é viável é ainda um tópico de
investigação. Se estes mapeamentos forem realizados de forma predefinida (formal), as relações entre
modelos de diferentes níveis de abstração podem ser asseguradas.
Arquitetura orientada a modelos da OMG
• O Meta Object Facility (MOF) é um standard para repositórios que desempenha um papel central na
estrutura do MDA. Um repositório compatível com o MOF permite gerir modelos de forma integrada,
mesmo quando os modelos são expressos em diferentes idiomas. Para tornar um repositório eficaz para a
EA, deve ser possível modelar relações entre modelos no repositório. O MOF por si só não oferece uma
solução para tal, mas modelos numa linguagem de modelação como o ArchiMate podem ser adicionados
para modelar estas relações.
• Para além do MOF, a OMG está a desenvolver o QVT (Consultas, Visualizações e Transformações), que
abordará a forma como os mapeamentos são obtidos entre modelos cujas linguagens são definidas
utilizando MOF e definirá uma forma padrão de consultar modelos MOF e criar visualizações desses
modelos.
• Estes desenvolvimentos dão uma perspetiva de um conjunto de linguagens específicas de domínio que
cobrem toda a empresa de forma integrada e consistente. Esperamos que dentro de alguns anos a estrutura
MDA e o MOF sejam tão importantes para a arquitetura empresarial como estes padrões são agora para o
desenvolvimento de software.
Outros Frameworks
• DoDAF/C4ISR: A Estrutura de Arquitetura de Comando, Controlo, Comunicações, Computadores, Inteligência,
Vigilância e Reconhecimento (C4ISR) (Grupo de Trabalho de Arquitetura C4ISR 1997) foi originalmente desenvolvida
em 1996, para o Departamento de Defesa dos EUA, para garantir uma abordagem unificada comum para os
comandos, serviços militares e agências de defesa seguirem na descrição das suas diversas arquiteturas.
• Uma nova versão da estrutura, agora intitulada Department of Defense Architecture Structure (DoDAF), foi lançada
em Agosto de 2003. Embora o DoDAF tenha um alvo bastante específico, pode ser estendido a arquitecturas de
sistemas mais gerais. O DoDAF vê a descrição da arquitetura como uma integração de três visões principais: visão
operacional, visão do sistema e visão técnica. Uma série de conceitos e definições fundamentais (por exemplo,
arquitetura, descrição da arquitetura, funções e inter-relações dos sistemas operativos e vistas de arquitetura
técnica) são fornecidas. Algumas orientações e princípios compatíveis com a estrutura paraa construção de
descrições de arquitetura (incluindo os tipos de produtos específicos necessários para todas as descrições de
arquitetura) e um procedimento de Descrição de Arquitetura em Seis Passos complementam-nos.
Outros Frameworks
• RM-ODP: O Modelo de Referência para o Processamento Distribuído Aberto (RMODP) é uma Norma ISO/ITU
(ITU 1996) que define uma estrutura para especificação de arquitetura de grandes sistemas distribuídos. A
norma visa fornecer suporte para interoperação, interoperabilidade, portabilidade e distribuição e, por
conseguinte, permitir a construção de sistemas abertos, integrados, flexíveis, modulares, geríveis,
heterogéneos, seguros e transparentes. A norma tem quatro partes:
• Parte 1: Referência, contendo uma visão motivacional da norma e dos seus conceitos (ITU 1996).
• Parte 2: Fundamentos, definição dos conceitos, estrutura analítica para a descrição dos sistemas ODP e uma
estrutura geral para a avaliação e conformidade (UIT 1995a).
• Parte 3: Arquitectura, descrevendo a estrutura ODP de pontos de vista para a especificação de sistemas ODP em
diferentes linguagens de ponto de vista (ITU 1995b). Identifica cinco pontos de vista sobre um sistema e o seu
ambiente: empresa, informação, computação, engenharia e tecnologia.
• Parte 4: Semântica arquitetónica, mostrando como os conceitos de modelação da Parte 2 e as linguagens de ponto
de vista da Parte 3 podem ser complementados em diversas técnicas de descrição formal, como LOTOS, Estelle, SDL e
Z (ITU 1997).
Outros Frameworks
• GERAM: A Arquitetura e Metodologia de Referência Empresarial Genérica (GERAM) (Força-Tarefa IFIP-IFAC
1999) define os conceitos genéricos relacionados com a empresa recomendados para utilização em projetos
de engenharia e integração empresarial. Estes conceitos podem ser categorizados como:
• Conceitos orientados para o ser humano para descrever o papel dos humanos como parte integrante da organização e
operação de uma organização e para apoiar os humanos durante o projeto, a construção e a mudança da empresa.
• Conceitos orientados para a tecnologia para a descrição da tecnologia de suporte envolvida tanto na operação empresarial
como nos esforços de engenharia empresarial (modelação e suporte à utilização do modelo).
• O modelo proposto pelo GERAM tem três dimensões: a dimensão do ciclo de vida, a dimensão da
instanciação, permitindo diferentes níveis de particularização controlada, e a dimensão da visão com quatro
visões: visão do conteúdo do modelo da entidade, visão do propósito da entidade, visão da implementação
da entidade e visão da manifestação física da entidade. Cada visão é ainda mais refinada e pode ter vários
componentes.
Outros Frameworks
• Framework de Nolan Norton (Zee, et al. 2000): Esta estrutura é o resultado de um projecto de
investigação do Instituto Nolan Norton (que envolveu 17 grandes empresas holandesas) sobre as
práticas actuais no domínio do desenvolvimento arquitectónico. Com base nas informações recolhidas
junto das empresas, os autores definiram uma visão de cinco perspetivas da arquitetura empresarial:
• Conteúdo e objetivos: que tipo de arquitetura é desenvolvida, quais os seus componentes e as relações entre eles, que
objetivos e rerequisitos tem a arquitetura para satisfazer? Mais precisamente, esta perspetiva é constituída por cinco
arquiteturas interligadas (correspondem aaquilo a que chamamos visões arquitetónicas): arquitetura de produto, arquitetura
de processos, arquitetura de organização, arquitetura de informação funcional e arquitetura de informação técnica.
• Processo de desenvolvimento da arquitetura: quais as diferentes fases do desenvolvimento de uma arquitetura, qual a sua
sequência e o que comcomponentes devem ser desenvolvidos em cada fase?
• Funcionamento do processo de arquitetura: quais os motivos da mudança, que informação é necessária e de quem é são as
responsabilidades pela tomada de decisões?
Outros Frameworks
• Competências arquitetónicas: que nível de especialização deve a organização atingir (e como) para desenvolver, implementar
e utilizar uma arquitetura?
• Custo/Benefícios: quais os custos e benefícios do desenvolvimento de uma nova arquitetura?