Você está na página 1de 27

Um melhor caminho para arquiteturas empresariais

Aplica-se a:

Arquitetura de aplicativos Iteração particionada

Sumário

Introdução

Roger Sessions

Abril de 2006

Quando as arquiteturas empresariais funcionam bem, elas constituem uma vantagem enorme na hora de encontrar formas eficazes de melhor utilizar a tecnologia. Quando não funcionam, podem ser um enorme escoadouro contraproducente nos preciosos recursos organizacionais. Com muita freqüência, é este último caso que é percebido.

Você não pode se dar ao luxo de ignorar as vantagens em potencial de uma arquitetura empresarial bem construída. Essas vantagens incluem redução dos custos, aumento das receitas, otimização de processos e expansão das oportunidades de negócio. Mas você também não pode ignorar os riscos de se complicar em uma arquitetura empresarial mal projetada. Entre os riscos estão gastos astronômicos, obstrução tecnológica e diminuição da credibilidade executiva.

Mas não se desespere: você pode desfrutar das vantagens e evitar os problemas. Este documento lhe mostrará como. Vou apresentar algumas dicas importantes e mostrar como tratar da arquitetura empresarial com base em duas disciplinas não-relacionadas: a teoria da probabilidade e a estratégia de guerra.

Da teoria da probabilidade, aprendemos algumas lições importantes sobre a natureza da complexidade. A impossibilidade de administrar a complexidade é, acredito eu, a principal razão para tantas tentativas de criar uma arquitetura empresarial darem errado. Poucas metodologias existentes para as arquiteturas empresariais tratam da administração da complexidade de qualquer modo significativo. E as arquiteturas das organizações atuais são altamente complexas.

Assim, como você administra a complexidade? A resposta vem da improvável área da estratégia de guerra. Você verá como uma lição retirada dos pilotos de combate que estavam tentando sobreviver a batalhas aéreas 50 anos atrás contém uma dica importante para desenvolver arquiteturas empresariais complexas hoje em dia.

Por fim, vou juntar tudo em uma série de diretrizes para desenvolver uma boa arquitetura empresarial que será um ativo organizacional importantíssimo, e não uma dívida cara e constrangedora.

Definindo uma arquitetura empresarial

Um bom ponto de início para a discussão sobre as arquiteturas empresariais é chegar a um acordo sobre a definição do termo arquitetura empresarial.

Segundo a Carnegie Mellon University (onde se encontram grandes pensadores desta área), a arquitetura empresarial é:

Um meio para descrever estruturas de negócios e processos que conectam essas estruturas. [CMU]

Embora seja sucinta, esta definição não capta nem o alto custo geralmente associado ao desenvolvimento de uma arquitetura empresarial, nem a justificativa de negócios para passar pelo processo.

A Wikipedia vai mais fundo na definição de arquitetura empresarial:

Prática de aplicar um método abrangente e rigoroso para descrever uma estrutura atual ou futura para os processos, sistemas de informação, sub-unidades pessoais de uma organização, para que possam se alinhar com as metas centrais e a direção estratégica da organização. [Wiki]

A definição da Wikipedia capta melhor a complexidade de tantas metodologias arquiteturais das empresas de hoje. Uma definição ainda mais completa vem do Escritório do CIO do Governo Americano:

Base estratégica de ativos de informação, que define o negócio, as informações necessárias para operar o negócio, as tecnologias necessárias para apoiar as operações comerciais e os processos de transição necessários para implementar novas tecnologias em resposta às necessidades de negócios em constante alteração. [Gov]

Você está começando a ter uma idéia do motivo pelo qual as arquiteturas empresariais podem ser tão caras? São muitas informações a serem documentadas.

Os gastos para criar uma arquitetura empresarial típica são dominados por três fatores:

Os cronogramas exaustivos necessários para realizar uma análise abrangente. A grande equipe interna qualificada que é absorvida pelo processo. O exército de consultores caros que são necessários para pesquisar metodologias complexas.

Mas não tem de ser dessa maneira. Eis minha definição da arquitetura empresarial, que contém várias dicas sobre como o processo pode ser aprimorado:

A arquitetura empresarial é uma descrição das metas de uma organização, como essas metas são percebidas pelos processos de negócios e como esses processos podem ser melhor atendidos por meio da tecnologia.

Muitos vão argumentar que minha definição não é ampla o suficiente. Discordo. Na definição que propus, a meta de uma empresa não é documentar completamente todos os processos de negócios, todos os sistemas de software e todos os registros de banco de dados que existem na organização. Em vez disso, minha definição assume uma meta muito mais pragmática: encontrar oportunidades para usar a tecnologia para agregar valor aos negócios.

Se agregar valor aos negócios não é a meta final de uma arquitetura empresarial, então a energia depositada na criação dessa arquitetura foi mal utilizada. Caso se consiga atingir esta meta sem passar por um processo oneroso e demorado, então eu digo "tanto melhor".

Parte da diferença entre a minha abordagem e a de outras pessoas começa com o próprio termo arquitetura. A palavra arquitetura implica projetos. Os projetos são conhecidos por sua completude e perfeição, especificando absolutamente tudo, da forma como o forro se integra às paredes e como são colocadas as tubulações, até onde devem ser colocadas as tomadas, e assim por diante. Esse nível de detalhamento é desnecessário e inapropriado em uma arquitetura empresarial.

Ao analisar como usar a tecnologia para agregar valor aos negócios, precisamos de respostas para as seguintes questões:

Quais são as metas gerais do negócio? Como o negócio é organizado em processos de negócios autônomos? Como esses processos de negócios são relacionados uns aos outros? Que processos de negócios (ou relações entre processos) parecem ser particularmente sensíveis ao aprimoramento por meio da tecnologia? Qual é o plano para fazer esses aprimoramentos?

Observe que, nesta abordagem, não existe uma arquitetura empresarial acabada. Ao invés disso, a arquitetura empresarial é vista como um conjunto vivo de documentos que orienta a utilização da tecnologia. Tem muito mais a ver com o mapa de uma cidade do que com o projeto de um edifício.

A analogia de uma arquitetura empresarial com o mapa de uma cidade foi apresentada pela primeira vez pela Armour em 1999 [Arm], e é particularmente importante para as organizações altamente complexas da atualidade.

A planta de uma cidade dá conta de problemas diferentes do que os projetos de um edifício. Eis o que a planta de uma cidade apresenta:

Que tipo de edifício é permitido em tais zonas (por exemplo, comerciais ou residenciais)?

Como os edifícios se conectam com a infra-estrutura da cidade (por exemplo, os encanamentos e a rede elétrica)?

Que impacto os edifícios terão em outros aspectos (por exemplo, qualidade do ar e tráfego)?

Os edifícios são construídos segundo um padrão que não representa risco aos habitantes (por exemplo, resistem a incêndios e terremotos)?

Imagine uma cidade que inclua no plano diretor um projeto detalhado de cada edifício que possa ser construído na cidade. Esse plano seria extremamente caro de criar e, se chegasse a ser concluído, seria inflexível e opressor. Tudo isso, só para pensar, se assemelham com algumas arquiteturas empresariais que já vi.

História das arquiteturas empresariais

Em geral, credita-se o nascimento da área das arquiteturas empresariais a um artigo publicado no jornal IBM Systems em 1987, "Estrutura para arquitetura dos sistemas de informações", escrito por J. A. Zachman [Zac]. Depois, Zachman renomeou sua estrutura de "information systems" para estrutura de "arquitetura empresarial". Atualmente, essa estrutura é conhecida simplesmente como Estrutura Zachman.

Em 1994, o Departamento de Defesa dos Estados Unidos lançou a TAFIM (Technical Architecture Framework for Information Management) [TAF]. Anunciou-se que a TAFIM seria o novo padrão de arquitetura empresarial para todo o trabalho de defesa. A TAFIM passou por várias iterações antes de ser finalmente descontinuada em 2000.

Embora a TAFIM não exista mais, algumas partes dela foram adotadas na TOGAF (The Open Group Architectural Framework). A TOGAF é uma estrutura de "código-fonte aberto" controlada pela The Open Group, e já está atualmente na versão 8.1 [TOG]. A TOGAF é, provavelmente, a mais popular arquitetura empresarial do setor privado atualmente, seguida de perto pela Zachman.

Em 1996, a disciplina das arquiteturas empresariais recebeu um grande incentivo do congresso americano. Naquele ano, o congresso aprovou a lei Clinger/Cohen, também conhecido como ITMRA (Information Technology Management Reform Act). A lei dava ao OMB (Escritório de Administração e Orçamento) ampla autoridade para ditar padrões para "analisar, controlar e avaliar riscos e resultados de todos os grandes investimentos de capital feitos por uma agência executiva em sistemas de informação". [Cli]

