Arquitetura Corporativa

Combinando o ArchiMate 3.0 com Outros Padrões - BMM / BS / BMC

postado em por Antonio Plais   [ atualizado‎(s)‎ ]

Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign - Tradução autorizada

Como descrevemos na nossa postagem anterior, a linguagem ArchiMate não pretende substituir outros padrões e abordagens de modelagem, mas, ao invés disso, conectá-los. Nesta postagem, focaremos no relacionamento do ArchiMate com várias técnicas orientadas para o gerenciamento: o Modelo de Motivação de Negócio (BMM-Business Motivation Model), os Indicadores Balanceados de Desempenho (BS-Balanced Scorecard) e o Canvas de Modelo de Negócio (BMC-Business Model Canvas).

Para ajudá-lo a relacionar os modelos ArchiMate com aqueles modelos mais detalhados em outras técnicas, as tabelas abaixo fornecem um mapeamento aproximado entre os conceitos presentes nas outras técnicas mencionadas anteriormente e os conceitos do ArchiMate.

Modelo de Motivação de Negócio - BMM

O Modelo de Motivação de Negócio foi uma das inspirações por trás dos conceitos de motivação do ArchiMate. O BMM distingue entre meios, fins, influenciadores e avaliações, e fornece uma descrição mais detalhada e granular da motivação do negócio do que os conceitos de motivação do ArchiMate.

 BMM  ARCHIMATE
 Visão, Resultado Desejado (Meta, Objetivo)  Meta
 Missão, Curso de Ação (Estratégico, Tático)  Curso de Ação
 Diretiva (Política de Negócio, Regra de Negócio)  Princípio, Requisito, Restrição
 Avaliação  Avaliação
 Influenciador  Motivador
 Impacto Potencial  Resultado

Para uma discussão mais detalhada a respeito do mapeamento entre os conceitos do BMM e do ArchiMate, acesse o artigo How to Use the ArchiMate® Modeling Language with BMM™, disponível na biblioteca do The Open Group.

Indicadores Balanceados de Desempenho - BS

Indicadores Balanceados de Desempenho (Balanced Scorecard, para os íntimos!) é uma técnica de alto nível amplamente usada para o gerenciamento do desempenho estratégico das organizações. Ela fornece quatro perspectivas sobre o desempenho e as endereça através de uma estrutura em camadas usando os conceitos de missão, objetivos, medições, alvos e iniciativas para expressar a direção estratégica. Mapas estratégicos são geralmente usados como uma expressão destes elementos e seus relacionamentos.

 BS  ARCHIMATE
 Missão, Objetivo  Meta
 Medição  Métrica (especialização de Motivador)
 Alvo  Resultado, Valor
 Iniciativa  Curso de Ação (alto nível)
 Pacote de Trabalho (baixo nível)

Canvas do Modelo de Negócio - BMC

O Canvas do Modelo de Negócio fornece uma visão geral de alto nível sobre a estrutura dos modelo de negócio atual e vislumbrado de uma organização.

 BMC  ARCHIMATE
 Parceiros Principais  Ator de negócio, Papel de negócio, Parte interessada
 Atividades Principais  Capacidade
 Recursos Principais  Recurso
 Proposições de Valor  Produto + Valor
 Canais  Recurso (realizado através de Interface)
 Segmentos de Clientes  Ator de negócio, Papel de negócio, Parte interessada
 Estrutura de Custos  Valor associado a elementos da arquitetura
 Fluxos de Receitas  Valor + Fluxo

Relacionando diferentes modelos no BiZZdesign Enterprise Studio

O BiZZdesign Enterprise Studio suporta o ArchiMate 3.0, juntamente com algumas das linguagens mencionadas anteriormente, como o Canvas de Modelo de Negócio. No entanto, o ArchiMate 3.0 é usado para expressar outras técnicas, como o Modelo de Motivação de Negócio e o Balanced Scorecard. A Figura 1 demonstra como os conceitos do ArchiMate 3.0 são usados para modelar conceitos do Modelo de Motivação de Negócio. Entre as << aspas angulares >> nós mostramos o nome do tipo ArchiMate (AM) e o tipo BMM (BMM).


Figura 1: ArchiMate 3.0 e BMM

No Enterprise Studio, os usuários podem usar os conceitos do ArchiMate 3.0 para produzir Indicadores Balanceados de Desempenho. Na Figura 2, mostramos como uma métrica (uma especialização do elemento Motivador do ArchiMate 3.0) pode ser usado como uma medição em um Balanced Scorecard.


Figura 2: Usando uma métrica como uma medição

A Figura 3 mostra um Canvas de Modelo de Negócio típico, e como o Enterprise Studio converte isso automaticamente para o ArchiMate 3.0. Você pode saber mais sobre o nosso suporte para o Canvas de Modelo de Negócio nesta série de postagens.


Figura 3: Mapeamento automático do Canvas de Modelo de Negócio para o ArchiMate

O Enterprise Studio possui muitas outras formas de combinar diferentes linguagens. Isso ajuda a responder questões específicas do negócio e entregar valor de negócio em diferentes níveis.

Na próxima postagem nesta série demonstraremos como você pode combinar o ArchiMate 3.0 com o BPMN.



* Mark Lankhorst é Gerente de Consultoria & Evangelista-Chefe de Tecnologia da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.


 http://bizzdesign.centus.com.br/biblioteca/ebooks/archimate-da-teoria-a-pratica
eBook ArchiMate - Da Teoria à Prática

Inovação, regulações em constante mudança, novas possibilidades tecnológicas, uma nova direção estratégica; estas são algumas das razões pelas quais muitas organizações estão em constante movimento. 

Este livro apresenta as melhores práticas dos autores, fruto da experiência do uso da linguagem ArchiMate em dezenas de projetos reais, em clientes dos mais diversos ramos de negócio. Uma leitura fundamental para quem quer se iniciar na prática da modelagem da arquitetura corporativa. 

Solicite sua cópia GRÁTIS aqui

Combinando o ArchiMate 3.0 com Outros Padrões - Introdução

postado em 15 de jan de 2019 07:59 por Antonio Plais   [ atualizado‎(s)‎ ]

Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign - Tradução autorizada

A linguagem ArchiMate não pretende substituir outros padrões e abordagens de modelagem. Para muitos domínios, existem linguagens e técnicas disponíveis que fornecem descrições mais detalhadas. Tais linguagens, como UML, BPMN e outras, têm um escopo mais estreito (e.g. a UML para especificação de software, o BMN para processos de negócio) do que o ArchiMate, mas lhes falta conceitos para relacionar isso com outros domínios. A Figura 1 mostra isso.


Figura 1: Modelo de arquitetura corporativa conectando outros modelos

É aqui que o ArchiMate adiciona valor. Primeiro, você precisa de uma descrição mais ampla, menos detalhada, para obter uma visão geral da sua empresa, e para ver as dependências entre os diferentes aspectos e áreas, evitando se afogar nos detalhes.

Além disso, como mostrado na Figura 1, existe alguma sobreposição entre o ArchiMate e estas outras técnicas. Por exemplo, o conceito ArchiMate de Componente de Aplicativo é em grande parte idêntico ao conceito de Componente da UML. Isso permite que você conecte os modelos ArchiMate aos modelos para estes domínios individuais, de forma que você possa se aprofundar nas partes específicas da arquitetura corporativa através do mergulho nestes outros modelos.

Isto fornece a você uma descrição integrada da empresa, que relaciona (sub)modelos de domínios anteriormente separados de uma forma significativa (como mostrado na Figura 2 abaixo). Desta forma, você pode analisar e definir as dependências entre os resultados desejados de negócio, os produtos e processos, os sistemas de TI, dados, projetos e programas, e outros aspectos da sua empresa, todos em um único ambiente. Isso é muito importante para a realização da estratégia de negócio: uma linha de visão clara entre todos os elementos da sua empresa, com uma fonte única da verdade (ao invés de silos separados de modelagem), análises eficientes do impacto das decisões gerenciais, e colaboração fácil entre os vários especialistas que trabalham para desenhar e mudar a sua organização.

Figura 2: Ligando um modelo ArchiMate com modelos detalhados para fornecer rastreabilidade

