Arquitetura Corporativa


Arquitetura Corporativa para Tomadores de Decisão: Sete Conselhos

postado em 21 de mai de 2019 04:35 por Antonio Plais   [ 21 de mai de 2019 04:40 atualizado‎(s)‎ ]

Originalmente postado por Remco Blom* no blog da BiZZdesign. Tradução, adaptação e reprodução autorizados.

A maioria dos arquitetos corporativos acredita que a Arquitetura Corporativa é uma disciplina relevante para os membros da Diretoria. No entanto, os CxO's geralmente não compartilham desta mesma opinião. Nós acreditamos que isso acontece porque eles normalmente não experimentam o verdadeiro valor da arquitetura. O que os arquitetos podem fazer para melhorar isto? Abaixo, nós apresentamos sete conselhos úteis.

1. Construa ativamente a conscientização

Forneça algum contexto para a sua audiência: conecte as questões arquiteturais com o mundo real. Pessoas, aplicativos, problemas aqui e agora, são mais fáceis de ser compreendidos e mais vívidos do que caixas e linhas abstratas. Os tomadores de decisão dificilmente tomam decisões por si só. Considere-os como uma Unidade de Tomada de Decisão (UTD), e influencie outras UTD's em torno do principal decisor usando mensagens da arquitetura corporativa. Torne isso pessoal. Encontre os executivos em entrevistas, encontros do departamento e em ambientes informais para conhecê-los e investir no relacionamento.

2. Arquitetura Corporativa tem a ver com investimentos

Não foque demais na construção da solução, mas, ao invés disso, posicione a Arquitetura Corporativa próximo do portfólio de investimentos. Seja ativo e ajude no início dos projetos, considere problemas (amplos) de integração e construa a confiança. Você pode trazer o aspecto da qualidade e da agenda de longo prazo para as discussões do portfólio.

3. Apresente problemas concretos e resultados concretos

Ilustre os problemas e as opções com casos de uso reais. "Este é o paciente João, que foi internado devido a um ataque do coração. Nós não conhecemos João, nós não sabemos qual é o seu uso de medicamentos, nós não temos seu eletrocardiograma mais recente. Naturalmente, faremos o que for possível, mas isso é o ideal?". Associe histórias como essa com os problemas que a empresa enfrenta e como a falta de informação (que poderia ser fornecida pela arquitetura) pode prejudicar a sua evolução.

4. Foque nos efeitos da arquitetura, não nos métodos ou na arquitetura em si

Padrões importantes de Arquitetura Corporativa, como TOGAF, ArchiMate, e mesmo BPMN, são realmente importantes para amadurecer a sua prática de arquitetura corporativa. Mas eles não são nem um pouco interessantes para os tomadores de decisão... Apresente cenários, forneça aconselhamento, e deixe os tomadores de decisão fazer o que eles fazer de melhor: tomar decisões.

5. Mostre o dinheiro, o risco e o tempo

A construção da solução atrai muito pouco o interesse dos executivos. A maioria gosta de falar sobre dinheiro (tanto o custo como as receitas potenciais), riscos e velocidade. Você pode mostrar isso como uma camada acima dos seus modelos?

6. Use diagramas simples

Um diagrama complexo, também conhecido como teia de aranha, é muito útil para mostrar como o seu panorama é complexo. Mas não espere que o seu gerente vá se interessar muito por ele. Rascunhos simples, atrativos, começando com uma perspectiva de negócio, têm se provado funcionar muito bem na Diretoria. Nós temos muitos bons exemplos de Modelos de Negócio como pontos iniciais de uma (efetiva) discussão sobre arquitetura corporativa.

7. Faça isso passo-a-passo

Comece sendo orientado para a solução (dos projetos), então evolua para ser orientado para os problemas/resultados (em programas como "racionalização de aplicativos", por exemplo), e mova para ser orientado para a estratégia. Mereça a sua posição, não reclame por ela!

Esperamos que estas dicas possam ajudá-lo a ter mais sucesso para criar a compreensão e o comprometimento da sua organização com a Arquitetura Corporativa. Se sentir necessidade, entre em contato conosco para compartilhar suas dores e conversar sobre como enfrentá-las com sucesso.



*Remco Blom é consultor sênior e especialista em melhoria de processos e segurança da informação na BiZZdesign

Modelagem ArchiMate na Prática: Usando um Repositório de Modelos

postado em 16 de mai de 2019 04:49 por Antonio Plais   [ 16 de mai de 2019 04:50 atualizado‎(s)‎ ]

Originalmente postado por Sven van Dijk*, no blog da BiZZdesign - Tradução e adaptação autorizadas

Em teoria, um modelo ArchiMate pode ser criado usando apenas papel e caneta, ou um quadro branco e marcadores. Também existem plataformas de software que fornecem um ambiente de modelagem ArchiMate, e que fornecem várias capacidades automatizadas e funções de análise.

No entanto, nesta postagem focaremos em um elemento importante para o amadurecimento da sua capacidade de modelagem avançada e de missão crítica: o repositório de modelos.

O repositório de modelos

O ArchiMate é usado para descrever e analisar múltiplas perspectivas da empresa, incluindo os estados atual (as-is) e futuro (to-be) da arquitetura, e para planejar os passos possíveis entre eles. Isso é muito útil, uma vez que o foco principal da Arquitetura Corporativa é suportar iniciativas de mudança.

Embora existam vários métodos, técnicas e melhores práticas para serem seguidas, isso ainda não é uma tarefa simples de executar. Isso acontece porque ela geralmente envolve várias pessoas trabalhando em equipes diferentes para atingir o mesmo objetivo: construir um modelo integrado da arquitetura corporativa.

Um repositório centralizado para suportar e organizar os esforços de modelagem é indispensável. O repositório em si pode tomar a forma de um banco de dados, mas não necessariamente. Muitas organizações usam sistemas de gerenciamento de documentos para implementar um (parte do) repositório para artefatos de arquitetura corporativa.

Um aspecto central do conceito de repositório é o reuso de modelos e de informações. No repositório de modelos ArchiMate os objetos são armazenadas uma única vez, e podem ser reutilizados em outros diagramas nos quais o objeto seja relevante. O repositório atua como um local central de armazenamento de todos os objetos, relacionamentos e atributos de informação, onde o modelo é mantido atualizado.

Isso torna a modelagem ArchiMate baseada em repositório fundamentalmente diferente daquela usando ferramentas de desenho: a habilidade de reusar objetos resulta em um enorme aumento na produtividade.

Uma vez que o repositório reúne informações de diferentes áreas, perspectivas e estados da empresa, a análise integrada pode ser realizada. A inclusão de dados quantitativos e/ou qualitativos como atributos dos objetos resulta em análises de alto nível muito interessantes. Os exemplos incluem informações de segurança para objetos de infraestrutura, ou indicadores de desempenho (KPIs) para componentes de aplicativo ou processos de negócio.

Usando as extensões do ArchiMate, as informações sobre os requisitos e o planejamento dos projetos podem também ser incluídas no repositório, relacionadas com a arquitetura, e fazer parte das suas análises. Desta forma, os modelos ArchiMate se tornam muito mais do que uma coleção coerente de objetos, relacionamentos e visões; ele se torna um "Corpo de Conhecimento Corporativo" integrado.

Configurando um repositório de modelos

A melhor abordagem para configurar um repositório de modelos é "pensar grande, começar pequeno".
 
Configurar um repositório centralizado se torna uma necessidade assim que os níveis iniciais de maturidade na modelagem ArchiMate é alcançado, tipicamente em dois ou mais "domínios" (e.g. informação, aplicativos, negócio e/ou tecnologia). Isto não é apenas um exercício técnico; os fatores pessoas e processos também precisam ser considerados. 

Principais considerações quando configurando um repositório de modelos

Pessoas

Uma imagem clara deveria ser estabelecida em torno de quem modela o que, e os problemas em torno da propriedade do conteúdo dos modelos deveria ser endereçada. Isso deveria estar claramente definido e documentado, por exemplo, usando matrizes RACI. Se você estiver usando uma solução de repositório automatizada, a estrutura organizacional para a modelagem ArchiMate pode ser implementada como níveis de acesso baseados em papéis.

