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.  

2 Pizzas = 1 Team

2 pizzas

Regra de ouro para dimensionar times ágeis.

Regra das duas pizzas: O Time deve ter o número de pessoas que possa ser alimentado com duas pizzas.

Assim, o time deve ter 7 mais ou menos duas pessoas, ou seja, de 5 a 9 pessoas. A razão para essa regra é que times pequenos facilitam a comunicação entre os seus membros. Agora, se o time for incluir o João Vitor, então pode pedir uma pizza só pra ele. 🙂

Essa regra é atribuída a Jeff Bezos, fundador da Amazon.

Novo livro sobre DAD: Introduction to Disciplined Agile Delivery

Você está procurando um livro enxuto, de poucas páginas, de fácil leitura, que mostra como aplicar o DAD em situações típicas do dia-a-dia?  Achou! 🙂

Acaba de ser lançado o livro Introduction to Disciplined Agile Delivery

Esse livro de 102 páginas é para aqueles que querem conhecer a essência do DAD, o que ele é e o que não é  e quais os seus benefícios.

Sobre o DAD, ele é gratuito para uso e apesar de ter sido desenvolvido originalmente na IBM agora é mantido pelo Disciplined Agile Consortion.  No DAC você encontra todas as informações sobre o programa de certificação em DAD.

Boa leitura!

IntroDADCoverMedium

A Small Agile Team´s Journey from Scrum to Continous Delivery.
by Mark Lines and Scott Ambler

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…

Ignição

engine_start_stop

Hoje é um dia especial. Estou reiniciando o blog depois de um período sem postar. Deu vontade de escrever sobre algumas coisas, sabe.

O que disparou a ignição?

Bom, algumas coisas que estou estudando e outras que li recentemente. A virada da chave foi que senti falta de um canto para organizar as coisas que estou aprendendo e quero registrar e compartilhar.

Mas você tem tempo?

Não, não tenho. Mas peraí! Não tenho tempo para desperdiçar. Mas o tempo que vai aqui não é tempo perdido.

Que assunto?

Assunto é o que não falta não é!? Então vou me concentrar em coisas que me motivam, como engenharia e arquitetura de software onde tem muita coisa acontecendo. Vou falar de Agile, APIs, DAD e tecnologia também claro.

ENGINE START…