Por Charlie Alfred

Introdução

Os sistemas existem para gerar valor para os seus investidores. Infelizmente, às vezes esse ideal é atendido em um grau apenas limitado. Os métodos de desenvolvimento atuais, como cascata, espiral e ágil, freqüentemente fornecem uma orientação incompleta e inadequada para investidores, arquitetos e desenvolvedores.

Este artigo introduz dois conceitos essenciais: modelos de valor e estratégia de arquitetura, que estão faltando em muitos processos de desenvolvimento

A criação de modelos de valor bem definidos fornece uma direção que aprimora a qualidade das decisões de balanceamento (trade-off), particularmente em sistemas que são implantados para muitos usuários em diversos ambientes. A existência de uma estratégia de arquitetura claramente estabelecida fornece uma orientação coerente de alto nível para o sistema, da mesma maneira como a Constituição dos EUA faz para a sua nação. Finalmente, este ensaio irá mostrar como esses dois conceitos podem ser integrados de forma eficaz com os métodos de cascata, espiral ou ágil.

Requisitos são bússolas ineficientes

As nossas maneiras atuais de construir sistemas complexos com uso intensivo de software são ineficientes. Não é a mesma coisa que dizer que são inadequadas. Muitos sistemas construídos com os métodos de cascata e espiral ou ágil são implantados com êxito e são capazes de satisfazer seus investidores. No entanto, muitos não são, e por razões que podem ser corrigidas.

Os processos tradicionais de construção de sistemas com uso intensivo de software, como os métodos de cascata e espiral, dependem de requisitos para fornecer a direção. Uma concepção errada comum é que os requisitos são instruções que descrevem o problema. De acordo com Greenfield e Short [1], não são. Eles definem a solução da perspectiva dos usuários e do patrocinador do sistema.

Os requisitos possuem algumas desvantagens notáveis:

• Os requisitos normalmente usam uma estrutura binária. Eles funcionam como passar/ser reprovado de ano em um curso de faculdade e oferecem pouca ajuda ao se tomar decisões de balanceamento. Naturalmente, essas decisões devem ser tomadas em algum ponto do processo. Geralmente elas são tomadas de forma implícita e sem consideração plena das implicações.

• Os requisitos geralmente são usados como base para especificar critérios testáveis de aceitação de um sistema. No processo de torná-los específicos, importantes decisões de design são tomadas de forma implícita, sem considerações plenas das implicações. Em algum momento no futuro essas decisões precisarão ser revertidas a um custo significativo ou terminam limitando o potencial do sistema.

• Os requisitos tendem a tratar da mesma maneira todos os indivíduos de um tipo de usuário determinado. Por exemplo, os cenários de casos de uso de um sistema médico poderão referir-se a médicos e enfermeiras, enquanto os de um sistema imobiliário poderão referir-se a comprador, vendedor, agente e financiador. O problema é que dois médicos não são iguais e não se satisfazem necessariamente com as mesmas coisas. Existe uma boa razão para os restaurantes populares possuírem muitos itens no cardápio.

• As informações necessárias para a tomada de decisões efetivas sobre arquitetura de software geralmente não são mencionadas. Todos os sistemas são implantados em ambientes que colocam obstáculos significativos em seu caminho. Superar esses obstáculos é responsabilidade de todo sistema e alcançar o sucesso apesar deles é a marca de um sistema eficiente. No entanto, a menos que os desenvolvedores possuam um entendimento extremamente profundo do domínio do problema, eles não terão acumulado a perspicácia para fazer bons julgamentos. Ao mesmo tempo, os usuários influentes e os patrocinadores do sistema geralmente possuem essa experiência, mas geralmente não têm o

Tabela 1. Serviços, funcionalidades e recursos característicos que os dispositivos podem suportar

Aspecto	Mecanismo	Exemplo
Fornecer recursos úteis	Fornecer uma nova capacidade significativa	Given Imaging, Inc. desenvolveu uma cápsula de 11x26 mm que envolve uma câmara digital que pode passar através do trato gastrintestinal superior do paciente e capturar imagens.
	Melhorar a qualidade das capacidades existentes	A CPU Pentium 4 da Intel usa uma regra de projeto de 90 mm (reduzida de 130mm) e pode realizar 13 bilhões de instruções por segundo.
