Arquitetura empresarial é uma organização lógica de uma empresa e de seus dados, aplicativos e infraestrutura de TI de suporte, com metas e objetivos claramente definidos para o sucesso futuro dos negócios. Uma arquitetura típica consiste em diagramas, ou modelos, que mostram como aspectos dos negócios se relacionam. Por exemplo, um organograma é um modelo de como as unidades de negócios se relacionam umas com as outras.

Empresas devem ter uma arquitetura real, que represente o estado atual, e uma arquitetura planejada, que mostre a direção dos negócios nos próximos um a cinco anos.

A arquitetura empresarial alinha as seguintes áreas principais. Observe os exemplos em cada área:

• Negócios: Processos, estratégias, organogramas e funções
• Informações: Modelos de dados conceituais, lógicos e físicos para mostrar quais informações são necessárias e como se relacionam com outras informações. Por exemplo, um cliente e um pedido
• Aplicativo: Portfólios, interfaces e serviços
• Infraestrutura: diagramas de conceito de rede, modelos de referência tecnológicos

Para obter alinhamento, modelamos cada área principal a partir de sua própria perspectiva, e em seguida ligamos os modelos de cada perspectiva. Por exemplo, processos de negócios são modelados a partir de uma perspectiva de negócios. Não inclua coisas como aplicativos. Em seguida, associe os processos de negócios aos aplicativos que os suportam, o que ajuda a conseguir o alinhamento. Fazemos isso para garantir que toda decisão seja baseada em uma necessidade comercial; assim um aplicativo não está ditando a maneira como um processo de negócios deve ser projetado.

Neste artigo, consideramos que você tem uma ferramenta de modelagem para criar sua arquitetura. As informações específicas da implementação neste artigo são baseadas no Rational System Architect.

"Estamos fazendo arquitetura... para fazer arquitetura!"

A maneira mais simples de garantir que a arquitetura fracasse é não ter um propósito para ela. Eu já trabalhei em projetos de arquitetura com centenas de clientes. Quando os projetos não tem êxito, eu pergunto a eles por que estão criando uma arquitetura empresarial. Eles respondem: "Porque queremos uma arquitetura!".

Voltar para parte superior

Etapa 1. Identifique o propósito da arquitetura

Para definir o propósito da arquitetura, faça estas perguntas:

• Quais informações são importantes para a arquitetura?
• Quantos detalhes são necessários para suportar análise e tomada de decisões?
• Quem irá produzir ou usar a arquitetura?
• Qual é o ROI esperado da arquitetura?
• Quais são as considerações de manutenção?

Se você não puder responder a essas perguntas, seu projeto de arquitetura provavelmente será um fracasso. Sem um propósito, é possível perder meses desenhando diagramas de processos de negócios que não interessam a ninguém. Ou você pode desenhar diagramas complexos de interfaces de aplicativos que não podem ser mostrados ao gerenciamento senior, pois faria a cabeça deles explodir.

Ao saber o propósito da arquitetura, é possível analisar os modelos e dados necessários para garantir que as pessoas usem a arquitetura para análise e decisões de negócios.

Não exagere em sua primeira tentativa de arquitetura. Mesmo que você tenha uma equipe muito grande e experiente, não será possível capturar todas as informações sobre sua organização.

Também é importante lembrar que uma arquitetura abrangente pode esconder as coisas importantes. Por exemplo, não faz sentido capturar 5.000 processos de negócios se apenas 50 processos forem críticos para os negócios. Identifique as questões críticas de negócios e use-as como foco em seu primeiro projeto de arquitetura.

Voltar para parte superior

Etapa 2. Identifique suas questões de negócios

A primeira coisa que faço com um cliente é discutir as questões que são críticas para seus negócios; em seguida eu o ajudo a identificar aquelas que são difíceis de responder. As questões a seguir são aquelas que muitos clientes precisam responder:

