Categoria: Arquitetura de Software

16 Axiomas da Arquitetura Ágil

Você já ouviu falar dos 16 axiomas para a prática da arquitetura ágil? Eles são fundamentais para guiar os times na construção de produtos e plataformas digitais robustas e flexíveis. Vamos ver cada um deles e entender como podem transformar a forma como trabalhamos a arquitetura de sistemas.

  1. Foco na experiência do cliente: Priorizar a criação de valor e satisfação para o cliente.
  2. Pensamento de fora para dentro: Entender o ambiente externo para informar decisões internas.
  3. Ciclos rápidos de feedback: Implementar loops de feedback frequentes para ajustar a arquitetura rapidamente.
  4. Orquestração de pontos de contato: Coordenar todos os pontos de interação com o cliente.
  5. Alinhamento do fluxo de valor: Garantir que todos os esforços estejam direcionados para criar valor ao longo de todo o fluxo de valor (Value Stream).
  6. Equipes autônomas e multifuncionais: Promover equipes independentes com habilidades diversas para maior eficácia.
  7. Distribuição de autoridade, responsabilidade e prestação de contas: Distribuir claramente essas funções para evitar gargalos.
  8. Sistemas fracamente acoplados: Construir sistemas modulares que possam ser facilmente modificados.
  9. Plataforma de dados modular: Utilizar uma plataforma de dados que permita fácil integração e expansão.
  10. Princípios de operação comuns e simples: Manter princípios operacionais claros e simples para todos.
  11. Particionamento sobre camadas: Preferir arquiteturas particionadas com componentes desacoplados, ao invés de arquitetura em camadas.
  12. Arquitetura de espelhamento organizacional: Estruturar a arquitetura para refletir a empresa. A Arquitetura Ágil deve estruturar times ágeis de forma a mapear a arquitetura intencional dos sistemas.
  13. Nivelamento organizacional: Alinhar a arquitetura com os níveis de hierarquia organizacional. Por exemplo: Grupo, Entidade, Time de times, Times ágeis.
  14. Viés para a mudança: Buscar um equilíbrio entre arquitetura intencional e emergente. Estar preparado e disposto a mudar conforme necessário.
  15. Mudança de projeto para produto: Focar em entregas contínuas de valor em vez de projetos isolados.
  16. Segurança by Design: Incorporar segurança desde o início do processo de design: Upstream e Downstream.

Para mais detalhes, confira no standard O-AA – Open Agile Architecture.

E você?

Quais axiomas você já aplica na sua prática diária? Compartilhe suas experiências e desafios nos comentários!

O software devorou o mundo e a IA está digerindo

Em um famoso artigo do Wall Street Journal de 2011, Marc Andreessen explicou por que naquela época o software estava devorando o mundo. A evolução acelerada da tecnologia de software impulsionava o crescimento dos negócios digitais. Seguindo os exemplos dos gigantes da Internet, algumas empresas da velha economia estavam se moldando como empresas de tecnologia.

Vamos voltar um pouco mais… Em 2002, a Amazon enfrentou uma barreira de complexidade. O tamanho de sua página inicial atingiu 800MB e levava de 8 a 12 horas para compilar. Jeff Bezos emitiu um mandato relativo a APIs, que mudou profundamente a forma como o software era criado e como a empresa era organizada.

  1. Todas as equipes deverão expor seus dados e funcionalidades por meio de interfaces de serviços.
  2. As equipes devem se comunicar entre si através dessas interfaces.
  3. Não será permitida qualquer outra forma de comunicação entre processos: sem links diretos, leitura direta do armazenamento de dados de outra equipe, sem modelo de memória compartilhada, nenhum tipo de backdoor. A única comunicação permitida é por meio de chamadas de interface de serviço pela rede.
  4. Não importa qual tecnologia seja utilizada. HTTP, Corba, Pubsub, protocolos personalizados – não importa.
  5. Todas as interfaces de serviço, sem exceção, devem ser projetadas desde o início para serem externamente acessíveis. Ou seja, a equipe deve planejar e projetar de forma a poder expor a interface para os desenvolvedores do mundo externo. Sem exceções.
  6. Aqueles que não seguirem esta regra serão demitidos.
  7. Obrigado; tenha um bom dia!

Ao mudar para a modularidade com APIs, a Amazon se posicionou bem para abrir suas capacidades de distribuição e logística para fornecedores terceirizados. A natureza de autoatendimento da plataforma facilitou para os fornecedores venderem e distribuírem seus produtos eliminando atritos. Isso ajudou a Amazon a competir contra o eBay, alavancando um modelo de negócio diferente.

