A arquitetura corporativa federal (FEA) é a mais recente tentativa do governo federal unir o grande número de agências e funções sob uma única arquitetura corporativa comum e universal. A FEA ainda está em seus primórdios, pois a maior parte dos principais itens está disponível desde 2006, apenas. Todavia, conforme mencionei na seção histórico, possui atrás de si uma longa tradição e, se não for por nenhum outro motivo, tem muitas falhas as quais, quem sabe, serviram para o aprendizado de lições valiosas.

A FEA é a mais completa de todas as metodologias discutidas até agora. Possui uma taxonomia abrangente, como Zachman, e um processo arquitetural, como o TOGAF. A FEA pode ser considerada uma metodologia para criar uma arquitetura corporativa ou o resultado da aplicação desse processo a uma determinada empresa, ou seja, o governo norte-americano. Farei a minha análise da FEA pela perspectiva metodológica. Meu interesse específico, aqui, é como poderemos aplicar a metodologia FEA às empresas privadas.

A maior parte dos escritores descreve a FEA como simplesmente compreendendo cinco modelos de referência, um para cada desempenho: negócio, serviço, componentes, técnico e dados. É verdade que a FEA tem esses cinco modelos de referências, mas existe muito mais na FEA do que apenas os modelos de referência. Um abordagem completa da FEA precisa incluir todos os seguintes itens:

• perspectiva de como as arquiteturas corporativas devem ser observadas (o modelo segmento, que descreverei de modo sucinto);
• conjunto de modelos de referência para a descrição de várias perspectivas da arquitetura corporativa (os cinco modelos acima mencionados);
• processo para criar uma arquitetura corporativa;
• processo transicional para migrar de um paradigma pré-EA para um pós-EA;
• taxonomia para catalogação de ativos que fica no âmbito da arquitetura corporativa;
• abordagem para medir o sucesso de se usar a arquitetura corporativa para trazer valor ao negócio.

Como se vê, a FEA trata de muitas questões e não de modelos, apenas. Inclui tudo o que é necessário na construção de uma arquitetura corporativa para, provavelmente, a mais complexa organização da Terra: o governo norte-americano. No dizer do FEA-Program Management Office (FEAPMO), a FEA, considerada in totum, fornece:

…uma linguagem e um framework comuns para descrever e analisar os investimentos em TI, aprimorar a colaboração e, por fim, transformar o governo federal em uma organização centrada no cidadão, orientada a resultados e baseada no mercado, conforme estabelecido na Agenda de gerenciamento do presidente. [25].

Ainda que seja um desafio imaginar que nada menos do que uma obra de intervenção divina possa “transformar o governo federal em uma organização centrada no cidadão, orientada a resultado e baseada no mercado”, existe pelo menos a esperança de que alguma metodologia FEA possa ajudar nossa problemática empresa MedAMore a lidar com seus problemas muito mais rotineiros. Assim, vejamos o que a FEA tem a oferecer.

A perspectiva da FEA sobre a arquitetura corporativa (EA)

Uma empresa constrói-se de segmentos. Essa é a perspectiva da FEA sobre a EA, idéia primeiramente apresentada pela FEAF [26]. Segmento é uma funcionalidade principal da linha de negócio, como a área de recursos humanos. Existem dois tipos de segmentos: segmentos de área de missão central (core mission) e segmentos de serviços do negócio.

Um segmento de área de missão central é aquele fundamental para a missão ou finalidade de um determinado limite político no âmbito da empresa. Por exemplo, na agência de saúde e serviços sociais (HHS) do governo federal, saúde é um segmento de área de missão central.

Um segmento de serviços do negócio é fundamental para muitas organizações políticas, se não para todas. Por exemplo, a gerência financeira é um segmento de serviços do negócio necessário a todas as agências federais.

Outro tipo de ativo da arquitetura corporativa é um serviço corporativo, função bem definida que transpõe limites políticos. Um exemplo de serviço corporativo é o gerenciamento de segurança, serviço que trabalha de modo unificado através de todas as seções da empresa.

A diferença entre serviços e segmentos corporativos, especialmente segmentos de serviço do negócio é confusa. Ambos são compartilhados por toda a empresa. A diferença está em que os segmentos de serviço do negócio têm um escopo que abrange apenas uma única organização política. O escopo dos serviços corporativos abrange toda a empresa.

No governo federal, por exemplo, as duas agências, HHS e a de proteção ambiental (EPA), utilizam o segmento de serviço do negócio recursos humanos. Entretanto, as pessoas gerenciadas por recursos humanos compõem dois grupos diferentes: HHS e EPA.

Ambas, HHS e EPA, também usam o serviço corporativo gerenciamento de segurança. Todavia, as credenciais de segurança gerenciadas pelo serviço de gerenciamento de segurança não são específicos para nenhuma dessas agências. As credenciais de segurança são gerenciadas efetivamente, apenas quando gerenciadas no âmbito da empresa.

Resista à tentação de equiparar segmentos ou serviços com serviços, como em arquiteturas orientadas a serviço. Existem dois motivos para desqualificar tal comparação. Em primeiro lugar, serviços corporativos, segmentos de serviço do negócio e segmentos de área de missão central são muito mais abrangentes no enfoque do que os serviços encontrados nas arquiteturas orientadas a serviço.

Depois, os segmentos são uma unidade organizacional de uma arquitetura corporativa, enquanto que serviços são uma unidade organizacional das implementações técnicas. Como unidades organizacionais de uma arquitetura corporativa, suas profundidades incluem não apenas a técnica, mas também as arquiteturas do negócio e de dados.

Uma nota final sobre segmentos: embora os segmentos funcionem no nível político (ou seja, agência), são definidos no nível corporativo (ou seja, governo). Os serviços corporativos, evidentemente, funcionam e são definidos no nível corporativo.

O fato de os segmentos serem definidos em nível global facilita a reutilização através de todos os limites políticos. Pode-se mapear o uso dos segmentos através dos limites políticos da empresa e, depois, usar esse mapa para procurar oportunidades de reuso arquitetural. A Figura 8, por exemplo, apresenta um mapa de segmentos do governo federal com base no guia prático da FEA [27]. Como se vê, existem muitos segmentos (colunas verticais) usados em várias agências e qualquer uma delas, ou todas, são boas candidatas ao compartilhamento.

Figura 8. Mapa segmentado do governo federal

Modelos de referência da FEA

Os cinco modelos de referência da FEA tratam, sobretudo, do estabelecimento das linguagens comuns. Aqui, a meta é facilitar a comunicação, cooperação e colaboração através dos limites políticos. De acordo com o FEAPMO:

A FEA compreende um conjunto de “modelos de referência” inter-relacionados projetado para facilitar a análise inter-agências e a identificação de investimentos duplicados, lacunas e oportunidades para colaboração dentro e através das agências. Em termos coletivos, os modelos de referência [compõem] um framework para a descrição de elementos importantes da FEA, de modo comum e consistente. [28]

Por que precisamos de uma linguagem comum? Analise este diálogo:

James: Você tem um “torch” (em inglês: lanterna, farolete ou maçarico) para me emprestar?

Roger: Não, acho que não.

James: Saberia me dizer onde posso comprar um?

Roger: A loja de ferragens na cidade pode ter.Com essa informação, James vai até a loja de ferragens e compra um torch (lanterna). Quando ele volta…

Roger: Conseguiu o seu torch?

James: Sim, aqui está.

Roger: Mas, isso não é um maçarico! É uma lanterna. Por que não me disse? Tenho uma que poderia ter lhe emprestado.

James: Bem, por que você não me disso isso?

O problema, lógico, é que o James é inglês, e o que eu chamo de lanterna os ingleses dizem farolete. E, pior, quando ouço torch (lanterna, farolete ou maçarico), logo penso em blowtorch (maçarico). Embora ambos falemos inglês, não falamos necessariamente o mesmo inglês. O resultado é que James saiu e, desnecessariamente, gastou dinheiro em algo que eu poderia ter lhe emprestado.

Esse é exatamente o problema que os modelos de referência da FEA tentam resolver em escala muito maior. Suponha que a receita federal (IRS) resolva que precisa de um sistema demográfico para rastrear dados de contribuintes. Perguntam aos fabricantes do setor se alguém tem um que possa ser modificado para essa finalidade. Ninguém tem.

Mal sabem eles que, na porta ao lado, a imprensa oficial do governo (GPO – Government Printing Office) tem um sistema demográfico perfeito, quase exatamente aquilo que a receita federal precisa. É que o pessoal da imprensa oficial chama o sistema de análise de clientes.