• Qual é o impacto de obsoletar um aplicativo?
• Qual é o impacto de mover um local?
• Quais aplicativos são necessários para suportar um processo de negócios?
• Qual é o impacto de substituir servidores?
• Quais processos precisam ser desenvolvidos para suportar uma nova estratégia?
• Onde estão as lacunas ou redundâncias em nosso portfólio de aplicativo?

As questões conduzem o conteúdo da arquitetura. Se a maioria das perguntas for relacionada ao portfólio de aplicativo, concentre-se em definir a área de aplicativos. Se você precisa entender como os seus processos suportam uma nova estratégia, concentre-se na área de negócios. Assim é possível começar a expandir o escopo da arquitetura com novas questões de negócios.

Voltar para parte superior

Etapa 3. Identifique suposições e regras de negócios

Agora que você identificou o público, propósito e questões, deve identificar as regras de negócios que limitam ou explicam a área de interesse.

Todo negócio tem regras. Por exemplo, se você estiver capturando informações sobre processos de negócios críticos, também precisará capturar qualquer regulamento ou padrão corporativo para o processo. Um exemplo de regulamento é o Health Insurance Portability and Accountability Act (HIPAA), que protege a cobertura do seguro de saúde para pessoas que trocam de emprego. Um regulamento corporativo seria então criado para mostrar que a empresa está cumprindo os requisitos do HIPAA.

É necessário capturar suposições sobre a arquitetura, tais como "O upload de informações sobre novos aplicativos é feito na sexta-feira", ou "Toda unidade de negócios é responsável por documentar processos de negócios".

Voltar para parte superior

Etapa 4. Identifique sua estrutura

As seguintes estruturas de padrão de mercado podem ajudar a criar uma arquitetura empresarial:

• ToGAF
• Zachman
• EA3

• DoDAF

Ao usar uma estrutura padrão, a arquitetura adquire um "esqueleto" que pode em seguida ser ampliado com os modelos.

Uma estrutura também oferece orientação sobre quais informações precisam ser capturadas com base nas partes interessadas que usarão a arquitetura. Oferece orientação sobre a organização de informações, mas não sugere uma implementação específica para a arquitetura.

Há informações suficientes na Internet para cada uma dessas estruturas. A estrutura escolhida depende da meta da arquitetura, da experiência da equipe e da decisão entre seguir um processo definido, como ToGAF, ou apenas obter ajuda para identificar que modelo usar para qual propósito, como em Zachman.

Também é possível combinar estruturas. ToGAF e Zachman são usadas juntas com frequência.

Como uma estrutura se encaixa em sua arquitetura?

Uma estrutura oferece orientação sobre o que modela. Em seguida, metodologias são usadas para criar modelos.

Uma metodologia é um conjunto de regras que explica como modelar algo. Por exemplo, a metodologia Business Process Modeling Notation (BPMN) fornece regras e símbolos precisos para modelar um processo de negócios.

Uma estrutura ajuda a organizar as áreas principais da arquitetura e identifica as visualizações necessárias para modelar, tais como a perspectiva e os dados necessários para responder a questões de negócios.

Sempre que possível, use uma metodologia padrão de mercado em vez de algo produzido internamente. Metodologias padrão de mercado têm conjuntos de regras e maneiras padrão de modelar. A maioria das metodologias de produção interna não capturam informações de maneira útil porque o conjunto de regras não é definido claramente, o que permite que as pessoas modelem as mesmas informações de diversas maneiras. Isso também afeta a análise, porque as informações não são capturadas de acordo com um padrão.

Diversos modelos são produzidos para suportar a estrutura com base no tipo de informações necessárias.

Voltar para parte superior

Etapa 5. Crie um metamodelo

Um metamodelo é uma visualização abstrata da arquitetura. Ele mostra os dados que o usuário está tentando capturar e os relacionamentos entre os dados. É aqui que se realiza o alinhamento, que é baseado nas respostas às questões de negócios.

