Categoria: Arquitetura de Software

Não existem soluções universais, apenas soluções contextuais.

Uma coisa que vejo que as pessoas buscam são as brilhantes soluções universais. Aquela solução que vai resolver tudo. Mas a real é que:

Não existem soluções universais.

Em um momento do milênio passado, eu acreditava que Java seria uma linguagem quase universal. Mas, começaram a aparecer .Net, Groove, Scala, Python, Node.js, Closure, PHP, Angular, ect, ganhando força em determinados contextos. Realmente, não era a solução universal. Algumas pessoas podem ter crescido e visto muita evolução. Outras puderam se especializar apenas em uma coisa ou no que se tornou popular hoje em dia, mas nenhuma delas resolve tudo.

Por exemplo, essa semana surgiu uma questão sobre o design de acesso à rede interna na AWS e no GCP. Inicialmente a idéia era aplicar a mesma solução AWS no GCP. Como diria o menino prodígio: “Santa falta de lógica, Batman!” No caso, o design e a organização das duas plataformas é diferente, não é possível usar a mesma solução para os dois contextos.

Enfim, para não cair na falácia das soluções universais, basta aceitar que não há soluções universais e tentar evitar esse desejo ingênuo e insano. Considere mais de uma opção de solução, teste e evolua rapidamente, tendo em mente que:

Existem apenas soluções contextuais.

Avalie qual padrão de design ou ferramenta se aplica melhor em cada contexto.

Arquitetura Ágil = Design Emergente + Arquitetura Intencional

Metodologias de desenvolvimento tradicionais costumam usar Big-Design-Up-Front (BUFD) para criar uma infra-estrutura de roadmap arquitetônico destinado a atender plenamente as necessidades do futuro sistema. A crença é que um esforço único no início poderia capturar requisitos e planos arquitetônicos suficientes para suportar o sistema para os próximos anos.

No entanto, esta abordagem vem com muitos desafios. Um deles é o delay no início da execução. Um outro desafio surge quando a arquitetura planejada, que possui um conjunto grande de especulações, se encontra com o mundo real. Pouco tempo é suficiente, para que os desenhos se tornem frágeis e difíceis de mudar e eventualmente surge um Big-branch-and-merge para que um novo conjunto de suposições especulativas seja colocado em ação. Para endereçar esses desafios combinamos o design emergente e a arquitetura intencional, impulsionados pela colaboração.

Design Emergente

O princípio 11 do Agile Manifesto é o principal motor por trás do conceito de design emergente: “As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas.” As implicações disso são:

  • O design é cultivado de forma incremental por aqueles que estão mais próximos a ele.
  • O projeto evolui de mãos dadas com a feature de negócios. Ele é constantemente testado e ativado por refatoração, TDD e integração contínua.
  • Equipes evoluem rapidamente o projeto de acordo com os requisitos atualmente conhecidos; o projeto é estendido somente conforme necessário para implementar e validar o próximo incremento de feature.

Esta nova prática de design emergente é eficaz no nível de equipe. No entanto, o design emergente por si só é insuficiente para o desenvolvimento de grandes sistemas.

  • Ele pode causar redesenho excessivo para coisas que poderiam ter sido antecipadas.
  • Equipes nem sempre são capazes de sincronizar com as outras, criando assim uma entropia de suposições e divergência de arquitetura.
  • As equipes podem mesmo não estar cientes de algumas das necessidades futuras de negócios maiores; fatores fora de seu alcance que direcionam a necessidade da arquitetura futura.
  • Bases comuns de arquitetura melhoram a usabilidade, extensibilidade, desempenho e manutenção de um sistema de sistemas maior.
  • Novos, padrões do usuário transversais afetam o propósito futuro da arquitetura.
  • Fusões e aquisições direcionam integrações e a necessidade de padronização da infra-estrutura.

Arquitetura Intencional

Portanto, chega um ponto em que o design emergente é uma resposta insuficiente à complexidade do desenvolvimento de sistemas em larga escala. Simplesmente, não é possível para as equipes se antecipar às mudanças que podem muito bem ocorrer fora do seu ambiente. Também não é possível para as equipes individuais entenderem completamente todo o sistema e, assim, evitar a produção de código e design redundante e ou conflitantes. Para isso alguma arquitetura intencional é necessária – um conjunto de iniciativas de arquitectura intencional, planejado para aumentar o design da solução, desempenho e usabilidade e fornecer orientação para o projeto entre as equipes e sincronização da implementação.

Arquitetura é uma colaboração