Desconhecendo o fato, a receita federal sai em campo e constrói seu sistema do zero, em lugar de apenas modificar aquele já construído (e pago) pelo GPO. E, assim fazendo, a receita federal vai gastar consideravelmente muito mais do que James gastou comprando uma lanterna desnecessária.

Isso, em poucas palavras, é a meta dos cinco modelos de referência da FEA: oferecer termos e definições padronizados para os domínios da arquitetura corporativa e, assim, facilitar a colaboração e o compartilhamento através do governo federal. Os cinco modelos de referência são os seguintes:

1. O modelo de referência do negócio (BRM – business reference model) oferece uma visão do negócio das várias funções do governo federal. Por exemplo, o BRM define uma capacidade-padrão do negócio denominada gerenciamento de recursos hídricos, subfunção de recursos naturais, considerada uma linha de negócio da área de negócio mais ampla, serviços para a comunidade; [29]
2. O modelo de referência de componentes (CRM – components reference model) oferece uma visão mais de TI dos sistemas que dão suporte à funcionalidade do negócio. Por exemplo, o CRM define um sistema de análise do cliente que descrevi anteriormente na inter-relação hipotética entre a receita federal e a agência de proteção ambiental; [30]
3. O modelo de referência técnica (TRM – Technical Reference Model) define várias tecnologias e normas que podem ser usadas na construção dos sistemas de TI. Por exemplo, o TRM define HTTP como um protocolo, subconjunto de um transporte de serviços, subconjunto de um acesso e entrega de serviços; [31]
4. O modelo de referência de dados (DRM – Data Reference Model) define formas padronizadas para descrever dados. Por exemplo, o DRM define uma entidade como algo que contém atributos e participa nos relacionamentos; [32]
5. O modelo de referência de desempenho (PRM – performance reference model) define formas padronizadas para descrever o valor gerado pelas arquiteturas corporativas. Por exemplo, o PRM descreve qualidade como uma área de medição tecnológica, definida como “a extensão de acordo com a qual a tecnologia satisfaz as exigências de funcionalidade ou capacidade”. [33]

Processo da FEA

O processo da FEA concentra-se, principalmente, na criação de uma arquitetura de segmentos para todo o subconjunto da empresa (no caso da FEA, a empresa é o governo federal e o subconjunto, uma agência governamental) e está descrita no Guia de prática da FEA [34]. Anteriormente neste artigo, já discuti a visão da FEA sobre os segmentos corporativos. O processo global de desenvolvimento da arquitetura de segmentos é (em um nível bem elevado) o seguinte:

• Etapa 1:

  Análise arquitetural: define uma visão simples e concisa do segmento, fazendo uma relação retrospectiva com o plano organizacional;

• Etapa 2:

  Definição arquitetural: define o estado arquitetural desejado do segmento, documenta as metas de desempenho, considera as alternativas de projeto e desenvolve uma arquitetura corporativa para o segmento, incluindo as arquiteturas de negócio, dados, serviços e tecnologia

• Etapa 3:

  Estratégias de investimento e custeio: considera como o projeto será custeado;

• Etapa 4:

  Plano do programa de gerenciamento e projetos executivos: criação de um plano para gerenciar e executar o projeto, incluindo eventos e medidas de desempenho que avaliarão o sucesso do projeto.

Medição do sucesso da FEA

O framework FEA para medir o sucesso organizacional do uso da arquitetura corporativa está definido no framework de avaliação da (EA) do programa de arquitetura corporativa federal 2.1 [35]. As agências federais são classificadas de acordo com os respectivos níveis globais de maturidade em três categorias principais:

1. Perfeição arquitetural: nível de maturidade da própria arquitetura;
2. Uso arquitetural: quão efetivamente a agência usa sua arquitetura para dar suporte à tomada de decisões;
3. Resultados arquiteturais: benefícios realizados pelo uso da arquitetura. O OMB atribui a cada agência uma classificação de sucesso, com base nas notas de cada categoria e uma nota cumulativa, como segue:

   Verde

   A agência se classifica muito bem no quesito perfeição (possui uma arquitetura corporativa bastante madura). Além disso, está bem classificada nos quesitos uso (a arquitetura corporativa está sendo usada com eficiência para encaminhar a estratégia existente) e resultados (o uso da arquitetura está trazendo valor ao negócio);

   Amarelo

   A agência se qualifica muito bem no quesito perfeição. Está, ainda, bem posicionada nos quesitos uso ou resultados;

   Vermelho

   A agência não tem uma arquitetura perfeita e/ou não a usa com eficiência.

O framework desperta o interesse além dos limites do setor público. As classificações das categorias podem ser proveitosamente adaptadas por muitas empresas para avaliar o nível de maturidade das próprias iniciativas arquiteturais. A Figura 9, por exemplo, apresenta a minha interpretação das categorizações de maturidade do OMB relativas à perfeição arquitetural, conforme minha adaptação para o setor privado. Adaptações similares podem ser criadas para uso e resultados arquiteturais.

Figura 9. Classificação da perfeição arquitetural do OMB, adaptada para o setor privado pelo autor (Roger Sessions)

FEA aplicada à MedAMore

Agora, depois de ter apresentado a abordagem FEA, vejamos o que isso pode significar para a MedAMore. Vamos pressupor que Cath (a CEO da MedAMore) ouviu referências à FEA e como essa metodologia é promissora para simplificar a organização do governo federal. Se pode fazer tudo isso pelo governo federal, pensa ela, por certo também poderá ajudar a sua empresa.

Cath admite um consultor, Fred, especialista em FEA (se é que se pode dizer isso de uma metodologia que, no momento em que este artigo é escrito, tem menos de um ano de vida!). O trabalho do Fred é mostrar à MedAMore como executar a FEA–lógico, não a verdadeira FEA, mas a FEA que poderia ser aplicada ao setor privado. Cath apresenta Fred ao Bret (o Vice-presidente comercial) e à Irma (a CIO) e solicita-lhes que construam para a empresa um sistema MEA-FEA adaptado para a MedAMore.

Lembre-se que a Cath assumiu um grande risco. Nenhuma outra empresa, até hoje, tentou aplicar a FEA ao setor privado; e mesmo a experiência de usar a FEA no setor público é simbólica, na melhor das hipóteses.

A primeira coisa que o Fred desejará fazer é despertar o entusiasmo para o sistema MEA. Lembre-se: ele está entrando numa organização em que o pessoal do comercial quase não fala com o pessoal da informática. Para que o sistema MEA faça sucesso, ele não só precisa transformar os processos, mas as pessoas. O Fred desejará criar uma série de seminários explicando o valor do sistema MEA a ser definido e como ele trará benefícios não apenas para a MedAMore como um todo mas, especificamente, a cada um dos setores da empresa.

A seguir, Fred construirá uma estrutura de governança, o equivalente à FEAPMO da MedAMore. MEAPMO será minha denominação a este grupo. A MEAPMO será proprietária do MEA, incluindo processos, modelos e a própria arquitetura.

O próximo passo do Fred, provavelmente, será criar modelos de referência que possam ser usados por todas as organizações de toda a MedAMore. Os cinco modelos de referência da FEA podem ser usados como um ponto de partida. Alguns, como o modelo de referência técnica, poderá ser usado com poucas modificações. Já outros, como o modelo de referência do negócio, exigirão grandes adaptações. Fred não deverá se ater demasiadamente aos detalhes mas, sim, criar pontos de partida e construí-los na medida em que o sistema MEA evolui.

A seguir, provavelmente Fred desejará criar uma descrição da arquitetura de segmentos aplicável à MedAMore. Observe que ele não fará uma arquitetura de segmentos completa, mas apenas uma descrição de alto nível. O processo real para concluir a arquitetura será um projeto em constante evolução.

Neste ponto, muito trabalho terá sido executado, com poucos resultados. Fred desejará dar um primeiro passo no processo da arquitetura de segmentos. O processo da FEA será um bom ponto de partida, mas exigirá especialização da MedAMore em nível de detalhe (por exemplo, quem são os componentes da equipe e que forma deverão tomar os artefatos gerados).

Agora, Fred testará o processo com a finalização do primeiro segmento. Ele precisará formar uma equipe e, depois, liderá-la na análise e priorização dos segmentos, mapeando-os de acordo com o seu valor para o negócio, determinando as respectivas opções arquiteturais, entregando o trabalho e, quem sabe, o mais importante, medindo os resultados. Essas medições serão críticas na construção do momento para o trabalho futuro.

