Arquitetura Corporativa
Combinando o ArchiMate 3.0 com Outros Padrões - BMM / BS / BMC
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 - BMMO 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.
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 - BSIndicadores 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.
Canvas do Modelo de Negócio - BMCO 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.
Relacionando diferentes modelos no BiZZdesign Enterprise StudioO 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).
 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.
|
Combinando o ArchiMate 3.0 com Outros Padrões - Introdução
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.  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.  |
Arquitetura de Negócio no Novo Normal
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:
"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?
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
 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.
 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
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 velocidadeArquitetos 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
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
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.
Clique aqui para solicitar sua cópia grátis deste eBook.
|
Entregando Valor de Negócio Rapidamente com TOGAF
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 PartidaAntes 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 FrameworkTendo 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 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:
O Apoio do Programa de Iniciação RápidaPara 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:
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. |
Avaliação de Riscos baseada em Arquitetura Corporativa com ArchiMate
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 ArchiMateA 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.
 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 QualitativaSe 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':
 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ãoAtravé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
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. ScrumOs 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 HumanosEntã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 flexibilidadeAs 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çaEm 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 ÁgeisA 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ãoNa 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
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:
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. Clique no link para solicitar sua cópia grátis deste eBook.
|
Escapando das Garras do Mostro dos Projetos
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.
EscopoPara 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 AdianteNó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.
|
Material em Português sobre a Linguagem ArchiMate no site do The Open Group
ArchiMate® 3.0.1 Specification (Brazilian Translation)
A Pocket Guide to the ArchiMate® 3.0.1 Specification (Brazilian Translation)
An Introduction to the ArchiMate® 3.0.1 Specification (Brazilian Translation)
How to Use the TOGAF® 9.1 Architecture Content Framework with the ArchiMate® 3.0.1 Modeling Language (Brazilian Translation)
Using the TOGAF® 9.1 Framework with the ArchiMate® 3.0 Modeling Language (Brazilian Translation)
ArchiSurance Case Study, Version 2 (Brazilian Translation)
ArchiMetal Case Study, Version 2 (Brazilian Translation)
ArchiMate® 3.0 Reference Cards (Brazilian Translation)
ArchiMate® 3.0 Translation Glossary: English – Brazilian Portuguese |
1-10 of 89