A lei Clinger/Cohen exigiu que cada agência executiva estabelecesse um CIO (Chief Information Officer) que, entre outras tarefas, seria responsável por "desenvolver, manter e

facilitar a implementação de uma

estrutura integrada para fazer evoluir ou manter a

... tecnologia de informação atual e adquirir nova tecnologia de informação para atingir as metas

estratégicas da agência e as metas administrativas dos recursos de informação". [Cli]

Estranhamente, a lei Clinger/Cohen não menciona o conceito de arquitetura empresarial. No entanto, o OMB interpretou esta lei como permissão para uma estrutura universal de arquitetura empresarial para todo o governo americano. Esta estrutura se tornou conhecida como FEAF (Estrutura Federal para Arquitetura Empresarial) [FEA]. Atualmente, todas as agências executivas, do Departamento de Justiça ao Departamento de Segurança Interna, passando pelo Departamento de Agricultura, foram obrigadas pelo OMB a desenvolver uma arquitetura empresarial e mostrar como essa arquitetura entra em sintonia com a FEAF.

O resultado prático, portanto, da lei Clinger/Cohen foi que todo o trabalho de TI feito por ou para o governo americano está sendo feito agora, em teoria pelo menos, sob a proteção de uma única e comum arquitetura empresarial.

Estudos de caso do setor público

A lei Clinger/Cohen não apenas controlou a utilização da arquitetura empresarial federal (ou, pelo menos, foi interpretada dessa maneira), como também estabeleceu que a eficácia do programa fosse regularmente monitorada e relatada. Isso nos deu a importante oportunidade de ver uma grande arquitetura empresarial em ação.

Com efeito, temos um grande estudo de caso sobre a utilização de uma arquitetura empresarial abrangente (FEAF) por parte, provavelmente, da única organização mais complexa do mundo, o governo americano. E, como a FEAF foi muito influenciada pela TOGAF e pela Zachman, podemos extrapolar as lições aprendidas com a FEAF e dar uma olhada nas lições dessas duas estruturas de arquitetura empresarial.

Como tem agido o governo americano?

Aparentemente, não muito bem. Dificilmente passou-se um mês no qual o GAO (Escritório de Contabilidade do Governo), um braço independente de vigilância do governo americano, não emitiu um relatório pungente sobre as práticas de Tecnologia de Informação de pelo menos uma agência. Parece que, quanto mais crítica for a agência do governo, maior será a probabilidade de ela ter grandes falhas de TI.

Em novembro de 2005, o GAO observou os seguintes problemas de TI com a Receita Federal americana (IRS):

A falta de um sistema completo de controle financeiro que pode produzir informações oportunas, precisas, úteis e necessárias para as decisões diárias continua sendo um desafio sério à administração da IRS. Os atuais sistemas de controle financeiro da IRS inibem a capacidade da IRS de resolver os problemas operacionais e de controle financeiro que afetam a capacidade do órgão de atender às suas responsabilidades como arrecadador de impostos do país. [GAO1]

O DOD (Departamento de Defesa) sofreu várias críticas. Por exemplo, em junho de 2005, o GAO emitiu um relatório afirmando o seguinte:

Os inúmeros pontos fracos da administração de negócios e financeira do DOD afetam adversamente não apenas sua capacidade de produzir informações financeiras auditáveis, mas também de fornecer informações precisas, completas e oportunas para a administração e o Congresso usarem na hora de tomar decisões informadas. Além disso, a falta de uma contabilidade adequada em todas as principais áreas comerciais do DOD tem como resultado bilhões de dólares em recursos anuais desperdiçados em uma época de aumento do aperto fiscal, tendo um impacto negativo no desempenho da missão. [GAO2]

O altamente visado DHS (Departamento de Segurança Interna) teve muitos problemas. Em um relatório de agosto de 2004, o GAO afirmou o seguinte:

O [DHS] carece, em parte ou no todo, de todos os principais elementos que se espera encontrar em uma arquitetura bem-definida, tais como descrições dos processos de negócios, fluxos de informações entre esses processos e regras de segurança associadas a esses fluxos,

para nomear apenas alguns

Além disso, os principais elementos que estão pelo menos

... parcialmente presentes na versão inicial não foram produzidos de uma forma consistente com as práticas recomendadas para o desenvolvimento de arquitetura. Como resultado, o DHS ainda não tem o projeto de arquitetura necessário para orientar e restringir efetivamente seus esforços contínuos de transformação de negócios e as centenas de milhões de dólares que está investindo no suporte aos ativos de tecnologia da informação. [GAO3]

A lista aumenta cada vez mais de tamanho. O FBI recebeu pesadas críticas por torrar mais de US$ 500 milhões em um esforço fracassado de criar um sistema virtual de preenchimento de caso. O FEMA gastou mais de US$ 100 milhões em um sistema que se provou ineficiente com o Furacão Katrina. Outros órgãos federais que foram motivo de crítica do GAO incluem o Census Bureau, a Federal Aviation Authority, a National Air and Space Administration, o HUD, o Health and Human Services, o Medicare e o Medicaid.

Talvez por ironia, um dos departamentos criticados por não conseguir se adaptar à lei Clinger/Cohen foi o Escritório de Administração e Orçamento, a organização que supostamente está monitorando as outras agências para ver se estão em conformidade com a lei Clinger/Cohen!

Se o governo americano for o estudo de caso mais abrangente do valor das arquiteturas empresariais, então essa área encontra-se em um estado bastante lastimável.

Estudos de caso do setor privado

Embora as falhas do setor privado provavelmente não acabem gerando headlines, a iniciativa privada também é perfeitamente capaz de estragar a TI em larga escala. Entre os problemas do setor privado que parecem amplamente atribuídos falhas nas metodologias de arquitetura empresarial estão:

O esforço malogrado do McDonald's de desenvolver um sistema integrado de gerenciamento comercial que ligaria todo o negócio de restaurantes. Custo: US$ 170 milhões. [Mac] A tentativa fracassada da Ford de desenvolver um sistema de compras integrado. Custo: US$ 400 milhões. [For] A tentativa mal-sucedida da KMart de desenvolver um sistema moderno de gerenciamento da cadeia de suprimentos. Custo: US$ 130 milhões. [Kma] Nicholas G. Carr, em um recente artigo para o New York Times, concluiu o seguinte:

Uma olhada no setor privado revela que os desastres de software são rotina. E que, quanto mais ambicioso for o projeto, maiores serão as chances de decepção. [Car]

Um recente artigo do IEEE Spectrum incluiu a seguinte avaliação melancólica:

Analisando o investimento total em novos projetos de software - tanto governamental quanto corporativo - nos últimos cinco anos, estimo que as falhas de projeto provavelmente custaram à economia americana pelo menos US$ 25 bilhões e talvez até US$ 75 bilhões. Naturalmente, esses 75 bilhões não refletem os projetos que ultrapassam os orçamentos - o que ocorre com a maioria deles. Nem refletem os projetos entregues com atraso - o que ocorre também com a maioria. Além disso, eles não dão conta dos custos de oportunidade de ter que começar de novo quando um projeto é abandonado nem dos custos dos sistemas cheios de bugs que exigem re-trabalho com repetida freqüência. [Cha]

Dos setores público e privado, temos vários exemplos de arquiteturas empresariais extensivas e onerosas que não conseguem alinhar as necessidades dos negócios com as soluções tecnológicas. Dadas as evidências disponíveis, deve-se concluir que nenhuma das arquiteturas empresariais vale a pena ser perseguida, ou que as metodologias que estamos usando para criar arquiteturas empresariais são altamente defeituosas.

Intuitivamente, parece que uma arquitetura empresarial deve ser uma boa coisa. Vamos reexaminar a definição que forneci antes:

A arquitetura empresarial é uma descrição das metas de uma organização, como essas metas são percebidas pelos processos de negócios e como esses processos podem ser mais bem atendidos por meio da tecnologia.

É difícil discutir com a idéia de encontrar formas melhores de atender às nossas metas organizacionais usando a tecnologia. Assim, isso deixa as metodologias como nossos principais suspeitos.

Complexidade