Superar obstáculos	Tratar os fatores limitantes	Muitos fundos mútuos e portfólios gerenciados de forma privada estão obrigados a enfrentar restrições de investimento. Os sistemas de conformidade pré-transação analisam as transações propostas para verificar que o portfólio continue estando em conformidade.
	Identificar e atenuar riscos	Um sistema de detecção de alterações na direção do vento em um avião comercial detecta a presença de microexplosões que poderiam comprometer um avião no processo de aterrissagem em queda.
Lidar com a mudança	Explorar oportunidades	A eBay reconheceu que a população em rápido crescimento de consumidores com acesso à Internet criou uma oportunidade para fornecer uma capacidade de leilão eletrônico.
	Adaptar-se rapidamente às novas condições	Eastman Kodak reconheceu a virada de tecnologia que habilitou a fotografia digital e conseguiu uma penetração de mercado nesse segmento para compensar as quedas nas vendas de filmes. A Polaroid não teve tanto sucesso com isso.

Métodos ágeis como EXTREME PROGRAMMING e SCRUM fazem uma abordagem ligeiramente diferente. Esses métodos enfatizam algumas alterações úteis, como colaboração íntima entre investidores e desenvolvedores, e iterações de projeto bastante curtas para obter feedback contínuo. A teoria é que a interação entre investidores e desenvolvedores é um mecanismo mais confiável para a navegação do projeto do que um grande investimento inicial em requisitos escritos.

Além disso, os métodos ágeis tendem a favorecer abordagens mais orgânicas e reativas (refactoring) aos que possuem orientação mais determinada (arquitetura). Os proponentes de métodos ágeis falam de deixar a arquitetura de um sistema evoluir. Em algumas situações essa abordagem pode ser eficaz. Um exemplo é quando as necessidades do usuário ou as condições competitivas mudam rapidamente. No entanto, há muitos casos em que essa abordagem pode ser arriscada. Um em particular é quando um produto deve ser desenvolvido para executar em muitos ambientes diferentes e/ou satisfazer investidores com diferentes necessidades e prioridades.

O maior problema com as abordagens cascata, espiral e ágil é que o desenvolvimento do software geralmente se dá sem algumas informações bastante críticas e sem as ferramentas necessárias para reuni-las. Um barco apto para navegar, um rádio que funcione e um conjunto completo de velas são todos necessários, mas não necessariamente o suficiente. Um marinheiro experiente nem pensaria em deixar o porto sem um bom conjunto de mapas náuticos, uma previsão meteorológica de longo alcance e uma maneira confiável de rastrear a localização do barco.

Este ensaio irá discutir dois processos: modelagem de valor e estratégia de arquitetura. Ele mostrará como será o uso eficiente dessas técnicas:

• Capturar informações essenciais sobre o domínio do problema que permita aos usuários e desenvolvedores fazer balanceamentos eficientes.

• Permitir que obstáculos significativos ao êxito sejam identificados e priorizados.

• Permitir que a estratégia de arquitetura seja expressa de uma maneira clara e concisa que possa ser entendida por todos os investidores.

Visão geral do modelo de valor

Sistemas com finalidade determinada são desenvolvidos para criar valor para seus investidores. Na maioria dos casos esse valor é percebido como benéfico porque esses investidores desempenham funções importantes em outros sistemas. Por sua vez, esses outros sistemas existem para criar valor para seus investidores. Essa qualidade recorrente dos sistemas é uma chave na análise e entendimento dos fluxos de valor. A próxima seção (Descobrindo modelos de valor) discute esse ponto com maior profundidade.

A tabela na página anterior apresenta três aspectos vitais de um sistema intencional. São descritos dois mecanismos para alcançar cada aspecto e um exemplo do mundo real é fornecido para cada mecanismo.

Esses três aspectos estão no âmago de um modelo de valor. Para identificá-los e trabalhar com eles de forma mais fácil, precisamos reduzir cada um a uma forma elementar.

A Expectativa de valor expressa a necessidade de um recurso específico, incluindo o que é fornecido (capacidades), como eles são fornecidos (atributos de qualidade) e como diversos níveis de qualidade são benéficos (função de utilidade). Por exemplo, um motorista pode ter uma expectativa de valor da rapidez e segurança com que o veículo pode parar em uma velocidade de 90 quilômetros por hora.

A Força de oposição representa alguma força natural ou imposta no ambiente em que um sistema é implantado, que torna satisfatória uma expectativa de valor bem mais difícil. Por exemplo, a eficiência com que um carro pode parar a 90 quilômetros por hora depende do tipo de superfície (asfalto versus cascalho), da inclinação (subida ou descida), das condições (seco, molhado, gelo) e do peso do veículo.