Logo após finalizar o primeiro segmento, Fred pode decidir que já é hora de medir o andamento dos vários grupos da MedAmore que utilizam o sistema MEA efetivamente. Para tanto, Fred precisa de um parâmetro para medir o sucesso dos vários grupos da MedAMore que trazem valor ao negócio com o sistema MEA. Assim, Fred lidera a MEAPMO na construção de um sistema na MedAMore equivalente ao framework de avaliação da (EA) do programa de arquitetura corporativa federal [35]. Esse parâmetro pode ser a principal ferramenta da Cath para garantir que os dois grupos diferentes consideram o sistema MEA seriamente e que seu investimento está sendo compensado.

E, por fim, depois de ter concluído este processo, Fred recomeçará. Cada iteração resultará na entrega de novos segmentos, geração de mais valor para o negócio e no acréscimo de mais substância à metodologia do MEA. Bem, no mínimo, esta é a teoria. Como mencionei anteriormente, com o sistema MEA, estamos trabalhando na vanguarda absoluta.

O framework arquitetural do Open Group é mais conhecido pelo seu acrônimo: TOGAF. O TOGAF é de propriedade do Open Group [19]. A Figura 5 apresenta a visão do TOGAF de uma arquitetura corporativa.

Figura 5. Arquitetura corporativa do TOGAF

Como apresentado na figura, o TOGAF divide uma arquitetura corporativa em quatro categorias, como segue:

1. Arquitetura de negócioDescreve os processos que o negócio usa para cumprir suas metas;
2. Arquitetura de aplicativoDescreve como aplicativos específicos são programados e como interagem;
3. Arquitetura de dadosDescreve como os armazenamentos de dados são organizados e acessados;
4. Arquitetura técnicaDescreve as infra-estruturas de hardware e software que suportam os aplicativos e suas interações.

O TOGAF descreve a si próprio como um “framework”, mas a parte mais importante do TOGAF é o método de desenvolvimento da arquitetura, mais conhecido como ADM. O ADM é uma receita para a criação da arquitetura. Receitas podem ser categorizadas como processos. Considerando que o ADM é a parte mais visível do TOGAF, coloquei o TOGAF na categoria geral de processo arquitetural, em lugar de framework arquitetural (como o Open Group descreve o TOGAF) ou de metodologia (como o ADM é descrito).

Considerado como processo arquitetural, o TOGAF complementa a rede Zachman a qual, recordo, categorizei como taxonomia arquitetural. A rede Zachman diz como categorizar seus artefatos. O TOGAF oferece um processo para criá-los.

O TOGAF observa o mundo da arquitetura corporativa como um continuum de arquiteturas, variando de extremamente genérico para altamente específico. Continuum corporativo é a denominação dada a esse continuum. Observa o processo de criação de uma arquitetura corporativa específica, como o sistema MAM-EA, passando do genérico para o específico. O ADM do TOGAF oferece um processo para encaminhar este movimento do genérico para o específico.

O TOGAF denomina as arquiteturas mais genéricas de arquiteturas de fundamento. Estes são princípios arquiteturais que, teoricamente, podem ser usados por qualquer organização de TI do universo.

O TOGAF denomina o próximo nível de especificidade de arquiteturas de sistemas comuns. Estes são princípios que ninguém esperaria ver em muitos, mas, talvez, não todos os tipos de empresas.

O TOGAF denomina o próximo nível de especificidade de arquiteturas setoriais. Estes são princípios específicos de muitas empresas, parte do mesmo domínio como, no nosso estudo de caso MedAMore, o de todas as empresas farmacêuticas.

O TOGAF denomina o nível mais específico de arquiteturas organizacionais. Essas são as arquiteturas específicas de uma determinada empresa, como a MedAMore.

A Figura 6 apresenta a relação entre o continuum corporativo e o método de desenvolvimento da arquitetura (ADM).

Figura 6. O continuum corporativo do TOGAF

O TOGAF define as várias bases de conhecimento que residem na arquitetura de fundamento. Duas que poderão cruzar o seu caminho são o modelo de referência técnica (TRM) e a base de informações-padrão (SIB). O TRM é uma descrição sugerida de uma arquitetura de TI genérica. A SIB é uma coleção de padrões e pseudopadrões que o Open Group recomenda considerar na construção de uma arquitetura de TI.

O TOGAF apresenta o TRM e a SIB como sugestões; nenhum deles é necessário. No meu entender, o TRM e a SIB têm falhas pela mesma razão: são tendenciosos em favor da portabilidade, em detrimento da interoperabilidade e da autonomia do aplicativo. Considero esta uma visão desatualizada das arquiteturas técnicas.

Para uma organização como a MedAMore, o TOGAF em grande parte reduz-se ao método de desenvolvimento da arquitetura (ADM). Os indivíduos da MedAMore ficarão expostos ao continuum corporativo, à SIB e ao TRM (assim como a alguns outros recursos do TOGAF) e por isso eu os trouxe para esta discussão. Todavia, a experiência diária de criar uma arquitetura corporativa será dirigida pelo ADM; a Figura 7 mostra uma visão de alto nível dessa criação.

Figura 7. O método de desenvolvimento da arquitetura (ADM) do TOGAF

Como ilustrado pela Figura 7, o ADM do TOGAF compreende oito fases cíclicas após um período de “partida no motor”. Eu os acompanharei através dessas fases, na medida em que poderiam ser aplicadas ao estudo de caso da MedAMore. Mas, antes de a MedAmore poder iniciar o ADM, ela precisa ter alguma experiência com o TOGAF. A MedAMore terá duas opções para obter essa experiência.

Primeiramente, a MedAMore pode aprender sozinha a trabalhar com o TOGAF. A MedAMore pode fazer o download da documentação [20], que descreve tudo sobre o TOGAF, inclusive o ADM, detalhadamente. Pode comprar livros sobre o TOGAF [21]. Provavelmente há mais informações gratuitas e acessíveis sobre o TOGAF do que sobre todas as outras metodologias arquiteturais juntas.

Segundo, a MedAMore pode contratar consultoria em TOGAF. Existem consultores especializados em TOGAF, certificados pelo Open Group [22]. Como a MedAMore deseja minimizar quaisquer oportunidades de falha, escolheu chamar um consultor em TOGAF. A MedAMore contratou Teri, uma arquiteta certificada pelo Open Group em TOGAF. Lembre-se: os outros participantes da MedAMore são Cath, a CEO da MedAMore; Bret, o Vice-presidente comercial e Irma, a CIO.

Nesta fase preliminar, Teri participa de reuniões com os principais participantes da MedAMore para apresentar o processo do TOGAF. Suas três metas nesta fase preliminar são:

1. Garantir que todos estejam satisfeitos com o processo;
2. Modificar o processo do TOGAF, conforme necessário, para adaptá-lo à cultura da MedAMore;
3. Definir o sistema de governança que supervisionará o futuro trabalho arquitetural na MedAMore.

Teri trabalhará em estreita colaboração com Bret para compreender a filosofia do negócio, seus modelos e os motivadores estratégicos da MedAMore. Ela também trabalhará em estreita colaboração com Irma para definir os princípios arquiteturais que orientam as arquiteturas tecnológicas da MedAMore e documentará esses princípios utilizando o formato recomendado pelo TOGAF.

Em algumas organizações, obter a adesão sobre a necessidade de uma arquitetura corporativa pode ser muito difícil. Esse fato é especialmente verdadeiro quando a iniciativa parte da organização de TI e ainda mais quando existe um histórico de discórdia entre as áreas comercial e técnica da organização. A MedAMore possui um histórico de animosidade. Entretanto, existe outro agravante para o qual Teri precisa considerar seriamente: a iniciativa não partiu da área de TI, mas da CEO Cath. Este fato dá grande visibilidade ao projeto e cria um incentivo positivo para a cooperação de todas as áreas.

Assim que Teri e a MedAMore concluírem a fase preliminar, estarão prontas para iniciar a Fase A que, pelo menos em teoria, começa com um Pedido de trabalho de arquitetura emitido por um dos departamentos da MedAMore. Este documento inclui os motivos do negócio para o pedido, informações sobre orçamento e pessoal e quaisquer limites a serem considerados. Como a MedAMore nunca emitiu um Pedido de trabalho de arquitetura, provavelmente a Teri precisará trabalhar com o departamento responsável para criar esse pedido.

Assim que o Pedido de trabalho de arquitetura (ou documento equivalente) for recebido, Teri (consultora TOGAF) dará início à Fase A do projeto MedAMore. Nessa fase, Teri tomará providências para que o projeto tenha o suporte necessário da MedAMore, definirá o escopo do projeto, identificará restrições, documentará as exigências do negócio e estabelecerá definições de alto nível para as arquiteturas básica (início) e final (desejada).