Outra questão importante é fornecer orientação sobre o uso específico da linguagem ArchiMate na organização. Introduzir um Guia de Estilo de Modelagem evita o surgimento de "dialetos" e o uso de níveis incompatíveis de modelagem através dos vários domínios. A mesmo tempo, o Guia de Estilo promove o uso de padrões de modelos reusáveis específicos da organização como parte (dos domínios) das arquiteturas.

Processo

Processos de governança, papéis e responsabilidades deveriam ser identificados e documentados. Isso pode ser feito usando formatos tradicionais, incluindo fluxogramas e organogramas. O processo de governança deveria indicar a sequência de atividades usada pela organização para configurar e manter o repositório de arquitetura.

É necessário definir, também, processos de revisão para manter um alto nível de qualidade, tanto em termos de consistência como de acurácia do conteúdo dos modelos, bem como dos dados nos atributos.

Tecnologia

Como mencionado anteriormente, um repositório de modelos ArchiMate pode ser implementado por meio do uso de vários tipos de tecnologia. O BiZZdesign Enterprise Studio oferece um repositório de modelos central e integrado, que fornece funcionalidade sofisticada. O repositório é flexível e configurável, permitindo implementar v´rias estruturas organizacionais e de governança para a modelagem ArchiMate.

Um bom repositório tem várias capacidades para gerenciar e publicar o conteúdo dos modelos, incluindo o gerenciamento de versões, funcionalidade de check-in/check-out, e autorizações baseadas em papéis. No repositório de modelos, diferentes estados (as-is, to-be), bem como versões (rascunho, em revisão, publicado, etc.) podem ser descritas.

Conclusão

Um repositório de modelos ArchiMate é indispensável para o gerenciamento e a governança efetivos das atividades de modelagem das equipes de arquitetura. A adoção e implementação de um repositório de modelos ArchiMate deveria ser encarado como um projeto em si, dando atenção não somente à tecnologia, mas também às pessoas e aos processos envolvidos. Uma estratégia baseada em "pense grande, comece pequeno" tem se provado muito bem-sucedida, pelo menos na nossa experiência.
 

Para saber mais e ver o Enterprise Studio em ação, entre em contato e solicite uma demonstração.


* Sven van Dijk é consultor, da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.

Crie seus Registros GDPR e LGPD com o BiZZdesign Enterprise Studio

postado em 13 de mar de 2019 17:17 por Antonio Plais   [ 14 de mar de 2019 03:31 atualizado‎(s)‎ ]

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

As empresas precisam criar e manter registros do porquê, onde e como eles estão processando dados pessoais dos seus clientes, parceiros, funcionários ou, no fundo, de qualquer pessoa, de acordo com regulações como o General Data Protection Regulation-GDPR, da União Europeia, ou com a Lei Geral de Proteção de Dados Pessoais-LGPD, no Brasil. Criar e manter estes registradores no BiZZdesign Enterprise Studio ajuda a garantir que você está criando registros coerentes e consistentes que se conformam com o desenho da arquitetura da sua empresa. Nesta postagem, gostaríamos de mostrar como usar o BiZZdesign Enterprise Studio para suportar este caso de uso específico da proteção de dados pessoais: a criação e manutenção de registros de todos os dados pessoais mantidos e processados pela empresa.

GDPR e LGPD

O General Data Protection Regulation (GDPR) é uma regulação bastante restritiva da União Europeia sobre a  proteção da privacidade, que entrou em efetividade em maio de 2018. A LGPD é a regulação brasileira correspondente, em vigor desde agosto de 2018 e com efetividade marcada para agosto de 2020. Em uma postagem anterior, nós destacamos os seguintes pontos sobre o GDPR, e que são também válidos para a LGPD:
  1. O GDPR se aplica a todas as empresas que processam dados de residentes na União Européia. A LGPD se aplica principalmente aos residentes no Brasil, além de alguns casos especiais
  2. O GDPR, assim como a LGPD, tem a ver com a demonstração da conformidade
  3. O GDPR e a LGPD esperam que você registre o propósito da coleta dos dados pessoais
  4. O GDPR e a LGPD requerem uma abordagem integrada de segurança-por-desenho
  5. O GDPR requer uma Avaliação de Impacto sobre a Proteção de Dados para qualquer alteração significativa nas condições de processamento dos dados pessoais, ao passo que na LGPD este requisito, embora existente, não seja tão claro
  6. O GDPR força a comunicação de vazamentos de informações dentro de 72 horas, enquanto a LGPD não estabelece explicitamente um prazo para comunicação
  7. A não conformidade com a regulação pode acarretar pesadas multas, de até 4% do faturamento, no caso do GDPR, e até 2% de faturamento limitado a R$50 milhões, no caso da LGPD
Alguns destes pontos terão impacto principalmente nos (desenhos dos) processos (itens 4, 5 e 6), enquanto outros mais impacto sobre o que e como você registra dados pessoais, e onde, como e porque você processa estes dados (itens 1,2 e 3).

Como muitas empresas estão lutando para implementar e se conformar com a LGPD e o GDPR, a Centus e a BiZZdesign desenvolveram uma solução prática para endereçar alguns dos problemas mencionados acima.

Registros

Uma forma prática para implementar alguns dos requisitos da LGPD e do GDPR é criar um registro de todos os processamentos de dados pessoais dentro da sua empresa. Tal registro poderia facilmente ser uma planilha, contendo todos os dados necessários. Tal registro poderia conter os seguintes itens, por exemplo:
  1. Nome da atividades de processamento
  2. Porque você está processando estes dados
  3. As bases legais para este processamento
  4. Alguma explicação adicional
  5. Quem está envolvido (internamente)
  6. Quem é responsável internamente
  7. Qual dado é processado
  8. Categorias especiais de dados
  9. De onde este dado foi obtido
  10. Categorias de terceiros recebedores dos dados
  11. Outros terceiros recebedores dos dados
  12. Período de retenção
  13. Contrato de processamento
  14. Tipo de processamento
  15. Aplicativos envolvidos
  16. Avaliação de impacto de privacidade necessária
Você poderia escolher manter este registro completo disponível apenas internamente e criar um registro com menos itens para divulgação pública, se necessário.

Como criar um registro como esse com o BiZZdesign Enterprise Studio

Para criar e manter um registro como esse, nós aconselhamos fortemente não criar um registro separado, mas integrar as informações necessárias nos seus modelos de arquitetura corporativa no Enterprise Studio. Em geral, você precisa dar os seguintes passos:

Figura 1. Passos para criar um registro no Enterprise Studio

Criar uma extensão do modelo

Use o metamodelador do Enterprise Studio para estender seu metamodelo atual com os atributos mencionados acima. Nós escolhemos adicionar um perfil (profile) especial com os atributos necessários ao conceito Componente de Aplicativo do ArchiMate. Depois, nós precisamos criar estereótipos para os Objetos de Dados e Atores de negócio para distinguir as categorias de dados, dados especiais e terceiros. Após aplicar o novo metamodelo ao repositório o perfil se parecerá com isso:


Figura 2. Perfil GDPR para o conceito ArchiMate Processo de Aplicativo

Modelar e adicionar os dados

A coleta de todos os dados sobre o processamento de dados pessoais na sua empresa é a parte mais difícil. Talvez você possa alavancar avaliações que você já tenha feito. Na próxima figura você pode ver um exemplo de um cenário de processamento de dados modelado.

Figura 3. Modelagem de um processamento de dados, incluindo os aplicativos, dados e atores envolvidos

Criar a exportação

Use a poderosa funcionalidade de exportação do Enterprise Studio para criar uma exportação dos dados para uma planilha Excel. Os princípios para criar uma importação (veja aqui) também podem ser usados para criar uma exportação. Você pode escolher desenvolver dois tipos de exportação, uma com o registro completo e outra apenas com as informações públicas.

Figura 4. Configuração da exportação do registro

Publicar o registro

Agora, você pode publicar o seu registro. Uma parte da planilha resultante pode ser vista abaixo. Se você implementou um processo de gestão de mudança adequado, você só tem que atualizar o modelo e publicar um registro atualizado de vez em quando (ou quando solicitado pelas autoridades).