O Catalisador de mudança representa alguma força ou evento no ambiente que faz com que as expectativas mudem ou que os fatores limitantes tenham um impacto diferente. Por exemplo, a diminuição no custo dos chips de memória e o aumento da densidade de armazenamento tornaram-se um catalisador da fotografia digital.

No restante deste ensaio iremos nos referir às forças de oposição e aos catalisadores de mudança como fatores limitantes e aos três coletivamente como condutores de valor.

Para um sistema ser eficiente ao satisfazer os modelos de valor de seus investidores, precisa ser capaz de identificá-los e analisá-los. As abordagens tradicionais, como cenários de casos de uso ou requisitos comerciais/de marketing começam focalizando os tipos de atores com que o sistema interage. Essa abordagem apresenta várias limitações importantes:

• Concentra-se mais em que coisas os atores fazem e menos em por que elas são feitas.

• Tende a estereotipar os atores em categorias, em que todos os indivíduos de um tipo são essencialmente iguais (comerciantes, gerentes de portfólio ou administradores de sistema, por exemplo).

• Tende a ignorar diferenças nos fatores limitantes (por exemplo: Um investidor em Nova York é o mesmo que um investidor em Londres? Negociar no mercado aberto é o mesmo que negociar durante o dia?).

• Baseia-se em resultados binários: o requisito é atendido ou não. O caso de uso é concluído com êxito ou não.

Existe uma razão bastante lógica e prática de por que essa abordagem é popular. Ela usa um raciocínio seqüencial e baseado em classificação, de modo que é fácil de ensinar e explicar e pode produzir um conjunto de objetivos fáceis de verificar. Naturalmente, se simplicidade fosse o único objetivo que contasse, ainda estaríamos caminhando ou cavalgando para ir de um lugar a outro.

Descobrindo modelos de valor

Em seu livro Competitive Advantage, Michael Porter [7] discute o conceito de cadeias de valores no contexto do planejamento estratégico corporativo:

"Embora as atividades de valor sejam os blocos de construção da vantagem competitiva, a cadeia de valores não é uma coleção de atividades independentes, mas um sistema de atividades interdependentes. Vinculações são os relacionamentos entre a maneira como uma atividade de valor é realizada e o custo ou desempenho de uma outra.

As vinculações existem não apenas dentro da cadeia de valores de uma empresa (vinculações horizontais), mas entre a cadeia de valores da empresa e as cadeias de valores dos fornecedores e canais (vinculações verticais). A maneira como as atividades desse fornecedor ou canal são realizadas afeta o custo ou desempenho das atividades de uma empresa (e vice-versa)."

Se pensarmos em uma empresa (ou uma cadeia de suprimentos) como um sistema e em cada a atividade de valor principal (compra, recebimento, fabricação etc.) como um subsistema, poderemos generalizar a noção de cadeias de valores e vinculações:

• Cada entidade (atividade de valor) possui seu próprio modelo de valor para representar suas expectativas de valor e fatores limitantes.

• Cada vinculação descreve como o modelo de valor de uma entidade se encaixa ao modelo de valor da entidade com a qual está vinculada.

• Cada vinculação entre duas entidades no mesmo sistema é o que Porter denomina de vinculação horizontal. Cada vinculação entre entidades de sistemas diferentes é uma vinculação vertical.

Porter também se refere ao conceito de diferenciação, em que duas entidades que realizam o mesmo conjunto de atividades de valor comportam-se de forma diferente. Um exemplo simples pode ser um táxi versus um ônibus urbano. Embora ambos forneçam transporte terrestre, esses dois contextos possuem recursos diferentes. O ônibus é relativamente barato e segue uma rota e um horário predeterminados. O táxi está disponível sob demanda (exceto quando você realmente precisa dele), opera ponto a ponto, é mais caro e pode conter um número limitado de passageiros. Quando está chovendo, o custo extra de um táxi pode não importar muito.

Questão de Equilíbrio

No restante deste ensaio usaremos o termo agrupamento de valores para nos referimos a uma entidade abstrata que realiza um tipo geral de atividade de valor. Contexto de valor será usado para nos referimos a uma forma especializada de agrupamento de valores que possua diferenças significativas em expectativas de valores, forças de oposição ou catalisadores de mudança em relação a outros contextos do mesmo agrupamento.