Nas postagens seguintes nós descreveremos como o ArchiMate 3.0 pode ser relacionado com várias linguagens e técnicas específicas existentes. Nós também mostraremos como o BiZZdesign Enterprise Studio suporta isso. A próxima postagem focará na combinação do ArchiMate com técnicas orientadas para a alta gerência, como o Modelo de Motivação de Negócio, Balanced Scorecard e Canvas de Modelo de Negócio. Nas postagens posteriores, discutiremos também a UML, o BPMN, o ERD e outras técnicas.



* Mark Lankhorst é Gerente de Consultoria & Evangelista-Chefe de Tecnologia da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.


eBook A Prática da Arquitetura Corporativa


Para saber mais como a Arquitetura Corporativa pode ajudar a sua organização a vencer os desafios de um mercado cada vez mais exigente, baixe o eBook A Prática da Arquitetura Corporativa, um oferecimento da BiZZdesign e Centus Consultoria.


Arquitetura de Negócio no Novo Normal

postado em 14 de jan de 2019 18:16 por Antonio Plais   [ 14 de jan de 2019 18:17 atualizado‎(s)‎ ]

Baseado na postagem original por Remco Blom* no blog da BiZZdesign. Adaptação, tradução e reprodução autorizados.

A arquitetura de negócio é uma capacidade desafiadora. Desenhar o negócio, otimizar seus processos e suavizar a forma como a informação é coletada e usada é muito interessante, mas acima de tudo muito difícil. Em uma postagem no blog da KLM, intitulado “I Have a Lack of Strategic Vision”, Martin van der Zee, SVP e-commerce, aponta que visões estratégicas em PowerPoint não funcionam para a Air France-KLM na nova era digital em que eles hoje se encontram. Ele apresenta uma série de razões pelas quais os planos estratégicos de longo prazo não estão funcionando para eles:
  1. As apresentações em PowerPoint contendo documentos de visão ou estratégia são preparadas a partir de uma perspectiva interna (a empresa, ou o departamento de uma pessoa específica).
  2. Estes documentos apresentam uma visão simplificada do que está acontecendo no mundo exterior.
  3. O autor se sente realmente satisfeito com o documento e, eventualmente, confunde visão estratégica e esforço com progresso.
"Neste novo mundo digital, ninguém sabe para onde está indo. A única forma de ter uma tênue visão do que está acontecendo é tentar entender o que nossos clientes querem, construir um protótipo funcional e testá-lo no mundo real. Falhe rápido e com frequência. Apresentações PowerPoint não ajudam você a fazer isso; construir, testar e ajustar o fará."

Projetos e experimentos são parte de um ciclo de aprendizado nas organizações. John Boyd introduziu o Ciclo OODA para expressar um ciclo de decisão para Observar, Orientar, Decidir e Agir. Uma vez que a velocidade das oportunidades que passam está aumentando, sua organização precisa acelerar seu ciclo OODA. Como você contribui para o ciclo OODA na sua organização?

A visão clássica dos arquitetos

Os arquitetos, tipicamente, argumentarão que os websites e bancos de dados temporários por trás dos protótipos sugeridos tendem a permanecer por mais tempo do que os inovadores e gerentes de projeto prometeram ao implementá-los. Os arquitetos sabem tudo a respeito de legados, crescimento orgânico e seus panoramas de aplicativos, bem como os enormes esforços que são exigidos para racionalizar estes panoramas. Os arquitetos preferem elaborar um plano antecipado, discutir os princípios subjacentes (esperando que eles sejam aprovados pela gerência sênior), desenhar uma visão geral do futuro desejado, analisar o impacto das mudanças propostas e, só então, iniciar os projetos.

As forças internas e a falta de velocidade desta abordagem são trazidas à discussão por Martijn van der Zee, mencionado acima. Joi Ito, do MIT, vai além em sua apresentação TED sobre inovação na Era da Internet, ao declarar que a Internet está mudando fundamentalmente a forma como nós inovamos. A velha forma "jeito MBA de inovação" é muito lenta e não se beneficia do mundo conectado de hoje.

OK, está certo... mas o que isso significa para a forma como estamos arquitetando (nas) organizações?

A alternativa: Contribuir para a flexibilidade e para a escalabilidade

  • Arquitetos no Novo Normal não deveriam frear a inovação, mas facilitar a inovação por todos os meios ao seu alcance. Através da criação e oferta de blocos de construção reusáveis (e.g. processos padrão, conjuntos de informação, serviços de aplicativo, padrões técnicos), os arquitetos contribuem para aumentar a velocidade das experimentações. Quanto mais blocos de construção bem documentados e reusáveis você tiver disponível, mais rápido você poderá ligá-los em um protótipo funcional com passos/funcionalidades a serem adquiridas (na nuvem) ou construídas.
  • Arquitetos no Novo Normal deveriam ser capazes de se engajar com pessoas que preferem outras formas de comunicação e estilos de aprendizado do que aqueles que eles preferem. "Fazer" e "Experiência Concreta" é o que os gerentes de negócio geralmente preferem, enquanto os arquitetos preferem um estilo orientado para "Pensar" e, em alguns casos, "Observar e Refletir". Não existe certo ou errado em relação a estes estilos de aprendizado, eles apenas ajudam você a assumir uma nova abordagem e atravessar todos os passos da aprendizagem para maximizar sua experiência de aprendizado. Em muitos casos, bom é bom o suficiente. Trabalhar com o Princípio de Pareto em mente e entender que em ambientes em rápida mudança um rascunho 80% de um desenho é bom o suficiente para rodar um experimento e aprender bastante.
  • Arquitetos no Novo Normal deveriam ter uma visão sobre a velocidade. Quais são os processos e canais mais rápidos na organização e onde precisamos maximizar a estabilidade? Arquitetos no Novo Normal também deveriam fornecer um conjunto de critérios para ajudar os gerentes de negócio a decidir como escalar um experimento, incluindo cenários para a integração ou reengenharia da funcionalidade que foi desenvolvida em um experimento isolado, para ajustá-lo ao restante do panorama de aplicativos. Escalabilidade é um desafio chave, tanto para startups como para experimentos em grandes organizações.

Técnicas de arquitetura de negócio ajudam você neste processo. A Centus e a BiZZdesign aplicam estas técnicas nas ferramentas, treinamentos e consultoria que fornecemos. Nós acreditamos fortemente que as capacidades de arquitetura deveriam focar na criação de valor de negócio através da racionalização e otimização, bem como através do crescimento e inovação. 

Se isso também faz sentido para você, entre em contato e vamos conversar mais sobre isso.


http://bizzdesign.centus.com.br/biblioteca/ebooks/empresa_adaptativa
Nós publicamos o eBook 'A Empresa Adaptativa - Prosperando em uma Era de Mudanças', no qual explicamos nossa visão dos desafios da mudança e do controle em empresas complexas, e descrevemos as capacidades necessárias para lidar com isso em maiores detalhes. 
Clique aqui para solicitar sua cópia grátis deste eBook.






*Remco Blom é consultor sênior e especialista em melhoria de processos e segurança da informação na BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.

Arquitetura Corporativa: em Alta Velocidade

postado em 27 de dez de 2018 07:41 por Antonio Plais   [ 27 de dez de 2018 07:52 atualizado‎(s)‎ ]

Baseado na postagem original por Remco Blom* no blog da BiZZdesign. Adaptação, tradução e reprodução autorizados.

Compartilhar conhecimento e melhores práticas é um dos valores fundamentais da BiZZdesign e da Centus Consultoria. Nós regularmente organizamos e contribuímos para seminários presenciais e online, conferências e mesas redondas. Em várias destas interações, uma questão é frequentemente levantada pelos participantes: Quais fatores levam a uma prática de arquitetura corporativa de sucesso?

A importância da velocidade

Arquitetos precisam entregar percepções de alta qualidade para várias partes interessadas na organização. Mas alguns arquitetos não percebem a importância da velocidade. Em várias ocasiões, nós discutimos a importância de entregar respostas para questões de negócio e de projeto de forma quase instantânea. Muitos arquitetos têm muita dificuldade para fazer isso acontecer, mas a maioria concorda que o aconselhamento dos arquitetos tem que ser relevante: "É melhor para um arquiteto apresentar metade da resposta mais cedo, do que a resposta completa muito tarde". O tamanho e a maturidade das empresas que participam dos nossos eventos varia bastante, mas muitos dos desafios relacionados com a velocidade são genéricos.