Por exemplo, se for preciso saber o aplicativo que suporta um determinado processo de negócios, deve haver um relacionamento entre esses dois no metamodelo. Do contrário, não há conexão entre os dados, não é possível responder às questões de negócios e a arquitetura não é funcional.

Observe que não se deve colocar um relacionamento direto entre tudo no metamodelo. Apenas ligue os fatos que têm relacionamentos lógicos. Por exemplo, ligar um departamento organizacional a uma tecnologia não faz sentido, mas ligar uma tecnologia a um aplicativo faz. Uma boa ferramenta de modelagem, como Rational System Architect, suporta o atravessamento do metamodelo para criar relatórios complexos. Portanto, nesse exemplo de metamodelo, é possível criar relatório sobre o hardware que suporta uma função de negócios, mesmo que não haja um relacionamento direto no metamodelo. Em um metamodelo, é possível atravessar de uma função de negócios para um processo de negócios de propriedade dessa função; para um local do processo de negócios; para um aplicativo de suporte necessário para o processo; e finalmente para tecnologias que suportam esse aplicativo.

Seu metamodelo deve incluir os seguintes recursos:

• Relacionamentos entre elementos da arquitetura. Por exemplo, um processo de negócios para um aplicativo.
• Definições dos elementos. Por exemplo, o significado do termo "aplicativo" e quais propriedades serão capturadas.
• Rastreabilidade para questões de negócios. Por exemplo, se a questão é "quais aplicativos suportam quais processos de negócios?". Você sabe que é preciso um processo de negócios e um aplicativo no metamodelo, com um relacionamento direto ou indireto entre eles.

Voltar para parte superior

Etapa 6. Identifique os modelos necessários na arquitetura

Agora que você identificou suas questões de negócios, sua estrutura e o metamodelo necessário para responder suas questões, é preciso decidir quais modelos desenhar.

Usando como exemplo um processo de negócios, há muitos padrões de mercado que suportam modelagem de processos de negócios, tais como BPMN e fluxogramas. Escolha sua metodologia de modelagem com base nos seguintes critérios:

• O público para as informações. Gerentes entendem diagramas simples, como BPMN; desenvolvedores de software geralmente preferem diagramas de sequência UML ou casos de uso.
• Os elementos do metamodelo. Se, em seu metamodelo, for necessário entender a relação entre os dados e os processos de negócios, considere usar BPMN para modelar isso. Se, ao contrário, você estiver preocupado apenas com a sequência de etapas do processo, considere criar um fluxograma.

Após saber o público e o conteúdo que se deseja modelar, é possível então identificar os diagramas que precisam ser criados. No exemplo acima, como você precisa de informações sobre processos de negócios e interfaces de sistema, pode selecionar os seguintes modelos:

• BPMN (captura processos de negócios)
• Arquitetura de sistema (captura aplicativos)

É importante lembrar que não é possível usar um único diagrama para modelar tudo na EA. Além disso, é uma boa prática separar as visões arquiteturais, tais como a visão de aplicativo, da visão de negócios. Tentar modelar duas visões no mesmo diagrama frequentemente cria confusão e não captura as informações de modo significativo.

Visualização maior da figura 7.

Como Will Gadd disse, "Há algo que eu acho maravilhosamente atraente em fazer nada útil".

Use as ferramentas certas

Uma única ferramenta de modelagem ou metodologia não fornece uma solução completa. Além de uma ferramenta para desenvolver modelos, você também deve ter ferramentas para publicação, gerenciamento de requisitos e exibição em um painel. Um painel apresenta suas informações de arquitetura empresarial em gráficos fáceis de entender, como gráfico de setores circulares e gráfico de barras.

Se a ferramenta de arquitetura for customizável, questione customizações que mudam a maneira como a ferramenta deve ser usada. Customização extensa é geralmente um sinal de que a ferramenta ou abordagem errada está sendo usada. Lembre-se também que a customização cria sobrecarga administrativa na arquitetura.