Tanto os agrupamentos de valores quanto os contextos de valor possuem seus próprios modelos de valor. O modelo de valor de um agrupamento representa os aspectos comuns de todos os contextos que especializam esse agrupamento. Cada contexto de valor especializa o modelo de valor do seu agrupamento. O conjunto dos modelos de valor de todos os contextos de um agrupamento fornece uma percepção importante das diferenças entre o que cada um espera e como é afetado pelo seu ambiente.

Por que isso é importante? A arquitetura de um sistema deve realizar um ato de equilíbrio delicado envolvendo seus condutores de valores.

Todos os cenários de implantação possuem expectativas de valor e fatores limitantes equivalentes. Provadores de vinho e pilhas AA são bons exemplos de sistemas de contexto único. Outros exemplos são editores de texto simples, analisadores de diferenças de arquivos e muitos outros utilitários de computador. Em um sistema de contexto único ainda é possível haver interdependência e conflitos entre combinações de expectativas de valores e fatores limitantes.

Porém, fica mais desafiador. A maioria dos sistemas complexos possui vários contextos. Em outras palavras, ao se considerar diferentes ambientes de implantação, eles possuem variações significativas nas expectativas de valores, forças de oposição e catalisadores de mudança. À medida que o número de contextos aumenta ou seu grau de compatibilidade diminui, fica muito mais difícil satisfazer todos eles com uma arquitetura única. Embora haja várias técnicas para tratar dessa situação, a primeira etapa é reconhecer quando se está diante dela.

Muitos sistemas possuem apenas alguns contextos. Isso ocorre com maior freqüência com sistemas que são implantados para uso interno em uma organização. Ambientes de implantação diferentes podem possuir fatores limitantes diferentes. Por exemplo, um sistema para despachar manipuladores de bagagem aérea é afetado por extremos climáticos ou um sistema internacional é afetado por regulamentos locais. Outras vezes, os ambientes de implantação possuem expectativas de valores diferentes. Isso é particularmente verdadeiro quando existem diferenças culturais ou internacionais. As enfermeiras que operam máquinas de hemodiálise para pacientes com problemas renais crônicos em um hospital patrocinado pelo governo na Europa irão ter necessidades e prioridades diferentes das enfermeiras que realizam a mesma tarefa em pequenas clínicas particulares nos EUA (onde empresas de seguro privado pagam os tratamentos).

Muitos outros sistemas possuem um grande número de contextos. Eles ocorrem com mais freqüência em produtos centrados em tecnologia, desenvolvidos para venda ou arrendamento a um conjunto amplo de clientes. As mesmas condições que causam variação em sistemas de contexto pequeno, ocorrem em alto grau devido a:

• O número de contextos de implantação pode ser milhares ou milhões de vezes maior,

• As organizações (ou sistemas) dos quais os financiadores participam podem ter conjuntos de expectativas de valores muito diferentes e

• Os catalisadores que acionam mudanças significativas em cada ambiente de implantação provavelmente são muito diferentes.

Em resumo, um modelo de valor captura os condutores que determinam a satisfação de um segmento de mercado específico e como será difícil satisfazê-los.

Curvas de Utilidade

A seção anterior fez referência a um conceito importante chamado curva de utilidade. De modo muito simples, uma curva de utilidade é um mapeamento de uma escala de medição para uma segunda. A primeira escala representa uma variável de resultado que pode ser quantificada. A segunda escala é o nível de valor (satisfação, utilidade) que é gerado. O exemplo mais comum de uma curva de utilidade é a usada para mapear os resultados de provas em notas para exames de colegial ou da faculdade. Como iremos mostrar, um bom entendimento das curvas de utilidade é absolutamente essencial para tomar decisões de balanceamento eficientes.

A Figura 2 ilustra um exemplo simples. A primeira escala representa a economia de combustível combinada na cidade e na estrada para um veículo segundo a Agência de Proteção Ambiental. A segunda escala representa 5 valores qualitativos:

Pior: O requisito mínimo aceitável. Pouco ou nenhum valor é perdido com resultados abaixo desse nível.

Adequado: Esse nível representa um resultado abaixo da média, desapontador mas aceitável.

Satisfatório: Esse é o resultado esperado: nem melhor, nem pior.

Preferível: Esse nível representa um resultado acima da média, satisfatório e compensador, mas não muito acima do comum.

Melhor: O melhor resultado esperado. Pouco ou nenhum valor é ganho com resultados que excedem esse nível.

A figura mostra três curvas de utilidade distintas. Há muitos outros formatos possíveis; esses representam os três mais comuns. A primeira curva é linear, a segunda tem um formato de curva em S e a terceira é uma parábola. Todas as três possuem os mesmos valores exatos pior e melhor. O que é interessante observar são os valores intermediários. Um aumento de 10 a 20 km por litro produz 10% do valor disponível para a curva em S, mas 60% para a parábola.

