“A arquitetura corporativa define a coleção de capacidades de negócio, processos, serviços de negócio, serviços tecnológicos e infraestrutura de TI para realizar tais capacidades.” – TOGAF

TOGAF (The Open Group Architecture Framework) é um dos corpos de conhecimento em arquitetura corporativa. A saber, alguns outros:

• Zachman: o primeiro framework de arquitetura corporativa
• EABOK: iniciativa do governo norte americano
• DoDAF : framework do Departamento de Defesa Norte Americano
• MODAF: framework do Departamento de Defesa do Reino Unido

A arquitetura corporativa se preocupa com as capacidades da organização, enquanto que a arquitetura de software é apenas um dos aspectos para desenvolver tais capacidades. Abaixo relacionamos o senso comum sobre os domínios da arquitetura corporativa.

Arquitetura de negócio é composta por:

• estratégia, governança e organização de um negócio;
• informação sobre os processos-chaves de negócio;
• relacionamento entre todos estes conceitos.

Arquitetura de dados é composta por:

• estrutura lógica e física de ativos de dados da organização;
• recursos de gestão de dados.

Arquitetura de aplicação descreve o grupo lógico das capacidades para gerenciar objetos de dados necessários para processar os dados e o negócio.

E, finalmente, a arquitetura tecnológica:

• envolve capacidades lógicas de software e hardware requeridas para suportar a implantação de serviços de negócio, dados e aplicação;
• inclui infraestrutura de TI, middleware, redes, comunicação e padrões (standards).

A arquitetura de software, ao mesmo tempo que se preocupa fortemente com a arquitetura de sistemas de informação (aplicações e dados), se relaciona diretamente com a arquitetura de negócios e arquitetura tecnológica.  O relacionamento com a arquitetura de negócio provê um alinhamento natural com o contexto organizacional, as estratégias corporativas e os processos de negócio. Além disto, a estreita ligação com a arquitetura tecnológica garante que a fundação de TI estará apta a suportar aplicações com necessidades de negócio perfeitamente endereçadas.

A arquitetura de software, dentro de uma abordagem corporativa, certamente terá maiores chances de transformar o software em valor real para a companhia.

Atualmente a Engenharia de Software Magazine só está disponível para assinatura digital. Havendo algum interesse pelo artigo, deixe seu comentário.

Obrigado, Adriano!

A arquitetura de software tem por objetivo fazer o melhor uso dos recursos técnicos de um projeto para garantir a maior eficiência possível aos objetivos do projeto, produto e mesmo à visão e missão de uma empresa.

Podemos identificar, nesta visão, atividades tais como:

• garantir o alinhamento técnico do projeto às diretrizes e estratégias tecnológicas de uma área ou organização, bem como à sua cultura organizacional;
• atender as restrições gerenciais de um projeto tais como custo, prazo e competências técnicas da equipe;
• identificar e detalhar requisitos significativos para a arquitetura de software;
• antecipar e mitigar os riscos técnicos de um projeto;
• realizar a análise e desenho técnico da arquitetura através de técnicas de modelagem arquitetural;
• construir provas de conceito e gerar código executável para os principais pontos de risco do projeto;
• orientar e acompanhar o time técnico para garantir a aderência do código construído às diretrizes arquiteturais do projeto;
• validar a estabilidade e objetivos da arquitetura do produto;
• coletar lições aprendidas e promover um novo ciclo de melhorias.

Em verdade, o ciclo de vida da arquitetura de software deve ser compreendido através de um processo mais amplo que aspectos puramente técnicos, que denominamos aqui como a gestão da arquitetura de software. 

Arquiteturas de software são sempre desenvolvidas dentro de um contexto de negócios como, por exemplo, a criação ou evolução de um produto, a automação de processos de negócio ou a integração entre sistemas de fornecedores distintos. Assim como a arquitetura de software realiza tecnicamente objetivos organizacionais, ela deve prover feedback do mundo real conforme mostrado na figura abaixo.

“O líder planeja no início, antes de começar a agir” – Sun Tzu em “A Arte da Guerra”

Um arquiteto é um papel generalista. Um projetista é um especialista para um determinado domínio (ex: Java EE ou .NET). A figura abaixo, adaptada do trabalho de Gerrit Muller, explora esta dicotomia.