Desde aquela época o software e o hardware representam uma parte crescente dos produtos e de suas operações de suporte. A arquitetura de software, a arquitetura de produto e a arquitetura de operações devem ser estruturadas de maneira simultânea.

Neste cenário em constante mudança, é essencial que as empresas se adaptem e inovem, reconhecendo o papel cada vez mais importante que o software desempenha em todos os aspectos de suas operações. Afinal, como Andreessen apontou, o software estava realmente devorando o mundo e a Inteligência Artificial (IA) nesse momento está fazendo a digestão. kkk

A IA é a força motriz por trás da transformação digital, permitindo que as empresas processem grandes volumes de dados e obtenham insights valiosos. Ela está automatizando tarefas, otimizando processos e possibilitando novos modelos de negócios. A IA está mudando a maneira como interagimos com o software, tornando-o mais intuitivo, personalizado e eficiente. Assim, a IA não apenas ajuda o software a ‘devorar’ o mundo, mas também a ‘digeri-lo’, transformando dados brutos em informações úteis e acionáveis que impulsionam o progresso e a inovação.

Avançando ainda mais nessa discussão, a IA generativa ocupa um lugar de destaque nesse processo de “digestão”. Esse ramo da IA, que inclui modelos de linguagem como ChatGPT, tem a capacidade de gerar novos conteúdos a partir de dados existentes. Isso significa que a IA generativa pode criar desde artigos e relatórios até designs de produtos e códigos de software, ampliando ainda mais o alcance e a eficiência do software. Além disso, a IA generativa pode aprender e se adaptar a estilos específicos, permitindo uma personalização sem precedentes.

Nesse sentido, a IA generativa não só contribui para a “digestão” do mundo pelo software, mas também para a sua “metabolização”, transformando dados em novas formas de criação e inovação.

Arquitetura Ágil na Era Digital: Desafios e Vantagens

Na era digital em constante evolução, a arquitetura ágil emerge como uma abordagem revolucionária para impulsionar a inovação e a entrega contínua. Com a comunicação assíncrona e o uso de microserviços, essa abordagem desafia as limitações impostas pelas antigas práticas de compartilhamento de bancos de dados e bibliotecas. Neste post, vou explorar os desafios e vantagens da arquitetura ágil e como ela está moldando o cenário atual. Vamos juntos!

A arquitetura ágil na era digital se baseia na comunicação assíncrona, em que mensagens ou eventos conectam serviços por meio de protocolos eficientes, como o de publicação e assinatura. Essa abordagem rompe com as práticas antigas de compartilhamento de bancos de dados e bibliotecas, permitindo maior flexibilidade e independência entre os serviço

Uma das principais vantagens da arquitetura ágil é a liberdade na escolha das ferramentas e da stack de desenvolvimento. Sem restrições impostas por padrões tecnológicos obsoletos, a inovação ganha espaço para florescer. As equipes têm a autonomia de decidir quais ferramentas utilizar, resultando em uma entrega contínua mais eficiente e alinhada com as necessidades do negócio.

Além disso, os serviços podem ser testados e implantados de forma isolada, facilitando uma implementação rápida e contínua. A capacidade de containerizar facilmente esses serviços contribui para agilizar ainda mais o processo de implantação e permite uma escalabilidade mais eficiente.

No entanto, a decomposição de um domínio em serviços requer um profundo conhecimento dos fluxos de valor, para delimitar os domínios de negócio. A exposição de APIs eficientes e escaláveis é um desafio crucial nesse processo. Aqui é onde entra o “Domain-Driven Design” (DDD) de Eric Evans, uma abordagem amplamente adotada que oferece um conjunto de processos e práticas para modularização eficaz de sistemas complexos.

A arquitetura ágil está transformando a maneira como as empresas desenvolvem e entregam software na era digital. Ao romper com as práticas tradicionais, ela proporciona maior flexibilidade, autonomia e eficiência no processo de desenvolvimento. No entanto, é importante lembrar que não existe uma abordagem única para todos os casos. O conhecimento do contexto e a compreensão das necessidades do negócio são, mais do que nunca, os fatores críticos para o sucesso.

Para saber mais:
The Open Agile Architecture™ Standard https://publications.opengroup.org/c208
DDD Crew https://github.com/ddd-crew

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…