Em um sistema de contexto único, o uso de curvas de utilidade para analisar estratégias de arquitetura é direto. O método de análise de decisão descrito por Kepner e Tregoe [2] pode ser usado para essa finalidade. Cada alternativa é avaliada em relação a cada expectativa de valor. As curvas de utilidade são usadas para mapear o valor da medida quantitativa obtida por cada alternativa para o seu valor correspondente. Em seguida, os níveis de valor são ponderados pela prioridade da expectativa e totalizados. As alternativas mais preferíveis possuem totais mais altos.

O aspecto mais desafiador desse método é escolher um mecanismo apropriado para avaliar cada alternativa em relação a cada meta desejada. O melhor cenário é quando o mecanismo fornece uma medição objetiva (como medir o consumo ou a potência de um motor de automóvel). Em alguns casos o mecanismo pode ser subjetivo. O custo de produzir uma medição objetiva apropriada deve ser equilibrado pela precisão e objetividade extra obtidas. Em algumas situações, uma avaliação inicial pode ser feita com avaliações subjetivas. Se os resultados forem próximos, medições objetivas podem ser feitas para se escolher entre as melhores alternativas.

Desafios da Arquitetura

Um desafio da arquitetura é uma situação em que um ou mais fatores limitantes tornam mais difícil satisfazer uma ou mais expectativas de valor. Dito de forma simples, um desafio da arquitetura é um obstáculo ou barreira que o sistema deve superar para fornecer valor. Esse é um ponto fundamental. Obstáculos e expectativas de valor são como yin e yang. Se não houver obstáculos presentes o valor cai, porque o resultado é fácil e qualquer um pode fazer. Água engarrafada é uma exceção digna de nota a essa regra.

Dentro de qualquer contexto, a identificação dos desafios da arquitetura envolve avaliar:

• Quais fatores limitantes causam impacto em uma ou mais expectativas de valor?

• Se forem observados impactos, eles tornam a realização das expectativas de valor mais fácil (impacto positivo) ou mais difícil (impacto negativo)?

• Cada impacto torna as coisas mais fáceis ou mais difíceis? Uma escala simples de baixo, médio ou alto geralmente é suficiente?

A Figura 3 descreve alguns desafios da arquitetura que ocorrem em um sistema de conformidade pré-negociação do gerenciamento de portfólio. Uma discussão mais aprofundada dos desafios da arquitetura e um estudo de caso podem ser encontrados em [4].

Os desafios da arquitetura devem ser considerados dentro de seus próprios contextos. Embora possa ser possível tirar uma média das curvas de utilidade através dos contextos, o mesmo não pode ser feito com o impacto de fatores limitantes nas expectativas de valor. Por exemplo, suponha que um servidor da Web forneça páginas a usuários em dois contextos. Um contexto acessa informações estáticas, como documentos de referência. Eles desejam tempos de resposta entre 1 e 3 segundos. O outro contexto acessa informações muito dinâmicas, como resultados de eventos esportivos em andamento. Eles ficam satisfeitos com tempos de resposta na faixa de 3 a 6 segundos.

Os dois contextos estão sujeitos às limitações da CPU, memória, disco e rede . No entanto, à medida que os volumes de solicitação aumentam em um fator de 10 ou 100, esses dois contextos provavelmente irão encontrar obstáculos de redimensionamento bastante diferentes. No caso de conteúdo dinâmico, a sincronização de atualizações e acessos torna-se um fator limitante em situações de carga intensa. Para o conteúdo estático, situações de carga intensa podem ser superadas armazenando em cache as páginas lidas com freqüência.

Existe um ponto final que deve ser mencionado sobre desafios da arquitetura e sistemas com vários contextos. Em muitos casos, pode parecer que um sistema único é capaz de suportar muitos contextos diferentes. No entanto, os contextos de arquitetura que surgem de cada contexto constituem uma boa ferramenta para avaliar a compatibilidade desses contextos um em relação ao outro. Quando contextos incompatíveis são tratados pela mesma arquitetura, o resultado nunca é satisfatório para nenhum deles. Um sofre às custas do outro ou ambos ficam comprometidos. Um exemplo disso é uma ferramenta de semicondutor tentando suportar contextos de produção e de pesquisa com uma única arquitetura. Devido aos conjuntos de expectativas de valor bastante diferentes (confiabilidade versus flexibilidade), forças de oposição (fábrica versus laboratório) e catalisadores de mudança (rodadas de produção versus experimentos), é improvável que esse casamento pudesse ser salvo.