A Sete Piores Práticas: Freiando com arquitetura

  1. Muito tempo é gasto com a manutenção atrasada do panorama (desatualizado) de TI
  2. O patrocinador da iniciativa de arquitetura corporativa está deixando o projeto, está sendo transferido para outro departamento ou está deixando a empresa
  3. A arquitetura corporativa é vista como um projeto isolado
  4. Continuamente entregar vagarosamente
  5. Necessidade de completude assumida
  6. Discutir sobre a arquitetura corporativa em si, ao invés de discutir sobre os efeitos da arquitetura nos negócios
  7. Muitas atividades concorrentes, falta de foco; gastar tempo com as tarefas erradas e com as audiências erradas
Nas organizações onde o panorama de TI não está atualizado, os arquitetos gastam um tempo enorme tratando de problemas operacionais e discussões internas da TI. Em algumas organizações, a arquitetura é um papel, ao invés de uma função. Nestes casos, é muitas vezes difícil manter o foco no trabalho arquitetural, porque os projetos e incidentes são sempre "mais urgentes".

Muitos pessoas com quem conversamos sentem que a arquitetura corporativa é vista pelas partes interessadas como um projeto, e não como uma capacidade. Assim sendo, quando o patrocinados principal da arquitetura corporativa, por exemplo, deixa a organização, a arquitetura corporativa não tem mais uma posição formal na abordagem de gerenciamento e/ou no portfólio de projetos, e você perde a importância e o suporte para continuar trabalhando.

Finalmente, ficar discutindo infinitamente sobre métodos e modelos de arquitetura freia a entrega e os efeitos da arquitetura corporativa. Apresentar os efeitos positivos da arquitetura corporativa, como a redução da complexidade, dos riscos e dos custos, e a análise de impactos e cenários relevantes para o negócio, é uma opção muito melhor.

Sete Boas Práticas: Melhorando a velocidade das entregas da arquitetura

  1. O panorama atual ("as-is") do negócio e da TI é modelado em um repositório único e suportados por uma ferramenta completa e colaborativa
  2. O pensamento Lean é estabelecido na organização
  3. Critérios claros para a continuidade dos projetos e um processo claro de gerenciamento com a participação ativa da equipe de arquitetura corporativa
  4. Prototipagem rápida
  5. Pensar grande, começar pequeno
  6. Investir na sua rede de contatos: participe de reuniões formais e informais, lanches e da roda do café; mostre interesse real pelas pessoas do negócio, pelos desafios do negócio, e pelos exemplos do que funciona e do que não funciona na prática. Em resumo: desça da Torre de Marfim!
  7. Reclame por um papel para a arquitetura nas equipes de desenvolvimento ágil
Em muitas organizações, os arquitetos se beneficiam das práticas e iniciativas de gerenciamento Lean. Aqueles que investem nas práticas Lean não apenas ajudam a melhorar os processos, mas também contribuem para uma cultura de análise de problemas e elicitação de requisitos. Em contraste, arquitetos que não abraçam a filosofia Lean tendem a "pular direto para as conclusões ou soluções", levando a resultados com baixa qualidade arquitetural.

Mais ainda, a integração da arquitetura com métodos de gerenciamento de projetos, como PMI e PRINCE2, é realmente benéfica para aumentar a velocidade da arquitetura. Produtos de arquitetura padronizados, como arquiteturas de iniciação de projeto, são muito úteis. Os arquitetos deveriam ser envolvidos nos projetos desde as suas fases iniciais, ao invés de serem chamados para contribuir somente quando surge algum problema. Muitas vezes, é útil começar com alguns protótipos rápidos: desenhos simples e rápidos, desenvolvidos de forma colaborativa, do estado potencial futuro e do estado atual da arquitetura, podem suportar de forma muito efetiva a elicitação dos requisitos e a comunicação com as partes interessadas, ajudando a influenciá-las na direção desejada. Deve-se tomar o cuidado, no entanto, para não dar às partes interessadas a impressão de que o problema e/ou solução são mais simples do que realmente são: simplicidade não significa falta de análise e avaliação adequados.

Quando seu objetivo é aumentar a velocidade de entrega da arquitetura corporativa, você não tem muito tempo para desenvolver uma arquitetura completa e compreensiva de toda a organização. Uma boa ideia é começar com um projeto ou domínio específico, especialmente se os recursos (tempo, equipe, experiência, dinheiro) são limitados. Você pode, posteriormente, integrar estas partições na arquitetura corporativa global que você está desenvolvendo passo-a-passo. Construir uma rede de contatos com as partes interessadas do negócio é um tempo bem investido. Se eles conhecem e gostam de você, você terá maiores chances de ser chamado para participar das discussões sobre investimentos e novos projetos que estão acontecendo através de toda a organização. Não confie apenas nos canais formais de governança da arquitetura.

Finalmente, a tendência pela adoção de abordagens de desenvolvimento ágil é cada vez mais forte na maioria das organizações. Reclamar o seu papel nesta maneira rápida de trabalhar pode ser um desafio, uma vez que a arquitetura corporativa sempre esteve associada com as velhas e lentas abordagens em cascata. As abordagens ágeis são, muitas vezes, sinônimos para velocidade, mas também apresentam desafios para a integração e a qualidade, para cuja solução os arquitetos podem contribuir de maneira muito significativa. Frameworks como o SAFe (Scaled Agile Framework) podem ajudar com orientações sobre o papel dos arquitetos nos projetos de desenvolvimento ágil.
 

http://bizzdesign.centus.com.br/biblioteca/ebooks/empresa_adaptativa
Nós publicamos o eBook 'A Empresa Adaptativa - Prosperando em uma Era de Mudanças', no qual explicamos nossa visão dos desafios da mudança e do controle em empresas complexas, e descrevemos as capacidades necessárias para lidar com isso em maiores detalhes. 
Clique aqui para solicitar sua cópia grátis deste eBook.






*Remco Blom é consultor sênior e especialista em melhoria de processos e segurança da informação na BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.

Entregando Valor de Negócio Rapidamente com TOGAF

postado em 26 de dez de 2018 05:31 por Antonio Plais   [ 26 de dez de 2018 05:39 atualizado‎(s)‎ ]

Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign - Tradução autorizada

O TOGAF (The Open Group Architecture Framework) é o mais popular framework para desenvolver uma arquitetura corporativa. Ele é um padrão aberto e pode ser usado livremente por qualquer organização que deseje desenvolver uma arquitetura corporativa para uso interno na organização. A Centus e a BiZZdesign acreditam que uma abordagem de arquitetura corporativa deve ser baseada em padrões e frameworks abertos. Nós combinamos e pré-empacotamos frameworks e padrões como o TOGAF e o ArchiMate na nossa ferramenta, o BiZZdesign Enterprise Studio, para uma abordagem acelerada para iniciar os programas de arquitetura corporativa dos nossos clientes. Nesta postagem, nós explicamos como nós usamos o framework TOGAF, aplicando-o na prática, com o objetivo de fazer uma arquitetura orientada para resultados de negócio.

A Estratégia de Negócio como Ponto de Partida

Antes de começar a um framework como o TOGAF, você precisa olhar para a sua estratégia de negócio: o ponto de partida para uma prática de arquitetura corporativa orientada para resultados de negócio é entender a sua estratégia e direção. A sua estratégia de negócio deveria, naturalmente, orientar as escolhas que você faz durante o desenvolvimento da sua arquitetura corporativa. Mais ainda, a estratégia deveria ter, também, um impacto sobre os métodos e técnicas que você usa para criar esta arquitetura, e, por conseguinte, no uso e adaptação de frameworks como o TOGAF. Por exemplo, uma estratégia que consiste de inovação e adoção precoce de novas tecnologias requer frameworks de arquitetura corporativa mais ágeis e flexíveis. Por outro lado, uma estratégia que foca na consolidação e na prevenção de riscos requer um framework de arquitetura corporativa com estruturas e políticas claras de governança. Este tipo de consideração deve ser levado em conta ao personalizar o framework TOGAF para a sua organização.

Adaptando o Framework