Estas definições, básica e final, incluirão definições de alto nível nas quatro subarquiteturas de EA apresentadas na Figura 5, ou seja, arquiteturas de negócio, tecnologia, dados e aplicativo.

O auge da Fase A ocorrerá com uma Exposição do trabalho de arquitetura, que deverá ser aprovada pelos vários participantes, antes do início da próxima fase do ADM. O resultado dessa fase é a criação de uma visão arquitetural da primeira passagem pelo ciclo ADM. A Teri orientará a MedAMore a escolher o projeto, validá-lo de acordo com os princípios de arquitetura estabelecidos na fase preliminar e garantir que os participantes adequados e seus problemas tenham sido identificados e considerados.

A visão arquitetural criada na Fase A será a principal informação da Fase B. A Teri tem como meta da Fase B criar arquiteturas detalhadas do negócio, básica e final, e executar uma análise completa das lacunas existentes entre elas. Para tanto, ela trabalhará, basicamente, com o Bret (ou com a equipe dele).

A Fase B é bastante complexa: envolve modelagem e análise altamente detalhada do negócio, além de documentação das exigências técnicas. Uma Fase B bem-sucedida exige informações de muitos participantes. Os resultados mais importantes serão uma descrição detalhada dos objetivos do negócio, básico e final, assim como as descrições das lacunas existentes na arquitetura do negócio.

A Fase C faz para a arquitetura dos sistemas de informação o que a Fase B faz para a arquitetura do negócio. Nesta fase, Teri trabalha principalmente com Irma (ou com a equipe dela). O TOGAF define nove etapas específicas, cada uma delas com várias subetapas:

1. Criar a descrição da arquitetura básica de dados;
2. Analisar e validar princípios, modelos de referência, pontos de vista e ferramentas;
3. Produzir modelos de arquitetura, inclusive modelos de dados lógicos, de processos de gerenciamento de dados e de relacionamento que mapeiam as funções do negócio para operações de dados CRUD (Criar, Ler, Atualizar, Excluir);
4. Selecionar blocos de construção da arquitetura de dados;
5. Realizar revisões formais do ponto de controle do modelo de arquitetura e dos blocos de construção com os participantes;
6. Revisar os critérios qualitativos (por exemplo, desempenho, confiabilidade, segurança, integridade);
7. Completar a arquitetura de dados;
8. Realizar análise de ponto de controle/impacto;
9. Executar análise de lacunas.

O resultado mais importante desta fase serão as informações finais e a arquitetura de aplicativos.

A Fase D completa a arquitetura técnica: a infra-estrutura necessária para dar suporte à nova arquitetura proposta. A conclusão desta fase é realizada principalmente com a participação da equipe técnica da Irma.

A Fase E avalia as várias possibilidades de implementação, identifica os principais projetos de implementação que poderiam ser assumidos e avalia a oportunidade para o negócio associada a cada uma delas. O padrão TOGAF recomenda que o primeiro passo da Teri na Fase E seja “dar enfoque aos projetos que produzirão benefícios a curto prazo e, assim, criar uma força propulsora para dar andamento a projetos de prazo mais longo”.

Essa é uma boa recomendação para qualquer metodologia arquitetural. Assim sendo, Teri deverá procurar projetos que possam ser realizados da forma mais econômica possível e que, ao mesmo tempo, produzam o mais alto valor observado. Um bom lugar para se começar a procurar tais projetos são os problemas organizacionais que inicialmente convenceram Cath (a CEO da MedAMore) a adotar uma estratégia baseada na arquitetura corporativa. Esses problemas, anteriormente descritos, incluíam dificuldades para satisfazer as especializações regional e de depósito e a falta de confiabilidade para compartilhar dados.

A Fase F relaciona-se muito com a Fase E. Nesta fase, Teri trabalha com a equipe de governança da MedAMore para priorizar os projetos identificados na Fase E que incluem não apenas o custo e os benefícios (identificados na Fase E), mas também os fatores de risco.

Na Fase G, com base na lista de projetos ordenada por prioridade, Teri cria especificações arquiteturais para os projetos de implementação. Essas especificações incluirão os critérios de aceite e a listagem de riscos e problemas.

A fase final é a H. Nessa fase, Teri modifica o processo arquitetural de gerenciamento da mudança com quaisquer artefatos novos criados nesta última iteração e com novas informações que forem disponibilizadas.

Assim, Teri está pronta para reiniciar o ciclo. Uma das metas do primeiro ciclo deveria ser a transferência de informações para que os serviços da Teri fossem cada vez menos necessários à medida que mais e mais iterações do ciclo sejam concluídas.

Grande parte dos resultados do processo TOGAF será determinada igualmente pela relação Teri/MedAMore quanto pela própria especificação do TOGAF. O TOGAF tem como propósito ser extremamente adaptável e os detalhes para os vários artefatos arquiteturais são poucos. Um livro sobre o TOGAF afirma:

O TOGAF não é totalmente específico com relação aos documentos gerados; na verdade, oferece muito pouco na forma de modelos de documentos prescritivos: são meras orientações das entradas e saídas possíveis. [23]

A especificação do TOGAF é também flexível com relação às fases. Conforme expresso na própria especificação:

Uma das tarefas anteriores à aplicação do ADM é a revisão de seus componentes quando à aplicabilidade e, então, adaptá-los conforme adequado às circunstâncias da empresa específica. Esta atividade pode muito bem produzir um ADM “específico da empresa”. [24]

O TOGAF permite que as fases sejam realizadas de modo incompleto, ignoradas, combinadas, reordenadas ou remoduladas para se adaptarem às necessidades da situação. Assim, nada haveria de surpreendente se dois consultores, ambos com certificado TOGAF, acabassem utilizando dois processos muito diferentes, ainda que estivessem trabalhando com a mesma organização.

O TOGAF é ainda mais flexível sobre a arquitetura real gerada. De modo surpreendente, o TOGAF na verdade não é partidário de nenhuma arquitetura. A arquitetura final pode ser boa, ruim ou inócua. O TOGAF apenas descreve como gerar uma arquitetura corporativa, não necessariamente como gerar uma boa arquitetura corporativa. Por isso, depende-se da experiência da equipe e/ou do consultor TOGAF. As pessoas que adotam o TOGAF na esperança de conseguir uma solução mágica ficarão muito desapontadas (assim como com qualquer das metodologias).

Service Component Architecture: Build systems using SOA Service Component Architecture: Construir sistemas utilizando SOA

Service Component Architecture (SCA) is a set of specifications which describe a model for building applications and systems using a Service-Oriented Architecture. Service Component Architecture (SCA) é um conjunto de especificações que descrevem um modelo para a criação de aplicativos e sistemas usando uma Arquitetura Orientada a Serviços. SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services. SCA amplia e complementa as abordagens anteriores à execução dos serviços, e SCA desenvolve em padrões abertos, tais como serviços web.

SCA encourages an SOA organization of business application code based on components that implement business logic, which offer their capabilities through service-oriented interfaces and which consume functions offered by other components through service-oriented interfaces, called service references. SCA incentiva uma organização de SOA do código do aplicativo de negócios baseado em componentes que implementam a lógica de negócios, que oferecem as suas capacidades através de interfaces orientadas a serviço e que consomem funções oferecidas por outros componentes através de interfaces orientadas a serviços, referências de serviço chamado. SCA divides up the steps in building a service-oriented application into two major parts: SCA divide os passos na construção de uma aplicação orientada a serviços em duas partes principais:

• The implementation of servicecomponents which provide services and consume other services. A implementação de servicecomponents que prestam serviços e consumir outros serviços.
• The assembly of sets of components to build business applications, through the wiring of service references to services. A montagem de conjuntos de componentes para criar aplicativos de negócios, através da fiação de referências de serviço para os serviços.

SCA emphasizes the decoupling of service implementation and of service assembly from the details of infrastructure capabilities and from the details of the access methods used to invoke services. SCA enfatiza a dissociação da execução do serviço e do conjunto de serviços a partir de detalhes de recursos de infra-estrutura e dos detalhes dos métodos de acesso utilizado para invocar serviços. SCA components operate at a business level and use a minimum of middleware APIs. componentes SCA operar a nível empresarial e usar um mínimo de APIs de middleware.
Figura 1. Service Component Architecture

SCA suporta implementações de serviço escrito usando qualquer uma das muitas linguagens de programação, ambos incluindo convencional linguagens orientadas a objeto e processuais, tais como Java ™, PHP, C + +, COBOL, linguagens XML centrado em como o BPEL e XSLT, e também de linguagens declarativas, como o SQL e XQuery. SCA também suporta uma variedade de estilos de programação, incluindo estilos assíncrono e orientado a mensagem, para além da chamada síncrona de estilo e volta.

