“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!

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?

Agile is Rational, Rational is Agile Series: Episode 2: Architecture? Agile Don’t Need No Architecture!

Fizemos esta semana uma apresentação sobre conceitos básicos de arquitetura de software (requisitos arquiteturais, modelagem, gerência de riscos, arquiteturas executáveis e métodos de validação de arquitetura). A apresentação está disponível aqui.

Fonte de Trevi - Foto de Jacqueline Fouche

“Todas (construções) devem possuir firmeza, utilidade e beleza.” – Marcus Vitruvius

A tríade vitruviana é composta pelos três elementos fundamentais da arquitetura: firmitas (estrutura), utilitas (utilidade) e venustas (estética). Através de citações da moderna arquitetura de software, apontaremos como esses elementos são igualmente aplicáveis para sistemas de software.

Firmitas

• “A arquitetura de software para um sistema é a estrutura do sistema que compreende elementos, relações entre eles e as propriedades visíveis de tais elementos e relações.” – Bass, Clements e Kazman
• “Arquitetura de software é a organização fundamental de um sistema.” – IEEE 1471
• “Arquitetura de software trata do projeto e implementação da estrutura de alto nível do software” – Philippe Krutchen, em “The ‘4+1′ View Model of Software Architecture”

Utilitas

• “Ela (a arquitetura de software) é o resultado da montagem de certo número de elementos arquiteturais em algumas formas bem escolhidas para satisfazer os principais requisitos de funcionalidade e performance do sistema tão bem quanto outros, os requisitos não funcionais tais quais confiabilidade, escalabilidade, portabilidade e disponibilidade.” – Philippe Kruchten, em “The ‘4+1′ View Model of Software Architecture”
• “A arquitetura de software também envolve: funcionalidade, usabilidade, superação, performance, reuso, facilidade de compreensão, restrições econômicas e tecnológicas (…)”- Grady Booch
• “As opções de design devem estar associadas aos requisitos, tanto funcionais quanto suplementares, e a outras restrições.” – RUP

Venustas

• “A arquitetura de software também envolve (…) preocupações estéticas.”- Grady Booch
• “(Sobre a) Beleza: Elegância não é uma aproximação para encontrar uma solução para um problema, é a etiqueta que nos colamos na solução ótima. Elegância é fazer mais com menos. Elegância significa simplicidade e menos código novo. Uma solução elegante resolve o problema inteiro. [Fisher & Gipson]” – Grady Booch
• “Está claro que o critério estético participa de um papel determinante na coesão e composição do software (…) Além disso, aparentemente há uma notável interação entre o desenho do software e o software de desenho – e que esta autorreferência posteriormente é dirigida pela necessidade da estruturação estética de sistema de operações computacionais.” – IS-MCA

Referências:

• Apresentação de Grady Booch sobre Arquitetura de Software
• “Software Architecture in Practice”, Bass, Clements e Kazman
• Philippe Kruchten, em “The ‘4+1′ View Model of Software Architecture” 
• IBM Rational Unified Process 7.2
• IEEE 1471 Website
• IS-MCA – International Society for MATHEMATICAL AND COMPUTATIONAL AESTHETICS 
• Primeiro livro de Vitruvius (latim)
• Primeiro livro de Vitruvius (inglês)