Tendo a direção e a estratégia de negócio como base, você pode pensar sobre como o TOGAF pode ser aplicado na sua organização e quais os resultados que você espera atingir com ele. O TOGAF é um framework bastante extenso e genérico, e é muito importante especificar quais os elementos do TOGAF são úteis no contexto da sua organização e quais não são relevantes.
O Método de Desenvolvimento da Arquitetura (ADM). Adaptado de: The Open Group, TOGAF 9.1

O TOGAF em si reconhece isso: o primeiro passo no Método de Desenvolvimento da Arquitetura (ADM-Architecture Development Method) do TOGAF é a Fase Preliminar. Esta fase diz respeito a definir "onde, o que, por que, quem e como nós faremos arquitetura" na empresa em foco (TOGAF 9.1, Seção 6.2). Em outras palavras: você vai adaptar o framework TOGAF e personalizá-lo de acordo com os requisitos da sua organização.

No entanto, isso não é tão fácil como possa parecer. O TOGAF sugere vários passos nesta Fase Preliminar que fazem todo o sentido, mas a abordagem ainda é bastante genérica. As organizações podem, assim, acabar presas nesta fase, gerando muita discussão mas muito pouco resultado. Para obter resultados de valor desta fase, nós aplicamos princípios do gerenciamento Lean ao processo de arquitetura: examinar todas as atividades e resultados em relação ao resultado que eles adicionam e eliminar todo o desperdício, evitar aprovações desnecessárias que causam atrasos, e melhorar continuamente nossa forma de trabalho. Na nossa experiência, é importante manter o foco em três aspectos:
  1. Usar um conjunto limitado de entregáveis de arquitetura corporativa: o TOGAF sugere vários entregáveis que podem ser produzidos nas suas várias fases. Na nossa experiência, 'menos é mais': apenas alguns entregáveis importantes já são suficientes para começar uma iniciativa de arquitetura corporativa e obter resultados rapidamente.
  2. Para selecionar e configurar estes entregáveis principais, o critério mais importante é o seu valor potencial de negócio. Quem vai usá-los, para quais atividades e com qual benefício esperado? Especialmente nas fases iniciais de uma iniciativa de arquitetura corporativa, é crucial mostrar para as várias partes interessadas (incluindo as partes interessadas do negócio) o valor adicionados dos entregáveis de arquitetura corporativa.
  3. Aprender fazendo. É impossível definir um framework completo de arquitetura corporativa antes de começar, e usá-lo, através de uma abordagem em cascata. É melhor começar pequeno, adotar uma abordagem iterativa, aprender e melhorar sua forma de trabalhar na medida em que você avança.

O Apoio do Programa de Iniciação Rápida

Para suportar as organizações a se concentrar nos três aspectos descritos acima, enquanto executam a Fase Preliminar do TOGAF, nós geralmente usamos um ciclo de oficinas. Isso consiste de uma série de oficinas compactas nas quais os principais elementos do framework TOGAF são discutidos e adaptados. Cada oficina  tem um conjunto de resultados e decisões concretos. Os tópicos que são discutidos podem ser categorizados em três grupos:
  1. Iniciar (Planejar): diz respeito a estabelecer metas e definir o papel da arquitetura corporativa, e definir os produtos e entregáveis da iniciativa. O que queremos atingir e o que precisamos para chegar lá?
  2. Implementar (Desenhar): discute a governança da arquitetura e as convenções de modelagem. Quem está envolvido neste esforço e como vamos descrever a arquitetura?
  3. Trabalhar a Arquitetura Corporativa (Construir & Rodar): os primeiros entregáveis de arquitetura corporativa (por exemplo, os princípios de arquitetura, requisitos principais, visão da arquitetura) são criados como ponto de partida para rodar o primeiro ciclo ADM.
Este ciclo pode ser, ainda, aumentado com oficinas sobre outros tópicos, tais como o (re)uso de material arquitetural existente, o gerenciamento dos requisitos da arquitetura, ou o relacionamento com outras disciplinas, como o gerenciamento do portfólio de projetos. Isso ajuda você a passar por todas as fases do processo do ADM e rapidamente completar a primeira iteração do ciclo.

Este ciclo de oficinas pode ser completado em poucas semanas, acelerando a sua iniciativa de introdução da arquitetura corporativa na sua organização. Todas as partes interessadas são envolvidas e a rapidez necessária para este programa acelerado cria uma atmosfera dinâmica que ajuda a entregar rapidamente valor de negócio real.

Para saber mais sobre o Programa de Iniciação Rápida e como as abordagens e ferramentas da BiZZdesign e da Centus podem ajudá-lo, entre em contato conosco.

* Mark Lankhorst é Gerente de Consultoria & Evangelista-Chefe de Tecnologia da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.


eBook A Prática da Arquitetura Corporativa


Para saber mais como a Arquitetura Corporativa pode ajudar a sua organização a vencer os desafios de um mercado cada vez mais exigente, baixe o eBook A Prática da Arquitetura Corporativa, um oferecimento da BiZZdesign e Centus Consultoria.

Avaliação de Riscos baseada em Arquitetura Corporativa com ArchiMate

postado em 18 de dez de 2018 09:14 por Antonio Plais   [ 18 de dez de 2018 09:15 atualizado‎(s)‎ ]

Originalmente postado por Henk Jonkers*, no blog da BiZZdesign - Tradução autorizada

Até pouco tempo, a segurança da TI era o domínio exclusivo dos especialistas em segurança. No entanto, nos últimos anos, as organizações começaram a compreender que os riscos relacionados com a TI não podem ser vistos em isolamento, e deveriam ser considerados como uma parte integral do Gerenciamento de Segurança e Risco Corporativo (ERSM-Enterprise Risk and Security Management). O ERSM inclui métodos e técnicas usadas por organizações para gerenciar todos os tipos de risco relacionados com a realização dos seus objetivos.

É bastante natural colocar o ERSM no contexto da Arquitetura Corporativa, que fornece uma visão holística sobre a estrutura e o desenho da organização. Assim sendo, não é uma surpresa que métodos de arquitetura corporativa, tais como o TOGAF, incluam capítulos sobre risco e segurança (embora a integração destes tópicos com a abordagem geral ainda esteja aberta para melhorias), e frameworks de segurança, como o SABSA, mostram uma notável similaridade com o framework Zachman para Arquitetura Corporativa. E, como um corolário, também faz muito sentido usar a linguagem ArchiMate para modelar os aspectos de risco e segurança.

Em uma postagem anterior, apresentamos um método para o gerenciamento de risco e segurança corporativo com ArchiMate. Esta postagem propõe um mapeamento inicial dos conceitos de risco e segurança para conceitos do ArchiMate, e ilustra como estes conceitos podem ser usados como uma base para realizar uma avaliação de risco no nível corporativo.

Mapeamento dos conceitos de risco para o ArchiMate

A maioria dos conceitos usados nos padrões de ERSM pode ser facilmente mapeada para conceitos existentes do ArchiMate. E, uma vez que o ERSM está preocupado com os riscos relacionados com a realização dos objetivos de negócio, estes são principalmente conceitos da do aspecto de motivação.
  • Qualquer elemento central representado na arquitetura pode ser um ativo, i.e. alguma coisa de valor suscetível a perdas que a organização quer proteger. Estes ativos podem ter vulnerabilidades, o que pode torná-los alvo de ataques ou perda acidental.
  • Uma ameaça pode resultar em eventos de ameaça, mirando as vulnerabilidades dos ativos, e podem ter um agente de ameaça associado, i.e., um ator ou componente que (intencionalmente ou não) causa a ameaça. Dependendo da capacidade da ameaça e da vulnerabilidade, a ocorrência de uma ameaça pode ou não levar a um evento de perda.
  • Risco é uma avaliação (qualitativa ou quantitativa) da perda provável, em termos de frequência do evento de perda e da magnitude provável da perda (informalmente, 'probabilidade vezes impacto').
  • Com base nos resultados da avaliação de risco, podemos decidir aceitar o risco ou estabelecer objetivos de controle (i.e. requisitos de segurança de alto nível) para mitigar o risco, levando a requisitos para medidas de controle. A seleção das medidas de controle podem ser guiadas por princípios de segurança previamente definidos. Essas medidas de controle são realizadas por qualquer conjunto de elementos centrais, tais como processos de negócio (por exemplo, processos de gerenciamento de riscos), serviços de aplicativo (por exemplo, serviços de autenticação) ou nós (por exemplo, um firewall).