Estratégia de arquitetura

Como as seções anteriores descreveram, a formulação da estratégia de arquitetura de um sistema começa com:

• Reconhecer os contextos de valor apropriados e priorizá-los.

• Definir as curvas de utilidade e priorizar as expectativas de valor em cada contexto.

• Identificar e analisar as forças de oposição e os catalisadores de mudança em cada contexto.

• Detectar onde os fatores limitantes tornam difícil satisfazer as expectativas de valor.

A Figura 2 ilustra esse processo. A lista de atividades anterior nos leva para a caixa Desafios da Arquitetura no meio do diagrama. Neste ponto, estamos trabalhando com uma lista de desafios de arquitetura que foram reunidos de todos os contextos. Cada um desses desafios representa o impacto de um ou mais fatores limitantes em uma ou mais expectativas de valor.

Como o diagrama mostra, antes de começarmos a tratar cada um desses desafios precisamos priorizá-los. As seguintes observações explicam por quê:

• Quanto antes uma decisão for tomada, mais coisas é provável que ela restrinja.

• Quanto mais tarde uma decisão for tomada, menos alternativas estarão disponíveis.

Como resultado, só faz sentido reservar as primeiras decisões de arquitetura para ser as que produzem o maior valor. Existem vários critérios que podem ser usados para priorizar os desafios da arquitetura. Recomendamos um equilíbrio entre o seguinte:

Importância: Qual a altura da prioridade das expectativas de valor que recebem impacto do desafio? Se essas expectativas de valor forem específicas a alguns contextos, qual é prioridade relativa desses contextos?

Magnitude: Qual a intensidade de um impacto nas expectativas de valor que foram causadas pelos fatores limitantes?

Conseqüência: Quantas opções realistas parece haver? Essas opções apresentam diferenças significativas de dificuldade ou eficiência?

Isolamento: Qual o isolamento do impacto das opções mais realistas? Quanto mais difundido o impacto, mais peso esse fator possui.

Após os desafios da arquitetura estarem priorizados, são formuladas abordagens para os de prioridade mais alta. Embora técnicas como estilos e padrões de arquitetura possam ajudar, essa é uma área em que uma profunda experiência com o problema e os domínios da solução é inestimável. Abordagens eficazes a desafios significativos são resultado de habilidade, percepção, empenho e trabalho compenetrado. Essa afirmação é verdadeira, quer o problema seja cirurgia, gerenciamento executivo ou arquitetura de software.

À medida que cada desafio é tratado, a sua abordagem irá restringir as soluções a outros desafios e, às vezes, criar outros novos. Se as prioridades dos desafios da arquitetura estiverem corretas, a maior parte das restrições em níveis mais específicos também estará apropriada. No entanto, em alguns casos a abordagem de um desafio de alta prioridade poderá ter impacto negativo em vários desafios de prioridade ligeiramente inferior. A prioridade combinada dos desafios que receberam impactos poderá superar o desafio de prioridade superior. Nesse caso, é aconselhável recuar e formular uma abordagem diferente ao desafio original.

Finalmente, com as abordagens formuladas para o conjunto de desafios de alta prioridade, a estratégia de arquitetura pode ser expressa. O arquiteto analisa o conjunto de abordagens e separa um conjunto de princípios de orientação nas seguintes áreas:

Organização: Como o sistema é organizado em subsistemas e componentes? Qual é a composição e as responsabilidades de cada um? Como o sistema pode ser implantado por uma rede? Que tipos de usuários e sistemas de externos existem? Onde estão localizados e como se conectam?

Operação: Como os componentes interagem? Em que casos a comunicação é síncrona? Em que casos é assíncrona? Como as ações dos componentes são coordenadas? Quando é aceitável configurar um componente ou fazer diagnóstico dele? Como as condições de erro são detectadas, diagnosticadas e corrigidas?

Variabilidade: Que recursos principais do sistema são permitidos variar de um ambiente de implantação para outro ? Que opções são suportadas para cada recurso e quando a opção pode ser feita (por exemplo, em compilação, em vinculação (link), instalação, inicialização ou em tempo de execução)? Que dependências existem entre os pontos de variação?

Evolução: Como o sistema é projetado para dar suporte à mudança enquanto retém a sua estabilidade? Que tipos específicos de mudanças significativas foram antecipados e quais são as maneiras preferidas de abordá-los?