Claramente, é melhor ter ambos: rápido, controle local do design emergente e uma visão global da arquitetura intencional. A combinação, proporciona a orientação necessária para assegurar que o sistema como um todo tenha integridade conceitual e eficácia. Alcançar o equilíbrio certo de design emergente e arquitetura intencional impulsiona a evolução eficaz do sistema, como mostrado no diagrama desse post. 

O diagrama mostra que eles não são construções independentes. Arquitetura intencional restringe o design emergente, mas a um nível suficientemente elevado de abstração para permitir que as equipes possam se adaptar eficazmente a parte “intencional” para seu contexto específico. Ao mesmo tempo, influências e design emergente corrigem a arquitetura intencional e também alimentam novas ideias para o futuro, centralizando o esforço intencional.

Tal reciprocidade profunda entre design emergente e arquitetura intencional só pode ocorrer como resultado da colaboração entre as equipes ágeis, arquitetos de sistemas e gestores de produto.

Fonte: SAFe

 

Architecture Owner

Outro dia eu estava conversando com um desenvolvedor super bom de serviço. Ele me disse que acha “waste” essa diversidade de práticas e processos de desenvolvimento ágil. Ele tem muita dificuldade em reunir e visualizar todas as práticas e métodos funcionando juntos porque veio de um contexto muito técnico onde o que tinha de ser feito era apenas escrever código e entregar o software. Ele me disse que gostaria de saber, por exemplo, o que o arquiteto de software faz. 🙂 Eu achei sensacional a duvida dele e expliquei rapidamente o papel do arquiteto, mas isso ficou na minha cabeça e resolvi fazer esse post.

O papel de arquiteto de software ágil hoje está bem mais consolidado. O Disciplined Agile Delivery define o papel do Architecture Owner e as principais responsabilidades desse papel são:

  • Guiar a criação e evolução da arquitetura da solução.
  • Mentor e o Coach dos membros do time nas práticas e questões de arquitetura.
  • Entender a direção arquitetural, os padrões da organização e garantir que o time esteja aderente à eles.
  • Garantir que o sistema será suportado de maneira fácil encorajando um design adequado e tocando as refatorações necessárias para garantir um bom design.
  • Garantir que o sistema seja testado e integrado frequentemente.
  • Tem a palavra final sobre as decisões técnicas, mas deve engajar o time nas decisões e não dita-las.
  • Lidera o esforço de visualização inicial da arquitetura.
  • Trabalhar junto ao time de arquitetura corporativa (se ele existir).

No ciclo de vida básico do DAD existe um marco específico para provar a arquitetura o mais cedo possível na fase de construção. É uma forma do arquiteto mitigar os riscos técnicos e um checkpoint de governança para sinalizar a gerência sênior e outros stakeholders as decisões e questões técnicas.

Por que você deveria considerar Microservices em um próximo projeto?

Para responder essa pergunta vou assumir que você desenvolve aplicações monolíticas. Os “monolitos” são o padrão “de fato” para a construção de aplicações de negócio hoje em dia. Você vai argumentar que as aplicações que você cria tem um alto-nível de modularização com alta-coesão e baixo acoplamento e que você desenvolve serviços e tal. Tudo bem, mas você tem de concordar que não é comum quebrar a aplicação em diversos serviços, implantáveis separadamente e manter essa prática em produção. Isso é novidade. Concorda?

Bom, se você já passou pelo desenvolvimento de uma aplicação grande em Java EE ou .NET, em algum momento já passou pelos seguintes problemas:

  •  A produtividade caiu ao longo do projeto. Sua aplicação se tornou difícil de manter a medida que a aplicação cresceu. Isso resultou em ciclos longos de build para implantar novas funcionalidades ou mesmo novos serviços, e você não conseguiu fazer muito mais rápido.
  • O deploy  era “tudo ou nada”. Os pacotes grandes forçaram a construção, testes e deploy, mesmo em uma pequena mudança. Os CRUDs, as transações mais críticas e os relatórios ficaram todos no mesmo implantável e na mesma infraestrutura;
  • A escalabilidade também foi “tudo ou nada”. Não dava para escalar apenas parte da aplicação. Até dava mas nem foi cogitado isso;
  • O Onboarding de novos desenvolvedores foi difícil. Os novos integrantes do time tiveram de baixar todo o código e aprender a lidar com a aplicação inteira.
  • O gerenciamento de dependências de código ficou complexo.
  • O projeto ficou preso a uma única opção de tecnologia.