Arquitetos (em vermelho) versus projetistas Java/.NET (em azul)

Resumimos abaixo as principais diferenças abaixo entre estes papéis, que muitas vezes são confundidos sob a mesma alcunha do “arquiteto” dentro do mercado brasileiro.

A notícia boa é que este corpo de conhecimento técnico permite que o arquiteto projete, elicite requisitos, modele, experimente, prove conceitos com código, acompanhe a sua equipe e edifique toda a arquitetura técnica de um produto.

A notícia ruim é que mesmo este corpo gigantesco não garante o bem mais esperado de uma arquitetura de software, que é o alinhamento às estratégias de uma organização.

A notícia pragmática, então, é uma arquitetura de software somente deve existir para servir à uma arquitetura de nível superior, chamada de arquitetura de negócio. A arquitetura de negócio não é um super-conjunto da arquitetura de software. Ela é apenas uma arquitetura que existe em outro plano.

Uma arquitetura de negócio é uma macro-organização que descreve o modelo operacional de uma organização, suas áreas de negócio, seus processos de negócio nucleares e os seus atores de negócio.

Para tornar o concreto o nosso raciocínio, uso como exemplo o eTOM dentro so segmento de TELECOM. o eTOM é um guia com a descrição dos processos de negócio para um provedor de serviços de telecomunicações.

Um outro exemplo concreto é o SCOR, modelo de referência para empresas que possuam complexas cadeias de fornecimento (supply-chains).

Um terceiro exemplo, dentro do governo Brasileiro, é a empresa de referência da ANEEL. Esta empresa de referência serve como modelo operacional para qualquer concessionária de distribuição de energia elétrica, descrita no documento supracitado através de um conjunto de motivadores de negócio, processos de negócio, regras de negócio e modelo organizacional.

Um quarto exemplo é o ITIL, que é uma arquitetura de negócio para operações e serviços de TI.

Ao saber mais do contexto onde atuamos como arquitetos, podemos escolher entre soluções técnicas mais adequadas e coerentes. Podemos usar melhor os recursos escassos da TI e gerar mais valor de negócio para estas empresas.

Para se tornar um melhor arquiteto e saber mais sobre arquiteturas de software, estude mais as arquiteturas de negócio das verticais de atuação da sua empresa.

Do desenvolvimento da estratégia à execução

Há algum tempo discutimos sobre a necessidade de definir uma visão da arquitetura do software, isto é, onde a arquitetura pretende chegar e como ela irá contribuir para concretizar a visão do produto. A visão arquitetural declara os objetivos pretendidos com a arquitetura. Também é interessante que a visão contemple princípios arquiteturais a serem seguidos, norteando os arquitetos e disciplinando suas atividades. A visão deve ser suficiente para provar que a equipe é capaz de desenvolver o projeto e conseguir o patrocínio.

Em seguida, convém que o time de arquitetura realize uma análise estratégica e descubra quais são as questões-chave para a arquitetura – as quais chamaremos de diretrizes arquiteturais. O time deve promover discussões com os stakeholders, investigando os interesses envolvidos, e analisar o contexto do projeto e organizacional de forma a revelar todas as forças quem podem influenciar o produto. Nesta análise, é imprescindível identificar e tratar riscos técnicos – cuja mitigação deve envolver o gerente do projeto. Invariavelmente o contexto dos projetos de desenvolvimento de software é permeado por oportunidades e ameaças como, por exemplo, prazos políticos, restrições tecnológicas, expertise do time de desenvolvimento, patrocínio, etc. Ao final desta atividade, o time deve contar com um conjunto de diretrizes arquiteturais. Ou, até mesmo, indicar que um projeto é inviavel tecnicamente dentro de tal contexto.

De posse das diretrizes arquiteturais, o time de arquitetura deve formular a estratégia. Atualmente a formulação de uma estratégia arquitetural pode ser considerada uma arte, dependendo muito da experiência da equipe. De uma forma geral, é importante identificar uma estratégia que atenda às diretrizes. Ao formular a estratégia, o arquiteto de software ou o time de arquitetura deve levar em consideração as experiências pregressas e se perguntar “qual estratégia melhor poderá responder às diretrizes arquiteturais?”  Estilos e padrões arquiteturais, sejam públicos ou de conhecimento do arquiteto, podem conduzir a escolha pois aproveitam experiências bem sucedidas. O principal produto desta atividade é a escolha dos principais mecanismos arquiteturais seguida de orientações sobre como desenvolvê-los.