SCA suporta ligações para uma ampla gama de mecanismos de acesso utilizado para invocar serviços. Estes incluem serviços Web, sistemas de mensagens e CORBA IIOP. Vinculações são tratadas de forma declarativa e são independentes do código de implementação. recursos de infra-estrutura, tais como segurança, transações e à utilização de Reliable Messaging também são tratadas de forma declarativa e são separadas do código de implementação. SCA define o uso de recursos de infra-estrutura através da utilização de políticas que visam simplificar o mecanismo pelo qual os recursos são aplicados em sistemas de negócios.

SCA promove igualmente a utilização de serviço de dados de objetos para representar os dados de negócio que formas os parâmetros e retornar valores de serviços, proporcionando um acesso uniforme aos dados de negócios para complementar o acesso uniforme aos serviços de negócios oferecidos pela SCA, em si.

A especificação SCA é dividido em uma série de documentos, cada um tratando de um aspecto diferente da SCA. The Assembly Model deals with the linking of components through wiring. A Assembléia modelo trata da vinculação de componentes através de fiação. The Assembly Model is independent of implementation language. O Modelo de Assembléia é independente da linguagem de implementação. O cliente e trata especificação de implementação com a implementação de serviços e de clientes de serviço – cada um tem a sua linguagem de implementação próprio cliente e especificação de implementação, que descreve o modelo SCA para esse idioma.

As atuais especificações SCA são publicados em um nível de versão 0,95, indicando que as especificações não estão em sua forma final. As especificações são publicados com a intenção de obter feedback da comunidade, a fim de assegurar que o eventual nível de versão 1.0 das especificações mais satisfaz plenamente as necessidades dos desenvolvedores e empresas.

Open Source runtimes SCA e ferramentas

• Há um projeto de código aberto que fornece uma implementação de tempo de execução Service Component Architecture, que você pode usar para executar aplicativos SCA. Este projeto é chamado de Toscana, atualmente sob incubação a Apache. See the Tuscany Web site at Apache . Consulte o site da Toscana no Apache .

• Há também um projeto de código aberto Eclipse que visa fornecer as ferramentas para permitir aos desenvolvedores construir soluções usando uma arquitetura orientada a serviços, que usa o Service Component Architecture como seu modelo principal. Este é o Eclipse Tools projeto SOA Platform. See the SOA Tools Platform (STP) Project Web site . Veja o SOA Tools Platform (STP) Project Web site .

Sobre a colaboração Open SOA

• As especificações de SCA e SDO estão actualmente a ser desenvolvido por uma colaboração de empresas de todo o setor, antes da eventual apresentação de um organismo de normalização formal. Para saber mais sobre o SOA Open Collaboration, visite a página inicial do site OSOA .

• Se você quiser um maior envolvimento com a evolução das especificações, você pode se juntar ao grupo de apoiantes OSOA. Saiba mais sobre os Defensores OSOA .