Figura 5. Registro exportado para uma planilha Excel (clique para ampliar)

Veja isso em ação

Nós esperamos haver inspirado você a alavancar os seus modelos de arquitetura existentes (ou iniciar aquele tão adiado projeto de modelagem!) e adicionar ao seu repositório as informações necessárias para atender aos requisitos do GDPR e da LGPD sobre o processamento de dados pessoais. Se você ainda não viu o Enterprise Studio em ação, entre em contato e solicite uma demonstração.


*Joost Niehof é consultor de sucesso do cliente com foco em melhoria de processos, gestão de riscos e segurança da informação na BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.


 
Webinar Don't let the GDPR be a loose cannon - Are you ready?

Joost Niedorf, Consultor de Sucesso do Cliente da BiZZdesign, e especialista em gerenciamento de riscos, segurança e conformidade, apresenta neste webinar os principais requisitos e dificuldades para o atendimento de regulações como o GDPR (e que também são válidos para a LGPD).

Veja como um repositório de arquitetura corporativa, flexível e baseado na linguagem ArchiMate, pode ajudá-lo a superar este desafio.

Nós somos diferentes! Mas, nós somos realmente diferentes?

postado em 11 de mar de 2019 04:17 por Antonio Plais   [ 11 de mar de 2019 04:52 atualizado‎(s)‎ ]

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

"Muitas partes interessadas consideram suas organizações como únicas". Dependendo do nível de abstração que você toma como ponto de vista, você pode argumentar que esta afirmação tanto pode estar certa como pode estar errada. É interessante compreender, a partir de um ponto de vista da arquitetura corporativa, por que as partes interessadas reforçam esta unicidade e quais os benefícios de entender onde a sua organização realmente é diferente das outras. Esta postagem usa organizações de saúde como exemplo, mas as ideias apresentadas são válidas para qualquer organização, em qualquer indústria.

Genérico x Específico

Um arquiteto em uma organização tem dois desafios importantes (entre outros):
  1. Aplicar arquiteturas (e soluções) genéricas para problemas específicos
  2. Desenhar soluções e arquiteturas específicas de uma forma genérica, de forma que estas possam ser úteis em situações futuras. Isso é muito mais difícil, tanto conceitualmente como na prática. Estariam os executivos do projeto dispostos a investir recursos adicionais para tornar as soluções reusáveis?
Isso é explicado também no Contínuo Corporativo (Enterprise Continuum), que é parte do padrão TOGAF.


Quanto mais genéricos são os elementos da arquitetura, mais reusáveis eles serão no futuro. Mas, também, na maioria dos casos será muito mais fácil adquiri-los, mantê-los e integrá-los.

Então, por que nós não trabalhamos com aplicativos padrão, desenhado colaborativamente, selecionados e hospedados para atender a vários hospitais em conjunto?

Entendendo por que e onde você é único

É claro que um banco é diferente de um hospital. Alguém pode dizer que quando os produtos e serviços são diferentes, os processos, fluxos de informação e panorama de aplicativos são diferentes. Eventualmente, lá em baixo na pilha, tecnologia genérica, como bancos de dados e conectividade, poderia muito bem ser bastante similar.

Mesmo quando as organizações têm os mesmos produtos, os processos usados para criar estes produtos podem ser diferentes. Mesmo quando os processos são padronizados, os fluxos de informação diferem. E mesmo se um conjunto de organizações consegue harmonizar isto, o panorama de aplicativos difere. Isso não parece ser lógico, ou, pelo menos, não é barato... especialmente em ambientes não-competitivos como o Governo. Nós temos visto que arquiteturas de referência estão se tornando bastante populares, principalmente em países como Austrália, Holanda, EUA, Singapura, entre outros. No Brasil, o FACIN é a primeira tentativa de criação de um framework de arquitetura corporativa comum para as entidades da Administração Pública Direta (APD). Na industria da saúde, o The Open Group tem trabalhado no desenvolvimento de uma arquitetura de referência chamada HERA-Healthcare Enterprise Reference Architecture (veja uma discussão sobre o tema aqui)

Mas mesmo assim, a cultura, a ambição por independência, o histórico, a estrutura da organização e, principalmente, a estratégia, provocam diferenças entre as organizações, mesmo quando atuando em áreas similares. A combinação e interação únicas entre as capacidades da organização torna cada organização única, mas isso não ajuda nosso trabalho arquitetural.

Existem dois passos para tornar mais claro onde você deveria querer se diferenciar:
  1. Criar um modelo de capacidades no qual você apresenta em alto nível o que a sua organização faz.
  2. Decidir, para cada capacidade, se a sua organização quer 'inovar', 'diferenciar', ou considerar esta capacidade de uso comum.

Nós descrevemos esta abordagem em uma postagem anterior que tratava da "Arquitetura de Negócio no Novo Normal". Esta abordagem ajuda a fornecer percepções sobre as capacidades primárias e secundárias, e alimenta a discussão sobre a implementação da estratégia e seu eventual custeio.

Tire vantagem das similaridades

A maioria dos elementos arquiteturais abaixo do nível dos aplicativos serão relativamente genéricos. Alguns aspectos da arquitetura de aplicativos e de negócios podem ser inspirados por outras indústrias. Finanças, Recursos Humanos, Suprimentos, etc. são exemplos típicos, mas também o CRM, o planejamento e o armazenamento de imagens podem ser (parcialmente) inspirados em como outras organizações fazem isso.

Processos específicos da indústria - e seus respectivos modelos de dados - podem ser fornecidos por provedores de serviços. Dentro da indústria da saúde, fornecedores de equipamentos de ressonância magnética e de prontuários eletrônicos entregam arquiteturas de processo padronizadas, que podem ser um ponto de partida para a sua arquitetura futura.

O que torna um hospital diferente de outras organizações

Hospitais possuem um conjunto único de processos, quando comparados com negócios que têm um impacto menos direto sobre a vida e a morte. Alguns exemplos:
  • Pessoas são tanto "sujeitos" como "objetos" dos processos. Alguns dos comportamentos de negócio são desempenhados pelos pacientes/clientes e, ao mesmo tempo, os pacientes são afetados pelo comportamento de negócio. Isso é fundamentalmente diferente de um banco ou indústria.
  • Fechar o ciclo de medicação é um processo que é único para instituições de cuidados de saúde, com o seu próprio conjunto de requisitos únicos.
  • A estrutura de governança é diferente para cada instituição de cuidados de saúde. Algumas são formadas por médicos cooperados, em outras os médicos são empregados. Algumas são ligadas a instituições de ensino ou fazem parte de um grupo maior, outras são independentes. Os conceitos de 'cuidado' e 'cura' têm abordagens diferentes e 'pulsam' através do negócio.

Toda Arquitetura Corporativa é Personalizada

Você pode usar arquiteturas de referência para acelerar o trabalho arquitetural, mas a história e a cultura da organização em que você está deve ser levada em conta. O processo de criar conscientização e conseguir o apoio da alta direção para a arquitetura corporativa deve ser levado em consideração em todos os casos, e a arquitetura resultante deve ser personalizada para as necessidades e metas estratégicas da organização, para que possa efetivamente entregar o valor desejado e esperado.


Para falar mais sobre o tema da arquitetura corporativa e do uso de modelos de referência para acelerar a sua adoção, entre em contato conosco e saiba mais sobre os nossos produtos, serviços e experiência.



*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 Ágil: Usando o ArchiMate com o Scaled Agile Framework (SAFe)

postado em 19 de fev de 2019 05:21 por Antonio Plais   [ 24 de fev de 2019 18:21 atualizado‎(s)‎ ]

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

Temos escrito várias postagens sobre arquitetura corporativa em um mundo ágil, como o suporte de ferramenta para os Métodos Ágeis e DevOps, e, anteriormente, sobre o uso do ArchiMate em um contexto ágil. Nesta postagem, revisitaremos este último assunto e adicionaremos novas percepções e ideias.