Em resumo, a estratégia de arquitetura é o leme e a quilha de um veleiro, fornecendo direção e estabilidade. Ela deve ser uma breve instrução de direção de alto nível que possa ser entendida por todos os financiadores e deve ser relativamente estável durante o tempo de vida do sistema.

Integração com desenvolvimento existente

Métodos

A Figura 3 mostra como os Modelos de Valor e a Estratégia de arquitetura relacionam-se aos métodos de cascata e espiral. Os Modelos de Valor e a Estratégia de arquitetura operam em um ponto anterior e um nível superior a esses métodos. Quando os modelos de valor são estudados e as estratégias da arquitetura são formuladas, fornecem um alicerces sólido para a especificação de requisitos e a definição de uma arquitetura mais detalhada. O modelo de valor conduz os requisitos e influencia a definição da arquitetura ao fornecer informações para se fazer balanceamentos. A estratégia de arquitetura conduz a definição mais detalhada da arquitetura e fornece um conjunto de requisitos derivados que são necessários para superar obstáculos conhecidos.

Uma analogia apropriada é considerar a estratégia de arquitetura como planejamento estratégico e os modelos de valor como análise de mercado. Sob essa luz, os requisitos tornam-se diretivas e objetivos corporativos. A definição da arquitetura é a organização comercial e o plano operacional, e os casos de uso são o equivalente aos processos comerciais.

Poucas empresas estabelecem objetivos corporativos, estrutura organizacional, planos operacionais e processos comerciais sem primeiro ter uma clara idéia da sua missão, mercados, concorrentes, recursos e estratégia. Até as menos eficientes fazem isso.

A Figura 4 mostra como os Modelos de Valor e a Estratégia de arquitetura relacionam-se aos métodos ágeis. Tanto EXTREME PROGRAMMING quanto SCRUM levam em consideração uma definição da arquitetura. SCRUM faz isso explicitamente, esperando que a arquitetura seja definida nas primeiras 4-5 semanas de iteração.

EXTREME PROGRAMMING faz isso implicitamente. Um dos 12 princípios centrais da EXTREME PROGRAMMING é chamado Metáfora do Sistema.

Esse princípio não é usado com tanta freqüência nem tão bem entendido quanto seus irmãos mais famosos: Pequenos Releases, Programação em Pares, Desenvolvimento Orientado a Teste. Nos primeiros tempos da EXTREME PROGRAMMING, a equipe que trabalhava no grande e complexo Sistema de Folha de Pagamentos da Chrysler precisava de uma boa maneira de descrever o gerenciamento do fluxo de trabalho para os desenvolvedores da Chrysler. Alguém teve a idéia de traçar uma analogia entre o fluxo de trabalho da folha de pagamentos e uma linha de montagem automotiva. A metáfora funcionou e os desenvolvedores da Chrysler conseguiram fazer a imagem.

O site EXTREME PROGRAMMING [6] define a Metáfora do Sistema como o que Extreme Programming (XP) usa em vez de uma arquitetura formal. Uma história simples compartilhada de como o sistema funciona, uma metáfora. Essa história normalmente envolve um punhado de classes e padrões que dão forma ao fluxo central do sistema que está sendo construído.

O que XP chama de "arquitetura formal" é mais próximo daquilo que chamamos acima de definição da arquitetura. Uma estratégia de arquitetura desempenha a mesma função que uma metáfora do sistema, sem ser uma metáfora. Essa é uma vantagem significativa, pois metáforas realmente eficazes (como a usada na Chrysler) podem ser difíceis de conseguir. Em contrapartida, princípios centrais claros e concisos são fáceis de formular e fáceis de entender. Uma pessoa não precisa sair e assistir ao filme Hidalgo para entender o que se quer dizer com "vida, liberdade e a busca da felicidade".

Conclusões

Em resumo, o modelo de valor ajuda-nos a entender e comunicar informações importantes sobre origens de valor. Alguns dos problemas importantes que ele trata são como o valor flui, por que ocorrem similaridades e diferenças nas expectativas de valor e nos fatores externos, e qual subconjunto desse valor o nosso sistema procura satisfazer. É trabalho do arquiteto satisfazer essas expectativas de valor resolvendo forças que influenciam o sistema em geral, forças que são específicas a determinados contextos e forças que se espera que mudem com o tempo. Nesse sentido a arquitetura é semelhante a voar em um avião a jato: o piloto deve transportar os passageiros com segurança a um destino conhecido, enquanto equilibra as leis da aerodinâmica, os recursos do avião e as condições climáticas atuais e futuras. A vinculação entre os modelos de valor e a arquitetura de software é clara e lógica e pode ser expressa pelos nove pontos indicados a seguir:

1. Os produtos e sistemas que fazem uso intenso de software existem para fornecer valor.

2. Valor é uma quantidade escalar que incorpora percepções de utilidade marginal e importância relativa através de muitas metas distintas. Balanceamentos entre metas são uma consideração extremamente importante.

3. O valor existe em vários níveis, alguns dos quais contêm o sistema de destino como um provedor de valor. Os modelos de valor desses escopos contêm os condutores primários da arquitetura de software.

4. Os modelos de valor acima desses na hierarquia podem provocar mudanças nos modelos de valor de seus filhos. Essa é uma entrada importante na formulação dos princípios de evolução do sistema.

5. Para cada agrupamento, os modelos de valor são homogêneos. Os contextos de valor, expostos a diferentes condições ambientais, possuem expectativas de valor diferentes.

6. O patrocinador de desenvolvimento do sistema possui prioridades diferentes para tentar satisfazer diversos contextos de valor.

7. Os desafios da arquitetura resultam do impacto de fatores ambientais nas expectativas de valor em um contexto.

8. As abordagens de arquitetura procuram maximizar o valor tratando primeiro dos desafios de arquitetura de prioridade mais alta.

9. As estratégias de arquitetura são sintetizadas a partir das abordagens de arquitetura de prioridade mais alta decompondose as regras, diretivas e princípios comuns de organização, operação, variação e evolução.

As principais contribuições dessa abordagem são:

1. As origens de valor no sistema são modeladas como conceitos de primeira classe. As expectativas de valor associam um pequeno número de recursos a atributos de qualidade, curvas de utilidade e fatores externos. As expectativas de valor são contidas por domínios de valor e contextos; os domínios capturam os aspectos comuns de expectativas de valor, enquanto que os contextos capturam as variabilidades importantes dentro de um domínio.

2. A possibilidade de rastreamento do raciocínio arquitetônico também é uma entidade de primeira classe. As expectativas de valor vinculam-se a desafios da arquitetura, que se vinculam a abordagens de arquitetura, que se vinculam a estratégias de arquitetura. Os investidores podem ver agora o processo de raciocínio que esteve por trás da solução.

3. Um efeito colateral bastante útil dessa capacidade de rastreamento é uma capacidade aumentada de revisar as arquiteturas de software. Como o raciocínio por trás das decisões é tornado explícito, fica mais fácil para outros investidores (patrocinadores do projeto, especialistas em domínio, especialistas em tecnologia, usuários finais) identificar aspectos que possam estar faltando ou que estejam incorretos.

Referências

1. Greenfield, J. and Short, K., Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools,Wiley, 2004. ISBN: 0-471-2084-3.

2. Kepner, C., Tregoe, B., The New Rational Manager, Kepner-Tregoe Inc., 1997,ISBN: 0971562717.

3. Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns: Elements of Reusable Object- Oriented Software, Addison Wesley 1995, ISBN: 0201633612.

4. Alfred, C., "Using Architecture Challenges to Formulate Software Architecture ", 2002, Foliage Software Systems, Inc. white paper. http://www.foliage.com/whitepapers/index.shtml

5. Kazman, R., Asundi, J., and Klein, M. "Making Architecture Decisions, an Economic Approach", SEI Technical Report: CMU/SEI-2002-TR-35, 2002.

6. Extreme Programming Core Practices - http://c2.com/cgi/wiki?ExtremeProgrammingCorePractices

7. Porter, M., Competitive Advantage: Creating and Sustaining Superior Performance, MacMillan Inc. 1985, ISBN: 0029250900.

8. Buschmann, F. et al., Pattern-Oriented Software Architecture, Volume 1: A System of Patterns, 1996, John Wiley and Sons, ISBN: 0471958697.

Sobre o autor

Charles Alfred é diretor técnico da Foliage Software Systems, que alcançou vantagem sobre a concorrência através de estratégia tecnológica, arquitetura de software e desenvolvimento personalizado de softwares. Desde sua fundação em 1991, a Foliage já completou mais de 175 projetos para clientes nas áreas de serviços financeiros, semicondutores, saúde, aviação e e-business.

Notas de rodapé

Uma técnica equivalente para mapear uma métrica quantitativa para uma escala de utilidade está descrita em [5].