Mapeamento dos conceitos de risco para o ArchiMate

Usando um dos mecanismos de extensão descritos no padrão ArchiMate, atributos relacionados ao risco podem ser atribuídos a estes conceitos. A taxonomia FAIR (Factor Analysis of Information Risk), adotada pelo The Open Group, fornece um bom ponto de partida para isso.

Avaliação de Risco Qualitativa

Se houver estimativas acuradas suficientes para os valores de entrada, a análise de riscos quantitativa fornece a base mais confiável para a tomada de decisão baseada em riscos. No entanto, na prática, estas estimativas são geralmente difíceis de se obter. Assim sendo, o padrão FAIR propõe uma avaliação de risco baseada em métricas qualitativas (discretas), por exemplo, capacidade da ameaça variando de 'muito baixa' até 'muito alta', e risco variando de 'baixo' até 'crítico'. A figura abaixo mostra como estes valores podem ser ligados aos elementos do modelo ArchiMate, e como eles podem ser visualizados através de 'mapas de calor':
  • O nível de vulnerabilidade (Vuln) depende da capacidade da ameaça (TCap) e da força do controle (CS). Aplicar medidas de controle com uma força de controle alta reduz o nível de vulnerabilidade.
  • A frequência do evento de perda (LEF) depende tando da frequência do evento de ameaça (TEF) como do nível de vulnerabilidade. Uma vulnerabilidade mais alta aumenta a probabilidade de que um evento de ameaça acionará um evento de perda.
  • O nível de risco é determinado pela frequência do evento de perda e pela magnitude provável da perda (PLM).

Avaliação de Risco Qualitativa

O exemplo abaixo mostra uma aplicação simples de uma avaliação como essa. Uma avaliação de vulnerabilidades de um sistema de pagamentos em uma seguradora mostrou que o nível de encriptação dos dados de pagamentos transmitidos é baixo (por exemplo, devido a uma versão obsoleta de protocolo de encriptação). Isso possibilita um ataque do tipo 'homem-no-meio', no qual um atacante pode modificar os dados para fazer pagamentos não-autorizados, por exemplo, através da mudança da conta bancária recebedora. Para um hacker com capacidades medianas (capacidade de ameaça média) e sem medidas de controle adicionais, isso leva a uma vulnerabilidade muito alta (de acordo com a matriz de vulnerabilidade acima). Assumindo uma frequência de evento de ameaça baixa (por exemplo, uma tentativa de ataque por mês, em média), de acordo com matriz de frequência de evento de perda, a frequência de evento de perda esperada é também baixa. Finalmente, assumindo uma magnitude de perda provável alta, o nível de risco resultante á alto. Como medida preventiva, um protocolo de encriptação mais forte pode ser aplicado. Através da modificação de parâmetros, pode ser mostrado que, aumentando a força do controle para 'alto' ou 'muito alto', o risco residual pode ser reduzido para médio. Uma redução adicional deste risco requer outras medidas como, por exemplo, medidas para limitar a magnitude de perda provável.


Exemplo de análise de risco

Conclusão

Através da ligação de propriedades relacionadas com riscos aos conceitos do ArchiMate, as análises de risco podem ser automatizadas com a ajuda de uma ferramenta de modelagem, como o Enterprise Studio. Desta forma, torna-se fácil analisar o impacto das mudanças nestes valores através da organização, bem como os efeitos potencial das medidas de controle para mitigar estes riscos. Por exemplo, o impacto no negócio dos riscos causados por vulnerabilidades nos sistemas ou na infraestrutura de TI podem ser visualizados de uma forma que suporta de forma ótima a tomada de decisão dos gerentes sobre segurança.

Para conhecer mais como o ArchiMate e o BiZZdesign Enterprise Studio podem ajudar a trazer o gerenciamento de riscos e a arquitetura corporativa para a mesma plataforma, entre em contato conosco.
 



* Henk Jonkers é consultor-pesquisador da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.

Colaboração Eficiente com Métodos Ágeis

postado em 8 de dez de 2018 06:36 por Antonio Plais   [ 8 de dez de 2018 06:38 atualizado‎(s)‎ ]

Originalmente postado por Marc Lankhorst e David van Eck*, no blog da BiZZdesign - Tradução autorizada

A maioria das pessoas pensa no Scrum quando fala a respeito de colaboração dentro dos métodos Ágeis. O Scrum  tem sido definitivamente um grande fator de contribuição em direção a uma maior colaboração. Note que nos referimos a ele apenas como um fator de contribuição; o Scrum tem uma forte ênfase em aspectos pragmáticos, e menos nos fatores humanos. Nesta postagem, pretendemos realçar as conexões entre estes dois fatores dentro dos métodos ágeis.

Scrum 

Os métodos Ágeis são baseados na ideia de um desenvolvimento iterativo e colaborativo de software dentro de um limite de tempo claramente definido. Estas iterações são chamadas de 'sprints' no Scrum, uma das mais populares das metodologias Ágeis. Muitas organizações aplicam o framework Scrum porque ele é relativamente direto, e evita custos indiretos. No centro de uma organização Scrum está uma equipe multifuncional e autogovernada. Cada membro da equipe está envolvido no planejamento, na remoção de entraves e na distribuição de tarefas. A metodologia Scrum assume que todo o conhecimento necessário está disponível dentro da equipe, o que é refletido na ideia de equipe multifuncional e equipes autogovernadas. Neste sentido, os métodos Ágeis são radicalmente diferentes dos métodos clássicos em cascata, com sua bordagem linear 'de cima para baixo' baseada na divisão do trabalho e no 'grande desenho antecipado'.

O desenvolvimento ágil de software acontece nas equipes com um foco nos fluxos de valor. Isto é bastante diferente das abordagens clássicas de gerenciamento de projetos (que são uma das maiores fontes de fracassos na TI, como discutimos em uma postagem anterior). As equipes estabelecem suas próprias metas bem definidas para cada sprint, e mesmo, às vezes, para aquele dia. Metas são atingíveis e realísticas, porque os próprios membros da equipe dividem o trabalho em partes gerenciáveis, e fornecem suas próprias estimativas em relação a quanto tempo será gasto em cada tarefa. Graças a essa flexibilidade inerente, abordagem pragmática e foco nas tarefas, os membros da equipe trabalham juntos em direção a uma meta comum. Dentro de uma equipe Scrum existem poucos papéis bem definidos: o Product Owner (responsável pelo produto), o Scrum master (responsável pela aplicação correta da metodologia e facilitação) e os membros da equipe (responsáveis pelo trabalho efetivo)

Muitas organizações valorizam os métodos ágeis por causa da produtividade aumentada de suas equipes. Isso é verdade se, e quando, a metodologia é aplicada corretamente dentro de cada equipe. O que nós vemos, muito frequentemente, é que muitas organizações que aplicam a metodologia prestam pouca atenção aos fatores humanos dentro da equipe, tais como confiança, transparência, espírito de equipe, etc.

De acordo com o Scrum, qualquer equipe que preste atenção ao planejamento, refinamento do backlog (um encontro para priorizar as histórias de usuário), papéis, responsabilidades, metas, etc., trabalhará junto efetivamente como um time. Um problema importante, no entanto, é que na ausência de confiança mútua, pouco progresso será alcançado. O sucesso da equipe não é dependente apenas da aplicação racional da metodologia, mas precisa também levar em consideração o fator humano. Uma equipe poderia executar o aspecto racional do Scrum com perfeição, mas, ao final, são as pessoas que precisam fazer o trabalho, de forma que prestar atenção a estes fatores humanos é igualmente importante.

Fatores Humanos

Então, o que nós queremos dizer exatamente por "fatores humanos"? Pense sobre honestidade, confiança, o balanço entre a individualidade do membro da equipe vs a equipe como uma unidade, coragem, determinação, intuição, liderança, desenvolvimento, aprendizado a partir dos erros, gerenciamento de mudanças, motivação pressão dos pares, e por aí vai. Todas estas coisas serão vivenciadas de forma diferente por cada membro da equipe, e isso terá impacto no sucesso da equipe. Estes fatores humanos são absolutamente críticos para uma implementação bem-sucedida de métodos ágeis. A experiência nos ensina que dentro dos frameworks Ágeis, é imprescindível prestar atenção na, e estimular a, colaboração, a crítica construtiva, e a melhoria contínua, para garantir a colaboração bem-sucedida ao longo dos sprints.