Mais uma vez, usaremos o Scaled Agile Framework (SAFe) como pano de fundo. Ele é o framework mais popular (mas, de forma alguma, o único) para aplicar métodos ágeis em larga escala, e nós o encontramos em muitos de nossos clientes. Ele fornece para as empresas a estrutura para coordenar os esforços de várias equipes ágeis em torno de metas compartilhadas e soluções comuns e em larga escala. Abaixo, você pode ver uma versão simplificada da encarnação completa, em quatro camadas, do SAFe.


Isso é mais relevante para organizações muito grandes, que precisam coordenar o trabalho de centenas ou milhares de desenvolvedores; digamos, um grande banco, uma seguradora, ou uma agência governamental. Organizações menores podem não precisar da camada Grandes Soluções, e as menores ainda, com apenas algumas equipes ágeis, podem precisar apenas das duas camadas inferiores. Um dos aspectos distintivos desta organização em camadas é que quanto mais alto você vai, mais o foco se move para a intenção, ao invés da construção, da solução.

Abaixo, você pode ver um exemplo de como isso pode ser refletido no uso dos conceitos do ArchiMate através destas camadas, neste caso, para a versão do SAFe de três camadas (sem a camada de Grandes Soluções).

Modelando a Intenção: Temas, Épicos, Funcionalidades e Histórias como Elementos de Motivação do ArchiMate

À esquerda, temas estratégicos de alto nível são modelados como metas no ArchiMate. Isso expressa a intenção de negócio da empresa. Estes temas são detalhados em épicos (modelados como resultados), os quais, por sua vez, são realizados por funcionalidades (modelados como requisitos), que são elas mesmas agregações de histórias individuais (também modeladas como requisitos). Note que todos estes podem, também, ser "habilitadores" em termos do SAFe, isso é, eles não são necessariamente usados diretamente pelos usuários, mas podem fornecer suporte para funcionalidades de negócio futuras, garantir a conformidade regulatória, melhorar a infraestrutura, habilitar a mantenabilidade, etc.

Épicos, funcionalidades e histórias são priorizadas por meio de backlogs nos seus níveis respectivos. Estes, por sua vez, são organizados em iterações, que são modeladas com o conceito ArchiMate de platô. No nível mais baixo nós temos os incrementos de produto (ou sprints, em termos Scrum), entregues pelas equipes ágeis individuais. Vários incrementos juntos constituem um release, entregue pelos ART-Agile Release Trains (Trens de Lançamento Ágil) do SAFe, uma equipe-de-equipes coordenada. No nível do portfólio, estes releases formam o roteiro do produto.

Modelando o que nós construímos: Elementos Centrais do ArchiMate

Platôs são usados no ArchiMate para agregar os elementos da arquitetura que são válidos durante um período de tempo específico. À direita, vemos os elementos constituintes destes vários platôs, expressos por meio de elementos centrais do ArchiMate. No nível mais baixo, eles são bastante concretos.

Primeiro, usamos o conceito de função de aplicativo. Isto descreve o (parte do) comportamento de um componente de aplicativo: o que esta coisa faz (ou deveria fazer)? De forma similar, você pode modelar, aqui, processos e funções das camadas de negócio ou de tecnologia. Isso também é ligado às histórias à esquerda, uma vez que o comportamento deve realizar aquela história.

Estas funções e processos precisam ser executados por elementos concretos do aspecto do ArchiMate chamado de "estrutura ativa". Neste caso, nós usamos componentes de aplicativo, ou seja, blocos de construção de software sendo usados ou criados. Existem, naturalmente, vários outros conceitos que você poderia usar aqui, para modelar, digamos, a infraestrutura de tecnologia, recursos da organização e outros elementos concretos da solução.

Note que este nível é governado pelas equipes ágeis; eles, e não algum arquiteto nos níveis superiores, são os responsáveis pelo desenho detalhado do produto que está sendo desenvolvido, e eles poderiam (ou não) usar especificações mais detalhadas em UML ou BPMN, conforme suas necessidades. Ligar modelos ArchiMate com estes modelos detalhados é bastante fácil, mas está além do escopo desta postagem; veja esta série de postagens para saber como combinar a linguagem ArchiMate com outros padrões.

Abstraindo dos detalhes do desenho: em direção à arquitetura intencional

Um nível acima, nós usamos o conceito de serviço de aplicativo. Serviços abstraem das estruturas e comportamentos internos, e descrevem somente o que alguma coisa faz para o seu ambiente. O conceito de serviço do ArchiMate (através das três camadas, Negócio, Aplicativo e Tecnologia) é, desta forma, um grande correspondente com a noção de "funcionalidade" no SAFe. Cada serviço, naturalmente, precisa se encaixar no seu ambiente, o que pode ser expresso por meio de vários outros conceitos do ArchiMate, não mostrados aqui.

É neste nível onde os arquitetos de solução desempenham seu papel, empregando conceitos como o Architectural Runway (Pista Arquitetural) do SAFe. Isso é desenvolvido de uma maneira oportuna e iterativa, e fornece para as equipes ágeis a arquitetura intencional que fornece os limites para garantir que os resultados do trabalho das várias equipes ágeis se encaixem bem juntos, se conformem com requisitos não-funcionais, demandas regulatórias e outras restrições.

Os conceitos do ArchiMate são uma ótima forma para expressar a arquitetura intencional, uma vez que o ArchiMate não é desenvolvido para o desenho detalhado de soluções. Seus conceitos objetivam expressar os aspectos estruturais e comportamentais essenciais das soluções e as motivações por trás disso. Mais ainda, o ArchiMate se expande através do negócio e da TI, e assim fornece para as equipes ágeis contexto e clareza além das preocupações com o desenvolvimento de software somente. Por exemplo, em quais processos de negócio isso será usado? Como ele se relaciona com outros produtos no nosso portfólio? Como isso contribui para as metas principais do negócio? Em qualquer organização (mas especialmente em um contexto ágil), todos deveriam entender o propósito dos seus esforços.

Isso, então, nos leva para a parte superior, onde vemos o conceito de capacidade. Uma capacidade é algo que uma organização é (ou quer ser) capaz de fazer, e aqui ela expressa que as soluções desenvolvidas fornecem certas capacidades novas ou melhoradas para a empresa. Estas capacidades, por sua vez, realizam épicos que foram definidos anteriormente. Mais ainda, elas contribuem para o curso de ação que a empresa adota para executar seus temas estratégicos e atingir suas metas.

Exemplo

Para dar um exemplo concreto, vamos pegar nossa empresa bancária, fictícia mas realista, BiZZbank. Um dos seus temas estratégicos é aumentar significativamente suas receitas de serviços bancários digitais, através do aumento do foco no segmento da Geração do Milênio (Millennials, ou Geração Y). Para isso, o BiZZbank objetiva desenvolver a melhor experiência de usuário de serviços bancários digitais. Isso, por sua vez, requer várias capacidades e recursos, tais como o gerenciamento do relacionamento com os clientes, análises analíticas dos clientes e um excelente aplicativo para dispositivos móveis. Abaixo, um modelo ArchiMate simplificado mostra isso, usando os conceitos de partes interessadas e valor para fornecer um pouco mais de contexto para o curso de ação ao centro.


A partir desta figura contextual de alto nível, poderíamos descer aos detalhes, por exemplos, dos serviços específicos que este aplicativo móvel precisa fornecer, como ele se encaixa na jornada do cliente, quais as suas funcionalidades e qual a sua arquitetura de software, sua integração com os sistemas de retaguarda do banco, etc. Muito mais coisas sobre o BiZZbank podem ser vistas no nosso webinar de demonstração.

No entanto, a principal mensagem que queremos passar é que fornecer este tipo de contexto e intenção de alto nível é essencial para o desenvolvimento ágil. Nos ambientes tradicionais em cascata, você poderia ter analistas de negócio, analistas de informação e outros papéis com tarefas específicas para traduzir a intenção estratégica em requisitos concretos. No desenvolvimento ágil, no entanto, muito desta responsabilidade recai sobre os ombros das equipes ágeis e dos donos de produto. Sem um claro entendimento do contexto, como você espera que eles tomem as decisões de desenho corretas?