O Sonar captura várias métricas para seu código base e as mostra em gráficos e em outras visualizações. Os criadores do Sonar o executaram em vários projetos de software livre (acessíveis via instância em execução do Sonar em http://nemo.sonarsource.org/), incluindo o Struts. A figura 3 mostra os resultados do Sonar para o Struts:

Figura 3. Sonar mostrando detalhes sobre o Struts

O Sonar mostra a saída de ferramentas de qualidade comum no espaço Java, incluindo o CheckStyle (consulte Recursos ), cobertura de códigos e uma ferramenta de sua própria métrica, Calculadora de Dívida Técnica (mostrada no lado direito). Essa fórmula usa um grupo de números derivados de métricas executadas no código do projeto.

O Sonar parece produzir números incrivelmente elevados prontos para serem aplicados. Por exemplo, ele sugere que seriam necessários 572 homens/hora e $ 280.000 para que o Struts liquidasse a dívida, a qual, na minha opinião, está altamente inflacionada. Você certamente deverá ajustar esses números para seu projeto antes de levá-los ao seu gerente. Se você produzir um relatório informando que serão necessários $ 1,2 milhão para obter seu código sem que ele cause problemas, seu gerente saltará pela janela. Ajuste os números para suportar seu caso no qual é necessário incluir alguns recursos de tempo integral na liquidação do débito.

O Sonar também possui outras visualizações interessantes. Considere o gráfico “Máquina do Tempo” mostrada na Figura 4:

Figura 4. Gráfico Máquina do Tempo do Sonar para Struts

Este gráfico mostra três métricas no decorrer do tempo: cobertura de código, complexidade ciclomática e complexidade ciclomática por método. Como você pode ver no gráfico, algo terrível aconteceu ao Struts próximo a 1 de setembro de 2009. Ele aparentemente incluiu outra estrutura que tinha métricas terríveis, que agora são refletidas no código base do Struts. Compare isso com as mesmas visualizações, mas para o Spring Batch, mostrado na figura 5:
Figura 5. Gráfico de Máquina do Tempo para Spring Ba O gráfico na Figura 5 mostra mais do que você gostaria de ver: cobertura relativamente constante, complexidade constante por método e complexidade geral de crescimento lento quando o software suporta recursos adicionais.

Um dos motivos da metáfora de dívida técnica funcionar tão bem está na similaridade do dinheiro para a dívida monetária com o tempo nos projetos de software. Quando você tem uma dívida e recebe mais dinheiro, parte desse dinheiro deve ser para pagamento de juros da dívida. Nos projetos de software, você lida com o tempo em vez do dinheiro. Quando você tem um novo intervalo de tempo para incluir novos recursos, tem que pagar parte desse tempo com tempo extra que é gasto no engajamento de todos os compromissos de design (e outros). Vale a pena desenvolver o caso para empregar esforço em tempo integral na redução da dívida, porque isso permite que todos trabalhem rápido uma vez que ela tenha sido liquidada. A liquidação da dívida técnica permite que a velocidade de toda equipe aumente.

Conclusão

Neste artigo, comecei abordando os fatores não técnicos que possuem um impacto no design emergente. Discuti como fazer uma estimativa do desconhecido e como ilustrar a dívida técnica. No próximo artigo continuarei neste mesmo caminho de preocupações externas em torno do design emergente, inclusive refatorando e isolando mudanças.

Related Content Vendedor
Dispositivo de Segurança Showdown Intel Expressway IBM DataPower vs
JBoss versus IBM WebSphere: custo, desempenho, eficiência, inovação WINS (IBM)
eBook – Smart SOA Application Foundation
Guia do Comprador Gunnar Peterson Gateway Security
Tomando o controle do Cloud: segurança da informação, visibilidade e Governança

Relacionados patrocinador
Guia do Comprador * Gateway Security * Tutoriais Gunnar Peterson Tech Dynamicperimeter.com Visita * Recursos de Segurança da Intel para Arquitetos
Aqueles familiarizados com ITIL V2 apenas frequentemente zombam o pensamento de que a ITIL pode servir como uma estrutura de governança de SOA. Com base na sua perspectiva, seria correto desde V2 estão mais focadas em processos operacionais, em vez de ciclo de vida do serviço. Com o ITIL V3, o foco do quadro deslocado em direção ao que só pode ser descrita com precisão como orientação a serviços. Os cinco livros centrais do ITIL V3 são apropriadamente chamado: Service Strategy, Service Design, Service Transition, Service Operation e Melhoria de Serviço Continuada; compreensão ITIL ilustrando o ciclo de vida de service-oriented.

O papel da governança em SOA
Como não há recursos, única e definitiva sobre SOA, a SOA termo foi confiscado para representar os interesses e agendas de muitos, esse é o problema das normas de jure. Dito isto, não há literatura suficiente sobre o tema que, quando analisados estatisticamente ilustra duas particulares inclinações fortes para SOA: negócio / alinhamento de TI e desenvolvimento de sistemas de software. Em ambos os casos, as mesmas metas de baixo acoplamento, consolidação e compartilhamento são evidentes. Tendo em conta estes são atributos adequados a procura, e eles não parecem melhorar a prestação de serviços e agilidade geral, quando aplicada, em seguida, fornece governança de processos, políticas, funções e ferramentas necessárias para garantir que todos os esforços na realização destes atributos.
A governança não irá magicamente proporcionar o sucesso, é apenas um quadro que fornece respostas para as perguntas que mais facilmente estrangulamento ou descarrilar os esforços de SOA. Governança “prestação de contas e orientar o esforço de tomada de decisão em torno de construção e prestação de serviços. Por exemplo, o processo de governança pode ser autorizado a decidir se a empresa vai investir em um determinado tipo de serviço e se esse serviço atende a uma necessidade legítima ou oportunidade. Além disso, o processo de governança pode incluir indivíduos de diferentes aspectos do negócio, de modo a proporcionar uma abertura ampla sobre os aspectos positivos e negativos do desenvolvimento de um determinado tipo de serviço.
Curiosamente, quando se trata de oferta de serviços, muitas empresas estão muito sofisticado quando esse serviço é necessário o envolvimento inter-departamental. Por exemplo, as seguradoras investem pesadamente em examinar se eles vão oferecer um serviço seguro de novo. Suas decisões começar com os exames de mercado, análises de clientes antes e cenários retorno e potencial de lucro. Esta pesquisa é alimentada então em um grupo em conjunto representado que irá fornecer feedback sobre o novo serviço a partir da perspectiva do serviço ao cliente, contabilidade, gestão financeira e tecnologia. Finalmente, o grupo fará uma recomendação ao executivo operacional com poderes para tomar a decisão final sobre o novo serviço.
No entanto, as decisões que são considerados intra-departamentais são muitas vezes feitas por um grupo seleto, com alcance limitado, geralmente os executivos do departamento, mesmo que esta decisão afetará os esforços e recursos de outros departamentos. Ou seja, onde um departamento possui a oferta de serviço completo, tais como TI, é menos provável que a tomada de decisões irá chegar a outros departamentos para ver se um determinado serviço faz sentido para o negócio como um todo, como é o caso da oferta um serviço aos consumidores do negócio. Quando isso ocorre em SOA, você acaba com um foco mais restrito, serviço de orientação, que não pode satisfazer as necessidades do negócio conforme o esperado.

ITIL V3 suporte para SOA
Primeiro, e acima de tudo, ITIL foca na entrega de TI como um serviço, o que realmente captura a essência da SOA que é muitas vezes perdido, incompreendido ou simplesmente ignorados. Ou seja, em contraste com aqueles que vêem a SOA como meio de distribuição de sistemas de software, o foco do ITIL é no próprio serviço. Na ITIL, o serviço inclui o software, infra-estrutura, help desk, gestão de ativos, e muito mais. Assim, esta pode ser a melhor representação de uma estrutura de governança, simplesmente porque se centra na prestação de serviços a partir de uma perspectiva puramente centrado no serviço e não uma perspectiva tecnológica.
No coração do ITIL V3 é o conceito de estratégia de serviço, que se concentra na criação de valor. Grande parte da literatura sobre reverências à abordagem SOA meet-in-the-middle “para a SOA, de modo a não ofender a nenhum público específico. A abordagem meet-in-the-middle olha para projeto de um serviço, concentrando-se em ambos os bottom-up e top-down. No entanto, tanto de baixo para cima é tão ineficiente e falta de compreensão da qualidade do negócio que incorporando esse conhecimento para o todo é na verdade um desserviço para a criação de um novo serviço. foco do ITIL na criação de valor significa que o primeiro passo na prestação de serviços é a partir de um ponto de vista estratégico, sem limitações colocadas sobre o resultado de tentativas passadas de prestação deste serviço.
ITIL V3 também enfoca o projeto de serviço, que usa o conceito de pacote de design de serviço para encapsular todas as exigências, os endereços das dependências e implementação, arquitetura, processos, medidas e métricas. Este conceito é uma ótima maneira de pensar sobre a organização de todos os artefatos produzidos como parte de uma iniciativa SOA. Incluído no projeto do serviço é o conceito de gestão de portfólio de serviços e gestão de catálogo de serviços, que tanto bem alinhar com os objetivos de serviços SOA registro de inventário de serviços, gerenciamento de mudanças e de autorização.
Finalmente, a transição de serviço, operação de serviço e foco a melhoria dos serviços nos processos de prestar um serviço para o mercado, garantir o seu desempenho operacional e continuamente ajustar esse serviço para entregar de forma otimizada. Aqueles que vêem a SOA através de uma lente tecnológica vai perder as nuances abrangidos por estas práticas, uma vez que está fora do escopo dos esforços do grupo de engenharia de software. A única maneira que um serviço possa ser adequadamente gerida após a implantação é o de permitir a comunicação com os consumidores do serviço e para monitorar seu uso. Mais uma vez, esta é mais uma evidência de que SOA é um esforço estratégico que requer os esforços de muitos dentro da empresa e não deve ser celebrado com ligeireza. Este ponto será abordado mais detalhadamente na seção seguinte sobre Big SOA SOA e Little.
Além disso, os desenvolvedores muitas vezes assumem que a instrumentação e medição pode ser realizada após o fato e que o próprio serviço não precisa incorporar suporte para essas atividades. Essa miopia é uma das razões que aquelas focadas em SOA para a construção de serviços de software necessidade de empregar o modelo ITIL V3 para garantir que os serviços desenvolvidos não incorrer em sanções de ter um viés de engenharia de software.
ITIL V3 não se concentra em como construir um serviço, que também é importante. No que respeita ao fornecimento de serviços de TI, há subseqüentes, as normas mais detalhadas que entram em jogo, como TOGAF, ISO / IEC 20000, CMMI, COBIT e Six Sigma. No entanto, o ciclo de vida do próprio serviço é orientado pela V3, que é exatamente o que queremos para

SOA um único acordado quadro que define SOA e guias de todo o ciclo do serviço do berço ao túmulo.

Big SOA SOA, Little & Governança SOA
Uma discussão sobre governança SOA não seria completa sem abordar a SOA Big, Little debate SOA. Há alguns que acreditam que SOA pode ser abordado de uma forma tática de TI centralizada, ou que tem sido chamado “Little SOA” e ter chamado um foco da empresa em SOA como “Big SOA”. Acredito que a aplicação do ITIL V3 para o problema de governança SOA resolve este debate uma vez por todas, só há uma SOA. Mesmo que uma organização decidiu que a arquitetura de TI centralizada, o ITIL V3 ilustra que o fornecimento de TI como um serviço requer ainda diligência incrível e disciplina para garantir que os consumidores do serviço estão a ser devidamente atendido e que o serviço atenda às suas necessidades. Embora talvez numa escala menor do que toda a empresa, ele ainda exige que a empresa implementar e acompanhar o modelo de prática integral para garantir o sucesso.
SOA em qualquer escala menor é apenas focando no desenvolvimento de aplicações e utilização de SOA como uma maneira alternativa de dizer a arquitetura de software do componente. Em última análise, isso não é SOA, uma vez que não incide sobre o ciclo de vida do serviço, mas em uma maneira de definir as interfaces entre os componentes de software para permitir modularidade. Modularidade e SOA não são sinônimos e os resultados desta e de SOA orientado pela ITIL V3 governança são animais muito diferentes.

Conclusão
Há muita atenção a ser pago e dinheiro sendo gasto em soluções de governança de SOA. Em muitos destes casos, as empresas estão tentando descobrir para si o melhor método para regular o seu SOA alguma da confusão ainda, decorrentes da confusão em torno de SOA em si. ITIL V3 oferece uma abordagem abrangente que regem a criação, concepção, desenvolvimento, implantação, operação de gestão de mudança, e eventual termo de um serviço.
Sobre o Autor
JP Morgenthal trabalha como arquiteto principal Sr. QinetiQ com a Missão da América do Norte Systems Group da empresa e fornecendo orientação arquitetura SOA para as agências federais civis e um analista independente para jpmorgenthal.com. Antes de ingressar na QinetiQ NA, JP fundada Avorcor onde desenvolveu um retalho Enterprise SOA baseado PaaS / fabricação que tenha sido a fundação de três soluções premiadas para clientes. Ele também é blogueiro freqüentes e notou o analista em arquitetura corporativa, SOA e tópicos de computação em nuvem. Morgenthal é também autor de “Enterprise Information Integration: uma abordagem pragmática”, que define uma metodologia para a utilização de SOA e semântica para simplificar a integração.

Os pontos são acumulados conforme as certificações que são obtidas na base da pirâmide. Há também neste novo esquema cursos avançados que estão ainda em desenvolvimento.

1. Nível Foundation

ITIL V3 Foundation é o curso introdutório. Este curso é voltado para profissionais de TI que precisam ter conhecimentos básicos dos conceitos da ITIL . Ao obter a certificação Foundation o profissional ganha 2 pontos no seu currículo. Para fazer o exame de certificação o candidato não é obrigado a participar de um treinamento oficial. É possível obter o conhecimento através de auto-estudo. O exame pode ser agendado nos centros de testes PROMETRIC e VUE ou na ZILLION que é também oferecido pela EXIN e ISEB. O custo é de US$ 165,00. O exame tem a duração de 60 minutos (75 minutos para quem vai fazer em um idioma que não é língua nativa), é composto por 40 questões de múltipla escolha com apenas uma resposta correta por questão. É necessário obter 65% de acerto para obter a aprovação. O exame no idioma português já está disponível nos centros de treinamento credenciados, na PROMETRIC possivelmente início de 2009.

2. Nível Intermediário

Este nível tem algumas semelhanças com os cursos practitioners da V2. É dividido em duas áreas: Ciclo de Vida e Habilidade. Os módulos do Ciclo de Vida são voltados para quem quer ter um entendimento do Ciclo de Vida do Serviço e seus estágios. Os módulos de Habilidade são orientados para processos, funções e papéis dentro de uma organização de TI. Cada curso nestes módulos possui uma prova de avaliação, e só é possível fazer esta prova participando dos cursos oficiais. É pré-requisito ter a certificação ITIL V3 Foundation para realizar os cursos do nível intermediário. Cada certificação realizada relacionada a um módulo do Ciclo de Vida acumula 3 pontos, e a um módulo de Habilidade acumula 4 pontos.

2.1 Gerenciamento através do Ciclo de Vida

Este é um curso direcionado para gerentes de serviços, abrangendo no conteúdo do curso questões de Negócio, Mudança Estratégica, Gerenciamento de Riscos, Avaliação do Projeto de Ciclo de vida. O pré-requisito é o certificado Foundation e mais 30 horas de treinamento acreditado. Esta certificação acumula 5 pontos.

3. Certificação ITIL V3 Expert

Ao acumular o mínimo de 22 pontos nos módulos anteriores o profissional recebe este certificado. O profissional pode receber 2 pontos da certificação Foundation e 5 da certificação mandatória Gerenciamento através do Ciclo de Vida. Os outros 15 pontos podem obtidos realizando as certificações dos módulos do Ciclo de Vida ou de Habilidade. A APMG recomenda que a pontuação seja balanceada em 2 cursos de cada área. Quem tem algum certificado na ITIL V2 também acumula pontos para a

obtenção do certificado de ITIL Expert. O ITIL V2 Manager dá 17 pontos e o ITIL V2 Foundation 1,5. Quem tiver já o certificado de ITIL V2 Manager basta fazer o curso V3 Manager´s Bridge e conseguirá os 22 pontos necessários para ser um ITIL V3 Expert, ou seja, não é necessário fazer o curso de V3 Foundation Bridge.

Opções de migração (bridge)

Quem já possui alguma certificação na ITIL V2 não é obrigado a fazer a migração para a V3, é uma opção para quem quer ter seu certificado atualizado ou para quem quer obter pontos para alcançar o título de ITIL V3 Expert. Uma vez que o profissional é certificado em ITIL, não importará a versão – o certificado terá seu valor no mercado. Entretanto, quem pretende seguir carreira no novo esquema de qualificação é interessante optar pelos exames de migração (Bridge).

Quem já tem a certificação ITIL V2 Foundation tem 1,5 ponto e pode fazer o exame ITIL V3 Foundation Bridge e acumular mais 0,5 ponto, totalizando 2 pontos. Este exame é oferecido apenas nos centros de testes EXIN e não está disponível na PROMETRIC/VUE. A taxa é de US$ 80.00, mas como estes centros cobram impostos e mais uma margem de lucro, no final o custo de fazer o V3 Bridge é o mesmo de fazer o ITIL V3 Foundation na PROMETRIC. Na PROMETRIC o pagamento da taxa é feito com cartão de crédito internacional diretamente no site e não há necessidade de pagar nenhuma taxa extra.

O exame ITIL V3 Foundation Bridge é composto por 20 questões de múltipla escolha, sendo necessário acertar 65% (13 questões). A duração é de 30 minutos. O pré-requisito é ter o certificado ITIL V2 Foundation. O exame está disponível somente no idioma inglês. Para saber quais são os locais que aplicam o exame V3 Bridge localize no site www.exin-exams.com as empresas credenciadas . As empresas que são centros de treinamento credenciados pelo EXIN nem sempre permitem o candidato fazer o exame sem ter feito o curso, mas não é obrigatório fazer o curso oficial para prestar o exame do V3 Bridge. No Brasil existem algumas empresas que são apenas centros de testes e permitem fazer o exame sem ter feito o curso.

Quem já tem a certificação ITIL V2 Manager acumula mais 17 pontos. Ao fazer o exame V3 Manager´s Bridge acumulará mais 5 pontos. É muito interessante ainda fazer a formação ITIL V2 Manager, pois esta é o caminho mais rápido para acumular pontos para obtenção do título ITIL V3 Expert. Para fazer o exame V3 Manager´s Bridge é necessário participar do treinamento oficial que tem duração de 4 dias e uma prova de 20 questões de múltipla escolha. Outro fator crucial para optar pela formação ITIL V2 Manager: para conseguir 17 pontos no novo esquema da ITIL V3 você precisará investir muito mais dinheiro e tempo.

Veja no site oficial da ITIL uma calculadora de conversão de pontos da ITIL V2 para ITIL V3.
http://www.itil-officialsite.com/itilmapping/v2/map.asp

As certificações Practitioners também pontuam neste novo esquema de qualificação. Cada certificação practitioner composta de mais de um processo (Clusters ou Combo) acumula 3.75 pontos. Certificações Practitioners de um processo apenas acumulam 1 ponto cada uma.

Principalmente em relação aos ciclos de vida de serviços que tem grande semelhança e aplicabilidade a Arquitetura SOA.

Espero que estas informações possam agregar conhecimento aos interreçados

Em um artigo anterior, eu disse que nós podemos ver Service-Oriented Architecture (SOA) como uma síntese de Enterprise Application Integration (EAI) plataformas com ferramentas de middleware. Esta evolução tem evoluído para um estilo arquitetônico que, as entidades podem então utilizar para executar os serviços essenciais e alinhar com o seu modelo operacional para atingir as estratégias, metas e objetivos.

A maioria dos que interagem com ou ter interagido com o Departamento de Defesa (DoD), vai saber dos vários domínios através do qual as operações são executadas.

Como acontece com qualquer entidade eficazes dentro da esfera federal, o Departamento de Defesa em seu esforço para garantir que as informações de missão crítica é acessível, visível, implicitamente claro para seus usuários finais e disponível como exigiu de forma eficiente, tem implementado uma abordagem técnica arquitetônica com SOA implementações.

É claro que como em qualquer implementação SOA independentemente da indústria, haverá áreas de necessidade que é necessário resolver, por exemplo, a existência de disparidades na modelagem de dados e de serviços.

Mas será que podemos realmente ter um centro de comando ao acaso, com diversas implementações DBMS possivelmente abastecido com aplicativos de servidor de múltiplos clientes, que por sua vez, provavelmente, codificados em várias línguas e integrá-los em uma execução de SOA funcional? Talvez, pelo menos em teoria … right? certo?

Infelizmente, devido a um motivo ou outro, no passado, o processo de compartilhamento de dados entre domínios foi difícil se em tudo isto é possível, preso em um fogão de tubos ou silos de informação. O Departamento de Defesa em um esforço para amenizar isso, mudou-se para adoptar e empregam uma série de estratégias dos quais um é registro de metadados e implementações de registro de serviço.

No entanto um desafio fundamental enfrentado com o volume de informações estruturadas e não estruturadas de forma adequada é compatível com o sistema de buscas intenção do usuário e do contexto – os metadados de direito. Isso para que a informação que se relaciona / dados pode ser efetivamente utilizado por ciclo de descoberta.

Enter the terminology NetCentric. Digite o netcentric terminologia Consórcio. De acordo com a Network Centric Operations Indústria NCOIC “; centricity-Net busca aproveitar a evoluir as capacidades de rede para melhorar a eficiência global da empresa. “

Por esta definição podemos ter esperança de assumir em termos de combate a intenção é tirar proveito da tecnologia. Uma rota que incorporam sistemas / processos em um movimento longe de simplesmente automatizar os processos para analisar e saída de dados em um sistema (SOA), mas sim onde a tecnologia é inversamente exploradas para melhorar as situações de combate em tempo real.

Estas estratégias evoluiu dentro da SOA – DOD espaço inteligência, resultante de três memorandos CIO DOD destinado a todos os serviços e foi denominado o DOD Net-Centric Dados Estratégia .

Em resumo, esta estratégia exige dados a: Visível, acessível, compreensível, confiável, interoperável, ágil e institucionalizada (este é o processo de incorporação de algo dentro de uma organização e estabelecê-lo como habitual dentro de um determinado ambiente).

De acordo com Cohen e Taylor, um dos objetivos do Departamento de Defesa, “é a construção de melhorias na capacidade atual usando os pedaços de SOA e de Orientação para o serviço que melhor o trabalho, passando a escassez de volta para a indústria ea comunidade educativa para a perspectiva de novas soluções”.

Um exemplo de uma instância de ganhos da indústria privada, foi detalhado para mim em uma conversa que tive há alguns dias com uma equipe da Modus Operandi .

O time chegou a discutir a sua contribuição em termos de SOA nas áreas federal e inteligência, uma vez que impactos uma melhoria na exploração de informações disponíveis e encurtando o ciclo de decisão.

O resultado do trabalho Modus Operandi é fornecer informações seguras dentro dos prazos taticamente útil

É claro que eles só compartilhado informações publicamente disponíveis comigo.

A empresa afirma que “grandes volumes de dados em bruto apresentam um desafio significativo. Usuário são normalmente deixadas manualmente para interpretar silos separados dos dados e resultados de pesquisa para peneirar o relevante do irrelevante”.

Como resultado, uma área que essa empresa de endereços é um meio para permitir que analistas de superar a enxurrada de dados que é entregue a eles, com uma proposta de quadro para gerenciar esse volume de dados não estruturados.

Esta é a sua vez pode levar a permitir que os usuários autorizados a trabalhar perfeitamente em conjunto, independentemente da localização.

De acordo com o diretor Tod Hagan, ISR Software Solutions, o quadro desta empresa tem desenvolvido, pode permitir que um analista de inteligência para a produção de matéria essencial e imediata pronto dentro de um cronograma que permite lutar eficazmente contra por exemplo, dados que normalmente leva vários dias para analisar e interpretar pode agora ser analisados e interpretados dentro de algumas horas ou minutos.

Em essência, este quadro chamado Wave-EF realiza enriquecimento semântico dos dados que por sua vez permite a fusão de dados baseados em ontologias e descoberta.

Modus Operandi define Semântica Enriquecimento e Fusão de Dados de base ontológica da seguinte forma:

Enriquecimento semântico: a automatizada e escalonável além de tags de metadados XML para dados brutos que representam o significado embutido e fatos relevantes.

Ontologia de dados baseado em Fusão: a correlação de fatos relacionados ao domínio da ontologia de conceitos um, e suporte para consultas de semântica e de raciocínio da máquina.

O quadro Wave-EF facilita um maior nível de automação de dados e raciocínio máquina. O benefício de raciocínio da máquina é a capacidade de inferir informações que não está explícito nos dados.  Wave-EF não só analisa a inteligência primas, mas também suplementos adicionais meta-tags.

Esse processo aumenta a construção de um processo que, não só permite a descoberta de informações, mas também aumenta a quantidade de dados relevantes sobre a capacidade de informação para se tornar detectável.

Em conclusão, enquanto, eu pessoalmente não interagia com esse sistema, baseado em folhas de dados, conversas e apresentações que eu tinha conhecimento, o sistema parece se concentrar em uma área de funcionalidade do núcleo e componentes de interface do usuário com o hardware de forma concisa e integral / integração de software .

Este, por sua vez garante integrações adequadas para outras fontes de dados fornecidos, é escalável, manipula os dados em movimento, configura rapidamente e devido a sua persistência plugáveis evita vendor lock-in.

SOA, em seguida, representa um modelo baseado em padrões de arquitetura com ênfase em serviços de negócios e operações centradas em vez do que a tecnologia orientada para objectivos: Em outras palavras, um estilo arquitectónico que as empresas podem utilizar para executar os serviços e alinhar com o seu modelo de negócios para atingir sua estratégia de negócios, metas e objetivos.

Por exemplo, uma solicitação do usuário final de um determinado serviço de TI por requisitos que definem os níveis de capacidade e qualidade, em resposta a isso, os requisitos será entregue quando especificado em uma metodologia de prestação de serviços com base que é um processo consciente e que permite a auditoria.

De acordo com Thomas Erl, podemos definir Service Oriented Architecture (SOA) como “uma abordagem baseada em padrões de arquitectura para a construção de aplicações usando um conjunto de acoplamento fraco, baseado em padrões, e bem definido de serviços reutilizáveis”.

Tradicionalmente, a maioria do pessoal de TI lidar com SOA em algum ponto no tempo encontrou obstáculos que afectem as estruturas de decisão, bem como construir um roteiro de SOA. Isto foi particularmente evidente se houve uma lacuna persistente entre TI e negócios.

Vimos também que uma demanda crescente na velocidade e flexibilidade em relação às implementações de SOA, mais com aplicativos de negócios que estão aumentando as exigências para obter o valor das aplicações que sejam implementadas. Esta unidade dinâmica e necessidade SOA torna um modelo ideal para implementar um serviço de computação em nuvem.

No entanto, embora eu acredite que as seguintes diretrizes estabelecidas por um SOA é essencial para o sucesso deste tipo de ambiente orientada a serviços, um aspecto importante de qualquer implementação SOA é a sua governação.

No entanto, há lacunas no modelo SOA tradicional em termos de governança que podem impactar a maximização completa de um serviço na nuvem.

afirmou que, “de gestão ou de governo nem sempre é implementado que bem com SOA.” O parecer apresentado foi de que, se os serviços de computação em nuvem e entrega adequadamente concebido e implementado, a integridade dos dados seja em repouso ou em transição podem ser expostos a riscos pela maneira na qual “as transacções são iniciadas, executadas e gravadas por meio potencialmente infra-estruturas e sistemas de aplicação distribuídos em vários locais na nuvem.”

In addition to affecting operational costs and the possibility of revenue loss, such a scenario can lead to unwanted legal concerns. Além de afetar os custos operacionais ea possibilidade de perda de receita, tal cenário pode levar a indesejáveis problemas legais.

Com a nuvem de ser um espaço de diversidade, a fim de tirar pleno partido da execução de uma SOA, deve haver protocolos para garantir que:

1. 1. Governança procedimentos sejam devidamente mapeadas

2. 2. O roteiro SOA está claramente definido e

3. 3. SOA processos envolvidos são efetivamente documentada

À luz deste arquiteto deve assegurar uma compreensão clara dos requisitos de processo de negócios que são coletados e interpretados para assegurar uma execução rigorosa que se alinha com os objetivos de negócio, objetivos e estratégias de longo prazo.

Tenha em mente que neste ecossistema dinâmico da computação em nuvem, um tem que responder por todas as possíveis variações de atividade do processo por entender como o processo pode e irá responder a um problema inesperado ou anormal, ao invés de simplesmente se concentrar no que poderia dar errado.

A fim de implementar e gerir um sistema eficaz de computação em nuvem estrutura de governança de implantação, políticas e processos precisam ser implementadas para superar as deficiências na gestão de SOA e prática actual governação.

Alguns desses problemas foram abordados em um estudo “A Comprehensive SOA Governance Framework Baseado no COBIT”, apresentado em 2010 no 6 º Congresso Mundial sobre os serviços em Miami.

Os pesquisadores apresentaram dados demonstrando o mérito de um quadro de governação procurar colmatar as lacunas que podem ser encontrados dentro de uma aplicação tradicional de uma SOA.

Sua proposta sugere um modelo que levaria a uma proliferação de capacidade de gestão para melhorar a tomada de decisões, gerenciar a complexidade e desenvolver mecanismos de controle e fiscalização; idealmente melhoria da governação.

Além de outras áreas, o estudo também identificou Serviço de Gerenciamento de Portfólio e de Monitoramento e Avaliação de processos como duas áreas que precisavam de mais atenção.

A solução para estes problemas pesquisadores foi de integrar os aspectos de governança e as principais características dos Objetivos de Controle para Informações e Tecnologia Relacionada (COBIT).

Assim que eles usaram essas características do COBIT para desenvolver um “mensuráveis e mais expressiva estrutura de governança SOA, gerenciáveis em que todos os processos descrições, objetivos de atividade, objetivos de controle, atividades e métricas foram totalmente documentados aspectos como processos de gestão”.

Com a incerteza a hesitação por parte de alguns a adotar um serviço de nuvem apesar das vantagens comparativio ou percebido, eu acredito que a implementação de um modelo SOA, como proposto por estes pesquisadores podem aliviar algumas das principais preocupações associadas com a adopção de um serviço de computação em nuvem.

Ao assegurar que os processos e os protocolos estão em lugar que são gerenciáveis, mensuráveis, claramente definidas e controladas – preocupações como segurança, identidade e controle de acesso, juntamente com a conformidade e auditoria pode ser devidamente negociada.