O planejamento da definição arquitetural permite que a estratégia seja traduzida em ações culminando em um plano detalhado. O plano de definição arquitetural organiza a decomposição dos subsistemas, módulos ou componentes do sistema de software. Este plano deve ser fomentar à Estrutura Analítica do Projeto (EAP ou WBS, em inglês), auxiliando o gerente de projeto à organizar as atividades de um projeto dirigido pela arquitetura.

Enfim, a execução da estratégia arquitetural é caracterizada pelas atividades de gestão de requisitos arquiteturais, modelagem arquitetural e avaliação de arquiteturas. Note que o ciclo formado tem forte relação com o ciclo de PDCA. Na execução, o emprego de táticas arquiteturais – sejam de mercado, acadêmicas ou conhecidas pelo arquiteto – consolida a definição arquitetural. Mas isto já é uma outra (longa) história…

Planejamento e execução arquiteturais

Referências:

1. What is Strategy? - Michael Porter
2. The Execution Premium – Kaplan e Norton 
3. Creating An Architectural Vision – Malan e Bredemeyer
4. The customer objectives view – Gerrit Muller
5. System Architecting – Gerrit Muller

1. Trilogia de arquitetura de software do SEI:
   • Software Architecture in Practice (2nd Edition)
   • Evaluating Software Architectures: Methods and Case Studies
   • Documenting Software Architectures: Views and Beyond (recomendamos esperar a segunda edição, a ser lançada ainda neste ano).
2. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives – de Nick Rozanski e Eóin Woods 
3. Livros e artigos do site do Gaudí System Architecting, mantido por Gerrit Muller.
4. Artigos do site de Dana Bredemeyer.
5. Blog de J. D. Meyer 
6. Família POSA. Para começar economizando, opte pelo Volume 4 e dispense o Volume 1. Pattern-Oriente​d Software Architecture Volume 4: A Pattern Language for Distributed Computing (v. 4) – Frank Buschmann (Author), et al.
7. The Art of Systems Architecting, Third Edition – Mark W. Maier e Eberhardt Rechtin
8. Software Architecture: Perspectives on an Emerging Discipline - Mary Shaw e David Garlan

Criei uma lista bem completa e que vai muito além do iniciante está disponível em uma wishlist da Amazon. Aliás, se você passou do item 6, já venceu com louvor sua iniciação arquitetural (a prática é outro papo).

Se está mesmo com preguiça, muito ansioso e quer ter uma noção sobre arquitetura de software em um fim de semana, sugiro o Essential Software Architecture de Ian Gorton. Simples como sua proposta.

É bom lembrar que estamos nos referindo somente aos conhecimentos necessários para o desempenho das atividades técnicas da arquitetura de software. Conforme já comentamos anteriormente, o arquiteto de software deve desenvolver habilidades como, entre outras, liderança e comunicação interpessoal.

Gostou? Achou exagerado? Conhece outro caminho? Fique a vontade para comentar.

E se você começou a estudar usando esta lista, por favor, queremos saber.

Bons estudos!

(*) Esta é uma resposta atribuída a Kent Beck em OOPSLA 1992, segundo Philippe Kructhen.

Nossa convicção é que a disciplina de arquitetura de software pode contribuir para a redução de riscos técnicos mesmo em projetos que empreguem métodos ágeis. Para tal, em primeiro lugar, os trabalhos arquiteturais devem respeitar a natureza evolutiva de tais projetos. Em segundo, deve se ater a comunicar modelos arquiteturais apenas na medida exigida pelo método. Por exemplo, se a filosofia de desenvolvimento prega abandonar diagramas após a realização no modelo através do código, o arquiteto assim deve proceder. Outra situação: caso a equipe não faça uso de ferramentas CASE ou de modelagem avançadas, o arquiteto pode considerar a modelagem coletiva usando um quadro ou flip chart. 

Algumas referências:

• Entrevista: Booch e Ambler sobre arquitetura em projetos ágeis
• Entrevista: Paulo Merson na Infoq
• What software architects do? - Philippe Kruchten
• Existe Arquitetura de Software em Projetos XP?