A noção de arquitetura intencional corresponde muito bem com a nossa visão de Empresa Adaptativa, onde a visibilidade das informações necessárias para delegar a tomada de decisões para toda a empresa é fundamental. Se você quer conhecer mais sobre a nossa visão, 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.


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.

Suporte para Agile/DevOps no BiZZdesign Enterprise Studio & HoriZZon

postado em 18 de fev de 2019 06:23 por Antonio Plais   [ 25 de fev de 2019 18:51 atualizado‎(s)‎ ]

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

Na nossa postagem anterior, delineamos porque a Arquitetura Corporativa e Agile/DevOps são importantes para se tornar uma empresa adaptativa. Também descrevemos vários casos de uso onde a Arquitetura Corporativa pode fortalecer os Métodos Ágeis e as práticas DevOps. Agora, gostaríamos de focar nas formas pelas quais você pode conectar isto na prática, usando modelos da arquitetura e o suporte adequado de ferramentas.

Priorizar o trabalho

Para a fazer uma priorização que é fundamentada no valor de negócio, você pode começar especificando temas estratégicos no seu modelo arquitetural. A visão da Contribuição das Metas na figura abaixo mostra dois temas estratégicos em uma seguradora, modelados como metas no ArchiMate (a parte de cima da figura). Vários resultados (na parte de baixo da figura) contribuem para estas duas metas estratégicas. Resultados representam efeitos produzidos e podem, por sua vez, ser ligados a épicos e habilitadores, que são elementos pivotais para o desenvolvimento ágil.

Neste modelo desta seguradora, dois resultados têm forte influência positiva sobre a meta Melhorar o serviço ao cliente. Eles são um formulário de sinistro online e um aplicativo móvel para comunicação com corretores virtuais de seguro. Este último também contribui para a meta de Reduzir o custo do trabalho. Um novo algorítimo para a automação do tratamento de sinistros contribui para a mesma meta. Uma priorização preliminar dos resultados pode ser derivada deste modelo. Para a seguradora, o corretor virtual produzirá o máximo valor de negócio e deveria ter prioridade sobre os outros resultados.

Figura 1. Visão da Contribuição das Metas

Subdividindo os resultados

Para atingir uma priorização no nível corporativo, de cima para baixo, você deve coordenar para refletir fatores adicionais, tais como as dependências arquiteturais dentro e através dos resultados, ou a atribuição de épicos através das equipes ágeis que são responsáveis pelos elementos arquiteturais distintos. É aqui onde a arquitetura corporativa brilha, uma vez que ter a informação arquitetural nas mãos é crucial para este planejamento abrangente.

Para este propósito, é proveitoso subdividir os resultados de uma forma consciente da arquitetura. Não há a necessidade de uma especificação detalhada de todos os requisitos; o objetivo é atingir uma granularidade apenas suficiente para delinear a impressão organizacional e arquitetural de cada resultado. Esta percepção sobre a impressão arquitetural é a chave para identificar conflitos e gargalos. Este tipo de informação normalmente não está disponível no seu gerenciamento típico de equipes ágeis ou em ferramentas como o Jira.

No exemplo da seguradora, o resultado Corretor virtual móvel pode ser dividido em dois requisitos que apresentam diferentes impressões arquiteturais. O componente de aplicativo App Android é afetado, assim como o componente Retaguarda Móvel, e eles são cobertos por equipes ágeis diferentes (veja a Figura 2). De acordo com o planejamento de sprints da equipe ágil responsável, os requisitos são realizados durante sprints diferentes. Com base no roteiro do Trem de Entrega Ágil (ART-Agile Release Train), ambos os requisitos serão parte do mesmo release. O modelo ilustra como o valor de negócio é criado ao longo do tempo e como os recursos de desenvolvimento são alocados.

Figura 2. Relacionamentos entre metas, resultados, elementos da arquitetura e sprints e releases ágeis

No BiZZdesign Team Platform, você pode facilmente agregar dados de diferentes fontes (como explicado em uma postagem sobre arquitetura contínua), incluindo ferramentas ágeis tais como o Jira. Esta informação pode ser agregada em vários níveis e compartilhada no portal HoriZZon, o que é mostrado na figura abaixo. À esquerda, você vê os resultados da figura anterior em uma visão Kanban. À direita, você vê os atributos para o resultado 'corretor virtual' como importado do épico correspondente no backlog do Jira. Navegando destes épicos para dentro da arquitetura em si levará você para visões similares à mostrada acima.


Figura 3. Portal HoriZZon mostrando dados da ferramenta ágil integrada com informações da arquitetura

Você pode, ainda, criar esta ligação no nível mais detalhado das funcionalidades, dependendo da granularidade das informações que você quer usar nos seus modelos da arquitetura. Em geral, nós não aconselhamos a ligar isso no nível das histórias de usuário individuais no Jira, uma vez que isso pode ficar bastante confuso. Com frequência, este nível de detalhe não é relevante para a arquitetura.

Além de visões Kanban como a mostrada acima, você pode criar várias visões de cores, roteiros e painéis de controle para informar às partes interessadas sobre o progresso das mudanças e o desempenho das equipes ágeis e pistas de implementação. Decisões e o planejamento de transições podem ser baseados na informação disponível sobre o progresso, disponibilidade provável de novas funcionalidades, e resultados de negócio associados. Você pode calcular os efeitos de atrasos antecipadamente e avaliar diferentes cenários quando épicos ou funcionalidades precisarem ser repriorizados. Desta forma, a mudança se torna mais previsível e menos arriscada, uma vez que você foca nas reais necessidades do seu negócio.

Se você quiser saber mais sobre o BiZZdesign Enterprise Studio e o portal HoriZZon, entre em contato e solicite uma demonstração.



* 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/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.

Arquitetura Corporativa e Agile/DevOps: Pedras Angulares da Empresa Adaptativa

postado em 17 de fev de 2019 06:42 por Antonio Plais   [ 18 de fev de 2019 06:24 atualizado‎(s)‎ ]

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

Arquitetura corporativa, desenvolvimento ágil de software e DevOps são, muitas vezes, vistos como estando em conflito. Nós acreditamos que eles podem colaborar e se comunicar de forma proveitosa, mas como você pode fazer isso? Como você pode alinhar os conceitos e processos destes mundos diferentes e transpor as barreiras culturais?

Em postagens anteriores, nós escrevemos sobre a necessidade de abordar a transformação de negócios de uma forma leve e ágil, a forma como os processos de arquitetura corporativa e desenvolvimento ágil podem trabalhar juntos, e como você pode mapear os conceitos ágeis para a linguagem de modelagem ArchiMate para suportar esta cooperação.

Nesta postagem, gostaríamos de discutir vários casos de uso que realçam a colaboração entre a arquitetura corporativa, o desenvolvimento ágil e DevOps. Discutiremos, também, como o software da BiZZdesign pode trabalhar junto com os métodos ágeis e ferramentas de DevOps para agilizar o fluxo de valor nos processos de mudança da sua organização, ajudando a torná-la uma empresa adaptativa.

Por que relacionar a Arquitetura Corporativa com DevOps?

As abordagens ágeis são uma grande ajuda para aumentar a responsividade à mudança. No entanto, elas não são as únicas abordagens que você precisa e, quando aplicadas incorretamente, podem até mesmo trazer mais danos para a adaptabilidade global da sua empresa.

Em geral, quanto maior a organização e mais interconexões e dependências existem entre as suas partes (capacidades, recursos, processos, sistemas) mais importante a arquitetura corporativa se torna para melhorar a adaptabilidade e alinhar as partes com a direção estratégica global.

Em organizações menores, algumas poucas equipes ágeis/DevOps podem coordenar a mudança entre elas mesmas, e as linhas de gerenciamento são curtas o suficiente para que a direção estratégica seja transmitida para as equipes diretamente. Em organizações maiores, no entanto, pode haver centenas de equipes ágeis, cada uma trabalhando em uma parte da grande 'máquina corporativa', e é necessária maior coordenação. Se você tem equipes ágeis construindo silos ágeis que desconsideram seu ambiente, você ainda não obtém um resultado final flexível e adaptativo. Além disso, as mudanças futuras podem se tornar ainda mais difíceis, o que torna uma boa arquitetura corporativa ainda mais essencial.

