Arquitetura Corporativa
Planejamento e Roteirização: Funcionalidade Avançada para Análise Baseada no Tempo
Originalmente postado por Marc Lankhorst e Sven van Dijk*, no blog da BiZZdesign. - Tradução e adaptação autorizados Nas nossa duas postagens anteriores, nós discutimos o planejamento e a roteirização no contexto da arquitetura corporativa, e como você pode usar os conceitos da linguagem ArchiMate para modelar seus roteiros. Nós mostramos como você pode modelar a evolução da sua empresa em um nível grosseiro, usando conceitos como o Platô do ArchiMate. Nessa postagem, discutiremos uma modelagem mais refinada da mudança no Enterprise Studio. Especificamente, mostraremos como você pode modelar os ciclos de vida dos elementos individuais da sua arquitetura e como nossa plataforma suporta a análise baseada em ciclos de vida e as dependências entre os elementos, por exemplo, para encontrar conflitos em seus planos de transição.
Modelando ciclos de vidaNo Enterprise Studio, você pode adicionar propriedades temporais aos elementos do seu modelo. Como o nome diz, o valor destas propriedades pode mudar ao longo do tempo. Pense, por exemplo, em propriedades que representam a versão de um componente de aplicativo, ou o nível de maturidade de uma capacidade. Propriedades temporais podem ser usadas para todos os tipos de propósito no Visual Studio, mas aqui nós vamos usá-las para modelar ciclos de vida. O Enterprise Studio vem com vários ciclos de vida pré-configurados para diferentes tipos de elementos, como aplicativos e projetos, entre outros; além disso, você pode definir seus próprios ciclos de vida. Abaixo você pode uma visão de ciclo de vida de um conjunto de aplicativos, com os ciclos de vida de cada um associados à uma linha do tempo.
 Visão de ciclo de vida
Nesta visão, você pode notar também as barras vermelhas abaixo de dois aplicativos. Isso demonstra conflitos de ciclo de vida, ou seja, eles podem estar trocando dados ou usando funcionalidades um do outro. Clicar na barra vermelha realçará qual é o aplicativo 'conflitante'.
Na visão ArchiMate abaixo você pode ver exatamente como os aplicativos neste exemplo estão relacionados uns com os outros. Nós realçamos os relacionamentos que causam o conflito de ciclo de vida mostrados acima: 'Ramadera' serve 'Crystal Ball', o qual por sua vez serve 'Backbase CXP'. Assim, se Ramadeira é desligado porque está em manutenção, Crystal Ball não pode fazer o seu trabalho. Como os vários relacionamentos na sua arquitetura afetam as dependências dos estágios do ciclo de vida é totalmente configurável. Isso pode incluir dependências através das camadas, por exemplo mostrando quais processos de negócio usam serviços e componentes de aplicativo; aplicativos que usam certas tecnologias, como sistemas operacionais, interfaces ou plataformas de bancos de dados; ou projetos que realizam as várias partes da arquitetura.
 Panorama parcial de aplicativos realçando as dependências que causam os conflitos de ciclo de vida
Análises de ciclo de vida avançadasVocê pode também executar esta análise para casos mais complexos, tais como relacionando os estágios de um projeto com o ciclo de vida do aplicativo que ele constrói, ou determinar o que acontece se uma equipe ágil decide adiar uma funcionalidade para o próximo sprint. Isso pode ajudar você para avaliar quais funcionalidades relevantes para o negócio serão atrasadas e quais clientes poderiam ser afetados. Com base nessa informação, você pode decidir a respeito das suas prioridades de desenvolvimento.
A figura abaixo mostra um exemplo mais elaborado. No alto, vemos como um conjunto de pacotes de trabalho dependem das saídas dos outros. Neste cenário, estes pacotes de trabalho refletem diferentes projetos, mas eles poderiam ser usados para modelar, também, sprints em um contexto ágil. Os sinais de aviso na figura, e a tabela à esquerda, mostram que se o Projeto P428 terminar atrasado acontecerá um conflito, uma vez que o Projeto 473 precisa da saída do primeiro projeto. Mais ainda, existem problemas potenciais com uma sobreposição de escopo, como mostrado na tabela da direita: os Projetos P431 e P473 trabalham ao mesmo tempo no aplicativo New Relic Insights. Se eles também se sobrepõem no tempo, eles podem acabar trombando um com o outro.
 Planejamento e dependências entre projetos
A informação sobre o escopo dos projetos, por sua vez, é buscada em outra parte do modelo. A visão abaixo mostra o roteiro de alto nível do programa de racionalização de aplicativos. As caixas rosa representam os mesmos projetos mostrados acima, migrando os dados de um aplicativo antigo para um novo aplicativo. Se um projeto toca um aplicativo, então aquele aplicativo está no escopo daquele projeto.
 Roteiro de alto nível
Este roteiro usa o conceito de platô do ArchiMate para modelar os principais estágios na transição do panorama de aplicativos, de uma forma semelhante ao que nós mostramos na postagem anterior. Assim, você pode conectar seu planejamento grosseiro de alto nível com as informações detalhadas dos ciclos de vida dos aplicativos, projetos e outros elementos individuais.
Se você quer saber mais sobre estas e outras funcionalidades avançadas do Enterprise Studio, entre em contato e agende uma demonstração.
* Mark Lankhorst é Gerente de Consultoria & Evangelista-Chefe de Tecnologia, e Sven van Dijk é consultor-líder da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria. |
Planejamento e Roteirização: Modelando com ArchiMate
Originalmente postado por Marc Lankhorst e Sven van Dijk*, no blog da BiZZdesign. - Tradução e adaptação autorizados Na nossa postagem anterior sobre planejamento e roteirização, discutimos a ideia geral do planejamento e roteirização no contexto da arquitetura corporativa e o planejamento baseado em capacidades. Nós abordamos vários níveis de roteiros, desde sprints de curto prazo com duração de poucas semanas, até roteiros de longo prazo cobrindo vários anos. Nesta postagem, queremos ir um pouco mais fundo nas várias formas de modelar a evolução da sua arquitetura.
Modelando roteiros com platôsUma das características mais marcantes da linguagem ArchiMate é o conceito de Platô. No padrão, isso é definido como: "um estado relativamente estável da arquitetura que existe durante um período limitado de tempo". A intenção deste conceito é modelar mudanças razoavelmente grandes na sua arquitetura, por isso 'relativamente estáveis'; mudanças em pequena escala são muito frequentes para se permitirem serem capturadas através de platôs. Por exemplo, você não deveria modelar cada atualização individual nos seus aplicativos desta forma. Uma vez que, de qualquer forma, estas pequenas mudanças raramente tenham significância arquitetural (embora possam, naturalmente, ser importantes por outras razões), um modelo de arquitetura não é o melhor lugar para capturar tais mudanças. Assim sendo, esta forma de modelar é particularmente útil nos níveis estratégico e tático com os quais tipicamente a arquitetura corporativa está preocupada.
Um platô é válido por algum período de tempo, então ele tipicamente tem uma data de início e de término. Um platô pode entrar em vigor depois que algum projeto ou trem de entrega ágil (ART-Agile Release Train) entrega uma mudança, e continua em vigor até que a próxima mudança acontece. Em termos de relacionamentos ArchiMate, platôs podem agregar quaisquer elementos ou relacionamentos na arquitetura que sejam válidos dentro do período compreendido pelo platô, O escopo da arquitetura de um platô pode ser limitado a uma parte específica da arquitetura, por exemplo, um domínio de negócio ou um sistema específico. Vários sub-platôs podem ser agregados em um platô mais amplo, para modelar, por exemplo, o roteiro completo que consiste de da evolução dos diferentes domínios de negócio. Naturalmente, você deveria manter os períodos de tempo dos sub-platôs consistentes com seu platô 'pai', se não seu modelo não fará muito sentido.
Modelando cenáriosVocê também pode usar platôs para expressar caminhos alternativos em direção ao futuro. A figura abaixo dmostra um exemplo disso, em um cenário pós-fusão de duas organizações: na Transição A, um sistema CRM comum é implementado primeiro, enquanto na Transição B os sistemas de retaguarda são substituídos primeiro. A Transição C, então, é o estado em que tanto o CRM como os sistemas de retaguarda já estão consolidados, e ele antecede a implementação de um armazém de dados comum.
 Exemplo de roteiro com platôs
A notação gráfica para os platôs é útil principalmente para mapear tal evolução, ao invés de organizar a arquitetura em si, uma vez que muitos elementos na sua arquitetura farão parte de vários platôs. Por exemplo, tudo aquilo na Linha de Base que sobrevive através das transições pode ser agregado em todos os platôs.
Por essa razão, nós geralmente usamos platôs em um modelo de arquitetura, mas não necessariamente em uma visão da maneira mostrada acima. Ao invés disso, nós entramos com os relacionamentos de agregação entre os platôs e o seu conteúdo em uma tabela de referência cruzada e usar isto em visões e análises. A figura abaixo mostra um exemplo disso, realçando os elementos de acordo com os platôs em que eles estão, também com base no mesmo cenário acima:
 Realçando os platôs na arquitetura
Modelando incrementos e releases como especializaçõesAlém da evolução grosseira do roteiro mostrada acima, você também pode querer modelar que algum elemento da arquitetura está sendo evoluído. Um exemplo comum disso é usar 'incrementos de capacidade' para expressar que a maturidade de uma capacidade cresce ao longo do tempo. Uma boa forma de fazer isso é modelar cada incremento como uma especialização de um elemento genérico de mais alto nível, neste caso esta capacidade específica, e agregar estas especializações nos platôs apropriados. Desta forma, você pode ver tanto a estrutura geral da arquitetura - ou seja, quais elementos são necessários para realizar esta capacidade - como mostrar as melhorias consecutivas. O mesmo padrão funciona para a modelagem de releases de software, de forma que você pode modelar o elemento genérico 'App de Pagamento' com especializações como 'App de Pagamento v3.3', 'App de Pagamento v3.4' e 'App de Pagamento v4.0'. Cada um destes elementos pode, por sua vez, ser relacionado com um platô que começa na data de liberação ou implementação daquela versão, e que termina quando ele é substituído pela próxima. A figura abaixo mostra isso:
 Roteiro com releases e versões
Na próxima postagem desta série, daremos uma olhada na modelagem do tempo em um nível mais detalhado e granular. Discutiremos também como você pode modelar os ciclos de vida dos elementos individuais e usar dependências entre os estágios dos ciclos de vida dos vários elementos na sua arquitetura para identificar, por exemplo, conflitos nos seus planos de transição. Se você quiser ver qualquer uma destas funcionalidades ao vivo e a cores, na nossa ferramenta BiZZdesign Enterprise Studio, assista nossos vídeos de introdução ou agende uma demonstração.
* Mark Lankhorst é Gerente de Consultoria & Evangelista-Chefe de Tecnologia, e Sven van Dijk é consultor-líder da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria. |
Planejamento e Roteirização: Introdução
Originalmente postado por Marc Lankhorst e Sven van Dijk*, no blog da BiZZdesign. - Tradução e adaptação autorizados Um motivador importante para o gerenciamento, em geral, e para a arquitetura corporativa, em particular, é obter um melhor controle sobre o futuro, sobre a evolução da sua empresa. Uma técnica comum para suportar isso é a roteirização. Um roteiro é um plano estratégico que mostra os principais passos ou marcos necessários para alcançar os resultados desejados. Ele articula a direção estratégica da sua empresa e mostra o caminho à frente. Ele ajuda você a identificar o que é necessário e quais são as principais dependências e prioridades, e serve como um instrumento de comunicação para alinhar a organização ao longo de um curso de ação comum.
É importante compreender que quanto mais distante no futuro nós planejamos, menos concretos nossos planos podem e devem ser. Por um lado, nós só podemos explorar e desenvolver o conhecimento necessário ao longo do caminho, por exemplo, porque os usuários só podem nos fornecer os seus requisitos de na base do 'eu só saberei isso quando eu ver isso'. Por outro lado, o mundo continua mudando à nossa volta, de forma que nós precisamos, de qualquer forma, mudar os nossos planos de acordo, fazendo com que definir planos detalhados muito à frente no futuro seja um exercício infrutífero e quase impossível. Um roteiro não é, com certeza, um planejamento quinquenal, mas um instrumento flexível para dar direção para a nossa empresa e identificar as principais dependências. A figura mais ampla e as partes mais distantes do nosso roteiro são, assim, pintadas por meio de um pincel mais largo.
Planejamento Baseado em Capacidades e RoteirizaçãoUm caso de uso importante para os roteiros é o planejamento baseado em capacidades. A evolução das capacidades em termos dos assim chamados 'incrementos' é algo que você pode expressar perfeitamente por meio de um roteiro. A figura abaixo mostra um roteiro simples onde a capacidade de Gerenciamento do Cliente é gradualmente melhorada por meio de vários projetos para homogenizar a informação e os dados sobre os clientes, melhorando o acesso global a estes dados e harmonizando os processos de faturamento através das várias unidades de negócio
 Planejamento Baseado em Capacidades
Estes projetos serão detalhados em partes menores de trabalho, e os incrementos de capacidade, em si, irão requerer melhorias específicas nos vários aspectos da arquitetura. Isso pode ser desenvolvido por meio de pacotes de trabalho específicos dentro destes projetos, e expresso por meio dos entregáveis apropriados.
Roteiros em múltiplos níveisRoteiros podem ser definidos de várias maneiras e em múltiplos níveis. No contexto do desenvolvimento ágil de software, por exemplo no Framework Scaled Agile, você verá com frequência múltiplos níveis e escalas de tempo, tais como:
Todos estes são considerados parte da 'roteirização' como uma técnica geral.
A evolução das suas capacidades pode ser expressa por meio de funcionalidades e histórias de usuário, e colocadas no backlog de algum sprint para serem desenvolvidas pelas várias equipes ágeis existentes. Vários sprints de múltiplas equipes ágeis em conjunto resultam em um release que fornece um incremento de capacidade, e uma série de releases, por sua vez, podem juntos resultar um um resultado de negócio específico.
Quando criando um roteiro multinível, você definirá o conteúdo detalhado dos sprints apenas no curto prazo, com histórias de usuário específicas para serem implementadas e mudanças concretas em processos e sistemas. Releases serão planejados, talvez, uns poucos meses à frente, mas as funcionalidades de cada release serão especificadas apenas em alto nível, de uma forma mais grosseira, sendo detalhadas somente para o próximo release. Estágios do roteiro em alto nível e escala de tempo mais longa serão ainda mais abstratos, por exemplo, identificando melhorias de capacidade, como no exemplo acima, ou mesmo apenas dando a direção na forma de metas de longo prazo e resultados desejados.
Modelando Roteiros no ArchiMateDois conceitos do ArchiMate fundamentais para modelar roteiros são o Pacote de Trabalho e o Platô. Pacotes de Trabalho são usados para modelar o trabalho a ser feito nos vários níveis envolvidos, desde os sprints individuais até roteiros completos. A resultante evolução da arquitetura é capturada em Platôs, que agregam os elementos da arquitetura válidos durante um certo período de tempo.
O exemplo abaixo mostra um pouco disso. À esquerda vemos o desenvolvimento concreto de processos, sistemas e dados organizados em sprints modelados por meio dos conceitos Pacote de Trabalho e Platô do ArchiMate. Múltiplas equipes podem estar trabalhando no mesmo período de sprint, por isso os Pacotes de Trabalho são replicados. À direita vemos os incrementos de capacidade mais abstratos organizados em releases que são, eles mesmos, o resultado de uma série de sprints. No modelo subjacente (mas não mostrado na figura), todos os elementos criados ou modificados nos dois sprints contribuem para o primeiro incremento de capacidade. Note que, diferente da figura anterior, esta não mostra uma linha do tempo da esquerda para a direita.
 Estágios do roteiro de alto nível e detalhados
Como mencionado acima, quanto mais à frente você olha, menos concreto seu roteiro será. Desta forma, os conceitos usados para o futuro próximo são tipicamente os elementos concretos e detalhados das camadas de negócio, aplicativo e tecnologia. Para o médio prazo, você poderia usar os conceitos mais abstratos de capacidade e recurso, e no longo prazo você poderia talvez expressar usando apenas metas e resultados. Na próxima postagem desta série vamos explorar em maiores detalhes como você pode modelar seus roteiros usando conceitos ArchiMate para as diferentes perspectivas de tempo e níveis de detalhe. Finalmente, na terceira e última postagem nesta série, entraremos em maiores detalhes em funcionalidades avançadas do Enterprise Studio para trabalhar com roteiros e ciclos de vida, por exemplo, para mostrar linhas do tempo, analisar dependências entre ciclos de vida de partes da sua empresa, ou para detectar conflitos entre as mudanças planejadas. Fique ligado! * Mark Lankhorst é Gerente de Consultoria & Evangelista-Chefe de Tecnologia, e Sven van Dijk é consultor-líder da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria. |
A "Consumerização" da Arquitetura Corporativa: Todo Mundo é um Arquiteto
Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign. - Tradução e adaptação autorizados A Arquitetura Corporativa é geralmente percebida como uma disciplina abstrata, conceitual e, de alguma forma, 'esotérica', praticada por 'gurus' que fornecem orientação por meio dos seus elevados 'princípios da arquitetura'. É verdade que os arquitetos estão geralmente interessados em preocupações amplas e transversais que não são sempre visíveis para as pessoas 'nas trincheiras', mas essa visão da arquitetura corporativa é no mínimo imprecisa e, cada vez mais, equivocada.
Coerência entre a mudança de cima para baixo e de baixo para cima.A tarefa da arquitetura corporativa é desenhar e melhorar de forma coerente a forma como a empresa opera, em concordância com a estratégia da empresa, o ecossistema de negócios, e as necessidades e desejos dos vários grupos de partes interessadas. Isso deveria ser algo com o qual todas as pessoas na organização deveriam se preocupar, cada uma dentro do seu escopo e a partir da sua perspectiva particular. Mintzberg and Waters[1] distinguiram as estratégias deliberadas (de cima para baixo) e emergentes (de baixo para cima) já nos anos 1980, e Ciborra[2] discutiu que o 'pensamento' local pode resultar em vantagem estratégica que é difícil de ser copiada pelos competidores.
Nas organizações modernas que empregam, por exemplo, metodologias Agile, DevOps e Lean, inovação e melhoria são igualmente uma preocupação de baixo para cima. Para ser bem-sucedido no ambiente de negócio volátil de hoje, no entanto, você precisa ter uma maneira de coordenar e alinhar estas mudanças de cima para baixo e de baixo para cima ao longo de uma visão compartilhada. É aqui que a arquitetura corporativa pode ajudar. Em uma postagem anterior que tratava do relacionamento entre Agile/DevOps e Arquitetura Corporativa, falamos um pouco sobre isso, pontuando como a arquitetura corporativa pode adicionar valor para a forma de trabalho do Agile e DevOps. Levar em consideração este relacionamento ajuda você para analisar o impacto dos vários eventos e mudanças, priorizar as mudanças com base no valor de negócio, coordenar o trabalho através das diferentes disciplinas, e fornecer o contexto para a inovação.
Tornando todo mundo um arquitetoNo longo prazo, estamos vendo uma mudança mais profunda no papel da arquitetura: posicionar a arquitetura corporativa não mais como uma disciplina operacional de alto nível, de cima para baixo, mas como um tecido de conexão entre os vários tipos de mudança. Dentro da empresa, isso significa que todo mundo terá, de alguma forma, um papel no desenvolvimento e na evolução da arquitetura. Essencialmente, todo mundo se torna um arquiteto!
Naturalmente isso não significa que cada colaborador terá que fazer um curso de TOGAF ou de ArchiMate. Ao invés disso, você deveria fornecer para todo mundo os instrumentos que permitam que eles vejam as opções e os efeitos que as mudanças locais ou globais poderiam ter, e agir de acordo. Todas essas mudanças podem, então, ser alinhadas com a visão compartilhada da empresa e trabalhar juntas em harmonia, indo desde o resultado de uma melhoria em um processo localizado ou na prioridade de alguma história de usuário ágil, até o impacto de uma fusão ou o efeito de novos requisitos regulatórios no seu modelo de negócio.
O arquiteto: de 'super-arquiteto' para administrador da mudançaO principal motivador para esta mudança na ênfase é a necessidade de velocidade na empresa. Para sobreviver e competir, as organizações precisam se adaptar a um ambiente em mudança cada vez mais rápida. Esta é uma preocupação estratégica que cada vez mais supera a visão tradicional de custos ou receitas, principalmente em mercados onde 'o vencedor leva tudo' que nós geralmente vemos no ambiente digital. Nós já falamos, anteriormente, sobre a nossa visão sobre a Empresa Adaptativa e sobre as capacidades que você precisa ter para suportar isso. Qualquer grande empresa precisa de mecanismos de coordenação além de equipes locais fazendo mudanças locais: se você só tem um bando de equipes ágeis construindo silos ágeis, você pode acabar com 'legados instantâneos' e a sua empresa pode se tornar menos - e não mais - adaptativa ao seu ambiente.
A figura abaixo, tirada do Modelo de Maturidade em Arquitetura Corporativa da BiZZdesign, mostra como nós vemos esta evolução, desde os esforços informais desconectados até um foco colaborativo na adaptabilidade e na inovação. Isso se aplica tanto à evolução da disciplina em si, como à forma como ela é empregada em cada empresa individualmente.
 Estágios da Maturidade em Arquitetura Corporativa
Atenção, esta mudança não significa que os arquitetos corporativos irão desaparecer. Pelo contrário, seu papel mudará de 'super-desenhistas' para administradores da mudança dentro da empresa. Ao invés de conceber tudo por si mesmos, eles cada vez mais fornecerão assistência para as outras pessoas envolvidas na mudança, e garantirão a qualidade e a coerência no nível corporativo da arquitetura, como um tecido de conexão da organização.
"Consumerização" da Arquitetura CorporativaEnvolver todo mundo na arquitetura da empresa requer uma nova abordagem para os instrumentos usados. Em um passado não tão distante, arquitetos, desenhistas de processos, desenvolvedores de software, gerentes de portfólio, e outros 'especialistas em mudanças' usavam suas ferramentas de modelagem e análise específicas, cada um no seu próprio domínio. A colaboração entre estes domínios, para não dizer com os 'não-especialistas', era difícil. Assim sendo, precisamos aumentar esta colaboração por meio de instrumentos acessíveis para todos dentro da organização, onde a informação sobre a arquitetura possa ser compartilhada de uma maneira fácil de ser consumida, personalizada para as necessidades dos vários grupos de partes interessadas. Isto significa, também, usar ferramentas comuns, padrão de mercado, e integrá-las no seu ambiente de colaboração - estabelecendo, assim, a 'consumerização' da arquitetura corporativa.
As funcionalidades de uma plataforma colaborativa como essa incluem:
A boa nova é que isso não é ficção científica! Já que você está lendo isso no blog Comunidade, da Centus Consultoria, você já deve ter adivinhado que isso é exatamente o que a plataforma colaborativa da BiZZdesign oferece. O Enterprise Studio é um ambiente de modelagem e análise usado pelos especialistas. O HoriZZon é o nosso portal de colaboração e visualização para os usuários não-especialistas, e ambos são suportados pela plataforma TeamServer, que fornece o gerenciamento dos modelos, fluxo de trabalho, segurança, integração de dados e muito mais. A ferramenta está evoluindo rapidamente suas funcionalidades, para acomodar esta mudança no foco em direção à 'consumerização' da arquitetura corporativa. Fique ligado nas nossas postagens para saber mais sobre as funcionalidades da nossa plataforma, ou entre em contato conosco para agendar uma demonstração.
[1] Of Strategies, Deliberate and Emergent; Henry Mintzberg e James A. Waters; Strategic Management Journal Vol. 6, No. 3 (Jul. - Set., 1985), pp. 257-272
[2] Ciborra C.U. (2009) From Thinking to Tinkering: The Grassroots of Strategic Information Systems. Em: Bricolage, Care and Information. Technology, Work and Globalization. Palgrave Macmillan, London
* 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. |
5 Práticas Importantes na Implementação da Transformação Digital
Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign. - Tradução e adaptação autorizados O uso efetivo de tecnologias digitais para a Transformação Digital é fundamental em um ambiente competitivo. Para ter sucesso, você não precisa de uma estratégia digital separada; você precisa de uma estratégia de negócio para a era digital. Mas a transformação digital é difícil de gerenciar, porque ela requer que você mude várias partes em movimento da sua empresa, algo como redesenhar e reconstruir um avião em pleno voo. Em um artigo publicado há algum tempo, a McKinsey identificou dez armadilhas que podem descarrilhar as transformações digitais. Eles mencionam fatores tais como o 'medo do desconhecido', 'falta de foco', 'falta de disciplina' e 'se mover muito devagar'. Em nossa experiência através de várias indústrias e com vários clientes diferentes, nós temos visto muitas destas armadilhas com nossos próprios olhos. Para superar estas armadilhas, no entanto, nós identificamos cinco práticas importantes que ajudarão você e a sua empresa a obter sucesso na sua transformação digital. 1. Definir sua direção estratégica Como o Gato Risonho diz, em Alice no País das Maravilhas, "Se você não sabe para onde está indo, qualquer estrada vai levá-lo até lá". Muitas organizações sofrem desta falta de direção e de foco. Mas como você pode definir sua estratégia de uma forma que seja fácil para ser compreendida? E como você avalia a sua viabilidade? Nós, da Centus/BiZZdesign, como você já deve ter imaginado, defendemos o uso de modelos para descrever e analisar suas opções e escolhas estratégicas. Várias técnicas são úteis neste contexto, como o Canvas do Modelo de Negócio (Business Model Canvas, de Osterwalder & Pigneur). Este modelo expressa os principais constituintes do modelo de negócio de uma forma clara e concisa.  Business Model Canvas (adaptado) Existem vários outros instrumentos de análise úteis, como por exemplo o modelo de Cinco Forças de Porter, o Balanced Scorecard e as análises SWOT e PESTEL, entre outros. Além destas, nós suportamos outras técnicas que incorporam o teste de estresse de modelos de negócio, que identificam as forças e as fraquezas dos seus modelos de negócio propostos, por meio da avaliação deles contra diferentes cenários antes da sua implementação. Nesta série de postagens nós detalhamos mais o nosso suporte para estas técnicas. O recado mais importante que queremos deixar é que todas estas opções são baseadas em um mundo integrado de modelos, permitindo que você analise as mesmas iniciativas estratégicas a partir de vários pontos de vista de uma forma coerente. 2. Alinhar a organização Definir uma estratégia coerente para a Transformação Digital é, naturalmente, apenas o primeiro passo. Uma vez que você tenha uma estratégia, você precisa garantir que todos compreendam a nova direção e ajam de acordo. Isto requer fornecer informação clara e útil sobre a estratégia e o seu impacto para todos na organização, de acordo como seu nível adequado de detalhes. Naturalmente, o gerenciamento de mudanças não é um assunto simples e, como afirmou Peter Drucker, "a Cultura come a Estratégia no café da manhã". De qualquer forma, existem lições comuns que podem ser aprendidas a partir de casos de transformação bem-sucedidos. Uma das lições mais importantes é que, no mundo de hoje, a transparência é fundamental. Como foi confirmado por uma pesquisa co-organizada pelo The Open Group, a BPTrends, a BiZZdesign, a Universidade de Twente e outros parceiros em 2016, um fator fundamental de inibição da implementação da estratégia é a falta de entendimento em relação à intenção estratégica. Fornecer informação prontamente acessível para os vários grupos na organização (no seu nível apropriado) através de um canal apropriado, como o nosso portal HoriZZon, ajuda a fomentar a compreensão e o alinhamento. 3. Implementar a sua estratégia de uma maneira adaptativa Os modelos estratégicos mencionados anteriormente podem ser facilmente relacionados com a sua arquitetura corporativa. Isso permite que você avalie o impacto e a viabilidade dos novos modelos de negócio, bem como desenhar a sua implementação no contexto da sua organização atual. Observe que nós não defendemos uma abordagem clássica em cascata, um 'grande desenho antecipado'. Como nós discutimos no nosso eBook 'A Empresa Adaptativa', a mudança de negócio bem-sucedida não é um caso de implementação rígida de grandes planos. Ela requer a orientação estratégica de cima para baixo, mas também a melhoria colaborativa de baixo para cima. Você precisa reunir pessoas de várias áreas da organização para fornecer o conhecimento e as competências necessárias, e então usar informação de alta qualidade para suportar a tomada de decisão, o desenho e a implementação. Modelos de arquitetura fornecem um contexto, um escopo e um conjunto de restrições para estas várias equipes, que então terão a autoridade local para criar a sua parte na transformação maior de uma maneira ágil. Da mesma forma, estes modelos ajudam às equipes a coordenar seus esforços, aprender com os outros, evitar a duplicação desnecessária do trabalho e prevenir um conjunto incoerente de 'silos ágeis' ou software 'legado imediato'. 4. Estimular a inovação, a melhoria e o aprendizado locais Uma estratégia de mudança deliberada, de cima para baixo, é apenas parte da história. Já nos anos 1980, Mintzberg e Waters haviam identificado a estratégia emergente como a outra metade da equação. No entanto, em muitas organizações, é difícil para as equipes locais melhorarem a sua forma de trabalho, criar software melhor ou de outra forma implementar a melhoria de baixo para cima, mesmo que as pessoas no 'chão de fábrica' em geral saibam melhor como as coisas funcionam. Isto acontece principalmente porque eles não têm as percepções necessárias para avaliar os efeitos das mudanças, e, desta forma, não estão autorizados a fazer com que elas aconteçam. Se você não tem os dados necessários, você precisa subir a hierarquia; somente as gerências seniores têm a autoridade para tomar as decisões com base no seu instinto ao invés dos fatos. Mas, fornecer a informação correta para as pessoas a partir de uma única fonte da verdade facilita delegar a tomada de decisões. Isso, por sua vez, acelera a mudança na sua organização, e você não terá que esperar que as decisões 'escorreguem' desde os níveis superiores. Uma fonte única da verdade agrega e integra a informação de várias fontes, e apresenta os resultados por meio de painéis de controle facilmente consumíveis, diagramas e outros formatos. Isto é um instrumento importante para suportar as equipes nas suas melhorias locais e para relacionar estas melhorias com a direção estratégia em larga escala da sua empresa. Mais ainda, ela inspira as pessoas a aprender com as outras e fornece uma plataforma para a disseminação de inovações através de sua empresa. 5. Mantenha-se em conformidade com as regulações aplicáveis Nenhuma transformação digital pode acontecer sem restrições. Agora, mais do que nunca, as organizações devem lidar com uma pressão regulatória crescente tanto de fontes esternas como internas. Algumas destas pressões são específicas de uma indústria, como serviços financeiros e de saúde, enquanto outras são mais genéricas, como a nova regulamentação da LGPD sobre proteção dos dados pessoais (veja nosso webinar e nossas postagens sobre GDPR e LGPD aqui: 1, 2, 3). É crucial que o risco, a segurança e a conformidade não sejam endereçados depois do fato, mas que sejam tratados como uma influência primordial no desenho. Por exemplo, um modelo de negócio baseado no uso intensivo de dados pessoais pode simplesmente ser invalidado por estas novas regulações de privacidade. Mais ainda, a segurança-por-desenho é agora uma exigência legal, e não mais uma opção de cada empresa. O ponto comum, aqui, é a necessidade de se ter percepções claras sobre os vários riscos que a empresa corre. E, no contexto da transformação digital, os riscos cibernéticos estão, naturalmente, no topo das preocupações. Na nossa plataforma, nós suportamos vários tipos de análises que ajudam você a avaliar e endereçar tais riscos (para saber mais, acesse esta postagem sobre a análise de riscos, segurança e conformidade). Nossa plataforma suporta a análise de riscos usando os mesmos modelos que você já criou para desenvolver a sua estratégia, sua arquitetura, seus modelos de dados, processos de negócio e lógica de decisão. Tudo isso alimenta a abordagem integrada necessária no ambiente atual de alta pressão. Gerencie os riscos para implementar a transformação Para citar novamente o artigo da McKinsey: "Para construir o valor real, os líderes do negócio precisam assumir riscos. Mas, aqueles bem-sucedidos serão aqueles que entenderem como gerenciar o risco que realmente importa, e como evitar as armadilhas que podem arruinar um esforço de transformação - tudo isso enquanto levam as suas organizações ao seu limite." * 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. |
Especificação ArchiMate® 3.1: A Nova Versão do Padrão
Originalmente postado por Marc Lankhorst*, no blog do The Open Group. - Tradução e adaptação autorizados
No evento do The Open Group em Amsterdan, em 05 de novembro de 2019, foi lançada a mais recente versão da linguagem ArchiMate® para a modelagem da Arquitetura Corporativa. A Versão 3.1 é uma atualização da versão anterior 3.0 (lançada em 2016). Embora seja "apenas" uma pequena atualização, ela trás várias adições e melhorias importantes para os praticantes da Arquitetura Corporativa.
As três melhorias mais importantes são:
Fluxo de ValorA mais importante e visível destas mudanças na Versão 3.1 é a adição de um novo elemento de Fluxo de Valor na camada de Estratégia. O padrão define isso como:
Um Fluxo de Valor descreve como uma empresa organiza suas atividades para criar valor. Como descrito no TOGAF® Series Guide to Value Streams, um importante princípio dos fluxos de valor é que o valor é sempre definido a partir da perspectiva da parte interessada - o cliente, usuário final ou recebedor do produto, serviço ou entregável produzido pelo trabalho. A noção de Fluxo de Valor também aparece em outros lugares, como em métodos de Arquitetura de Negócio, como o Guide to the BIZBOK®, e em métodos ágeis como o Scaled Agile Framework (SAFe®). A definição do ArchiMate é genérica o suficiente para cobrir estas noções.
Fluxos de Valor são diferentes de processos de negócio. Este último está preocupado com o 'como', as tarefas realizadas por uma organização para produzir algum produto ou serviço concreto, enquanto fluxos de valor dizem respeito ao 'o que', o valor que é criado. O valor está no olhar do espectador; ele depende mais da percepção de valor da parte interessada sobre o valor do produto, serviço, resultado, ou entregável, do que do seu valor intrínseco (isso é, o custo do produto). Isso é modelado na linguagem ArchiMate usando o elemento de Valor (que já existia desde a especificação do ArchiMate versão 1.0).
Fluxos de valor são normalmente realizados por processos de negócio. Os estágios em um fluxo de valor fornecem uma estrutura para organizar e definir estes processos, mas diferentes partes da organização podem ter suas próprias implementações dos processos para realizar o mesmo estágio do fluxo de valor. Da mesma forma, um processo de negócio pode realizar vários estágios em um fluxo de valor.
Recursos podem ser atribuídos a fluxos de valor e capacidades podem servir (isso é, habilitar) um fluxo de valor. Isso suporta a técnica comum de mapeamento cruzado entre fluxos de valor e capacidades, onde você identifica quais capacidades e empresa precisa ou usa para suportar os estágios de um fluxo de valor. Um exemplo disso é mostrado na figura abaixo. Ela mostra um modelo do fluxo de valor de uma análise de dados para um estudo de caso de inteligência de negócio. Entre os estágios do fluxo de valor, vemos os fluxos de valor com o valor adicionado associado por cada estágio, e ao final o resultado de negócio de 'tomada de decisão bem fundamentada' que este fluxo de valor realiza para uma parte interessada em particular. Cada estágio no fluxo de valor requer várias capacidades, mostradas abaixo dos estágios e também mostrando como você pode usar o conceito de agrupamento melhorado para modelar eficientemente este mapeamento cruzado.
 Exemplo de Fluxo de Valor
Adicionar este conceito de fluxo de valor criou uma perfeita simetria na linguagem. Fluxos de valor e capacidades refletem o modelo de negócio da empresa e a criação de valor de uma forma independente da sua organização, enquanto os processos de negócio e as funções de negócio refletem seu modelo operacional e são mais dependentes da organização. Nos seus respectivos níveis de abstração, fluxos de valor e processos de negócio representam a 'empresa em movimento', enquanto que as capacidades e funções de negócio descrevem a 'empresa em descanso'.
Associação DirecionadaA adição de um relacionamento de Associação direcionada é uma pequena melhoria com um grande potencial. Um caso de uso comum é para expressar a navegabilidade, por exemplo, que uma apólice de seguro se refere a um ativo segurado, e não o contrário.
Especialmente quando combinado com a noção de relacionamentos especializados do ArchiMate, e a notação de estereótipo relacionada (veja o capítulo sobre Mecanismos de Personalização no padrão), ela permite que você forneça mais significado para uma associação 'sem significado'. A figura abaixo mostra o relacionamento entre o sono de um aplicativo e o aplicativo que ele possui, usando uma associação direcionada estereotipada como essa.
 Associação Direcionada com Estereótipo
Agora, você precisa exercitar alguma cautela ao usar esta funcionalidade. Ela não seria muito útil, por exemplo, para definir seus próprios relacionamentos se alguma coisa bastante próxima já é oferecida nativamente pelo padrão.
Derivação de RelacionamentosAlém das adições e melhorias mencionadas acima, a nova especificação também introduz regras refinadas para a derivação de relacionamentos. Este é um assunto mais especializado, que para a maiorias das pessoas fica escondido por trás das ferramentas de modelagem ArchiMate.
Estas regras de derivação permitem que você tire conclusões ou sumários sobre relacionamentos que podem (ou devem) existir entre dois pontos em uma cadeia de elementos conectados por vários tipos de relacionamentos. Por exemplo, se o seu Departamento de Serviço ao Cliente desempenha (é atribuído a, em termos ArchiMate) um processo de negócio Tratar Solicitação do Cliente, que por sua vez fornece (isso é, realiza) um Serviço de Helpdesk, você pode concluir que o Departamento de Serviço ao Cliente realiza o Serviço de Helpdesk.
Na nova versão do padrão, nós formalizamos estas regras (e as restrições que se aplicam a elas) para garantir que elas sejam bem entendidas e implementadas consistentemente. Isso agora se parece mais com uma especificação 'matemática', mas não entraremos em detalhes sobre isso aqui.
Nós também refinamos estas regras para fazer uma distinção entre derivações que devem ou podem ser verdadeiras. O primeiro tipo, chamado derivação 'válida', são necessariamente verdadeiras. Por exemplo, se A contém B, e B contém C, A por definição contém C (usando um relacionamento de composição). Esta derivação é sempre válida.
 Derivação válida (em azul)
Também é possível tirar conclusões sobre relacionamentos que são apenas 'potenciais'; se eles existem ou não na realidade depende de fatores específicos da sua arquitetura. Por exemplo, se um serviço de aplicativo S serve um processo de negócio P, que consiste dos sub-processos Q e R, qualquer um destes sub-processos poderia (potencialmente) ser servido (ou seja, usar) o serviço S. Somente uma decisão do arquiteto, ou um exame detalhado de Q e R, poderia dizer qual é realmente o caso, mas os dois relacionamentos de servidão são corretos.
 Derivações Potenciais (em vermelho)
Note que todos estes relacionamentos derivados são também permitidos na linguagem ArchiMate. Adicionar esta noção de relacionamentos 'válidos' e 'potenciais' aumentou a força analítica da linguagem e expandiu os relacionamentos possíveis, dando aos modeladores mais liberdade e opções.
Expectativas para o FuturoAlém das principais melhorias mencionadas acima, várias mudanças grandes e pequenas foram feitas nas definições dos conceitos na linguagem, tanto para torná-las mais claras como para melhorar o alinhamento com outros padrões como o TOGAF. A notação de ícone é agora permitida para todos os elementos que possuem uma notação 'caixa com ícone', e não apenas para um pequeno sub-conjunto aleatório. Finalmente, a exibição e a estrutura do metamodelo do ArchiMate foi melhorada em vários lugares. Isso não é algo que o usuário médio da linguagem notará, mas isso ajuda a compreender melhor o padrão.
Com estas recentes melhorias e adições, a cobertura da disciplina da Arquitetura Corporativa pela linguagem ArchiMate está bastante completa, pelo menos em termos dos domínios que ela pode descrever. assim sendo, não esperamos maiores extensões para o escopo da linguagem no futuro próximo. Existem, no entanto, alguns outros aspectos que poderiam ser objeto de melhorias. Por exemplo alternativas de notação que pareçam mais agradáveis para as partes interessadas de negócio, ou formas de usar a linguagem nos estágios iniciais do desenho arquitetural, quando as ideias ainda não estão cristalizadas. Mais ainda, podemos querer procurar formas de simplificar a estrutura da linguagem (naturalmente, sem reduzir a sua força expressiva). Estas são, no entanto, ideias de longo prazo. Por enquanto, a Especificação ArchiMate 3.1 está pronta para uso e sem nenhum concorrente sério, enquanto sua base de usuários cresce continuamente. Se você tem ideias sobre o padrão e quiser contribuir para a sua evolução, ou simplesmente quer conhecer mais sobre ela, junte-se ao Fórum ArchiMate do The Open Group ou ao grupo ArchiMate (ou ArchiMate Brazil) no LinkedIn, onde acontecem discussões acaloradas sobre todos os aspectos da linguagem. Você pode encontrar a Especificação ArchiMate 3.1 aqui (em breve, também em Português Brasileiro).
* 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.
|
Gerenciamento do Portfólio de Aplicativos: Em Direção à Arquitetura Orientada para o Valor
Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign - Tradução e adaptação autorizados Muitas organizações com grandes panoramas de aplicativos legados não podem mais adiar uma reforma geral na sua TI. Mas como você evita criar de novo, hoje, os legados de amanhã? E como você emprega o seu orçamento de TI da forma mais sensata? Além de um desenho e de práticas de desenvolvimento apropriadas (por exemplo, com arquitetura corporativa, métodos ágeis e DevOps, como mostramos anteriormente), você precisa gerenciar seu portfólio de aplicativos como um todo, para decidir onde é mais importante investir.
Gerenciamento de Portfólios Fraco vs ForteO Gerenciamento de Portfólios é um processo de tomada de decisão dinâmico no qual um conjunto coordenado de aplicativos, projetos, programas ou produtos é rotineiramente monitorado, analisado e gerenciado para maximizar sua efetividade. A avaliação e priorização de projetos e atividades associadas com o inventário fornece a oportunidade para priorizar, acelerar, terminar ou "despriorizar" partes do portfólio e alocar ou realocar os recursos associados.
Quando as organizações não têm um gerenciamento de portfólios forte, elas são relutantes para terminar projetos ou executar a retirada de aplicativos ou produtos ao final do seu ciclo de vida. Além disso, os critérios para decidir de um projeto continua ou não (Go/No Go) são inefetivos ou inexistentes. Ativos com baixo desempenho não são avaliados ou eliminados. Alguns projetos desenvolvem vida própria, enquanto outros são adicionados com pouca ou nenhuma consideração pelos seus requisitos de recursos, atenção da gerência ou impacto em outros projetos. Recursos podem ser realocados para o último projeto "urgente", sem uma consideração exaustiva dos efeitos disruptivos que isso pode ter sobre os esforços "importantes" que já estão em andamento.
Como resultado, uma verdadeira falta de foco se instala - resultando em muito mais itens no inventário do que os recursos disponíveis são capazes de gerenciar. Listas de pendências de tarefas começam a se acumular, os tempos de ciclo começam a crescer, e os processos em uso se tornam inefetivos. Os esforços se tornam cada vez mais reativos e a qualidade sofre, resultando em uma taxa de falhas crescente. O impacto mais significativo de um gerenciamento de portfólio fraco é o impacto na direção estratégica - projetos que não estão alinhados com a estratégia do negócio ou que não possuem importância estratégica competem por e consomem recursos valiosos que deveriam estar focados nos esforços mais estratégicos. Muitas organizações sofrem do chamado "estrangulamento da inovação": todos os recursos e orçamentos disponíveis são usados para manter o panorama de legados em funcionamento, espremendo para fora inovações estratégicas importantes.
Existem vários desafios para atingir um gerenciamento de portfólios forte:
Como Fazer um APM da Maneira Correta?Falando genericamente, o Gerenciamento do Portfólio de Aplicativos (APM-Application Portfolio Management) é o processo de gerenciar uma coleção de aplicativos para tomar decisões efetivas sobre oportunidades de investimento. Assim como um portfólio de investimentos, que contém uma coleção de ativos selecionados para suportar objetivos de lucratividade ou crescimento específicos, portfólios de aplicativos deveriam ser gerenciados para efetivamente suportar as principais estratégias e metas de negócio da organização. Em geral, portfólios de ativos podem incluir produtos e serviços; capacidades e processos de negócio; software, como aplicativos de negócio, middleware e bancos de dados; infraestrutura, como servidores, redes, estações de trabalho, dispositivos móveis; e, finalmente, recursos para suportar tudo isso. No APM, nós focamos nos ativos de software.
Infelizmente, muitas organizações abordam o APM como uma simples racionalização de aplicativos pontual, na maioria das vezes focada no custo ou em problemas técnicos de curto prazo. Isso trás alguns problemas significativos. Em primeiro lugar, limpar o seu panorama de aplicativos apenas uma vez e esquecer disso de novo resultará nos mesmos problemas que você tem hoje reaparecendo em um futuro próximo. Ao invés disso, é necessário de uma abordagem de ciclo de vida para o portfólio de aplicativos. O monitoramento e governança regulares, incluindo critérios de valor de negócio claramente definidos da saúde (de negócio e técnica) dos aplicativos e opções de avaliação para o seu futuro, são necessários para gerenciar o portfólio de aplicativos em direção às necessidades do negócio.
 Figura 1. Avaliação de aplicativos usando Análise TIME
Mais ainda, os aplicativos são, em geral, julgados caso-a-caso, mas o panorama como um todo é mais importante, considerando as dependências entre os aplicativos e com os processos de negócio que eles suportam, e a complexidade, os riscos e o valor de negócio do panorama de aplicativos como um todo. Simplesmente substituir ou desligar um aplicativo isolado geralmente não é uma opção.
É essencial saber o valor de negócio dos aplicativos e como eles suportam o negócio, seus processos e capacidades. Mas como você determina isso de uma forma objetiva (isso é, não apenas perguntando para os usuários)? Para isso, você precisa usar modelos de arquitetura corporativa através de todos os domínios da arquitetura para mostrar a rastreabilidade para os processos de negócio, capacidades de negócio, produtos e serviços, e para as estratégias e metas do negócio. Isso também inclui mostrar casos de uso, cadeias de valor e fluxos de trabalho, e como eles são suportados pelos aplicativos, suas funcionalidades e objetos de dados, por exemplo, para um produto ou cliente. Isso ajuda a avaliar os aplicativos em seu contexto, ao invés de isoladamente, e isso pode também melhorar o valor dos aplicativos ao revelar novos usos potenciais. Mais ainda, diferentes categorias de aplicativos são julgadas de acordo com diferentes aspectos. Aplicativos de linha de frente inovativos precisam atender a critérios diferentes dos sistemas de registro estáveis. Portfólios adequados deveriam ser definidos para tais categorias. Você quer garantir uma distribuição balanceada dos investimentos, tanto dentro como através dos portfólios, e tanto para os seus ativos como para seus projetos e programas. É importante escolher critérios baseados nos objetivos de negócio. Tipicamente, um gerenciamento do portfólio de aplicativos forte se apóia em cinco medidas de desempenho:
 Como relacionar o APM com outras disciplinasComo nós indicamos acima, um APM forte depende criticamente de uma linha clara e visão com a estratégia de negócio e uma fundação forte na arquitetura corporativa. Uma forma útil de relacionar seus portfólios de aplicativos com a estratégia é através das capacidades de negócio. Capacidades de negócio definem o que uma organização precisa ser capaz de fazer para atingir os resultados que estão definidos na estratégia corporativa. Elas são os principais blocos de construção do negócio, únicos e independentes uns dos outros, e tendem a ser estáveis ao longo do tempo. Assim sendo, elas são uma fundação muito útil para estruturar portfólios de aplicativos e determinar a importância estratégica dos aplicativos nestes portfólios. Isso pavimenta o caminho para uma arquitetura verdadeiramente orientada para o valor. Mais ainda, um APM forte precisa ser parte dos processos do dia-a-dia que mantém e melhoram o seu panorama de aplicativos. Sua abordagem baseada em valor o torna bem adequado para abordagens como o Scaled Agile Framework (SAFe), discutido na nossa postagem anterior. Ligar o APM com os fluxos de valor no nível de portfólio do SAFe e orçamentar tais fluxos com base em (entre outros) resultados do APM é relativamente simples. ConclusãoEm resumo, um gerenciamento de portfólio de aplicativos forte leva a abordagem de ciclo de vida para o panorama de aplicativos completo, relaciona-o com a estratégia de negócio e é fundamentada sobre uma sólida prática de arquitetura corporativa. Isso pode parecer simples, mas ainda é uma disciplina difícil: desligar os aplicativos machuca, e racionalizar a tomada de decisões pode não ser do interesse de todos... Mas, através do foco nos resultados de negócio, decisões melhores podem ser tomadas e maior valor de negócio pode ser obtido, algo que todas as organizações estão lutando para conseguir.
* 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.
|
Transformação Digital: Como Gerenciar e Governar um Ambiente de TI de Várias Velocidades - Parte 2
Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign - Tradução e adaptação autorizados Na nossa postagem anterior, falamos sobre o impacto da TI de várias velocidades na organização de TI e da Arquitetura Corporativa. Vamos falar, agora, sobre as diferentes opções para gerenciar uma abordagem de TI de várias velocidades. O gerenciamento e a governança da arquitetura ágil de alta velocidade e da arquitetura de linha de base estável e robusta que nós discutimos anteriormente pode ser feita através de várias opções, como mostrado na Figura 1. Você poderia assumir que nós estamos falando apenas sobre uma simples abordagem de TI de duas velocidades, como mencionado em alguns lugares, mas isso não é tão simples como parece.
 Figura 1. Abordagem Bimodal
Por que a TI Bimodal não funciona?Muitas organizações tendem a estabelecer uma função de Escritório Digital que inclui a governança das novas iniciativas digitais suportadas por uma equipe dedicada. Isso soa um pouco parecido com a abordagem bimodal, como defendido pelo Gartner. Assim como qualquer outra abordagem, esta tem seus pontos positivos e pontos negativos. Equipes separadas trabalhando em problemas separados parece ser uma boa ideia, uma vez que cada equipe pode se concentrar nas suas tarefas específicas na caminhada em direção ao seu alvo.
No entanto, isso também resulta em uma desconexão entre as duas equipes. Ao estabelecer duas equipes diferentes para trabalhar em duas tarefas diferentes, a comunicação entre elas sofrerá, independentemente da qualidade da estratégia de comunicação. Mais ainda, a equipe da linha de base estável poderia se sentir com a reputação prejudicada (sendo percebida como 'lenta' e 'antiquada' em comparação com as iniciativas digitais), no acesso aos recursos e ao orçamento, e no poder e influência na organização. Esta circunstância leva a graves conflitos entre as duas equipes, e a qualidade do trabalho pode sofrer dramaticamente.
Mais ainda, a abordagem bimodal, infelizmente, não parece oferecer uma solução sustentável a longo prazo. Ela, inclusive, tem sido acusada de ser incapaz de oferecer uma solução potencial para o problema mais simples da estabilidade vs agilidade. E ainda mais, as organizações que efetivamente implementaram uma abordagem bimodal tiveram que encarar consequências desastrosas, tais como a formação de silos artificiais para produtos, processos e pessoas, e a institucionalização da estagnação em detrimento da inovação nas plataformas tradicionais, com a desculpa que "se não está quebrado, não conserte".
Junto com isso tudo, existe um desafio arquitetural e tecnológico muito maior: os sistemas estáveis de linha de base precisam ser conectados aos sistemas inovadores em rápida mutação do novo domínio dos negócios digitais, uma vez que eles em geral contém os dados de negócio mais importantes. Tais sistemas de registro são indispensáveis, mas são também difíceis de integrar. Colocar o peso desta transformação e integração nas costas da equipe de transformação digital pode diminuir o seu ritmo até um nível inaceitável, enquanto a equipe de linha de base já está ocupada o suficiente apenas para manter as luzes acesas e os sistemas legados funcionando, lidando com novas regras e regulações. Desta forma, parece que nós precisamos de alguma coisa entre estas equipes, para ultrapassar tanto as diferenças culturais como técnicas entre o mundo estável da linha de base e o mundo em constante movimento da transformação digital.
Seria uma Abordagem Trimodal a Solução?Uma abordagem trimodal, como mostrado na Figura 2, oferece um método mais sofisticado e flexível que um cenário simples de duas velocidades. Esta abordagem considera três equipes diferentes: Os Pioneiros, os Colonos e os Urbanistas. Os Pioneiros desenvolvem a organização digital alvo habilitando a inovação e a co-criação, usando métodos e técnicas ágeis. Na outra ponta do espectro, os Urbanistas representam a linha de base, fornecendo serviços estáveis e robustos para os Pioneiros e os Colonos. Simultaneamente, eles gerenciam provedores de serviços externos através de uma função de gerenciamento e integração de serviços, e adicionam valor para as outras equipes. Os Colonos estão posicionados no meio e lidam com transições ou, melhor dizendo, com arquiteturas de transição, ajudando a organização a industrializar e personalizar os serviços, sistemas e aplicativos para que se ajustem na arquitetura de linha de base, e para gradualmente transformar a arquitetura de linha de base para acomodar as novas necessidades de negócio digitais. Eles também garantem um melhor gerenciamento do fluxo de trabalho e da comunicação na medida em que se movem de um nível para o próximo.
 Em Direção à uma Estrutura CelularEvoluir a abordagem trimodal resulta em uma estrutura celular (Figura 3), onde cada equipe (ou ainda, cada membro de uma equipe) suporta a equipe acima dele, preenchendo seus objetivos e assim sendo envolvido nos negócios diários da sua equipe. Várias equipes são responsáveis pelas várias partes da TI, algumas focadas em funcionalidade de linha de base estável, algumas em capacidades digitais avançadas, e algumas em alguma coisa no meio. Aplicar práticas DevOps implica que cada equipe é totalmente responsável por construir e operar sua parte da TI. A comunicação entre as equipes acontece diariamente no 'chão-de-fábrica', e as decisões necessárias entre as equipes podem ser tomadas de forma rápida e eficiente. Mais ainda, partes interessadas relevantes do negócio e da TI podem ser integradas suavemente na equipe de trabalho, contribuindo com as suas visões e fornecendo orientação estratégica e tática quando necessário.
 Figura 3. Abordagem Celular
Arquitetos corporativos são um destes grupos de partes interessadas, focados em garantir que os esforços e os resultados das equipes estão alinhados com a estratégia digital da organização e com as suas metas de médio e de longo prazo. Seu escopo amplo e conhecimento da organização torna-os um fator central neste processo. Se você está nesta posição, tire vantagem deste conhecimento e facilite sua organização em suas jornadas de transformação digital que estão por vir.
* 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.
|
Transformação Digital: Como Gerenciar e Governar um Ambiente de TI de Várias Velocidades - Parte 1
Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign - Tradução e adaptação autorizados Analisando várias discussões que temos tido com muitas organizações a respeito de Estratégia Digital, a maioria delas tem o desafio de balancear suas ações no dia-a-dia. Primeiro, uma Organização Orientada para o Digital precisa aceitar que os papéis e responsabilidades do Negócio e da TI irão se fundir, enquanto precisam habilitar as inovações do negócio e da TI em direção às necessidades do negócio digital. Simultaneamente, eles precisam configurar uma abordagem ágil através de toda a organização para desenvolver e gerenciar modelos de negócio digitais inovadores, lidando com novos momentos de negócio, e realizando os serviços e a tecnologia associada. Finalmente, o controle dos custos da TI e dos seus serviços se mantém no alto das preocupações da organização.
Tais mudanças são especialmente difíceis em organizações com uma grande base de sistemas legados, tanto em termos da TI como em termos dos processos e da cultura organizacional. No setor bancário, por exemplo, nós vemos que bancos e seguradoras estão sob ataque das ágeis empresas FinTech, e lutam para responder de uma maneira adequada. Elas carregam o peso de panoramas de TI complicados, uma cultura de aversão ao risco, e uma sempre crescente demanda por conformidade regulatória. Em termos arquiteturais, eles têm uma arquitetura de linha de base obsoleta em funcionamento, e precisam desenvolver uma nova arquitetura alvo para permitir modelos de negócio digitais e inovadores, que são melhor realizados através de uma abordagem ágil.
Mas, ao mesmo tempo, eles não podem simplesmente substituir os velhos sistemas que rodam os seus processos de negócio centrais, ou mudar radicalmente a forma como estes sistemas e seus processos de negócio associados são mantidos. Os riscos operacionais, as demandas regulatórias e a cultura da organização de desenvolvimento impedem uma abordagem tão radical. É aqui que a chamada abordagem de TI bimodal entra no jogo; as equipes de TI e de Arquitetura Corporativa precisam gerenciar a complexidade nos dois mundos: o ambiente estável e avesso ao risco dos sistemas legados, e os negócios digitais ágeis e inovadores.
Da Linha de Base Tradicional para o Alvo DigitalA arquitetura de linha de base forte e estável é refletida no lado direito da figura abaixo. Isto é gerenciado totalmente através do gerenciamento apropriado de portfólios, arquitetura e liberações, com base em métodos, padrões e frameworks estabelecidos e definidos. Esta arquitetura normalmente é bastante estável e suportada por robustos serviços internos e externos, os quais raramente mudam ao longo do ano. O foco está na redução dos custos e do risco, mantendo a atenção no negócio, e não no desenvolvimento de soluções de negócio e de TI inovadores.
No contexto da Arquitetura Corporativa, a arquitetura alvo representa o estado futuro imaginado da organização, que parcialmente substitui e transforma a arquitetura de linha de base. Atualmente, o desenvolvimento de uma arquitetura alvo é principalmente um projeto de transformação de médio prazo, levando de 1 a 2 anos para implementar um panorama de arquitetura e de soluções complexo através de vários negócios e/ou domínios. Mas, será que isso é realmente sustentável no futuro próximo? A velocidade das mudanças e as pressões competitivas de novos entrantes inovadores requer uma resposta muito mais rápida. Na nossa visão esta abordagem mudará dramaticamente, ou já está mudando em muitas organizações.
Mesmo no futuro próximo, estaremos falando sobre desenvolver e integrar microsserviços no panorama de arquitetura existente, e seremos confrontados com o gerenciamento destes serviços e seus provedores de serviço relacionados, criando um papel completamente novo para os arquitetos.
Por exemplo, vamos assumir que uma seguradora planeje desenvolver uma plataforma colaborativa para permitir a co-criação do desenho e desenvolvimento de novos produtos de seguro. Simultaneamente, eles querem melhorar a experiência do cliente através de um gerenciamento omnicanal. A partir da perspectiva atual, isso parece ser um projeto de transformação de médio prazo, daqueles que nós vemos o tempo todo. Para ser honesto, eles estão na realidade demorando muito para começar a colher os frutos dos galhos mais baixos.
Adicionando Agilidade à MisturaMas o que acontece se você quebrar este projeto em um punhado de serviços menores, ou melhor, microsserviços, que possam ser desenvolvidos por vários fornecedores e outros parceiros usando uma abordagem ágil? Usando métodos e conceitos como produto mínimo viável (MVP-minimal viable product), desenvolvimento ágil e DevOps, cada um destes serviços menores pode ser rapidamente desenvolvido e implementado através de protótipos, e terminar como produtos funcionais em 2 a 4 semanas. Ao fazer isso, é crucial entender que esta abordagem implica em experimentação rápida e ágil que pode, eventualmente, falhar.
Consequentemente, uma cultura de aceitar as falhas, aprender com elas, e fazer certo da próxima vez, é essencial para o sucesso no longo prazo. Você também pode experimentar os chamados testes A/B, testando variações diferentes dos serviços com os clientes para identificar qual variante funciona melhor na prática. Ninguém possui todas as respostas certas desde o início, então você apenas tem que testar o que se encaixa melhor com os seus clientes. Naturalmente, esta abordagem implica em um processo de desenvolvimento rápido e ágil com liberação frequente de novas versões dos serviços, coordenado com conceitos como ART-Agile Release Trains (Trens de Lançamento Ágil), do Scaled Agile Framework (SAFe). Estes trens de lançamento ágil, combinados com o desenvolvimento e publicação frequentes da arquitetura de linha de base estável, são considerados em conjunto como parte da função de Gerenciamento de Portfólio Corporativo sobre a qual escrevemos anteriormente.  Figura 1: Portfólio Corporativo e de TI de 2 Velocidades
Então, a equipe de arquitetura corporativa tem que gerenciar e governar os dois mundos em direção a uma estratégia e visão de arquitetura digital comuns. Mas a questão crucial, aqui, é como gerenciar e governar este mundo digital? Com muita frequência você escuta a respeito de abordagens como TI bi-modal ou tri-modal. Mas elas realmente ajudam você a lidar com a complexidade da transformação digital? Vamos falar sobre isso na nossa próxima postagem.
* 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.
|
Modelos de Arquitetura de Referência com o ArchiMate
Originalmente postado por George Pang*, no blog da BiZZdesign - Tradução e adaptação autorizadas Em uma postagem anterior, realçamos o valor das arquiteturas de referência, incluindo o por quê e o como utilizá-las. Nesta postagem, vamos nos aprofundar um pouco mais, focando no 'produto' que nós (ou alguns de nós) vemos com alguma familiaridade - modelos de referência construídos usando a linguagem ArchiMate.
O que são Modelos de Referência?Primeiro, vamos dar um passo atrás e olhar novamente para as arquiteturas de referência, descritas como "arquiteturas padronizadas que fornecem uma estrutura de referência para um domínio, setor ou campo de interesse específico". O que um modelo de referência trás para a mesa é uma visão muito clara (usualmente em uma página) de um domínio de interesse - algo que é reusável e que, naturalmente, pode ser adaptado para atender às necessidades da organização.
Os exemplos de tipos de modelos de referência incluem:
Existe uma infinidade de modelos de referência da indústria disponíveis para uso por todos, mas a verdadeira força dos modelos de referência é pegá-los e transformá-los em modelos de referência específicos da organização - modelos que possam provocar a discussão, promover o reuso e fornecer rastreabilidade para outras áreas da arquitetura.
Como eu represento isso usando o ArchiMate?Modelos de referência geralmente nascem como um simples slide em uma apresentação PowerPoint, um diagrama no Visio, ou mesmo algumas células preenchidas em uma planilha Excel. Isso é ótimo para a comunicação, e transmite a mensagem rapidamente de forma pontual.
No entanto, quando estamos falando sobre Arquitetura Corporativa, muito raramente os modelos de referência são usados em isolamento - nós precisamos 'ligá-los' às outras áreas e disciplinas, de forma que é necessário usar um padrão para unir os elementos dos modelos de referência - por exemplo, a linguagem ArchiMate.
A questão que aparece continuamente é: "qual o conceito que nós deveríamos usar para representar os 'blocos de construção' neste modelo de referência em particular?"
Esta é um assunto que pode, muitas vezes, gerar dias, e até mesmo semanas, de discussão - e brigar sobre isso na realidade apenas invalida o objetivo de usar modelos de referência como, bem, referência - nós apenas precisamos concordar com a representação e, então, simplesmente usá-la de forma consistente! Para aconselhar ou responder a esta pergunta, nós realmente precisamos observar mais de perto o modelo de referência em questão. Vamos voltar aos três exemplos mencionados acima.
O Modelo de Referência de NegócioEssencialmente, para descrever o 'Negócio em uma página' nós quebramos as áreas principais (pais) em áreas menores (filhos), e então mais uma vez (netos), e assim por diante. Isto deveria descrever 'o que a organização faz', e isso geralmente fornece uma pista sobre o elemento a ser usado. Para aqueles que possuem um conhecimento razoável da linguagem ArchiMate, algum tipo de 'comportamento' está sendo descrito, e ele deveria ser naturalmente de negócio. Isso nos leva a alguma coisa como uma Função de Negócio!
 Figura 1. Arquitetura de Referência da Indústria Bancária da Microsoft
O Modelo de Referência de TecnologiaSimilar ao Modelo de Referência de Negócio, o TRM tipicamente descreve a 'Infraestrutura em uma página', mas, novamente, em uma perspectiva mais funcional - ele não deveria chegar ao nível de detalhamento fino, por exemplo, de "servidor x, y ou z", nem de processadores, memória, ou outras informações deste tipo.
Tendo estes pontos em mente, nós estaremos olhando para Serviços de Tecnologia e Funções de Tecnologia (ou seja, comportamento de tecnologia).
 Figura 2. Modelo de Referência do Ecossistema em Nuvem
O Modelo de Referência de InformaçãoAté aqui, nos dois exemplos acima, nós vimos que foram usados os conceitos de 'comportamento' do ArchiMate - o que é comum para vários modelos de referência. Os conceitos 'estruturais', em geral, acabam sendo mais próximos da implementação. O IRM é uma descrição das informações 'comuns' disponíveis dentro de uma organização (alguma coisa como o SID, do TM Forum, é uma boa inspiração). Colocando isso em perspectiva, o uso de conceitos de comportamento não se encaixa aqui - assim, nós logicamente olhamos para a coluna 'estrutura passiva' (que descreve os 'objetos' de algum tipo). Como os modeladores ArchiMate experientes estão conscientes, deve ser tomada a decisão sobre usar Objetos de Negócio ou Objetos de Dados para representar os elementos do IRM. Isso, mais uma vez, está sujeito à interpretação, mas, em geral, algo tão alto-nível como 'informação' é melhor representado por um Objeto de Negócio.
 Figura 3. O Modelo de Informação SID, do TM Forum ConclusãoEntão é isso! Estas são algumas sugestões para trabalhar com Modelos de Referência usando a linguagem ArchiMate. Você poderia, potencialmente, usar vários conceitos do ArchiMate para representar elementos nos modelos; no entanto, os pontos mais importantes são concordar com um padrão (e segui-lo), ser consistente no seu uso, e compartilhar os resultados! Uma última conclusão foca na apresentação para partes interessadas "não-técnicas" - lembre-se, embora o ArchiMate possa criar modelos de referência usando uma notação padronizada (para criar relacionamentos válidos que permitam a análise de impacto e outras), não existe nenhuma razão para não formatar a saída de uma outra forma (usando um ponto de vista de 'informação', por exemplo).
Uma ferramenta de arquitetura pode facilitar de forma significativa a documentação deste tipo de modelos e ajustar sua visualização para atender às necessidades (visuais) da sua audiência. Então, dê uma olhada nas funcionalidades da nossa ferramenta BiZZdesign Enterprise Studio e entre em contato para uma demonstração.
* George Pang é Consultor Líder da BiZZdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria. |
1-10 of 111