Para entender as falhas das várias metodologias de arquitetura empresarial, precisamos entender quais características estão presentes em todas as tentativas fracassadas de criar arquiteturas empresariais. Quais características estão presentes em sistemas tão diversos quanto o Sistema de Gerenciamento Financeiro da Receita Federal americana, o Sistema de Gerenciamento Comercial do Departamento de Defesa, o Sistema de Gerenciamento de Desastres do Departamento de Segurança Interna, do Sistema de Arquivos de Caso Virtual do

FBI, o Sistema de Gerenciamento Comercial do McDonald's, o Sistema de Aquisição da Ford e o Sistema de Gerenciamento da Cadeia de Suprimentos da KMart?

Há apenas uma característica compartilhada por todos esses sistemas: a complexidade. Acredito que o grande ponto fraco da FEAF, da TOGAF e da Zachman é o fato de não conseguirem gerenciar a complexidade do sistema.

Infelizmente, a complexidade não é um capricho passageiro. Há três previsões que podemos fazer com certeza sobre o futuro da TI.

A complexidade só tende a piorar.

Se não encontrarmos abordagens para gerenciar a complexidade, estamos condenados ao fracasso.

As abordagens atuais não funcionam.

Deixar que as infra-estruturas e arquiteturas de TI se tornem cada vez mais complexas, sem nenhuma ação preventiva, é algo inaceitável e irresponsável. Se simplesmente colocarmos mais programadores qualificados e outras pessoas neste problema, o caos será a

ordem do dia

Até que os fornecedores e usuários de TI resolvam o problema da

... complexidade, os mesmos problemas serão repetidos e continuarão contaminando o mercado.

[Mur]

Modelando a complexidade

Para gerenciar a complexidade, devemos primeiro entendê-la. E conseguir modelar a complexidade é um grande passo para compreendê-la.

O melhor modelo que conheço para a complexidade é um dado. Esse modelo tem a vantagem de ser intuitivo, visual, previsível e matematicamente fundamentado. Vou declarar o princípio fundamental deste modelo como Lei da Complexidade de Sessions:

A complexidade de um sistema vai depender do número de estados nos quais esse sistema pode se encontrar.

Vamos usar o dado para compreender a importância desta lei. Vou comparar a complexidade de dois sistemas arbitrários, Sistema A e Sistema B, como mostrado na Figura 1. O Sistema A é composto por um único dado com duas faces (ou seja, uma "moeda"). O Sistema B é composto por um dado com seis faces (ou seja, um dado comum).

FBI, o Sistema de Gerenciamento Comercial do McDonald's, o Sistema de Aquisição da Ford e o

Figura 1. Sistema A e Sistema B

O Sistema A tem dois estados em potencial: cara e coroa. O Sistema B tem seis estados em potencial: 1, 2, 3, 4, 5 e 6. Com base na Lei de Complexidade de Sessions, o Sistema B é 6/2, ou 3 vezes mais complexo do que o Sistema A. Mesmo que não compreendamos a matemática, isso parece intuitivamente plausível.

Em geral, o número de estados de um Sistema do dado D, cada um com S lados, é SD. Com esta fórmula, podemos calcular a complexidade de outros sistemas.

Agora vamos comparar o Sistema B e o Sistema C. O Sistema B consiste em um dado de seis lados, como antes, e o Sistema C consiste em três dados de seis lados, como mostrado na Figura 2.

Em geral, o número de estados de um Sistema do dado D, cada um com S

Figura 2. Sistema B e Sistema C

O número de estados de B ainda é 61 ou 6. O número de estados de C ainda é 63 ou 216. De acordo com a Lei de Complexidade de Sessions, o Sistema C é 216/6 ou 36 vezes mais complexo do que o Sistema B.

Se você tivesse que prever um resultado específico para o lançamento do dado no Sistema C, você teria uma chance em 216 de acertar. Se você tivesse que prever um resultado específico para o lançamento do dado no Sistema B, você teria uma chance em 6 de acertar. Se você tivesse que dar palpites repetidos para os dois sistemas, você acertaria, em média, 36 vezes com mais freqüência com o Sistema B do que com o Sistema C. Como o Sistema B é menos complexo do que o Sistema C, é mais fácil de prever.

Particionamento

Com este modelo básico de complexidade, podemos ter algumas idéias sobre como os sistemas complexos podem ser mais bem organizados.

Vamos comparar dois sistemas, o Sistema C e o Sistema D, ambos formados por três dados de seis lados. No Sistema C, os dados estão todos juntos, como antes. No Sistema D, no entanto, os dados estão divididos em três partições. Esses dois sistemas são mostrados na Figura 3.

Em geral, o número de estados de um Sistema do dado D, cada um com S

Figura 3. Sistema C e Sistema D

Vamos assumir que podemos lidar com as três partições de forma independente - com efeito, três subsistemas, cada um como o Sistema B.

Já sabemos que a complexidade do Sistema C será 216. A complexidade geral do Sistema D é dada como a complexidade da primeira partição, mais a complexidade da segunda partição, mais a complexidade da terceira partição. A complexidade de cada partição

ainda é dada pela regra SD, que é 61 ou 6. A complexidade de todo o Sistema D é, portanto, 6+6+6 ou 18.

Se você não está convencido disso, imagine verificar a precisão do Sistema C e do Sistema D. Com o Sistema C, você precisaria examinar 216 estados diferentes, verificando a precisão de cada um. Com o Sistema D, você precisaria examinar 6 estados diferentes para garantir que a primeira partição esteja correta, outros 6 estados para garantir que a segunda partição esteja correta e outros 6 estados para garantir que a terceira partição esteja correta.

Em geral, a complexidade de um sistema de P partições, cada um com a complexidade de C, é CxP. Se cada partição sempre inclui um dado, então a fórmula se torna S1xD, o que se reduz a SxD.

Agora, vamos ir além dessas lições, para os sistemas particionados e não-particionados em geral. Para simplificar, vamos assumir que as partições sempre incluem um dado (como fez o Sistema D). Assim, a complexidade do sistema não-particionado (por exemplo, o Sistema C) é sempre SD, e a complexidade do sistema particionado (por exemplo, Sistema D) é sempre SxD.

Assim, a questão então se reduz a como as duas fórmulas (SxD) e (SD) podem ser comparadas. A Tabela 1 mostra valores diferentes para S, D, a fórmula particionada (SxD) e a fórmula não-particionada (SD).

Tabela 1. Complexidade particionada e complexidade não-particionada

ainda é dada pela regra SD, que é 61 ou 6. A complexidade de todo o

Usando a Tabela 1, pode-se ver o quão mais complexo é um sistema não-particionado de nove dados, em comparação a um sistema particionado que contém o mesmo número de dados. É a proporção de 10.077.696 para 52. Para os leigos, isso é muito!

Provavelmente você entendeu a Tabela 1. Quanto maior for a complexidade geral de um sistema, maior será o impacto que o particionamento tem na redução da complexidade.

Portanto, essa é a dica número um sobre como lidar com a complexidade:

particionamento.

Iteração

Depois de usarmos a divisão para reduzir a complexidade, devemos tomar outra decisão. Como analisamos a complexidade que ficou? Há duas escolhas: iterativamente (da esquerda para a direita) ou recursivamente (de cima para baixo). Você pode ver a diferença nessas duas abordagens analisando o modelo de complexidade do dado dividido, como mostrado na Figura 4.

Figura 4. Dado particionado Em uma abordagem iterativa da complexidade, analisamos cada partição individualmente. Por exemplo,

Figura 4. Dado particionado

Em uma abordagem iterativa da complexidade, analisamos cada partição individualmente. Por exemplo, primeiro analisamos totalmente a Partição 1. Depois analisamos a Partição 2. E continuamos até que todas as partições sejam analisadas.

Na abordagem recursiva da complexidade, analisamos uma camada horizontal de cada partição. Por exemplo, primeiro analisamos o caso em que saiu um em todos os dados. Depois analisamos o caso em que deu um no primeiro dado e dois nos outros. Continuamos essa análise até completarmos o último caso possível para todas as partições.

Qual abordagem é melhor? A iterativa ou a recursiva?

Para responder a essa pergunta, devemos voltar a 1950 e à curiosidade de um Coronel da Força Aérea, chamado John Boyd [Boy]. Boyd não estava interessado em construir sistemas complexos de TI. Ele provavelmente nunca tinha ouvido falar de uma arquitetura empresarial ou até de um sistema de TI. Sua preocupação era vencer as batalhas aéreas.

As batalhas aéreas são lutas individuais entre dois pilotos de combate, cada um tentando derrubar o outro antes de ser atingido. Dá para ver perfeitamente por que um Coronel da Força Aérea estava interessado em ganhar as batalhas.