Abordagens como LeSS (Large-Scale Scrum) e SAFe (Scaled Agile Framework) foram criadas para lidar com a coordenação de equipes ágeis nestas circunstâncias. A figura abaixo mostra uma versão simplificada do SAFe, destacando alguns dos termos significativos e ciclos de retroalimentação.


A abordagem que estas metodologias fazem da arquitetura corporativa é focada nas necessidades do desenvolvimento de software e, como resultado, olha para a empresa principalmente a partir de um ponto de vista de software e soluções. No entanto, há muito mais na empresa do que apenas software. É aqui onde a visão "grande figura" oferecida pela arquitetura corporativa adiciona valor, uma vez que ele engloba outras partes interessadas do que os usuários de software e inclui resultados de negócio desejáveis (e indesejáveis?), capacidades a serem desenvolvidas ou melhoradas, recursos necessários, processos de negócio, infraestrutura física e de TI a ser realizada, e muito mais.

Casos de uso para os Métodos Ágeis e a Arquitetura Corporativa

A combinação da arquitetura corporativa com o desenvolvimento ágeis é inestimável em muitos casos. Por exemplo, esta colaboração é crucial quando:

  • Priorizar o valor de negócio. Com base em uma análise da sua arquitetura corporativa você pode ver como os vários épicos e funcionalidades são relacionados com os processos de negócio, capacidades, metas de negócio e partes interessadas associadas. Rastreando através dos seus modelos da arquitetura, você pode encontrar para quais metas de negócio e partes interessadas uma funcionalidade contribui, e se esta funcionalidade é mais importante do que outras. Informação objetiva como esta pode ajudar os donos de produto (Product Owner) colocar um fim na priorização "orientada pelo grito", onde os usuários com as vozes mais altas garantem que os seus desejos sejam atendidos.
  • Planejar o trabalho com coerência. As dependências na sua arquitetura podem ser usadas nas atividades de planejamento ágil: se uma funcionalidade A depende da funcionalidade B, construa B primeiro. Isto é ainda mais importante naquilo que o SAFe chama de "habilitadores": aspectos da solução que não fornecem funcionalidade diretamente para os usuários, mas suportam esta funcionalidade indiretamente e permitem a evolução e qualidade no longo prazo. Seu conceito de "Pista Arquitetural" (Architectural Runway) é um exemplo disso, onde você constrói a fundação técnica das novas funcionalidades no momento apropriado. Este conceito pode, no entanto, ser estendido além do software apenas. Investir nas competências da equipe, por exemplo, pode fornecer uma fundação para muitos desenvolvimentos e melhorias futuros.
  • Acompanhar o progresso. Se alguma funcionalidade ou habilitador é atrasado, por exemplo, por causa de uma equipe ágil querendo empurrá-la para o próximo sprint, o impacto na solução total precisa ser fatorado naquela decisão. Existem várias boas razões para esta equipe priorizar alguma outra coisa no lugar, mas geralmente eles não têm informações suficientes para entender as consequências da sua decisão. Ser capaz de rastrear de volta para a meta geral demonstrará como uma decisão afetará um release, projeto, data de entrega, etc. Isso também ajuda as equipes para fazer perguntas como: "Como isso impacta as metas de negócio da organização? Quais grupos de clientes serão afetados? Nós podemos mitigar estes efeitos, através da priorização de outras funcionalidades, possivelmente de outras equipes?". É aqui que os modelos da arquitetura são de grande ajuda, especialmente para os habilitadores. Uma vez que os habilitadores não fornecem funcionalidades para o usuário final, poucas pessoas reclamam quando eles são adiados. No entanto, eles são em geral muito importantes para várias funcionalidades diferentes e para a viabilidade da solução no longo prazo, de forma que manter a rastreabilidade destas dependências é muito importante.
  • Atualizar a arquitetura com novas percepções. Em um contexto ágil, uma arquitetura corporativa não é apenas uma descrição estática de um estado futuro de longo prazo. Ao invés disso, ela é um instrumento compartilhado para fornecer a visão, dar a direção e garantir a coerência através da empresa, com base tanto em entradas de cima para baixo como de baixo para cima. A estratégia, metas e resultados desejados do negócio fornecem a direção de cima para baixo, enquanto as inovações e melhorias locais oferecem as mudanças de baixo para cima. Assim, os vários grupos na empresa trabalham juntos na arquitetura a partir de suas próprias perspectivas.

Casos de Uso para DevOps e Arquitetura Corporativa

Quando nós estendemos o desenvolvimento ágil com DevOps, existem outros casos de uso para a arquitetura que podem ser adicionados à lista acima. O gerenciamento de operações, em geral, não está sempre consciente dos benefícios da arquitetura. No entanto, em um ciclo de desenvolvimento rápido como o Scrum/DevOps, e com uma abordagem "falhar para frente" para resolver problemas, a arquitetura se torna ainda mais valiosa para o DevOps. Por exemplo, modelos da arquitetura pode ser usados para:
  • Correlacionar eventos. Modelos da arquitetura permitem que você veja os eventos através da sua empresa de uma maneira integrada. Por exemplo, se hackers estão tentando comprometer sua segurança por meio de diferentes vetores de ataque ao mesmo tempo (e.g., engenharia social, phishing, vírus, e intrusão física), modelos da arquitetura podem ajudá-lo a correlacionar isso para entender qual poderia ser o seu verdadeiro objetivo.
  • Analisar a causa-raiz. Com frequência, uma longa cadeia de sistemas tem que ser traçada para encontrar a causa de uma falha ou problema. Modelos da arquitetura são uma grande ajuda para isso, uma vez que eles fornecem para o gerenciamento de operações as várias interconexões e dependências que precisam ser investigadas.
  • Analisar riscos. Antes de implementar uma mudança, você gostará de saber quais partes da sua empresa serão afetadas. Mudanças de baixo risco podem ser implementadas rapidamente, mas mudanças de alto risco irão requerer uma análise mais apurada e medidas de mitigação.
Na próxima postagem desta série, vamos olhar para o uso de modelos e o suporte de ferramenta para integrar o desenvolvimento ágil e a arquitetura no BiZZdesign Enterprise Studio e HoriZZon. Fique ligado!



* 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/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.

Usando o ArchiMate em um Contexto Ágil

postado em 15 de fev de 2019 02:59 por Antonio Plais   [ 18 de fev de 2019 13:30 atualizado‎(s)‎ ]

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

No passado, nós publicamos várias postagens sobre a combinação da arquitetura corporativa com os métodos ágeis de trabalho (e.g. Arquitetura Corporativa e Inovação: Uma Mudança Cultural, Escapando das Garras do Mostro dos Projetos, e Arquitetura Corporativa e Desenvolvimento Ágil: Os Opostos se Atraem?). Nesta postagem, gostaríamos de focar com maiores detalhes no uso da linguagem ArchiMate no contexto dos métodos ágeis, em particular como Scaled Agile Framework (SAFe).

Para aqueles que não estão familiarizados com o SAFe, este é um framework para organizar a agilidade em larga escala, usado por grandes corporações que precisam coordenar os esforços de muitas equipes ágeis em torno de um mesmo conjunto de metas estratégicas. O framework SAFe é apenas uma forma de ilustrar o uso da linguagem ArchiMate em conjunto com frameworks ágeis, e a linguagem pode ser usada com qualquer método ágil. A figura abaixo apresenta uma visão simplificada do SAFe, na sua encarnação em três níveis. Ela mostra vários conceitos usados no SAFe e em outros métodos ágeis. Não é nosso objetivo explicar isto em detalhes; por favor, consulte o website do SAFe se você quer conhecer (muito) mais. Nesta postagem, nós forneceremos apenas um breve resumo.

Figura 1. Visão simplificada do Scaled Agile Framework.

Mapeando os conceitos do SAFe para o ArchiMate