Para atacar estes problemas os caras pensaram em modularização e particionamento da aplicação em pequenas partes que chamaram de micro-serviços. Cada micro-serviço funciona como uma aplicação independente, implantável separadamente, com interface de serviço baseada em REST agnóstica em relação à tecnologia. Isso possibilita uma liberdade de escolha de tecnologia de implementação. Com essa liberdade você pode implantar serviços em plataformas diferentes e escalar de forma independente também.

Mas não existe almoço grátis… atenção ao desempenho. Você vai ter de monitorar o tempo de resposta e o uso de recursos e é importante ficar atento desde o início. Serviços distribuídos tendem a ter problemas em função da latência, por exemplo. Atenção ao design dos serviços. Evite as dependências entre serviços e a necessidade de orquestração para conseguir que o deploy fique realmente independente, senão vai acabar tendo deploy “tudo-ou-nada” do mesmo jeito. 🙂

Mas voltando aos benefícios… outra liberdade que você tem com esse modelo é “rampar” times diferentes para cada serviço. Isso te dá a possibilidade de paralelizar ou adiar a entrada de um novo time de acordo com o melhor momento para investimento. Lembrando que a métrica do time de “2 pizzas” vale aqui e também a abordagem DevOps onde o time que desenvolve também é responsável por manter e acompanhar o serviço em produção.

As vantagens dessa abordagem estão sendo experimentadas ainda, mas resultados positivos tem sido apresentados em conferências. Acho que você deveria considerar para tornar os times mais capazes de responder rapidamente às novas necessidades de negócio. A abordagem de desenvolvimento de aplicações monolíticas gera respostas mais lentas. Microservices promete entregas mais freqüentes e mais rápidas. Isso permite feedback mais rápido dos usuários e ajustes nos investimentos por parte do time de negócios.

O seleto grupo de certificados TOGAF 9 no Brasil

O The Open Group vem fazendo investimentos desde 2010 para a difusão do TOGAF no Brasil. Em 2013, por exemplo, por iniciativa do AEA Brazil Chapter, participei como voluntário do time de tradução do glossário do TOGAF 9 para o português brasileiro. Essa iniciativa possibilitou a oferta da certificação e outros materiais no nosso idioma.

Mesmo com esses investimentos o número de profissionais certificados em TOGAF ainda é baixo no Brasil. De acordo com o TOGAF Visual Map, até outubro de 2014 tinhamos apenas 184 do total de 36.435 certificados em todo o mundo.

Screen Shot 2015-07-07 at 09.44.14

Seguem alguns detalhes da certificação para os interessados em entrar para esse seleto grupo de profissionais brasileiros.

A visão da certificação TOGAF 9

Definir e promover um programa de capacitação dirigido pelo mercado  e um programa de certificação para TOGAF 9.

Os princípios da certificação TOGAF 9

  1. Abertura,  o programa é aberto para aplicação em todos os países;
  2. Equidade, a certificação é obtida por todos os candidatos da mesma maneira, apenas passando no exame;
  3. Relevância para o mercado, programa estruturado para atender as necessidades do mercado;
  4. Apoio ao aprendizado, os treinamentos são fornecidos por parceiros de acordo com as necessidades do mercado;
  5. Qualidade, os treinamentos fornecidos devem ser chancelados pelo The Open Group (uma lista é fornecida no site);
  6. Melhores práticas, programa desenhado seguindo as melhores práticas do mercado.

A importância da certificação TOGAF 9

A existência do programa de certificação é um incentivo forte para firmar TOGAF como um método padronizado e aberto para arquitetura empresarial (ou corporativa) evitando a proliferação de métodos proprietários dependentes de fornecedor. Este é um passo importante para tornar a arquitetura empresarial uma disciplina bem definida e reconhecida e introduzir um rigor na seleção de ferramentas e serviços.

Sobre os exames

São 13 os tópicos da certificação do primeiro exame – TOGAF 9 Foundation:

  1. Conceitos básicos (3 questões);
  2. Conceitos centrais (3 questões);
  3. Definições gerais (3 questões);
  4. Introdução ao ADM (Architecture Development Method) (4 questões);
  5. Enterprise Continuum e ferramentas (2 questões);
  6. Fases do ADM (Nível 1) (9 questões);
  7. Diretrizes e técnicas do ADM (6 questões);
  8. Governança da arquitetura (Nível 1) (4 questões);
  9. Visões Arquiteturais, pontos de vista e envolvidos (2 questões);
  10. Blocos de construção (Building blocks) (2 questões);
  11. Produtos de trabalho (deliverables) do ADM (2 questões);
  12. Modelos de referência do TOGAF (Nível 1) (2 questões);
  13. Programa de certificação TOGAF (2 questões).