Alguns clientes customizam ferramentas de arquitetura para criar seus próprios modelos. Essa não é uma abordagem de melhores práticas, especialmente se o "modelo" for um único diagrama ocupando uma parede inteira e contendo todas as informações sobre a arquitetura. Em vez de criar papel de parede, crie relatórios. Nem tudo precisa ser mostrado em um diagrama.

No desenvolvimento de uma arquitetura, pessoas e ferramentas são igualmente importantes. Uma única pessoa não pode ser especialista em todos os aspectos da arquitetura. Desenvolva uma equipe bem diversificada para suportar a arquitetura. Para ver uma lista das características ideais de uma equipe de arquitetura, consulte o primeiro artigo nesta série Obtenha o valor máximo do seu consultor de arquitetura empresarial.

Voltar para parte superior

Etapa 7. Integre a arquitetura

Ligue os dados capturados juntos com base nos relacionamentos identificados antes. Não, uma ferramenta não faz isso por mágica, não importa o que os vendedores tenham dito a você. E sim, ligações de relacionamentos são muito difíceis de fazer sem um repositório. Se alguém sugerir que o projeto pode fazer isso usando uma planilha, o mais sábio para você é procurar outro projeto no qual trabalhar.

Se você tiver arquitetura existente para projetos ou linhas de negócios e desejar criar uma arquitetura empresarial, a abordagem mais fácil é preencher sua EA de baixo para cima. Tome as arquiteturas existentes e coloque elementos comuns em um repositório. Além disso, tente padronizar os modelos e terminologia usados na organização, pois todos usam o mesmo nome para uma organização, por exemplo, definir como padrão "Financeiro" em vez de ter variações como "Depto. financeiro", contabilidade, ou contabilidade e financeiro.

Se esta for sua primeira arquitetura empresarial, use um blueprint comum em sua organização de modo que uma arquitetura que tenha sido criada para uma linha de negócios use a mesma estrutura, terminologia e modelos que a arquitetura empresarial. Dessa forma é possível criar relatórios para a empresa inteira.

Analise a arquitetura

Se você não destinar tempo para analisar a arquitetura, não haverá tempo para analisá-la. Se você não a analisa, por que a desenvolveu? Essa importante etapa é ignorada com frequência no planejamento. Deixe ao menos 50% do tempo destinado ao desenvolvimento de um modelo para análise; isso inclui revisar o modelo para verificação e validação.

Faça análise quantitativa, assim como qualitativa. Matemática é importante, especialmente para mostrar ROI. Análise quantitativa pode ser usada para mostrar gargalos em um processo, economia de tempo, economia de custo e eliminação de redundâncias se um método padrão for usado, como BPMN. BPMN é "estruturado" porque tem um conjunto de regras que não podem ser violadas. As regras garantem que seja sempre possível fazer análise, como simular uma alteração em um processo de negócios para ver ser a mudança economiza tempo ou dinheiro, ou se tem um impacto negativo, como um gargalo.

Análise qualitativa é feita examinando um modelo para ver onde estão os problemas em potencial. Por exemplo, se houver um processo de negócios que tenha feedback para uma parte anterior do processo, isso geralmente significa que retrabalho é necessário. Eliminar loops de feedback em um processo é uma maneira de melhorá-lo.

Após concluir sua análise, compartilhe os resultados. As pessoas irão valorizar a arquitetura se aprenderem a usá-la. Relatórios são essenciais, portanto, ao selecionar uma ferramenta de arquitetura empresarial, escolha uma que tenha sólidos recursos de relatórios.

Não se esqueça - você precisa de um plano de jogo

As pessoas esquecem com frequência que há muitos problemas administrativos que precisam ser resolvidos para iniciar e suportar um projeto de EA. Alguns dos problemas administrativos que precisam ser resolvidos incluem:

• Como implementar a arquitetura empresarial?
• Onde implementá-la (Web site etc.)?
• Quem está na equipe?
  • Comissões de revisão
  • Gerenciamento de projetos
  • Administração
• Quem usará as informações?
• Quem terá acesso às informações?
• Quais normas serão seguidas?
  • Convenções de nomenclatura
  • Códigos de cor

Equipe é essencial para EA

Não é possível criar arquitetura no vácuo. Você deve estar preparado para trabalhar com pessoas fora da equipe de EA, do contrário a arquitetura não pode ser adotada e usada. Além disso, faça com que as partes interessadas (por exemplo, as pessoas que estão pagando a você para desenvolver a arquitetura, ou as pessoas que estão ajudando a desenvolver a arquitetura) estejam envolvidas na tomada de decisões.

Governança é necessária para tomar decisões. Governança ajuda a definir as regras e estratégias que serão usadas para a arquitetura. Um exemplo é governança na nomenclatura das linhas de negócios na organização, de modo que uma pessoa não chame um departamento de "Contabilidade" e outra chame de "Financeiro". Governança também determina quais modelos estão prontos para serem lançados conforme "aprovados". Comitês que são geralmente necessários para ter uma EA de sucesso incluem:

• Comissão de revisão de arquitetura
• Comitê de configuração e controle
• Diretrizes administrativas (por exemplo, quem pode criar modelos, qual é o processo de aprovação, qual é o processo para uma solicitação de mudança)

Quanto mais pessoas estiverem envolvidas no suporte à arquitetura, melhores as chances de que ela seja usada

Algumas dicas finais

Se parece difícil, é porque é difícil. Mas isso também poder ser um sinal de que você está fazendo algo errado com um destes aspectos:

• Modelos. Por exemplo, usar um modelo BPMN para capturar interfaces de aplicativo),
• Partes interessadas. Por exemplo, pessoas que não estão familiarizadas com um processo de negócios fornecendo sugestões e feedback em vez das pessoas que realmente fazem o processo

Saiba como separar reações políticas da arquitetura

• "Não documente isso! Assim as pessoas vão saber o que a gente está fazendo errado!" – Essa é uma reação comum à arquitetura empresarial. Mas não há para quê documentar uma visão idealizada do mundo, pois não será possível planejar-se para consertar as coisas no futuro.
• "Minha organização está usando um método diferente para capturar nossa arquitetura." – Sempre há uma linha de negócios, em todas as organizações nas quais trabalhei, que não quer desenvolver sua arquitetura da maneira padrão. Ninguém é especial. Ninguém tem uma razão legítima para não fazer as coisas da maneira padrão. A melhor abordagem para essa situação é treinar para os cabeças-duras que querem ser diferentes. Se eles estiverem tranquilos e entenderem o que se espera deles, devem estar dispostos a seguir as normas. Se isso não funcionar, sua única opção é dobrá-los.

Use a arquitetura para desmontar as barreiras para a informação

• "A gente não pode falar com esses rapazes. Eles são, tipo, o pessoal do software." – Na maioria das empresas há pessoas que acham difícil conversar com os desenvolvedores de software. Quando você os conhece, vê que eles são boas pessoas. E a atitude deles irá mudar quando eles descobrirem que podem se comunicar facilmente com você usando imagens em vez de documentos de requisitos de 500 páginas que não dizem nada.
• "Eu quero passar esses dados para você, mas preciso verificar com a gerência antes. Que tal eu dar um retorno a você no dia de São Nunca?" – Algumas pessoas acham que reter informações traz segurança no emprego. Não é possível demitir Barney se ele for a única pessoa que entende como os aplicativos estão ligados uns aos outros. Outras linhas de negócios podem não querer compartilhar informações porque temem que elas sejam usadas para demitir pessoas. Para lidar com essas situações, explique como as informações serão usadas e como isso irá beneficiar a pessoa que as forneceu. Se você usar as informações para fins nefastos, como demitir pessoas, pode contar com a diminuição das pessoas dispostas a lhe dar informações.