Exemplo 1: Espaço necessário e flexibilidade

As equipes ágeis tipicamente consistem de vários profissionais que contribuem para um resultado final a partir da perspectiva de seu próprio conhecimento e habilidades individuais. Estes profissionais devem exibir um envolvimento aberto e engajado, o que naturalmente implica que eles devem ser excelentes na colaboração dentro da equipe. Cada profissional deve ter o espaço e a flexibilidade necessários dentro de um ambiente estruturado. Quando um profissional não tem o espaço necessário, ele ou ela não é capaz de usar o seu conhecimento e suas habilidades de forma plena. Isso reflete negativamente naquele indivíduo e na visibilidade das suas contribuições. Muitos profissionais/membros de equipes lutam com isso. É um desafio comum para muitas equipes ágeis.

Exemplo 2: Confiança

Em um arranjo ágil, a equipe mesma recebe muita atenção. Equipes ágeis são estabelecidas e os membros da equipe são alocados à equipe com base nos conhecimentos, habilidades e experiência necessários. Depois disso, o trabalho é distribuído entre as várias equipes e os vários membros de cada equipe, junto com metas específicas. A equipe completa é estabelecida e definida, mas algumas vezes os membros da equipe podem não ter confiança uns nos outros devido a diferenças de entendimento, experiências passadas ruins com um colega, ansiedade, etc. Assim, os membros da equipe podem trabalhar como indivíduos, e não como uma equipe, o que afeta o desempenho da equipe como um todo. Muitas vezes, bastante atenção é dada à estrutura das equipes, mas não tanto ao que acontece dentro daquelas equipes. Isso é, pelo menos, tão importante em termos de sucesso e resultados quanto a estrutura das equipes em si.

Lidando com Equipes Ágeis

A partir destes exemplos, torna-se claro que uma implementação ágil bem-sucedida não depende apenas do estabelecimento da estrutura correta. Fatores humanos também desempenham um papel importante. O  Scrum Master é um elemento vital na promoção da interação humana e na orientação da equipe para a aplicação de boas práticas. Ele ou ela pode fazer isso ajudando a equipe a estabelecer algumas regras de ouro. Por exemplo: preocupação em compartilhar, tão cedo e frequente quanto possível. Isso serve como um contrato entre os membros da equipe, o que estimulará a colaboração. Mais ainda, a comunicação interna sobre as regras de ouro dentro da equipe é importante. Os membros da equipe precisam de um espaço para falar sobre seus medos e enganos nas reuniões da equipe. As regras de negócio são uma ferramenta para ajudar os membros da equipe e o Scrum Master a facilitar este tipo de seção.  Esta é uma forma ideal para que os membros da equipe se tornem mais acostumados com o método Scrum.

Outra tarefa chave dentro da equipe é fornecer feedback, e equipes recém-formadas precisam praticar isso. Isso garantirá para os membros da equipe uma oportunidade para compartilhar suas histórias e opiniões pessoais. Um ambiente aberto e de confiança é criado, no qual os membros da equipe se sentem livres para discutir problemas de melhoria. O Scrum Master pode precisar, também, orientar alguns membros individuais da equipe no fornecimento de feedback. Por exemplo, quando eles são muito contidos ao fornecer feedback, ou são muito críticos em relação aos colegas.

Os métodos ágeis, mais do que os métodos tradicionais, requerem cooperação, confiança, aceitação de responsabilidades e disciplina. Os membros da equipe, juntos, são responsáveis pelo resultado geral. Como membro individual, você não pode simplesmente jogar sua parte do resultado por cima da cerca para outro membro da equipe. Desenvolvedores que preferem trabalhar sozinhos podem, assim, ter desempenho piorado em uma equipe ágil. Comportamento evasivo e solitário é fatal para uma equipe assim. Esta necessidade para comunicação aberta e clara é uma das razões pelas quais as equipes ágeis não podem ser muito grandes. Você precisa de comunicação pessoal e isso funciona melhor em uma equipe com não mais do que 7 a 10 pessoas. O papel do Scrum Master é orientar a equipe para o estabelecimento de uma cultura focada no time como esta. Este é um dos principais fatores 'suaves' para o sucesso (ou fracasso) de uma equipe ágil, especialmente com equipes inexperientes.

Conclusão

Na introdução desta postagem, destacamos como o método Scrum fornece estrutura e molda uma equipe baseada em projeto. Um ambiente ágil bem-sucedido não depende apenas dos aspectos formais (planejamento, definição de objetivos, etc.), mas também é importante levar em consideração os fatores humanos dentro da equipe. Juntar os aspectos formais e os fatores humanos no desenvolvimento de software permitirá que a organização otimize o trabalho Ágil. Na prática, infelizmente, isso ocorre muito pouco.

Em postagens futuras gostaríamos de discutir o uso de métodos ágeis no contexto de organizações grandes e intensivas de TI, com processos de negócio e panoramas de sistemas complexos. Em um contexto como esse, o relacionamento entre o gerenciamento de portfólios, a arquitetura corporativa, o desenho de processos de negócio e o desenvolvimento ágil se torna cada vez mais importante. No entanto, existem várias tensões entre estas disciplinas, tendo por um lado a sincronização dos seus vários ritmos e ciclos, e por outro lado, e talvez o mais importante, suas diferenças culturais.

Por favor, não hesite em compartilhar suas experiências e opiniões sobre o trabalho com equipes Ágeis!



* Mark Lankhorst é Gerente de Consultoria & Evangelista-Chefe de Tecnologia, e David van Eck é consultor e instrutor da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.

100 Questões para Uma Perfeita Entrevista de Emprego para Arquitetos Corporativos

postado em 7 de dez de 2018 15:58 por Antonio Plais   [ 8 de dez de 2018 05:18 atualizado‎(s)‎ ]

Originalmente postado por Raz Mitache*, no blog da BiZZdesign - Tradução autorizada

Entrevistas são onde empregos são perdidos ou ganhos. Um currículo - especialmente um bom currículo - pode lhe garantir um lugar na mesa, mas para efetivamente garantir a colocação você precisa brilhar na entrevista, o que significa que você tem que estar bem preparado. A preparação faz com que você pareça bem informado e relaxado, duas características que as pessoas e, principalmente, os selecionadores, apreciam nos seus colegas de trabalho.