Pilotar um avião de guerra em uma operação de combate é algo muito complicado. O

piloto precisa levar em consideração informações de muitas fontes diferentes, tudo enquanto o piloto inimigo está tentando abatê-lo. Dá para ter uma idéia da complexidade que os pilotos de Boyd tinham que enfrentar dando uma olhada na cabine de um avião, mostrado na Figura

5.

Figura 4. Dado particionado Em uma abordagem iterativa da complexidade, analisamos cada partição individualmente. Por exemplo,

Figura 5. Cabine de um avião

Boyd estava interessado não apenas em qualquer batalha, mas especificamente em batalhas entre MiG-15s e F-86s. Sendo ex-piloto e projetista de aeronaves completas, Boyd conhecia muito bem os dois aviões. Ele sabia que o MiG-15 era um avião melhor do que o F- 86. O MiG-15 podia ir mais alto do que o F-86; o MiG-15 podia voar mais rápido do que o F- 86; e o MiG-15 tinha uma visibilidade melhor à distância.

Havia apenas um problema em tudo isso. Embora o MiG-15 fosse considerado uma aeronave superior por Boyd e pela maioria de outros projetistas, o F-86 tinha a preferência

dos pilotos. A razão dessa preferência era simples: em batalhas individuais com MiG-15s, o F-86 vencia nove em dez batalhas.

Esse problema fascinava Boyd. Por que um avião inferior vencia consistentemente um avião superior?

Para resolver essa anomalia, Boyd precisava entender como os pilotos realmente operavam o avião nas batalhas. Boyd tinha uma vantagem aqui. Ele não era apenas piloto, mas um dos melhores combatentes da história. Ele tinha, portanto, alguns conhecimentos de primeira mão sobre o assunto.

Vamos pensar em um piloto envolvido em uma batalha aérea. Vamos chamá-lo de Pete. Boyd propôs que a batalha de Pete consistisse em quatro estágios distintos. No primeiro estágio, Pete observa o estado do mundo ao seu redor, incluindo o avião do inimigo. No segundo estágio, Pete se orienta em relação a esse estado. No terceiro estágio, planeja uma ação adequada. No quarto, Pete age.

Assim, nosso piloto primeiro observa, depois se orienta, depois planeja e por fim age. Boyd chamou essa seqüência de OOPA (observar, orientar, planejar, agir).

(Na verdade, os leitores que conhecem o trabalho de Boyd podem reconhecer que Boyd chamou essa seqüência de OODA, ou seja, observar, orientar, desenvolver, agir. No entanto, troquei o "desenvolver" por "planejar" por duas razões. Primeiro, os leitores de tecnologia vão confundir essa sigla com a sigla de projeto e análise orientados a objeto, também OODA em inglês. Segundo, lendo os trabalhos de Boyd, concluí que "planejar", como utilizado no contexto de TI, se aproxima mais do significado original de Boyd do que "desenvolver").

Mas, e aqui há um fato importante, Pete não faz isso apenas uma vez. Ele faz isso o tempo todo. Na verdade, Pete está usando essa seqüência de OOPA de forma cíclica. E, naturalmente, aqui está seu oponente. Assim, quem vencerá? Pete? Ou o anti-Pete? Se Pete estiver pilotando o F-86, sabemos que provavelmente ele vai ganhar. Mas por quê?

Pareceria que o anti-Pete pilotando o MiG-15 seria melhor usando o OOPA do que Pete. Como o anti-Pete pode ver mais, ele conseguirá enxergar melhor. Como ele pode girar e subir com mais rapidez, conseguirá reagir com mais rapidez. No entanto, o anti-Pete perde, e Pete ganha.

Boyd decidiu que o fator determinante principal para vencer batalhas não era observar, orientar, planejar ou agir melhor. O mais importante para vencer as batalhas era observar, orientar, planejar e agir mais rápido. Em outras palavras, a rapidez com que se conseguia iterar. A velocidade da iteração, sugeriu Boyd, vence a qualidade da iteração.

A próxima pergunta que Boyd se fez foi a seguinte: por que o F-86 conseguia iterar com mais rapidez? A razão, concluiu ele, era algo que ninguém tinha pensado que fosse particularmente importante. Era porque o F-86 tinha uma alavanca de vôo hidráulica e o MiG- 15 tinha uma alavanca manual.

Sem a hidráulica, era necessário um pouco mais de energia física para mover a alavanca de vôo do MiG-15 do que era preciso no F-86. Embora o MiG-15 conseguisse girar com mais rapidez (ou ir mais alto) depois que a alavanca fosse movida, a quantidade de energia necessária para mover a alavanca era levemente maior para o piloto do MiG-15.

Com cada iteração, o piloto do MiG-15 ficava um pouco mais cansado do que o piloto do F-86. E, ficando mais cansado, levava um pouco mais de tempo para completar o ciclo OOPA. O piloto do MiG-15 não perdia porque o outro era melhor. Ele perdia porque o OOPA do outro era melhor.

Vou chamar a descoberta de Boyd de Lei da Iteração de Boyd. Analisando a complexidade, uma iteração rápida quase sempre produz melhores resultados do que uma análise aprofundada.

Iteração particionada

Agora temos duas lições sobre como administrar melhor a complexidade das arquiteturas empresariais. Do estudo dos dados, sabemos que particionar a complexidade é uma das chaves para reduzir a complexidade. Do estudo dos pilotos de caça de Boyd, sabemos que a melhor maneira de analisar as divisões da complexidade é iterar nelas, e fazer essa iteração com o foco na velocidade, e não na completude.

Agora vamos ver como podemos aplicar essas duas lições a arquiteturas empresariais complexas. Pensemos em um grande sistema de gerenciamento de negócios, semelhante àquele em que o McDonald's perdeu US$ 170 milhões tentando (e não conseguindo) criar. Vou chamar esse sistema de Sistema Grande e Complexo de Gerenciamento de Negócios, ou SGCGN. Imagine que o SGCGN precise incluir a seguinte funcionalidade:

RH global Folha de pagamento Razão geral Contas a pagar Contas a receber Cobrança Ativos Contas Tesouraria Portal do funcionário

Como dividimos o SGCGN? Essa lista nos dá uma dica imediata. Não crie um mega projeto para o SGCGN. Crie uma arquitetura para o sistema RH global, um para o sistema Folha de pagamento e assim por diante. Em outras palavras, não projete um sistema complexo, grande e único. Projete vários sistemas simples e pequenos. Projete um, desenvolva-o e depois passe para o próximo. O particionamento diminui a complexidade geral. A iteração aumenta a probabilidade de sucesso.