Nas tabelas abaixo, nós demonstramos como você pode usar os elementos do ArchiMate para expressar estes conceitos do SAFe. No nível do Portfólio, os elementos de estratégia e motivação de alto nível do ArchiMate 3.0 (Curso de Ação, Capacidade, Recurso, Meta e Resultado) podem ser usados produtivamente. O Planejamento Baseado em Capacidades pode ser um bom ponto de partida para discussões de investimento neste nível. A visão inicial da arquitetura é expressa em alto nível usando conceitos centrais do ArchiMate. O trabalho necessário é gerenciado usando um portfólio de Pacotes de Trabalho, que tipicamente representam, neste nível, programas (lembre-se que o ArchiMate usa um único conceito para todos os níveis de detalhe, desde programas inteiros até tarefas individuais).

Tabela 1: Conceitos SAFe e ArchiMate no nível de Portfólios
 SAFe ArchiMate
 Tema Estratégico Partes Interessadas & Motivadores, Metas, Cursos de Ação
 Épico, Habilitadores Metas. Resultados, Capacidades, Recursos, Elementos Centrais (alto nível)
 Portfólio de programas Pacotes de Trabalho e Entregáveis

No nível dos Programas, vemos que a visão do programa é expressa através dos seus Resultados desejados, o Roteiro é representado através de séries de Platôs e Entregáveis associados, Pistas Arquiteturais são expressas através dos conceitos centrais do ArchiMate, e Funcionalidades são expressas pelos Requisitos e Restrições (de nível médio) que precisam ser atendidos pela solução.

Tabela 2: Conceitos SAFe e ArchiMate no nível de Programas
 SAFe ArchiMate
 Visão Resultados, Requisitos, Restrições
 Roteiro Série de Platôs, Entregáveis
 Pista Arquitetural Conceitos Centrais (mais detalhados)
 Funcionalidades Requisitos & Restrições

Finalmente, no nível das equipes, nós vemos principalmente a expressão das histórias de usuário e da arquitetura, através de Requisitos e Restrições, e os incrementos dos produtos, consistindo de um ou mais Entregáveis como resultado de um Platô (um estado estável da arquitetura).

Tabela 3: Conceitos SAFe e ArchiMate no nível das Equipes
 SAFe ArchiMate
 Histórias de Usuário & Arquitetura Requisitos & Restrições (mais detalhados)
 Resultado do Sprint (incremento do produto) Entregáveis & Platôs

Note que os detalhes da solução não são, tipicamente, expressos através da linguagem ArchiMate. Ela é, afinal, uma linguagem que objetiva a arquitetura corporativa. O desenho de software é, em geral, feito melhor usando a linguagem UML (e, em alguns casos, o BPMN ou outra linguagem de modelagem de nível de implementação). No entanto, é bastante fácil ligar os seus modelos ArchiMate com estes modelos de nível de implementação. Por um lado, vários conceitos na sua Pista de Arquitetura poderiam ser mapeados diretamente para os elementos correspondentes no nível de implementação, tais como Componentes, interfaces e Serviços de Aplicativo para a UML, e Processos de Negócio para o BPMN. Veja postagens anteriores onde falamos sobre a ligação do ArchiMate com a UML e o BPMN

Relacionamento com outros conceitos e ferramentas para suportar a rastreabilidade

Além dos relacionamentos entres estes conceitos que expressam a solução, os relacionamentos com as histórias de usuário também são significativos. As equipes ágeis tipicamente usam ferramentas de rastreamento de problemas, como Jira ou Bugzilla, para administrar isso. Ligar o BiZZdesign Enterprise Studio com tais ferramentas fornece a você rastreabilidade ponta-a-ponta desde as metas estratégicas de alto nível até as histórias de usuário individuais, e de volta. Isso fornece percepções muito úteis para priorizar e alocar orçamentos e recursos, por um lado, e para monitorar o progresso em direção ao atingimento dos resultados de negócio, pelo outro.

Mais ainda, a retaguarda arquitetural fornecida pelos modelos ArchiMate é imprescindível para rastrear as várias dependências entre as diferentes iniciativas, programas e resultados. Este é o principal desafio para escalar os métodos ágeis para o nível corporativo: se você não coordena as equipes individuais, cada um deles construirá seu próprio silo ágil, e você terminará construindo legados instantâneos.

Esta rastreabilidade entre os diferentes níveis significa que você sabe onde as mudanças nas estratégias e requisitos podem ter um impacto, você pode garantir a coerência e a estabilidade do seu panorama de TI, e você pode demonstrar que está no controle, o que é cada vez mais importante em, algumas vezes, ambientes de negócio altamente regulados.

Isso não significa que nós estamos aconselhando você a criar modelos ArchiMate de "grandes desenhos antecipados", que capturam o desenho completo antes que você construa qualquer coisa. Ao invés disso, é melhor criar e evoluir modelos no tempo certo, que capturam a informação necessária para tomar as decisões certas no momento certo. Desta forma, sua organização pode se tornar uma verdadeira Empresa Adaptativa.

Para saber mais sobre 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.


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.





Combinando o ArchiMate 3.0 com Outros Padrões - UML / SysML / ERD

postado em 21 de jan de 2019 16:58 por Antonio Plais   [ 22 de jan de 2019 02:50 atualizado‎(s)‎ ]

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

Como declaramos na introdução desta série de postagens, modelos ArchiMate podem ser combinados de forma muito útil com modelos em outras técnicas, para entrar em aspectos específicos da sua empresa. Se estes modelos são ligados em um modelo geral da arquitetura corporativa no ArchiMate, pode ser construído um modelo integrado da empresa que relaciona os (sub)modelos de domínios anteriormente separados de uma forma significativa.

Modelo de arquitetura corporativa como um pivô entre os outros modelos

Em nossas postagens anteriores, nós já discutimos o relacionamento da linguagem ArchiMate com o Modelo de Motivação de Negócio (BMM-Business Motivation Model), os Indicadores Balanceados de Desempenho (BS-Balanced Scorecard), o Canvas do Modelo de Negócio (BMC-Business Model Canvas) e com o BPMN. Nesta última postagem desta série, vamos elaborar como o ArchiMate 3.0 pode se relacionar com linguagens como UML, SysML e ERD. As tabelas abaixo fornecem um mapeamento aproximado entre os conceitos do ArchiMate e os conceitos destas técnicas. Nós terminaremos esta postagem mostrando alguns exemplos de como o BiZZdesign Enterprise Studio suporta isto.

UML

A UML (Unified Modeling Language) é o padrão de fato para a modelagem de software. Vários conceitos no ArchiMate foram fortemente inspirados pela UML. O mais óbvio é o conceito de componente de aplicativo, que corresponde ao componentet UML. Os elementos nó, artefato, dispositivo, software de sistema e caminho também foram (mais ou menos) tirados da UML (onde software de sistema é chamado de ambiente de execução). Essa ligação próxima facilita uma cadeia contínua de desenvolvimento, entre os modelos de alto nível da arquitetura corporativa, descritos na notação ArchiMate, e os modelos de implementação e arquitetura de solução de baixo nível na notação UML.

 ARCHIMATE  UML
 Ator de Negócio, Papel de Negócio  Ator
 Requisito + Serviço  Caso de Uso
 Componente de Aplicativo  Componente
 Objeto de Negócio, Objeto de Dados  Classe
 Colaboração de Aplicativo  Colaboração
 Nó, Dispositivo, Software de Sistema  Nó, Dispositivo, Ambiente de Execução
 Artefato  Artefato
 Interface + Serviço de Aplicativo  Interface
 Agregação, Composição, Especialização  Agregação, Composição, Generalização

Existem, também, algumas diferenças importantes entre os dois. O relacionamento de servidão do ArchiMate, embora superficialmente similar em notação, é semanticamente diferente da dependência na UML, e geralmente aponta na direção oposta. Uma dependência UML é usada para modelar, por exemplo, chamadas de função em programas de software. No nível arquitetural no qual a linguagem ArchiMate é usada, detalhes operacionais de tempo de execução, tais como gráficos de chamadas, são menos importantes do que o noção mais genérica e estável do fornecimento de serviço. No ArchiMate, a direção do relacionamento de servidão, desta forma, significa a direção da entrega do serviço, independente do fato do serviço ser chamado pelo consumidor ou ser oferecido proativamente pelo fornecedor.