Cada um destes tópicos são divididos em sub-tópicos específicos que o candidato deve dominar. O exame tem 40 questões de múltipla escolha. O tempo do exame é de 60 minutos. O candidato deve acertar 22 questões para passar, ou seja, 55% de aproveitamento.

O segundo exame TOGAF Certified tem 8 questões baseadas em cenários. Para passar o candidato tem de obter 60% de aproveitamento, ou seja, 24 dos 40 pontos distribuídos. O tempo do exame é de 90 minutos.

Os exames são em português? Onde fazer?

Como já citei antes, os exames estão disponíveis em português. Eles são aplicados nos centros Prometric. Acesse o site e verifique o melhor centro na sua região.

Mais informações no site:

https://togaf9-cert.opengroup.org/home-public

http://www.opengroup.org/certifications/exams

Bons estudos!

Estou ajudando a organizar um curso oficial de TOGAF, que cobre todo o conteúdo da certificação, em BH, numa parceria entre a comunidade PanGea e a Gnosis. Caso tenha interesse em participar entre em contato.  

15 conceitos básicos para entender o TOGAF 9

togaf-certified

É um método? é uma arquitetura? O que é TOGAF mesmo? Para responder essas dúvidas eu listo aqui 15 conceitos básicos que vão esclarecer o que é o TOGAF.

1. Empresa

Definição: Uma coleção de organizações que compartilham um conjunto de metas em comum.

Exemplos:

  • Órgãos do governo;
  • Partes de uma corporação;
  • Corporações.

Grandes corporações podem ser compostas de muitas empresas. Podem ser “empresas estendidas” incluindo parceiros, fornecedores e clientes.

2. Arquitetura

Definição: Uma Arquitetura é a organização fundamental de “alguma coisa”, em termos dos seus componentes, os relacionamentos entre eles, o ambiente onde estão inseridos e os princípios que governam seu projeto e evolução.

3. Modelo Operacional

Definição: Um Modelo Operacional é o nível desejado de integração e padronização de processos de negócio para entregar bons serviços aos clientes.

4. Arquitetura Empresarial

Se substituirmos  esta “alguma coisa” da definição de arquitetura por “Empresa” e juntarmos o conceito de Modelo Operacional temos a “Arquitetura Empresarial” (chamada também de “Arquitetura Corporativa”).

Definição: Uma Arquitetura Empresarial é a organização lógica dos processos de negócio e infra-estrutura de TI, refletindo a integração e padronização dos requisitos do modelo operacional da empresa.”

Mais informações em: O que é arquitetura empresarial?

5. Tipos de arquitetura

TOGAF  classifica a arquitetura empresarial nos seguintes tipos de arquitetura:

  • Arquitetura de Negócio: processos de negócio, organização, pessoas;
  • Arquitetura de Aplicações: serviços;
  • Arquitetura de Dados: dados, informação;
  • Arquitetura Tecnológica: hardware, software, rede.

6. Porque Arquitetura Empresarial?

O gerenciamento efetivo e exploração da informação através da TI é a chave do sucesso dos negócios.

Bom gerenciamento da informação = vantagem competitiva;

Os sistemas atuais de TI não correspondem às necessidades de negócio em relação ao gerenciamento da informação apresentando deficiências como fragmentação, duplicidade da informação, entendimento ruim e não responder a mudanças. Os investimentos em tecnologia da informação tem foco em manutenção de sistemas. A maioria do esforço é despendido em desenvolvimentos táticos e reativos ao invés de estar ancorados em um planejamento estratégico. Neste cenário as duas razões principais de porque você precisa de uma arquitetura corporativa:

  • É crítico para sobrevivência e sucesso dos negócios;
  • Permite gerenciar a inovação da empresa;

7. Pressão para desenvolver  arquitetura empresarial

  • As leis e regulamentações como Sarbanes-Oxley, Clinger-Cohen Act (US Information Technology Management Reform Act 1996), EU Directives on the Award of Public Contracts;
  • empresas mais estendidas;
  • operações de TI mais cooperativas;
  • publicidade relativa a falhas;
  • aumento de litígios;
  • requisitos de auditorias.

8. Benefícios da arquitetura empresarial para o negócio

  • Ajuda a organização a atingir as estratégias de negócio;
  • rapidez no “time to market” para novas inovações e capacidades de negócio;
  • processos de negócio mais consistentes e informações entre as unidades de negócio;
  • maior disponibilidade e segurança;
  • além de redução de riscos.

9. Benefícios da arquitetura empresarial para a TI

  • Melhor rastreabilidade dos custos com TI;
  • redução de custos com projetos, compras, operação, suporte e mudanças;
  • desenho e desenvolvimento mais rápido; menor complexidade;
  • menor risco de TI.

10. A importância da governança

  • Uma arquitetura corporativa é tão boa quanto o frameowork de tomada de decisão que ela estabelece em torno do framework de governaça.

O sucesso do Framework de Governança depende:

  • De uma estrutura de autoridade clara;
  • Dos participantes corretos.

11. O que é um framework de arquitetura?

  • Um framework de arquitetura é um toolkit que pode ser usado para desenvolver uma ampla gama de arquiteturas diferentes;
  • ele deve descrever um método para desenhar um sistema de informação em termos de um conjunto de blocos de construção e mostrar como estes blocos de construção trabalham em conjunto.
  • ele deve conter um conjunto de ferramentas e fornecer um vocabulário comum.
  • ele deve também incluir uma lista de recomendação de padrões e produtos compatíveis que podem ser usados para implementar os blocos de construção.

12. O valor de um framework

  • Fornece um ponto de partida prático para um projeto arquitetônico;
  • Evita o pânico inicial quando a escala das tarefas se torna aparente;
  • Pragmático – “senso comum codificado”;
  • Captura o que outros tem de fazer no mundo real;
  • Contém uma “Baseline” de um conjunto de recursos para reuso.

13. Método para desenvolvimento de Arquitetura Empresarial

Características do método:

  • Um método geral abrangente e compreensivo;
  • Complementar e não concorrente com outros frameworks;
  • Amplamente adotado no mercado;
  • Customizável para atender uma organização e as necessidades da indústria;
  • Disponível sob uma licença livre perpétua;
  • Padrão aberto e neutro em relação a ferramentas, fornecedores e tecnologias;
  • Evita re-inventar a roda;
  • Alinhamento entre negócios e TI;
  • Baseado em melhores práticas;
  • Possível participar na evolução do framework.

14. TOGAF 9

Origens

  • Uma iniciativa que partiu dos clientes
  • Um framework, não uma arquitetura
  • Um framework genérico para desenvolver arquiteturas para atender diferentes necessidades de negócio
  • Não é  “one-size-fits-all”

Escopo do TOGAF

  • Originalmente baseado no TAFIM (U.S. DoD)
  • TOGAF enfatiza metas de negócio como condutores arquiteturais e fornece um repositório de boas práticas incluindo:
    • TOGAF Architecture Development Method (ADM)
    • ADM Guidelines & Techniques
    • TOGAF Architecture Content Framework
    • Enterprise Continuum
    • TOGAF Reference Models
    • TOGAF Capability Framework

15. Certificação TOGAF 9

A certificação TOGAF possui dois níveis, cada um corresponde a um exame:

Nível da certificação Propósito
TOGAF 9 Foundation Para fornecer a validação de que a pessoa conhece os conceitos básicos da terminologia e compreende os princípios fundamentais da Arquitetura Empresarial e do TOGAF 9
TOGAF 9 Certified Para fornecer validação que, além de conhecimento e compreensão, o candidato é capaz de analisar e aplicar conhecimentos de TOGAF 9

Para acessar outros recursos sobre TOGAF acesse o site: http://www.togaf.info/

Estou ajudando a organizar um curso de TOGAF em BH numa parceria entre a comunidade PanGea e a Gnosis. Caso tenha interesse em participar entre em contato.  

Microservices

Enquanto estou criando uma massa de dados resolvi escrever sobre Microservices. 

Mas por que Microservices?

Porque é o estilo arquitetural mais falado do mercado no momento e porque eu acho bem interessante. Se você perguntar para aquele seu colega early adopter ele vai dizer que já aplicou no último projeto e que já está dominando o Node.js.:)

Brincadeiras a parte, segue uma definição de elevador:

Microservices é um estilo arquitetural no qual um sistema complexo de software é formado por um ou mais serviços pequenos, chamados de micro serviços. Estes serviços tem foco restrito a uma capacidade de negócio, são fracamente acoplados e agnósticos em relação à linguagem de implementação. Cada serviço é uma aplicação que tem uma API REST bem definida. Os serviços se comunicam uns com os outros através de suas APIs. Eles são desenvolvidos e mantidos por pequenas equipes. Essas equipes geralmente aplicam práticas ágeis e ao contrário da prática normal, onde uma equipe desenvolve e outra equipe mantém a aplicação, é comum que a equipe que desenvolve também seja responsável pela operação. Nesse contexto as equipes aplicam Continuous Delivery e práticas de DevOps.

Então é isso. A massa de dados está quase pronta. Fui…