Podemos partir do pressuposto de que os exemplos anteriores de falhas na arquitetura (por exemplo, o fracassado Sistema de Arquivos de Caso Virtual do FBI ou o malogrado BMS do McDonald's) baseavam-se todos em metodologias-padrão de arquitetura empresarial, como a FEAP, TOGAF e Zachman. Essas metodologias eram não-iterativas. Não causa surpresa, portanto, que não tenham dado certo. Também não causa surpresa o fato de essas falhas terem sido caras.

Todas as metodologias da arquitetura empresarial concordam que devem ocorrer as seguintes fases:

Projeto da arquitetura de negócios Projeto da arquitetura técnica Implementação

Teste

Implantação

As metodologias tradicionais realizam essas fases uma por vez, concluindo totalmente uma antes que a próxima seja iniciada. Isso é mostrado na Figura 6.

∑ Teste ∑ Implantação As metodologias tradicionais realizam essas fases uma por vez, concluindo totalmente uma

Figura 6. A abordagem do mega projeto

Como aparece na Figura 6, as metodologias tradicionais começam com uma arquitetura de negócios aprofundada do sistema-alvo - digamos, nosso SGCGN hipotético. Depois criamos uma arquitetura técnica. Depois implementamos. Depois começamos a testar e a depurar. Depois implantamos. Observe que só teremos valor ao negócio associado ao projeto quando for concluído o estágio final de implantação.

Essa análise também nos mostra o que as organizações deveriam ter feito. Elas deveriam ter usado a abordagem da iteração particionada.

A abordagem da iteração particionada parece um pouco diferente. A Figura 7 mostra a abordagem da iteração particionada em ação. Observe que seguimos as mesmas fases que antes, mas agora as realizam em uma base partição por partição.

Figura 7. Iteração particionada O resultado da abordagem da iteração particionada é um fluxo constante em

Figura 7. Iteração particionada

O resultado da abordagem da iteração particionada é um fluxo constante em direção à funcionalidade. Não começamos uma partição até que a anterior tenha sido concluída. Em organizações grandes e complexas, é comum ter projetos simultâneos em paralelo, mas o número deve ser mantido no mínimo possível, especialmente nas iterações iniciais. Vários projetos simultâneos vão aumentar a necessidade de coordenação.

Estruturas atuais da arquitetura empresarial

As atuais estruturas-padrão de arquitetura empresarial (incluindo a TOGAF, Zachman e FEAF) compartilham um mesmo passado. Todas foram muito influenciadas pelo mundo da análise e do OODA (Projeto e Análise Orientados a Objeto).

O fato de que essas estruturas se encontram na geração OODA é significativo, pois isso as coloca na era pré-SOA (Arquiteturas Orientadas ao Serviço). Atualmente, a maioria dos grandes sistemas se baseia na noção de interoperabilidade de aplicativos autônomos por meio de padrões de serviço da Web (tais como SOAP, WS-Security e outros). Essa noç��o está muito ligada ao mundo orientado ao serviço que não existia quando foram criadas as estruturas arquiteturais iniciais.

As tecnologias de objetivo foram projetadas para implementação de aplicativos, e não para as empresas de arquitetura. A maior desvantagem delas é sua incapacidade de administrar a complexidade.

Como observou a The Royal Academy of Engineering e a British Computer Society em um estudo de larga escala, realizado em 2004, sobre a complexidade de TI:

...

os

métodos e as práticas atuais de desenvolvimento de software não se adaptarão para

administrar sistemas globalmente distribuídos e cada vez mais complexos a um custo ou riscos para o projeto razoáveis. Assim, há um grande desafio de engenharia de software para lidar com o aumento inexorável na capacidade das tecnologias de computação e comunicações. [Roy]

Os problemas que precisam ser tratados nas grandes arquiteturas empresariais complexas têm a ver com as interações entre os aplicativos, e não com as implementações dos próprios aplicativos. A noção de que um grande sistema poderia ser composto das interações de aplicativos autônomos, o equivalente técnico das partições, é uma noção que só atingiu a maturidade muito tempo depois da era dos Objetos. Este era, na verdade, o recurso de definição da era das SOAs.

A utilização das SOAs ajuda a administrar a complexidade no nível técnico. Da mesma forma que a arquitetura de negócios deve ser particionada para reduzir a complexidade a níveis gerenciáveis, a arquitetura técnica também deve ser. As SOAs são, de longe, a melhor abordagem que temos hoje para realizar essa divisão técnica.

As estruturas OODA geralmente reivindicam o suporte a uma noção de iteração, mas é muito diferente da iteração no modelo particionado. A noção OODA de iteração realmente não tem muito a ver com iteração, pois se relaciona à recursão, como mostrado na Figura 8. Ela trata da complexidade do sistema tomando-o em porções de tamanho reduzido. Ela não reduz a complexidade do sistema: meramente diminui a quantidade de complexidade que deve ser enfrentada a qualquer momento.

Os problemas que precisam ser tratados nas grandes arquiteturas empresariais complexas têm a ver com as

Figura 8. Abordagem OODA para arquiteturas empresariais

A iteração particionada difere da abordagem OODA de duas formas importantes. Em primeiro lugar, e mais importante, ela reduz a complexidade por meio do particionamento, e não tentando gerenciá-la por meio da recursão. Mas, em segundo lugar, a iteração particionada enfatiza a velocidade da iteração à custa do planejamento exaustivo. A teoria é que aprendemos mais fazendo do que planejando. A Figura 9 mostra a abordagem da iteração particionada.

Figura 9. Abordagem da iteração particionada para arquiteturas empresariais O particionamento é uma abordagem fundamentalmente diferente

Figura 9. Abordagem da iteração particionada para arquiteturas empresariais

O particionamento é uma abordagem fundamentalmente diferente de lidar com a complexidade do sistema do que a recursão ao estilo OODA. O OODA trata da complexidade tentando separá-la em quantidades gerenciáveis. A iteração particionada ataca a complexidade de frente. Ela luta não para tornar a complexidade gerenciável (a abordagem OODA), mas para eliminar a complexidade como um todo. Ela utiliza o princípio matemático que vimos anteriormente nos estudos do dado: a redução da complexidade por meio do particionamento da funcionalidade.

Vantagens da abordagem iterativa particionada

A abordagem da iteração particionada começa a agregar valor muito antes do que a abordagem OODA recursiva. A razão para isso é que estamos entregando nosso sistema em segmentos. Na medida em que projetamos nossos segmentos verticais de forma que cada um contenha valor aos negócios mensurável, a iteração se traduz em TTV (Time-to-value) mais rápido.

No mundo dos negócios, o TTV é uma medida de valor essencial, ainda mais importante do que o ROI (Retorno sobre Investimento). O ROI é uma meta de longo prazo. Qualquer projeto, independentemente da deficiência de sua organização, do orçamento extrapolado e do mau alinhamento com as exigências dos negócios, pode alegar um bom ROI, uma vez que os custos do projeto são amortizados em um período de tempo longo o suficiente. A questão é a seguinte: será que a empresa sobrevive tempo suficiente para perceber o retorno?

O TTV é muito mais imediato. Pessoas diferentes têm definições diferentes para o TTV, mas defino o TTV como a quantidade de tempo entre a aprovação do orçamento de um projeto e o momento quando os executivos sentem que o projeto está tendo um impacto positivo nos negócios da organização. Em outras palavras, é a quantidade de tempo entre o dinheiro que sai e a percepção do valor que entra. O ROI é muito irrelevante para o TTV.

Por exemplo, suponhamos que a administração aprove um orçamento de US$ 20 milhões para reorganizar o atendimento ao cliente. Você poderia adotar a abordagem OODA recursiva, e nesse caso não haverá percepção de valor até que todo o projeto de US$ 20

milhões tenha sido concluído (se você tiver sorte). Ou você pode usar uma abordagem de iteração particionada, dividindo o projeto em partições verticais que contêm valor.

Suponhamos que o primeiro segmento seja uma biblioteca on-line de fácil acesso, com informações úteis que o cliente pode acessar. A fatia vertical pode ser entregar percepção de valor muito antes da conclusão do resto do projeto, mesmo antes de ter um ROI positivo. Se você puder mostrar, por exemplo, que, no primeiro mês, a biblioteca já tiver diminuído o tempo das ligações dos clientes ao suporte técnico em 20%, você estará mostrando valor, embora possa levar anos para mostrar um ROI positivo para o projeto geral.

Que projeto você acha que mais provavelmente será cancelado? Um projeto que está retornando um valor de alta visibilidade em alguns meses (iteração particionada) ou um projeto que retornou uma percepção de valor zero, mesmo depois de dois anos de despesas e esforços (OODA recursiva)?

Um rápido time-to-value é da maior importância para manter os projetos no topo da lista de prioridades da administração. Quem não é visto não é lembrado é uma máxima que certamente se aplica a projetos de TI.

A segunda vantagem da abordagem da iteração particionada é que ela aumenta as chances gerais de haver um projeto bem-sucedido. Isso porque você pode aplicar as lições aprendidas nas iterações anteriores aos esforços que vão ocorrer nas iterações futuras.

Voltando ao call center do cliente, vamos dizer que sua partição imediata está completando uma nova interface de usuário para o cliente, e que uma das suas iterações futuras está criando uma interface de usuário do call center. Suponhamos que você tivesse assumido que poderia completar a nova interface de usuário do cliente com seis pessoas/meses, e a nova interface do call center em oito pessoas/meses. Mas, ao concluir a nova interface de usuário do cliente, você descobre que utilizou nove pessoas/meses, em vez de seis. Obviamente, você tem um problema na estimativa do trabalho para criar interfaces de usuário.

Agora você tem a oportunidade de aprender com os erros cometidos. Vamos dizer que você tenha identificado o problema: você subestimou o tempo necessário para treinar os desenvolvedores. Ao cuidar da interface do call center, você pode se certificar de designar desenvolvedores com experiência. Se as ferramentas de desenvolvimento forem mais complicadas do que você pensa, você poderá pensar em trocar as ferramentas. Se o processo simplesmente levar mais tempo do que você pensa, será possível ajustar o cronograma restante do projeto.

O ponto importante é que, com a iteração particionada, você descobre os problemas no início, antes que se tornem excessivos em todo o projeto. E, caso não possam ser resolvidos, pelo menos podem ser reconhecidos antes que os atrasos resultantes se transformem em surpresa para a administração. A administração talvez não goste de atrasos, mas ela odeia ainda mais as surpresas.

Administrar as expectativas com eficácia é um componente essencial de quase qualquer projeto. Usando a abordagem da iteração particionada, você pode reagir com mais facilidade aos problemas em potencial e pode transmitir à equipe executiva, de forma mais eficaz, as expectativas reais.

Uma terceira vantagem da iteração particionada é que ela ocupa muito menos do tempo de sua equipe mais importante (e mais cara) e de mais alto nível. Isso ocorre porque o projeto de cada partição exige consenso apenas entre a equipe que está diretamente envolvida naquela divisão. Na abordagem OODA recursiva, a maioria da equipe está envolvida na maioria das

decisões de projeto, e aparentemente as decisões simples de projeto geralmente precisam de cuidado para serem tomadas.

Uma quarta vantagem da abordagem de iteração particionada é que seu resultado são projetos que podem ser naturalmente mapeados em uma SOA. As SOAs são compostas por pequenos serviços autônomos, e não de monstros monolíticos típicos da abordagem OODA. Esses pequenos serviços autônomos e interoperacionais são muito mais cômodos para reutilização, colaboração, interoperabilidade, agilidade e fluxo de trabalho automatizado do que suas contrapartes da OODA.

E, por fim, a iteração particionada oferece uma solução muito melhor para os recursos com problemas do que a abordagem OODA. Há três fatores que favorecem a abordagem da iteração particionada na hora de reduzir os recursos com problemas:

O número de partições é muito maior na iteração particionada do que na abordagem OODA. Isso reduz a necessidade psicológica das pessoas de sentir que uma dada partição é sua única chance de incorporar algum recurso desejado.

Menos pessoas se envolvem no projeto de qualquer uma dessas partições do que na abordagem OODA. Isso significa que, em uma determinada iteração, menos pessoas serão questionadas sobre novos recursos.

A iteração particionada enfatiza o TTV em vez do ROI, que é a criança querida da OODA. A maioria das pessoas associa o ROI positivo com a riqueza de recursos. Ao final de contas, mais recursos indicam que mais pessoas podem usar um aplicativo determinado. Quanto mais pessoas usam o aplicativo, maior será o "retorno" que o aplicativo fornecerá. Esse foco excessivo no ROI é um ímã irresistível para recursos com problemas.

O TTV, o foco da abordagem da iteração particionada, enfatiza entregas rápidas. Todos entendem a necessidade de predeterminar o tempo para obter uma entrega rápida. A predeterminação de tempo significa limitar os recursos para aqueles que são importantes e que podem ser fornecidos de acordo com um cronograma determinado. Isso se presta a um espírito organizacional que deseja dar uma olhada mais a fundo nos recursos solicitados e eliminar os que não são verdadeiramente necessários.

Como você pode ver, há uma série de grandes vantagens que uma organização pode perceber ao trocar de uma metodologia de arquitetura empresarial do tipo OODA por uma metodologia iterativa particionada. Entre elas estão:

Fornecimento mais rápido de valor aos negócios quantificável. Maior probabilidade de conclusão bem-sucedida do projeto. Mais oportunidades de aprender com sucessos e fracassos anteriores. Planos de projeto mais precisos. Melhor alinhamento com as arquiteturas técnicas orientadas ao serviço. Resistência natural a recursos com problemas.

Estas são algumas vantagens importantes que deveriam chamar o interesse de qualquer organização que esteja procurando encontrar um valor real a partir de seus esforços de arquitetura.

Regras para o sucesso

Agora que lhe dei algumas idéias sobre a teoria e a prática da abordagem da iteração de partição para as arquiteturas empresariais, vou fornecer um conjunto de regras que acho que o ajudarão a ser mais bem-sucedido com esta abordagem.

Regra 1: comece apanhando as frutas mais baixas

Depois de dar o primeiro passo e identificar seus projetos/partições, você precisa decidir de quais vai tratar primeiro. Muitos profissionais recomendam que você vá primeiro atrás dos projetos de maior risco. A lógica é que, se existirão problemas, você irá descobri-los mais cedo. Não concordo com isso.

A primeira coisa que você quer fazer na hora de desenvolver uma arquitetura empresarial é demonstrar sucesso. Isso o ajudará a perceber o momento certo para sua meta maior. Isso é especialmente verdade nas organizações que foram destruídas no passado por arquiteturas empresariais com metodologias OODA.

Assim, sua primeira e mais importante meta nas primeiras iterações é estabelecer credibilidade. A melhor maneira de estabelecer credibilidade é garantir sucessos altamente visíveis que podem ser compreendidos por todos na organização.

A Tabela 2 fornece uma visão geral dos fatores mais importantes na hora de priorizar as partições, a melhor forma de analisar cada uma e como cada uma deve influenciar a priorização geral.

Tabela 2. Fatores de priorização de partição

Agora que lhe dei algumas idéias sobre a teoria e a prática da abordagem da iteração

Uma boa maneira de priorizar as partições é usar um Alvo de prioridade, como mostrado na Figura 10. Em um Alvo de prioridade, cada eixo representa uma das

considerações de prioridade que listei na Tabela 2. Cada eixo é fornecido com as medidas positivas mais próximas do centro, e as medidas negativas mais próximas da borda.

considerações de prioridade que listei na Tabela 2. Cada eixo é fornecido com as medidas positivas

Figura 10. Alvo de prioridade

Depois de criar o Alvo de Prioridade, dê seus "tiros" em cada um dos círculos. Se, por exemplo, essa partição tiver um risco médio, coloque um círculo no eixo de risco na região amarela (neutra) do alvo. Ao terminar, você pode ver visualmente quais projetos candidatos (partições) devem ser tratados primeiro.

Por exemplo, vamos dizer que você tenha identificado dois projetos. O primeiro é desenvolver uma base de conhecimento acessível ao cliente. A segunda é criar um procedimento de conexão único para melhor segurança. Você cria as metas de prioridade para as duas partições e o resultado é o mostrado na Figura 11. Torna-se imediatamente óbvio qual dos dois projetos melhor se qualifica como "a fruta mais baixa".

considerações de prioridade que listei na Tabela 2. Cada eixo é fornecido com as medidas positivas

Figura 11. Comparando dois Alvos de prioridade Regra 2: promova a economia de pequena escala

Uma falácia comum nas arquiteturas empresariais é que você pode obter economias fazendo coisas em larga escala. A teoria diz que, se houver pessoas suficientes fazendo um projeto grande o suficiente, haverá inevitavelmente muitas redundâncias. A eliminação dessas redundâncias resulta na redução dos custos de desenvolvimento e manutenção. Quanto maior

for o projeto, mais redundâncias haverá. Quanto mais redundâncias, mais oportunidades de eliminação de redundância. Quanto mais eliminação de redundâncias, menor o custo geral do projeto.

Infelizmente, essa teoria ignora uma lei ainda mais básica de gerenciamento de projeto:

a lei da diminuição dos retornos de recursos. Quanto mais pessoas estiverem envolvidas em um projeto, menos eficiente se tornará o projeto como um todo. A lei de diminuição dos retornos de recursos é um corolário da famosa Lei de Brooks. Fred Brooks observou pela primeira vez, há cerca de 30 anos, que acrescentar mais recursos a um projeto atrasado de software só atrasa o projeto [Bro]. Por esta e outras observações, ele recebeu o Turing Prize em 1999.

Um grupo relativamente pequeno que ataca uma partição bem-definida da empresa pode fazer um trabalho razoável em um cronograma razoável. Um grupo grande que trata de uma empresa não-particionada pode encontrar redundâncias. Mas o custo de encontrar essas redundâncias, discutir a melhor forma de eliminá-la e tentar acertar um projeto para uma abordagem unificada superará em muito, em quase todos os casos, o custo das próprias redundâncias.

É verdade que as economias vêm em escala. Mas as reais economias vêm em escalas pequenas, e não grandes.

Regra 3: centralize a interoperabilidade, descentralize as implementações

Muitas organizações desenvolvem arquiteturas empresariais que são excessivamente centralizadas. Freqüentemente, elas criam um escritório de arquitetura empresarial e lhe dão autoridade sobre um grande número de decisões. Essa centralização excessiva pode resultar em uma redundância asfixiante e em uma paralisação de projetos.

Uma organização centralizada de arquitetura empresarial faz-se necessária. Mas a organização central precisa se focar nas questões certas, e não ficar presa em questões que são irrelevantes.

A regra básica geral é que as decisões que causam impacto na interoperabilidade devem ser centralizadas. As decisões que causam impacto nas implementações devem ser descentralizadas. Não saber qual decisão é que é um erro comum nos departamentos de arquitetura empresarial.

Vamos dar uma olhada nos erros típicos que surgem nas arquiteturas empresariais:

Plataforma - Muitas organizações tentam definir uma plataforma-padrão de software, em geral em um debate interminável sobre, digamos, o Microsoft .NET, o WebSphere da IBM ou o WebLogic da BEA. Esse esforço é dispensado no lugar errado. A plataforma é uma decisão de implementação, mas não tem relação com a forma como as aplicações nessas plataformas vão funcionar juntas. Na medida em que a plataforma atende às exigências de interoperabilidade da organização, a equipe do aplicativo deve ter liberdade para escolher a melhor plataforma para as necessidades do aplicativo.

Dados - Muitas organizações tentam definir uma camada única de dados que será compartilhada por todos os aplicativos nas organizações. Esse esforço é geralmente caro e raramente bem-sucedido. A forma como os dados são armazenados deve ser tratada como um detalhe da implementação de um aplicativo.

Business Intelligence - A maioria das organizações trata os dados e a Business Intelligence de forma intercambiável. Ao passo que os dados (por exemplo, como um

cliente é armazenado no banco de dados) são um detalhe da implementação, e a inteligência (por exemplo, que negócio realizamos com um determinado cliente) é um ativo organizacional. É apropriado decidir como essa inteligência será compartilhada. Não é apropriado decidir (no nível da empresa) como os aplicativos vão manter o controle dos dados que alimentam essa inteligência.

Compartilhamento de código - Muitas organizações acreditam que a reutilização é obtida por meio do compartilhamento de código. É por vezes surpreendente que essa crença persista, apesar das décadas de fracassos para obter esse resultado. A melhor maneira de reduzir a quantidade de código de que um determinado projeto precisa é por meio da delegação da funcionalidade (como no caso dos serviços da Web), e não por meio do compartilhamento de código.

APIs do serviço da Web - Muitas organizações acreditam, corretamente, que a utilização dos serviços da Web é essencial para obter interoperabilidade. Muitas organizações pensam que isso significa que a forma como os aplicativos usam as APIs do serviço da Web deve ser padronizada. Na realidade, as APIs do serviço da Web estão muito abaixo do nível de interesse dos aplicativos. Em geral, os aplicativos usam uma camada de buffer que é específica ao fornecedor - por exemplo, a camada Windows Communications Framework fornecida pela plataforma Microsoft .NET. O objetivo dessa camada é dispensar os aplicativos da necessidade de entender as confusões das APIs de serviço da Web. A camada de buffer é específica à plataforma e, portanto, faz parte dos detalhes de implementação do aplicativo.

O resultado é que a arquitetura empresarial não é igual à arquitetura de aplicativo. A arquitetura de aplicativo tem a ver com o projeto dos aplicativos. Esses projetos devem ser de responsabilidade do grupo que tem os aplicativos. Esta é uma das maneiras de obter economias de pequena escala (consulte a Regra 2: promova economia de pequena escala). Os arquitetos empresariais devem se preocupar com a forma como os aplicativos funcionam e, portanto, fornecer um melhor valor para a organização.

Conclusão

A arquitetura empresarial pode ser um recurso importante na hora de ajudar uma organização a encontrar melhores maneiras de usar a tecnologia para apoiar seus processos de negócios críticos. Infelizmente, muitas organizações gastam quantias enormes tentando criar arquiteturas empresariais, apenas para obter um valor limitado, ou mesmo negativo, com o esforço. Tanto no setor público quanto no privado, são comuns falhas que custam muitas centenas de milhares de dólares.

Há três razões principais para essas falhas onerosas. A primeira é uma confiança exagerada em metodologias recursivas de arquitetura do tipo OODA (Projeto e Análise Orientados a Objeto). A segunda é a falsa noção de que criar uma arquitetura empresarial significa o desenvolvimento de um esboço detalhado de toda a organização. E a terceira é a incapacidade de dividir estruturas complexas em projetos menores e mais gerenciáveis.

As metodologias OODA, como todas as abordagens recursivas, têm a capacidade limitada de gerenciar a complexidade. A complexidade é o principal desafio enfrentado nas organizações altamente voláteis de hoje.

Este artigo propõe uma abordagem diferente para desenvolver arquiteturas empresariais. A abordagem se baseia no particionamento vertical dos processos de uma organização, priorizando a necessidade de melhorar esses processos e depois fazê-los passar por iteração, com o foco no TTV. Essa abordagem é descrita como iteração particionada. Ao contrário das metodologias recursivas, a iteração particionada ataca a complexidade de cabeça erguida.

Este documento descreve três regras para o sucesso em uma estratégia de iteração particionada. São as seguintes:

  • 1. Comece apanhando as frutas mais baixas, focando-se em um time-to-

value rápido.

  • 2. Promova economia de pequena escala, focando-se em processos ágeis.

  • 3. Centralize a interoperabilidade e descentralize a implementação,

focando-se na redução da complexidade, por meio do particionamento, e na iteração

mais rápida por meio da agilidade.

As abordagens à arquitetura empresarial, baseadas na iteração particionada, têm uma série de vantagens em relação às abordagens baseadas na recursão. Entre elas estão:

Melhor utilização da tecnologia para resolver problemas de negócios urgentes. Reduções drásticas no custo do desenvolvimento de sistemas complexos. Fornecimento mais rápido de projetos técnicos de alto valor aos negócios. Melhor controle dos custos gerais do sistema. Maior precisão na previsão das datas de entrega. Probabilidade muito maior de sucesso geral no sistema.

A iteração particionada é a abordagem mais econômica que temos para descrever as metas de uma organização, como essas metas são percebidas pelos processos de negócios e como esses processos podem ser mais bem atendidos por meio da tecnologia.

Em outras palavras, a iteração particionada fornece soluções técnicas de alto valor aos negócios o mais rápido possível, e ao menor custo possível. Alto valor. Tempo mínimo. Custo mais baixo. Este é o resultado.

Glossário

.NET - Termo guarda-chuva para a família Microsoft de produtos que inclui a infra-estrutura de serviços da Web da empresa.

Agilidade - Medida da capacidade de uma entidade (por exemplo, de uma empresa) para responder rapidamente às condições ambientais em mudança.

Lei de Iteração de Boyd - Analisando a complexidade, uma iteração rápida quase sempre produz melhores resultados do que uma análise aprofundada. Seu nome se deve ao Cel. John Boyd.

Lei de Brook - Adicionar recursos extras a um projeto com atraso só faz o projeto se atrasar. Atribuída a Frederick Brooks.

Lei Clinger/Cohen - Consulte Information Technology Mangement Reform Act.

Colaboração - O processo pelo qual dois aplicativos em empresas diferentes conseguem funcionar juntos em termos programáticos, em contraste com interoperabilidade.

arquitetura empresarial - Descrição das metas de uma organização, como essas metas são percebidas pelos processos de negócios e como esses processos podem ser mais bem atendidos por meio da tecnologia.

Estrutura de arquitetura empresarial - Metodologia para criar uma arquitetura empresarial. FEAF - Consulte Estrutura Federal para Arquitetura Empresarial.

Estrutura Federal para Arquitetura Empresarial (FEAF) - Estrutura de arquitetura empresarial usada pelo governo norte-americano para descrever como as várias agências governamentais e seus sistemas de TI se relacionam uns com os outros.

FEMA - A Federal Emergency Management Agency, braço do governo americano responsável por responder aos desastres.

GAO - Consulte Escritório Geral de Contabilidade.

Escritório de Contabilidade Geral - Órgão do governo americano responsável por monitorar a eficácia das diferentes organizações no governo.

Information Technology Management Reform Act - Lei aprovada pelo congresso americano em 1996 que exige que todas as organizações utilizem estratégias e estruturas eficazes para desenvolver e manter os recursos de TI.

Interoperabilidade - Processo pelo qual dois ou mais aplicativos na mesma empresa podem funcionar juntos em nível programático. Em contraste com colaboração.

TI - Tecnologia da informação.

Iteração - Qualquer processo que trata do todo como uma série de partes menores, de tamanhos pequenos.

Arquitetura iterativa - Abordagem aos sistemas de arquitetura que projeta, desenvolve e implanta sistemas grandes e complexos em estágios.

Processo iterativo - Abordagem ao desenvolvimento ágil de softwares no qual o desenvolvimento de software passa por iterações rápidas de projeto, implementação e reavaliação, resultando (alega-se) em sistemas que estão mais alinhados com as condições comerciais que se modificam. Em contraste com processo cascata.

ITMRA - Consulte Information Technology Management Reform Act.

Lei da Complexidade - A complexidade de um sistema relaciona-se ao número de estados nos quais esse sistema pode se encontrar. Geralmente usada para comparar a complexidade de duas abordagens diferentes para desenvolver um sistema.

Fruta mais baixa - Termo que descreve um subconjunto de escolhas que fornecem a percepção de valor máximo para o custo calculado mínimo.

Projeto e análise orientados a objeto - Estrutura arquitetural que se baseia na decomposição recursiva orientada a objeto.

OODA - Consulte Projeto e análise orientados a objeto.

OOPA - Observar, orientar, planejar, agir. Processo seqüencial proposto pelo Cel. John Boyd em relação aos pilotos de combate, embora ele tenha descrito a seqüência como observar, orientar, desenvolver, agir. Na descrição de Boyd, essa seqüência de observar, orientar, planejar e agir é feita iterativamente, e a entidade que conseguir iterar com mais rapidez supera a entidade que iterar de forma mais completa.

Iteração particionada - Abordagem para desenvolver uma arquitetura empresarial, na qual a empresa é particionada em uma série de segmentos verticais autônomos, depois analisada iterativamente e, por fim, quando apropriado, aprimorada por meio do uso de processos de negócios e técnicos melhores.

Alvo de prioridade - Representação visual de um objetivo proposto como meta, com linhas que saem do centro do alvo representando fatores de priorização, e "tiros" junto de cada eixo mostrando a importância relativa daqueles fatores para esse objetivo. Os tiros são

colocados em cada círculo, com a proximidade ao centro do alvo indicando a força da influência positiva.

RUP (Rational Unified Process - Processo para desenvolver software que é a base para a suíte de ferramentas da IBM/Rational.

Recursiva - Em análise, um processo pelo qual um sistema é analisado como sendo composto por múltiplos subsistemas; cada um deles é analisado como sendo composto por múltiplos subsistemas, e assim por diante, até que um conjunto de sistemas terminais seja identificado, não podendo mais ser logicamente divididos.

Redundância - Sobreposição na funcionalidade entre vários sistemas.

Retorno sobre investimento - Medida (em percentagem) do valor aos negócios de um projeto, com base no aumento dos lucros (por causa de um rendimento maior ou de gastos menores) dividido pelo custo do projeto. Por exemplo, um projeto com um custo de US$ 100.000 que devolve US$ 200.000 em lucro tem um ROI de 200%.

ROI - Consulte Retorno sobre investimento. SOA - Consulte Arquitetura orientada ao serviço.

Lei Sarbanes-Oxley - Lei aprovada pelo congresso americano em 2002 para impedir atividades fiscais fraudulentas por parte das organizações. A lei exige uma rígida auditoria dos dados financeiros e a responsabilização pessoal por parte dos oficiais financeiros caso haja problemas na realização da auditoria.

Serviço - Consulte Serviço da Web.

Arquitetura orientada ao serviço - Arquitetura de interoperabilidade entre sistemas autônomos e desenvolvidos com base em tecnologias de serviço da Web.

SOX - Consulte Lei Sarbanes-Oxley. TAFIM (Technical Architecture Framework for Information Management) - Estrutura

arquitetural desenvolvida pelo Departamento de Defesa e oficialmente descontinuada em

2000.

Predeterminação de tempo - Utilização rigorosa de ciclos de entrega geralmente curtos para diminuir a tentação de acrescentar constantemente novos recursos a um sistema.

Time-to-value - Delta entre a aprovação do orçamento de um projeto e o momento em que os executivos sentem que o projeto está tendo um impacto positivo sobre os negócios da organização.

TOGAF (The Open Group Architectural Framework) 8.1 - Estrutura arquitetural controlada pela The Open Group.

TTV - Consulte Time-to-value.

Serviço da Web - Sistema autônomo de software que pode responder a solicitações de outros sistemas independentes de software por meio de um formato de mensagem e um protocolo de transporte não-proprietários. Em geral, o formato de mensagem é SOAP.

Fluxo de trabalho - O fluxo de trabalho em uma organização, enquanto a tarefa de alto risco é concluída (por exemplo, processar uma reivindicação de seguro).

Estrutura Zachman para arquiteturas empresariais - Estrutura arquitetural na qual a empresa é modelada como 30 células, cada uma delas representando uma interseção entre uma perspectiva e uma abstração.

Referências

Arm - A big-picture look at arquiteturas empresariais by Armour, F.J.; Kaisler, S.H.; Liu, S.Y. in IT Professional Volume 1, Edição 1, jan/fev de 1999 Páginas:35-42. Bro - The Mythical Man-Month; Essays on Software Engineering by Frederick Phillips Brooks. Addison-Wesley, edição de 20º aniversário publicada em 1995. Boy - Para ter uma boa introdução do trabalho do John Boyd, consulte Genghis John in Proceedings of the U. S. Naval Institute julho de 1997, pp. 42-47 By Franklin C. Spinney.

Car - Does Not Compute by Nicholas G. Carr, New York Times, 22 de janeiro de 2006. Cha - Why Software Fails by Robert N. Charette in IEEE Spectrum setembro de 2005. Cli - Information Technology Management Reform Act, do Centésimo Quarto Congresso dos Estados Unidos, Segunda Sessão. CMU - Carnegie Mellon University, www.sei.cmu.edu/architecture/glossary.html. Gov - Esta citação está disponível em muitos lugares - por exemplo,

Fea - A FEAF é descrita em muitos lugares - por exemplo, A Practical Guide to Federal arquitetura empresarial, disponível em http://www.gao.gov/bestpractices/bpeaguide.pdf. GAO1 - Relatório do GAO para o Secretário do Tesouro, novembro de 2004 FINANCIAL AUDIT IRS's Fiscal Years 2004 and 2003 Financial Statements. GAO2 - Testemunho ante o Sob comitê sobre Administração, Finanças e Contabilidade do Governo, Comitê sobre Reforma Governamental, House of Representatives; DOD BUSINESS TRANSFORMATION - Sustained Leadership Needed to Address Long-standing Financial and Business Management Problems (junho de 2005). GAO3 - Relatório do GAO para o Subcomitê sobre Tecnologia, Política de Informações, Relações Intergovernamentais e Censo, Comitê sobre Reforma Governamental, House of Representatives Agosto de 2004 HOMELAND SECURITY Efforts Under Way to Develop arquitetura empresarial, but Much Work Remains. For - Oops! Ford and Oracle mega-software project crumbles by Patricia Keefe in ADTMag, 11 de novembro de 2004. Kma - Code Blue by David F. Carr and Edward Cone in Baseline, novembro/dezembro de

2001.

Mac - McDonald's: McBusted by Larry Barrett and Sean Gallagher in Baseline, 2 de julho de

2003.

Mur - Managing Complexity in IT, Part 1: The Problem by Richard Murch in InformIT, 1º de

outubro de 2004. Roy - The Challenges of Complex IT Projects: relatório de um grupo de trabalho da The Royal Academy of Engineering and The British Computer Society, abril de 2004. TAF - Departamento de Defesa dos EUA. Technical Architecture Framework For Information Management (TAFIM) Volumes 1-8, Versão 2.0. Reston, VA: DISA Center for Architecture, 1994. TOG - TOGAF (The Open Group Architectural Framework) Version 8.1 "Enterprise Edition" disponível em http://www.opengroup.org/. Wiki - Wikipedia, http://en.wikipedia.org/wiki/Enterprise_architecture. Zac - A framework for information systems architecture, by J.A. Zachman in The IBM Systems Journal, 1987, volume 26, número 3, páginas 276-292.

Sobre o autor

Roger Sessions é CTO da ObjectWatch Inc. e autor de seis livros e dezenas de artigos e documentos. Ele faz parte do Conselho de Administração da Associação Internacional de Arquitetos de Software (http://www.iasahome.org/). Freqüentemente, Roger dá palestras em eventos em todo o mundo, realizando seminários e treinamento destinados à comunidade de

arquitetos. Roger escreve um boletim mensal especificamente para arquitetos empresariais e gerentes de TI chamado ATA (Architect Technology Advisory). A ObjectWatch é especializada em ajudar as organizações de todos os portes a perceber o máximo valor possível das arquiteturas empresariais por meio de consultorias e treinamentos. No endereço http://www.objectwatch.com/, há mais informações sobre Roger Sessions e a ObjectWatch.