Para lhe dar uma vantagem adicional nas entrevistas, nós preparamos 100 questões que o ajudarão a superar com perfeição uma entrevista de emprego para a posição de Arquiteto Corporativo. Algumas delas têm em mente arquitetos corporativos iniciantes, outras são destinadas a arquitetos corporativos com maior experiência - juntas, elas lhe darão uma boa ideia do que esperar na entrevista. Sem maior demora, aqui estão as 100 Questões para Uma Perfeita Entrevista de Emprego para Arquitetos Corporativos:
  1. Com que facilidade você pensa no panorama geral e que exemplos você pode dar onde você usou esta qualidade no seu trabalho?
  2. Por que você acha que é adequado para trabalhar na nossa empresa?
  3. Como você faz para melhorar suar rede de conexões profissionais?
  4. Você já trabalhou antes em organizações que têm uma estrutura baseada em silos, e como você lidou com isso?
  5. Qual foi a iniciativa de maior sucesso em que você participou, e como você descreveria sua participação para isso?
  6. Como você equilibra seu relacionamento com diferentes grupos de partes interessadas, especialmente aqueles que discordam das suas ideias?
  7. Como você avaliaria as suas capacidades de liderança?
  8. Qual é o papel de um arquiteto em um ambiente Ágil?
  9. Você tem alguma experiência trabalhando com algum framework de arquitetura de segurança? Se sim, quais?
  10. Onde você espera estar na sua carreira daqui a 10 anos?
  11. Você tem alguma experiência com padrões e práticas de gerenciamento de dados?
  12. Você tem alguma experiência na negociação de acordos de nível de serviço com fornecedores?
  13. Alguma vez você já falhou na entrega bem sucedida de um projeto e, se sim, o que você aprendeu com a experiência?
  14. Para onde você acredita que a disciplina da arquitetura corporativa está indo?
  15. Como você acha que deveria se parecer uma área de arquitetura corporativa após o primeiro ano de funcionamento?
  16. Quais as qualidades que você procura nos seus colegas arquitetos.
  17. Você poderia me dar uma breve descrição do que você entende por arquitetura corporativa?
  18. Na sua experiência, quais grupos de partes interessadas deveriam ser envolvidos no ciclo de vida da Arquitetura Corporativa?
  19. Em termos simples, o que é um padrão de arquitetura?
  20. Como você evoluiria a arquitetura corporativa de uma empresa que funciona em um ambiente volátil?
  21. Você poderia citar alguns desenvolvimentos técnicos recentes que são, na sua opinião, importantes que os profissionais de arquitetura corporativa conheçam.
  22. Qual é a sua opinião sobre o papel da arquitetura corporativa na tomada de decisões estratégicas?
  23. Você tem algum exemplo da sua colaboração em equipes que envolveram toda a organização?
  24. Qual é a sua experiência lidando com partes interessadas no nível executivo da organização?
  25. Como você consegue o apoio da gerência para as suas ideias?
  26. Como a arquitetura corporativa apoia a estratégia e as metas de negócio da empresa?
  27. Você poderia descrever uma prática de arquitetura corporativa madura?
  28. Você tem alguma experiência trabalhando em ambiente Ágil?
  29. Como você descreveria sua abordagem para encontrar atividades de negócio importantes para a adição de valor para a organização?
  30. Você tem experiência na construção de roteiros de evolução da arquitetura?
  31. Qual foi o projeto mais difícil em que você participou, e como você superou os desafios?
  32. Você se sentiria confortável para fazer uma avaliação de maturidade em Arquitetura Corporativa?
  33. Como você faz para garantir que uma solução está alinhada com a arquitetura?
  34. Quais as ferramentas que você já usou até agora na sua carreira?
  35. Você tem alguma experiência configurando uma função de governança de arquitetura?
  36. Você poderia descrever uma situação em que você tenha se sentido orgulhoso da sua abordagem para resolver um problema?
  37. Como você garante que os requisitos das partes interessadas de negócio estão sendo atendidos?
  38. Que métricas você usaria para demonstrar que a prática da arquitetura corporativa tem um efeito positivo no negócio?
  39. Você poderia dar exemplos de situações onde você apresentou estratégias e arquiteturas para os executivos?
  40. Quais foram alguns objetivos de negócio para os quais você contribuiu, e como você fez isso?
  41. Você possui certificação na versão mais recente do ArchiMate?
  42. Você gosta de participar na definição da estratégia de negócio?
  43. Como você faz para apontar pontos fracos ou enganos dos seus colegas?
  44. Como a arquitetura pode contribuis para o DevOps?
  45. Você realizou anteriormente alguma análise de impacto de risco?
  46. Como você responde quando um colega te corrige, e você acha que um arquiteto júnior pode corrigir alguém mais experiente?
  47. Como você encoraja a colaboração interdepartamental?
  48. Você poderia me dar uma breve visão geral do TOGAF?
  49. Qual é a sua experiência com métodos e frameworks Ágeis?
  50. Como uma prática de arquitetura corporativa se difere em diferentes culturas organizacionais?
  51. Você poderia fornecer um exemplo de implementação bem-sucedida de uma solução que reduziu os custos para o negócio?
  52. Você poderia definir resumidamente Gerenciamento de Serviços de TI?
  53. Como você posicionaria a arquitetura de negócio em relação à arquitetura corporativa?
  54. Você tem alguma experiência na introdução de um novo padrão em um Departamento de Arquitetura Corporativa?
  55. Alguma vez você orientou uma organização para sair de uma crise usando arquitetura?
  56. Você poderia definir resumidamente Gerenciamento de Portfólio de Aplicativos?
  57. Em quais tendências tecnológicas você está mais interessado atualmente?
  58. Como você mantém suas competências e se mantém atualizado em relação às últimas tendências na TI?
  59. Você tem alguma experiência com uma ferramenta de modelagem?
  60. Você poderia descrever como você usou fluxos de trabalho em uma posição anterior para melhorar a sua entrega de resultados?
  61. Cite alguns grupos de partes interessadas fora da área de Arquitetura Corporativa com os quais você interagiu enquanto trabalhava em um projeto.
  62. Em quais áreas da Arquitetura Corporativa você tem mais experiência?
  63. Você tem alguma experiência com alguma ferramenta certificada de modelagem ArchiMate?
  64. Você possui certificação na versão mais recente do TOGAF?
  65. Você poderia descrever a prática de Arquitetura Corporativa mais madura que você já utilizou?
  66. O que os arquitetos corporativos fazem para maximizar o valor que eles trazem para o ambiente Ágil?
  67. O que você faria para elevar a maturidade de uma organização em Arquitetura Corporativa?
  68. O que você entenderia por arquitetura “Just in time, just enough” (no tempo certo, apenas o suficiente)?
  69. Qual a sua opinião sobre microserviços?
  70. Você tem experiência com a migração de aplicativos para a nuvem?
  71. Você teve alguma experiência com planejamento baseado em capacidades nos seus empregos anteriores?
  72. O que é ArchiMate?
  73. Você pode fornecer alguns exemplos de como você ajudou a identificar ameaças de segurança e entregou controles para mitigá-las?
  74. Você tem experiência com Arquitetura Orientada para Serviços?
  75. Quais os aspectos que você levaria em consideração para avaliar a maturidade em Arquitetura Corporativa de uma organização?
  76. Qual a sua experiência no uso do ArchiMate?
  77. Você poderia citar alguns exemplos de Informação Pessoalmente Identificável?
  78. Você tem alguma experiência de trabalho com o ITIL?
  79. Você poderia descrever resumidamente Arquitetura de Negócio?
  80. Você alguma vez trabalhou na melhoria da experiência do cliente através da arquitetura?
  81. Você poderia descrever brevemente a arquitetura de segurança?
  82. Você tem alguma experiência na mentoria de arquitetos menos experientes?
  83. O que você sabe sobre a LGPD-Lei Geral de Proteção de Dados Pessoais?
  84. Você pode explicar a diferença entre desenho orientado para objetos e desenho orientado para aspectos?
  85. Qual o programa de melhoria de arquitetura tecnológica mais abrangente no qual você teve participação e como você contribuiu para o seu sucesso?
  86. Como você descreveria a sua experiência com o uso de mapas da jornada do cliente?
  87. Alguma vez você testemunhou pessoalmente uma quebra de segurança e, se sim, o que essa experiência lhe ensinou?
  88. Quais os aspectos que você mudaria na forma como os arquitetos corporativos geralmente fazem o seu trabalho?
  89. Você acha que existe uma camada da arquitetura que seja menos importante para a organização?
  90. Você pode compartilhar um exemplo de uma prática bem sucedida de Gerenciamento de Portfólio em que você tenha participado, e descrever seu papel e contribuição para o seu sucesso?
  91. Qual o papel das arquiteturas de referência?
  92. Para que propósitos você usaria as linguagens de modelagem ArchiMate, BPMN e UML, e como você as relacionaria?
  93. Quais são, na sua opinião, os fatores de previsão de sucesso mais importantes durante um projeto?
  94. Você seria capaz de descrever sucintamente o papel de um arquiteto de soluções durante o ciclo de vida do desenvolvimento de software?
  95. Quais são os melhores aspectos do seu trabalho?
  96. Você participou alguma vez de um projeto de implementação de IoT-Internet das Coisas?
  97. Você já realizou alguma vez uma análise de cenários para orientar decisões de investimento?
  98. Você tem alguma experiência de implementação de um programa de conformidade com a LGPD-Lei Geral de Proteção de Dados Pessoais?
  99. Quais visões arquiteturais do TOGAF você considera especialmente relevantes em uma prática de arquitetura corporativa de baixa maturidade?
  100. Você pode fornecer um exemplo de como você se ajustou com sucesso a uma mudança inesperada nos objetivos de um projeto?