Um agradecimento especial para Joe Josephson, da First Ascent Press www.firstascentpress.com, por fornecer imagens, e a Will Gadd, www.gravsports.com, por fornecer imagens e citações.

Recursos

Aprender

• Saiba mais sobre o Rational System Architect:
  • Navegue pela página do developerWorks para obter o Rational System Architecte assista a demonstração on-line ou leia a transcrição por escrito.
  • Verifique o Centro de Informações do Rational System Architect para obter documentação para todas as versões ou obtenha suporte a partir de tópicos da ajuda do Rational System Architect .
  
  
• Visite a área do software Rational no developerWorks para obter recursos técnicos e boas práticas para os produtos do Rational Software Delivery Platform.
  
  
• Fique por dentro dos eventos técnicos e Webcasts do developerWorks com foco em uma variedade de produtos da IBM e tópicos do segmento de mercado de TI.
  • Participe de um briefing gratuito do developerWorks Live! para se atualizar rapidamente sobre produtos e ferramentas IBM, bem como tendências do segmento de mercado de TI.
  • Acompanhe as demos on demand do developerWorks, variando de demos de instalação e configuração de produtos para iniciantes a funcionalidades avançadas para desenvolvedores experientes.
  
  
• Melhore suas qualificações. Consulte o catálogo Treinamento e certificação do Rational que inclui muitos tipos de cursos em uma ampla variedade de tópicos. É possível realizar alguns deles em qualquer local, a qualquer momento, e muitos dos cursos para iniciantes são gratuitos.
  
  
• Artigo: Obtenha o valor máximo do seu consultor de arquitetura empresarial
  
  

Obter produtos e tecnologias

• Faça o download de uma versão de teste gratuita e com funcionalidades completas do Rational System Architect.
  
  
• Avalie o software IBM da forma que melhor lhe convier: faça o download da versão de avaliação, experimente-a on-line, use-a em um ambiente de nuvem ou passe algumas horas no SOA Sandbox aprendendo a implementar Arquitetura Orientada a Serviços de forma eficiente.
  
  

Discutir

• Participe do fórum Enterprise Architecture and Business Architecture, no qual poderá compartilhar informações sobre métodos, estruturas e implementações de ferramentas. As discussões incluem discussões técnicas específicas da ferramenta Rational System Architect.
  
  
• Classifique ou revise o software Rational. É rápido e fácil. Realmente.
  
  
• Compartilhe seu conhecimento e ajude outros a usar o software Rational, escrevendo um artigo para o developerWorks. Você terá um público mundial, organização RSS, reconhecimento de autoria e uma biografia, e o benefício da edição e produção profissional no Web site do Rational no developerWorks. Descubra quais são as características de um bom artigo do developerWorks e como realizá-lo.
  
  
• Siga o software Rational no Facebook e no Twitter (@ibmrational), e inclua seus comentários e solicitações.
  
  
• Faça e responda a perguntas e aumente seus conhecimentos participando dos fóruns do Rational, caféés e wikis.
  
  
• Entre em contato com outras pessoas que compartilham seus interesses fazendo parte da comunidade do developerWorks , e respondendo aos blogs de desenvolvedores.
  
  

Sobre o autor

Franki Schafrik tem 17 anos de experiência no uso do Rational System Architect e do DoDAF com clientes de defesa do mundo todo. Ela presta consultoria e leciona sobre o DoDAF internacionalmente.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Etapa 1. Identifique o propósito da arquitetura
• Etapa 2. Identifique suas questões de negócios
• Etapa 3. Identifique suposições e regras de negócios
• Etapa 4. Identifique sua estrutura
• Etapa 5. Crie um metamodelo
• Etapa 6. Identifique os modelos necessários na arquitetura
• Etapa 7. Integre a arquitetura
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais