Arquitetura Corporativa
Arquitetura Corporativa para Tomadores de Decisão: Sete Conselhos
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çãoForneç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 investimentosNã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 concretosIlustre 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 siPadrõ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 tempoA 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 simplesUm 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-passoComece 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
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 modelosO 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.
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 modelosA 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 modelosPessoasUma 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. ProcessoProcessos 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. TecnologiaComo 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ãoUm 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. * 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
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 LGPDO 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:
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.
RegistrosUma 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:
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 StudioPara 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:
 Criar uma extensão do modeloUse 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 dadosA 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.
 Criar a exportaçãoUse 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.
 Publicar o registroAgora, 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çãoNó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.
|
Nós somos diferentes! Mas, nós somos realmente diferentes?
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íficoUm arquiteto em uma organização tem dois desafios importantes (entre outros):
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:
 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 similaridadesA 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çõesHospitais 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:
Toda Arquitetura Corporativa é PersonalizadaVocê 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)
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).
 À 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 ArchiMatePlatô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 intencionalUm 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.
ExemploPara 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.
 Clique aqui para solicitar sua cópia grátis deste eBook.
|
Suporte para Agile/DevOps no BiZZdesign Enterprise Studio & HoriZZon
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 trabalhoPara 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.
 Subdividindo os resultadosPara 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.
Clique aqui para solicitar sua cópia grátis deste eBook.
|
Arquitetura Corporativa e Agile/DevOps: Pedras Angulares da Empresa Adaptativa
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 CorporativaA combinação da arquitetura corporativa com o desenvolvimento ágeis é inestimável em muitos casos. Por exemplo, esta colaboração é crucial quando:
Casos de Uso para DevOps e Arquitetura CorporativaQuando 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:
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. Clique aqui para solicitar sua cópia grátis deste eBook. |
Usando o ArchiMate em um Contexto Ágil
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 ArchiMateNas 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
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
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
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 rastreabilidadeAlé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. Clique aqui para solicitar sua cópia grátis deste eBook. |
Combinando o ArchiMate 3.0 com Outros Padrões - UML / SysML / ERD
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.
UMLA 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.
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.
SysMLA 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.
Modelo Entidade-RelacionamentoUm 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, UML e ERD no BiZZdesign Enterprise StudioNo 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.
 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.
|
Combinando o ArchiMate 3.0 com Outros Padrões - BPMN
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.
BPMNO 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.
Relacionando modelos BPMN no BiZZdesign Enterprise StudioNo 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.
|
1-10 of 99