Nós cremos que responder a estas perguntas antecipadamente permitirão que você esteja preparado para enfrentá-las sem se sentir pressionado durante uma entrevista real para uma posição de arquiteto corporativo e aumentarão as suas chances de sucesso. Para aprender mais sobre o estado atual da transformação digital e como é importante que as empresas se tornem mais adaptativas, fique à vontade para baixar nosso eBook abaixo. 

http://bizzdesign.centus.com.br/biblioteca/ebooks/empresa_adaptativa
Nós publicamos o eBook 'A Empresa Adaptativa - Prosperando em uma Era de Mudanças', no qual explicamos nossa visão dos desafios da mudança e do controle em empresas complexas, e descrevemos as capacidades necessárias para lidar com isso em maiores detalhes. 
Clique no link para solicitar sua cópia grátis deste eBook.






Raz Mitache é Consultor da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.

Escapando das Garras do Mostro dos Projetos

postado em 29 de out de 2018 12:10 por Antonio Plais   [ 29 de out de 2018 12:24 atualizado‎(s)‎ ]

Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign - Tradução autorizada

Há algum tempo, enquanto eu estava refletindo sobre as razões pelas quais muitas grandes organizações vêm a maioria das suas iniciativas de TI falharem ou não atingirem seus objetivos, eu cheguei a uma conclusão muito simples: o 'pensamento em projetos' é a causa-raiz destes desapontamentos. Deixe-me explicar melhor.

O princípio básico por trás de uma abordagem por projetos é que cada projeto tem uma meta clara, um orçamento fixo, um início, uma data de entrega, e um resultado concreto. Uma razão importante para esta abordagem é que ela dá à gerência um sentimento de governança através da ilusão de controle: eles pensam que eles sabem no início o que eles receberão no final, eles podem medir o progresso através do controle dos gastos, e eles podem culpar alguém (isso é, o gerente do projeto) quando as coisas dão errado. Uma vez que os projetos são temporários, a gerência de linha não se sentem responsáveis por eles. Eles podem transferir (e culpar) para os gerentes de programa e de projetos as decisões que eles deveriam tomar!

A abordagem por projetos apresenta várias outras desvantagens, também: novas equipes que precisam se familiarizar com o problema e a solução proposta; uma burocracia autoritária imposta pela insistência da gerência em usar métodos como PRINCE2 ou PMI (porque eles são 'as melhores práticas da indústria'); os momentos de início e parada requeridos por estes métodos, que interrompem o progresso e atrasam os projetos; a construção de funcionalidades apenas porque elas fazem parte do plano do projeto, não porque elas são realmente necessárias; e por aí vai...

Mais ainda, tais abordagens só funcionam (se funcionam!) em circunstâncias estáticas. No ambiente de negócios complexo e em constante mudança dos dias de hoje, os clientes de um projeto em geral não podem dar uma declaração clara sobre o que eles querem ou precisam ('Eu vou saber quando eu vir'). E mesmo que eles (pensem que) possam, essas metas começam a mudar mesmo antes do projeto tomar forma. O gerenciamento clássico de projetos vê este 'estouro de escopo' como uma ameaça ao sucesso do projeto. Como uma reação, os gerentes de projeto defendem o seu escopo construindo barreiras, excluindo requisitos importantes e influências externas relevantes. Assim, a satisfação do usuário é inalcançável e o fracasso está garantido.

Escopo

Para tornar as coisas piores, o próprio escopo é definido de forma muito ampla. Sem a aplicação apropriada da separação de preocupações, os projetos são definidos como solução para problemas de governança ou de negócio através da construção de um grande 'aplicativo' ou 'sistema'. Além da falácia do otimismo tecnológico, o que discutiremos em outra oportunidade, esta abordagem falha com uma grande explosão se a menor peça deste quebra-cabeças não se encaixar. Se você define um projeto monstruoso, o monstro dos projetos vai te devorar...

Finalmente, existe uma ideia de que um projeto de TI tem um momento de 'entrega', quando o resultado está terminado e pronto para uso. Como nós todos sabemos, mais de 80% dos gastos com TI nas grandes organizações está alocado na 'manutenção'; este é um conceito difuso, uma vez que isso normalmente significa adicionar novas funcionalidades e, então, como pode ser diferente de 'desenvolvimento'?

O Caminho Adiante

Nós deveríamos parar de tratar as mudanças como exceção, a serem tratadas através de programas e projetos que são realizados fora das operações 'normais'. As organizações no 'Novo Normal' estão em um estado constante de fluxo. Como o Gartner declarou em uma palestra no ITXpo 2013 (talvez com um pouco de otimismo):

"Em 2017, todas as empresas serão digitais. As capacidades para mudar rapidamente e permanecer ágil serão imperativas".

Precisamos adotar uma abordagem mais holística para o ciclo de vida completo da TI e das capacidades e recursos do negócio, deixando para trás essa distinção artificial entre 'construção' e 'manutenção'. O panorama de negócio e de TI devem ser vistos como um portfólio de elementos, cada um com seu próprio valor de negócio, ciclo de vida e ritmo de evolução. Nós podemos alocar e realocar o orçamento para estas capacidades e recursos com base no seu valor de negócio esperado e mensurado. Respeitando o seu ritmo e reagindo com fluidez às influências externas, podemos criar organizações mais ágeis que estejam em sintonia com o seu ambiente.

Várias práticas do movimento Ágil são passos nesta direção. Iterações curtas em interação próxima com o cliente, entrega contínua com práticas DevOps, e a abordagem 'sempre em beta' de empresas como o Google, Netflix e Spotify são exemplos disso. Métodos de gerenciamento como o Lean e o Kaizen também adotam esta postura de melhoria contínua e de ciclo de vida. O conceito de 'fluxo de valor', como adotado por abordagens como o Scaled Agile Framework (SAFe), é também um passo importante na direção correta.

Nós defendemos o uso da Arquitetura Corporativa como um eixo de conhecimento de negócio para conectar as várias disciplinas envolvidas na mudança das organizações. A Arquitetura Corporativa ajuda a integrar e compartilhar informações sobre as várias estruturas através da sua organização. Ela fornece entradas relevantes para priorizar e planejar as transformações. Ela fornece coordenação no nível dos programas através dos fluxos de valor para realizar aquelas mudanças de uma maneira coerente. Ela ajuda você a acompanhar a realização dos benefícios esperados e, assim, corrigir o rumo se necessário. Fortemente relacionado com isso, o gerenciamento de portfólio corporativo permite que você adote uma abordagem baseada em valor para gerenciar os ativos e as iniciativas de mudança na sua organização. Isso ajuda a manter tudo alinhado com os resultados de negócio esperados, o que deveria, naturalmente, estar focado no cliente ou no cidadão.

A Arquitetura Corporativa como um eixo de conhecimento de negócio

CEOs e CIOs com um olhar no futuro estão começando a pensar em formas diferentes de organizar e gerenciar a evolução das capacidades das suas organizações. Ao longo dos últimos anos, temos conversado com vários gerentes em organizações nos setores de seguros, bancário e governamental que descobriram que é necessária uma nova forma de trabalho. Eles estão construindo sua capacidade de mudança com base em uma abordagem de fluxo de valor, ciclo de vida e entrega contínua, focados em entregar e desenvolver um portfólio de capacidades de negócio. Vamos torcer para que outras organizações sigam o seu exemplo e escapem das garras do monstro dos projetos. Nós, da Centus-BiZZdesign estamos prontos para ajudar nossos clientes para construir esta capacidade de transformação de negócio.
 

* Mark Lankhorst é Gerente de Consultoria & Evangelista-Chefe de Tecnologia da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.


 
http://bizzdesign.centus.com.br/biblioteca/ebooks/apm
eBook Gerenciamento do Portfólio de Aplicativos

As organizações são desafiadas por uma crescente necessidade de mudanças em um ambiente em constante pressão. A TI desempenha um papel crucial nesta mudança. Para realizar a necessária transformação digital, as organizações precisam desenvolver e executar uma estratégia de aplicativos que racionalize seu portfólio de sistemas legados e, ao mesmo tempo, prepare para requisitos de negócio e novas tecnologias que estão surgindo rapidamente.  

Solicite sua cópia GRÁTIS aqui

1-10 of 89