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.

Enterprise Agile

Como ponto de partida o Scrum é um excelente método ágil. No Brasil ele abre as portas das empresas para a agilidade. Isso se dá pela sua grande difusão entre os profissionais de gerenciamento de projetos nas áreas de TI. Agora, quando as empresas começam a levar o agile para um patamar corporativo o Scrum sozinho se mostra insuficiente.

Na prática, para uma abordagem corporativa é necessário recorrer a outros métodos para preencher os gaps de processo que o Scrum não trata. É aí que surgem as dificuldades. Quando as empresas começam a olhar para outros métodos surge o conflito de terminologias e a sobreposição de conceitos. Isso gera uma certa confusão na hora de definir e instalar esse novo processo. Faltam elementos para integrar o agile com as estratégias de governança das empresas.

Nesse contexto surgiu o Disciplined Agile Delivery (DAD). O DAD é uma abordagem híbrida que faz a “costura” de diversos métodos no formato de um framework de decisão. Esse framework te ajuda a definir o processo mais adequado de acordo com o contexto e a cultura organizacional da sua empresa. Diferente do Scrum, o DAD considera que existe um ecossistema corporativo e ele não pode ser ignorado.

O DAD estende o Scrum com estratégias do Extreme Programming (XP), Agile Modeling (AM), Unified Process (UP), Kanban, Lean Software Development, SAFe entre outros. Ele aborda práticas técnicas como Continuous Delivery, TDD, arquitetura, modelagem e também documentação e governança, fornecendo alternativas que aumentam a chance de você adotar estratégias que funcionem no seu contexto. Se você tem interesse em DAD entre em contato comigo. Vamos bater um papo.

Para mais informações acompanhe o blog Disciplined Agile Delivery. Para saber mais sobre treinamentos e certificações acesse o site do Disciplined Agile Consortium

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.