Isso também aponta para outra diferença importante: a UML não tem um conceito separado de serviço, uma vez que no seu paradigma orientado para objeto o comportamento expresso por um serviço é encapsulado através (das operações) de uma interface. A linguagem ArchiMate diferencia entre interfaces e os serviços que elas fornecem, para especificar que um mesmo serviço é oferecido através de múltiplas interfaces. Assim, a interface UML corresponde à combinação de um serviço e uma interface de aplicativo.

SysML

A Linguagem de Modelagem de Sistema (SysML-Systems Modeling Language) é um desdobramento da UML para a especificação, análise, desenho, verificação e validação de um amplo leque de sistemas e sistemas-de-sistemas. Ela é menos centrada em software do que a UML, e muito menor e mais fácil de aprender (embora os diagramas possam se tornar bastante complicados). Quando desenhando sistemas físicos (ou sistemas com partes físicas), a SysML pode ser adequada como uma linguagem para desenhos mais detalhados, em um contexto onde o ArchiMate é usado para o nível de abstração da arquitetura.

 ARCHIMATE  SysML
 Elemento de Estrutura Ativa (e.g. Componente de   Aplicativo), Ator de Negócio, Dispositivo, Equipamento,   Instalação  Bloco
 Requisito, Restrição  Requisito
 Serviço + Interface  Porta
 Função, Processo  Atividade

Modelo Entidade-Relacionamento

Um dos mais antigos tipos de técnica de modelagem em TIC é o modelo de entidade-relacionamento (ER). Um modelo ER engloba tipos de entidades, que classificam as coisas de interesse, e relacionamentos específicos entre as instâncias destes tipos. Existem várias técnicas para mostrar modelos ER através de diagramas ER, e uma das populares é a chamada notação pé-de-galinha.

Modelos ER são em geral usados na modelagem de dados, em particular no desenho de bancos de dados relacionais. Assim sendo, eles mapeiam quase naturalmente para os conceitos de estrutura passiva do ArchiMate, como mostrado na tabela a seguir. Atributos, chaves ou instâncias de entidades não deveriam ser, tipicamente, modelados no Archimate, uma vez que isso é usualmente muito detalhados para o nível de abstração da arquitetura corporativa. Pela mesma razão, o ArchiMate não suporta a cardinalidade dos relacionamentos. 
 
 ARCHIMATE  SysML
 Objeto de Negócio, Significado  Entidade (Conceitual)
 Objeto de Dados  Entidade (Lógica)
 Artefato  Entidade (Física)
 Associação (com etiqueta)  Relacionamento

ArchiMate, UML e ERD no BiZZdesign Enterprise Studio

No BiZZdesign Enterprise Studio os usuários são capazes de criar modelos ArchiMate 3.0, UML e ERD. Você poderia escolher usar apenas uma linguagem de modelagem, mas você poderia querer usar as diferentes linguagens juntas, para suportar partes interessadas específicas e que têm diferentes necessidades de modelagem. Modelos de dados no ArchiMate podem ser modelados usando conceitos de estrutura passiva, como objetos de negócio e objetos de dados.

Figura 1 Exemplo do uso de objetos de negócio e de dados no ArchiMate

Se for necessário mais detalhes, você poderia escolher fazer diagramas de classe UML mais detalhados dos objetos de negócio e de dados definidos no ArchiMate.

Figura 2 Exemplo de diagrama de Classe UML

Se você é fã do Diagrama de Entidade-Relacionamento (ERD) você poderia escolher ERD ao invés da UML para sua modelagem de dados (Figura 3).

 
Figura 3 Modelagem ERD

O BiZZdesign Enterprise Studio é capaz de suportar todos estes diferentes tipos de modelos. Seja escolhendo apenas uma linguagem, ou usando múltiplas linguagens como ArchiMate, BPMN e UML, por exemplo, você verá que construir modelos ajudará você a entender melhor o seu negócio, e que o BiZZdesign Enterprise Studio pode acomodar todas as suas necessidades de modelagem.

Para saber mais sobre como o BiZZdesign Enterprise Studio e como ele pode ajudar a integrar todas as suas necessidades de modelagem, entre em contato com a Centus Consultoria e agende uma demonstração.


* 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 - BPMN

postado em 17 de jan de 2019 03:04 por Antonio Plais   [ 17 de jan de 2019 18:19 atualizado‎(s)‎ ]

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

Como explicamos na primeira postagem desta série, 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. A singularidade do ArchiMate não está nos conceitos individuais, mas sim no oposto: muitos conceitos na linguagem foram desenhados para ter uma correspondência direta com conceitos similares em outras técnicas, de forma que você possa usá-las facilmente em combinação e entrar nos detalhes de partes da sua empresa através destas outras técnicas.

Na postagem anterior, mostramos a relação entre o ArchiMate 3.0 e o Modelo de Motivação de Negócio (BMM-Business Motivation Model), Indicadores Balanceados de Desempenho (BS-Balanced Scorecard) e Canvas do Modelo de Negócio (BMC-Business Model Canvas). Nesta postagem, nós focaremos na relação entre o ArchiMate 3.0 e a linguagem BPMN (Business Process Model and Notation). A tabela a seguir fornece um mapeamento aproximado entre os conceitos do ArchiMate e do BPMN. Nós terminaremos a postagem demonstrando como o BiZZdesign Enterprise Studio suporta isso.

BPMN

O BPMN (Business Process Model and Notation) é o principal padrão para a modelagem de processos de negócio. O ArchiMate é tipicamente usado para processos de alto nível e seus relacionamentos com o contexto da organização, mas ele não pretende modelar fluxos de trabalho detalhados. O BPMN suporta a modelagem detalhada de subprocessos e tarefas até o nível de especificações executáveis, mas carece de conceitos corporativos mais amplos para, por exemplo, modelar os serviços de aplicativo que suportam um processo ou as metas e requisitos que ele deve atender. Para a modelagem de processos, o BPMN possui um conjunto de elementos bastante granular, com vários tipos de eventos, tarefas e desvios. As duas linguagens podem facilmente ser usadas em combinação.

 ARCHIMATE  BPMN
 Ator de Negócio, Papel de Negócio, Componente de   Aplicativo  Participante / Piscina, Raia
 Colaboração de Negócio, Colaboração de Aplicativo  Colaboração
 Processo de Negócio, Processo de Aplicativo  Processo
 Acionamento  Fluxo de sequência
 Acesso  Associação de dados
 Junção E  Desvios inclusivos e paralelos
 Junção OU  Desvios exclusivos e baseados em eventos

Relacionando modelos BPMN no BiZZdesign Enterprise Studio

No BiZZdesign Enterprise Studio existem várias formas de relacionar modelos BPMN com os seus modelos ArchiMate 3.0. Naturalmente você poderia usar o ArchiMate 3.0 para construir uma visão de alto nível do processo, e um modelo BPMN correspondente, mais detalhado, baseado no mapeamento descrito na tabela acima (veja as Figuras 1 e 2). Para criar as ligações relevantes para relacionar os objetos ArchiMate com o seu modelo BPMN, você pode usar relacionamentos inter-modelos (Figura 3) no Enterprise Studio.


Figura 1. Modelo ArchiMate de um processo de pedido de pizza


Figura 2. Modelo BPMN de um processo de pedido de pizza
 

Figura 3. Mapeamento dos objetos ArchiMate para os objetos BPMN

Outras integrações entre modelos ArchiMate e BPMN são também possíveis. Você poderia escolher modelar seu panorama de aplicativos no ArchiMate e relacionar isso com o modelo de processo BPMN, como mostrado na Figura 4.


Figura 4. Panorama de aplicativos ArchiMate usado em um modelo de processo BPMN

O BiZZdesign Enterprise Studio oferece várias formas de combinar diferentes linguagens. Isso ajuda os usuários a responder questões específicas de negócio e entregar valor de negócio para as várias partes interessadas. No próxima, e última, postagem nesta série nós discutiremos como você pode combinar o ArchiMate com UML, SysML e ERD.


* 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

1-10 of 99