ArchiMate na Prática - Serviço de Negócio, Função de Negócio e Processo de Negócio

Para iniciantes no uso da linguagem ArchiMate, uma questão recorrente é: qual a diferença entre serviço, função e processo de negócio? Este artigo procura apresentar uma maneira clara de usar de forma correta cada um destes conceitos.

Serviço de Negócio

Um serviço de negócio representa o valor adicionado que uma organização entrega para o ambiente. É a parte "visível" das atividades da organização, sendo que o termo "organização" deve ser entendido em um sentido amplo: pode ser uma empresa, uma área da empresa (departamento), um conjunto de empresas, em suma, qualquer parte identificável da estrutura organizacional. Os serviços de negócio podem ser internos, quando prestados para outras unidades organizacionais da organização, ou externos, quando prestados para o ambiente externo da organização (clientes, fornecedores, governo, etc.).

Função de Negócio

Uma função de negócio é uma área em que a organização coloca esforços para atingir seus objetivos e metas. Uma função de negócio agrupa comportamento e recursos internos com base em algum critério significativo (por exemplo, localização geográfica, departamento, competências requeridas, recursos e conhecimento compartilhado, etc.). Uma função de negócio representa parte do valor adicionado por uma organização. Funções de negócio, geralmente, conectam O QUE a organização faz com QUEM o faz, sem indicar COMO são feitas.

Processo de Negócio

Um processo de negócio é uma unidade de comportamento interno, ou uma sequência (causal) de unidades de comportamento interno (atividades), com o objetivo de produzir um resultado determinado. Processos podem ser constituídos de sub-processos, e são iniciados por eventos de negócio ou outros processos de negócio. Informalmente, isto significa que um processo consiste de atividades e/ou subprocessos, realizados em uma determinada sequência. Cada atividade é parte de uma função de negócio, como exemplificado abaixo:

Fig.1 - Exemplo de função de negócio em relação a processos de negócio

Conclusão

Um processo nem sempre pertence a uma única função de negócio (como mostrado no exemplo acima); uma função de negócio quase sempre é constituída por várias atividades em múltiplos processos; um processo, quase sempre, é realizado por várias (partes de) funções de negócio.

Funções de negócio, assim como processos de negócio, descrevem o comportamento interno da organização que não é "visto" pelas partes interessadas externas à organização. Serviços de negócio descrevem o resultado e o valor que é percebido pelas partes interessadas externas, sem descrever os detalhes de como o serviço é realizado através de funções e processos de negócio.

Na figura abaixo, são mostrados os principais relacionamentos entre estes conceitos:

Fig.2 - Relacionamentos mais comuns entre os conceitos

Se você quer conhecer mais sobre a linguagem ArchiMate, e conversar sobre Arquitetura Corporativa, acesse regularmente este blog e o site da Centus Consultoria

Fonte: ArchiMate Made Pratical, Harmen van der Berg e outros, NAF Working Group "ArchiMate usage"

Um Novo Paradigma para Sistemas de Informação (Parte 1-Introdução)

Introdução

Há uma importante mudança de paradigma acontecendo no campo dos sistemas de informação (SI). Isto significa que uma nova geração de sistemas de informação está surgindo, assim como novas abordagens para o seu desenvolvimento. A boa notícia é que os analistas de negócios podem ser
mais importantes para este novo paradigma do que foram para os anteriores.

Uma mudança de paradigma é uma mudança sutil, mas importante, de uma maneira de pensar para outra. É uma revolução, uma transformação, uma espécie de metamorfose. Ela não simplesmente acontece; ao contrário, é conduzida por um forte impulso para a mudança. As duas principais áreas de mudança que impulsionam esta nova mudança na TI são o desejo, ou a necessidade, de:

(1) gerenciar os processos de negócio e as regras de negócio como recursos distintos, mas estreitamente relacionados e conectados, e

(2) decompor o código de programação ou software em módulos reutilizáveis, chamados de serviços, geridos por uma infraestrutura de Arquitetura Orientada a Serviços (SOA). A infraestrutura SOA gerencia e media os serviços usados em um processo de negócio.

Pesquisa e prática comprovam que uma mudança de paradigma bem sucedida não pode acontecer sem que aqueles que estão no meio dela sejam treinados e educados. A falta de treinamento e de educação está impedindo esta mudança de paradigma em curso. Há uma escassez nas empresas, hoje, de pessoas treinadas em processos de negócios, gerenciamento de regras, e SOA. Parte da razão para este déficit educacional é que os programas acadêmicos são lentos para responder às sérias mudanças que ocorrem na maioria das empresas, hoje.

Esta série de artigos tem como objetivo fornecer uma visão geral da nova geração de sistemas de informação, incluindo o que um analista de negócios precisa saber, e o que um currículo escolar ou de formação correspondente deve incluir. Voltaremos em breve...

Arquitetura Corporativa: Mais do que simples arquitetura de TI

Arquitetura Corporativa - um novo momento

Cada vez mais, as organizações precisam lidar com transformações de alto impacto e melhorias de negócios urgentes, em uma realidade negócio e de TI verdadeiramente complexos. É por isto que a BiZZdesign e a Centus acreditam que as organizações deveriam ter as capacidades de mudança para transformar ou melhorar seus negócios e realizar sua missão. Nós ajudamos nossos clientes a construir organizações fortes, pela transformação e melhoria dos negócios, fornecendo capacidades de mudança através de soluções integradas, formadas por ferramentas de desenho, treinamento, consultoria de negócios, e melhores práticas.

As empresas, em geral, compreendem a necessidade e a importância da arquitetura corporativa. Dez anos atrás, muito esforço foi necessário para convencer a alta direção que a arquitetura era indispensável para o gerenciamento da complexidade de qualquer grande empresa, e ela foi percebida como uma disciplina de TI. Hoje, a arquitetura corporativa prova seu valor no apoio à transformação de negócio de alto impacto, entregando os resultados desejados e fomentando a agilidade da empresa, tudo em um ambiente sob constante pressão do tempo.

A contribuição da arquitetura corporativa é, naturalmente, encontrada na sua relação com as outras disciplinas dentro da empresa, e não dentro de sua própria torre de marfim, ou apenas concentrada na TI. Nos concentramos em ajudar os arquitetos a entregar valor para os grupos de partes interessadas nestas outras disciplinas. Concentramos, portanto, os nossos esforços em cinco áreas principais:

• Realizar a estratégia da empresa. A arquitetura corporativa em geral e, especificamente, a arquitetura de negócios e o planejamento baseado em capacidade, são instrumentos importantes para traduzir a visão em ação. Além disso, eles fornecem feedback essencial sobre a viabilidade de uma visão estratégica, e também desempenham um papel na definição da estratégia através da modelagem de negócios e da análise de cenários estratégicos.

• Apoiar as decisões de investimento estratégico. Decisões bem fundamentadas sobre o portfólio de produtos e segmentos de mercado, que estendem o gerenciamento integrado do portfólio de TI, exigem a percepção de suas dependências e de seu valor. O gerenciamento de portfólios baseado em arquitetura fornece estas percepções, e oferece também o suporte perfeito para programas de otimização de custos. Fornecer para os líderes empresariais cenários de investimento, análises de impacto, roteiros e outros produtos de informação baseados em arquitetura é uma tarefa-chave para qualquer arquiteto corporativo.

• Fomentar a agilidade empresarial. Os processos de arquitetura precisam acompanhar a velocidade das mudanças dentro e fora da empresa; os resultados rápidos fornecidos por iniciativas Lean e Agile são um exemplo importante. Ao vincular sua prática de arquitetura corporativa com processos de entrega contínua, as organizações poderão aumentar consideravelmente sua capacidade de mudança. Os dias dos "planos quinquenais" estão definitivamente terminados.

• Aproveitar as oportunidades tecnológicas. A arquitetura corporativa é essencial para fazer pleno uso de desenvolvimentos como computação na nuvem, Big Data ou BYOD(Bring Your Own Device-Traga Seu Próprio Dispositivo), para realizar a "empresa digital". Uma visão clara sobre as oportunidades de negócio das novas tecnologias, e uma abordagem estruturada para a sua realização na empresa, são ingredientes essenciais de qualquer abordagem de arquitetura corporativa.

• Controlar o risco e garantir a conformidade. As percepções trazidas pela arquitetura corporativa são essenciais para conhecer e mitigar seus riscos. Além disto, reguladores e legisladores apresentam cada vez mais demandas explícitas sobre a arquitetura corporativa de, por exemplo, órgãos do governo e instituições financeiras.

Uma abordagem baseada em modelos para a descrição da arquitetura corporativa oferece uma base sólida para a análise e o desenho, e fornece a ligação necessária para os outros domínios. Ela suporta o gerenciamento de portfólios com as análises necessárias para determinar o valor esperado, o custo e o risco de várias iniciativas. Ela fornece os dados necessários para priorizar e planejar as mudanças no panorama do negócio e da TI. Ela proporciona às organizações a coordenação, ao nível de programa, entre as iniciativas que realizam estas melhorias de negócios, de uma forma coerente. Ela fornece as informações necessárias para avaliar e garantir a conformidade com regulamentos e regras, internos e externos. Finalmente, ela ajuda no acompanhamento da realização dos benefícios previstos em todo o panorama de negócio e de TI, do objetivo estratégico ao resultado operacional e, portanto, na correção do seu curso, se necessário.

Nas próximas postagem vamos mostrar tudo o que a nova Suíte de Ferramentas BiZZdesign Enterprise Architecture tem para oferecer, e como a convergência da arquitetura corporativa com outras disciplinas, como a gerência de projetos, pode revolucionar a forma como as organizações lidam com as mudanças.

Até breve...

TDM e DMN - Uma combinação destinada ao sucesso

A OMG aprovou, recentemente, a publicação do padrão DMN-Decision Model and Notation (Notação e Modelo de Decisão), que objetiva fornecer uma notação para decisões que seja compreendida por todas as audiências (negócios e técnica) e que permita o compartilhamento de modelos entre ferramentas de software. Para a comunidade de modelagem de decisões em geral, e para aqueles que adotaram a metodologia TDM em particular, isto é uma excelente notícia!

Por que o DMN é Importante?

O DMN reforça a necessidade de um modelo específico para a lógica de negócios - distinto de todos os outros tipos de modelo. O DMN, como uma especificação da indústria de software, reconhece a necessidade de uma nova classe de ferramentas correspondente. É digno de nota as empresas que integram o Comitê DMN: IBM, Oracle, TIBCO, KPI, Decision Management Solutions, Escape Velocity, Model Systems, e KU Leuven University.

Cinco Filosofias Comuns

A tabela abaixo apresenta os pontos comuns entre o TDM e o DMN

• Decisões e lógica pertencem ao pessoal de negócios
• A maneira de modelar decisões é a solução
• Decisões se conectam com modelos de processos de negócio
• A lógica das decisões deve ser facilmente automatizada
• Software de modelagem de decisão é a solução

Modelos de processo

Em 2009, o TDM introduziu o conceito de processos conscientes de decisões, definido como processos que distinguem atividades que realizam o trabalho daquelas que derivam conclusões a partir de modelos de lógica completos. O DMN também relaciona modelos de decisão com processos de negócio, como mostrado abaixo:

Figura 1: Relacionamento entre modelos BPMN e DMN

Cinco Diferenças

1 - Público-alvo

O TDM tem como alvo, desde sua proposição, o pessoal de negócios. Por isto, um de seus princípios é ser completamente isento e independente de dependências em relação à tecnologia usada para a implementação dos modelos.

O DMN é uma especificação direcionada para audiências técnicas e desenvolvedores de ferramentas, e possui cinco componentes principais: notação no nível da lógica e dos requisitos, linguagem de expressões (FEEL-Friend Enough Expression Language), metamodelo, e níveis de conformidade.

2 - Nível de Requisitos

O DMN prescreve uma notação para um Diagrama de Descrição de Requisitos (DRD-Decision Requirements Diagram). Os requisitos incluem as decisões e os elementos relacionados, várias formas de lógica detalhada, e as dependências entre elas. O DMN é uma notação híbrida. O TDM é um modelo de lógica pura, composto de 15 princípios que orientam as funcionalidades orientadas para modelo do TDM. A figura abaixo mostra um DRD típico:

Figura 2: Parte de um DRD DMN

Basicamente, uma caixa de decisão DMN se correlaciona com a Família de Regra de Decisão do TDM. Setas entre as decisões são dependências, similares às relações inferencias no TDM. Outros elementos do DRD incluem o Modelo de Conhecimento de Negócios (BKM-Business Knowledge Model), fonte de conhecimento de negócio, e dados de entrada.

Existem diversas maneiras de representar modelos TDM através da notação DMN. A figura abaixo contém um modelo TDM (à esquerda) e uma possível tradução utilizando a notação DMN (à direita):

Figura 3: Diagrama do Modelo de Decisão TDM e sua tradução no DRD DMN

3 - Nível da Lógica

Uma caixa de decisão DMN pode ter ter uma forma gráfica diferente para expressar seus detalhes - por exemplo, uma expressão de valor ou um BKM. Um BKM pode ser um conjunto de regras de negócio, diversas formas de tabelas de decisão DMN, ou modelos analíticos.

Uma Família de Regra TDM tem somente uma forma gráfica. Seus detalhes não são uma estrutura separada. No DMN, os detalhes da Família de Regra podem se tornar BKMs ou Decisões, com ou sem BKMs.

4 - Automatização

O nível 3 de conformidade do DMN inclui a linguagem FEEL, para automatização das decisões. O TDM não inclui uma linguagem de automatização. Atualmente, organizações que utilizam software TDM, como o SAPIENS Decision e o BiZZdesign Decision Modeler, exportam os modelos de decisão e os convertem para o código nos ambientes de execução desejados.

5 - Glossário de Negócios

O DMN não inclui um glossário de negócios. O modeladores TDM usam os termos do glossário de negócios para especificar as condições e conclusões que formam a lógica das decisões, e para funcionalidade adicional (isto é, validação automática, geração e execução de casos de teste).

Um Momento no Tempo

Estamos em um momento interessante para a modelagem de decisões:

• O TDM tem mais de seis anos de existência, tem uma grande base mundial de clientes[1], anos de utilização em produção, e funcionalidade sofisticada baseada em modelos[2]
• O DMN é um novo padrão em desenvolvimento, se conformando com aquilo que os praticantes do TDM já conhecem há anos, e proporcionando uma notação mais ampla para os requisitos das decisões.

Eles possuem similaridades e diferenças. Algumas diferenças são cosméticas, Algumas não são. Estas últimas são o objeto de discussões interessantes, e é onde os praticantes da modelagem de decisões têm muito a ganhar.

Para saber mais sobre o Modelo de Decisão, acesse o site da Centus, ou baixe uma cartilha contendo os conceitos básicos da modelagem de decisões.

Notas:
[1] Até onde sabemos, o TDM é o único modelo de descrição de lógica de negócios largamente automatizado em ambiente de produção, em diversas plataformas e BRMS de mercado, em clientes dos mais variados portes e segmentos de negócio

[2] com a utilização de software de apoio adequado

Que Decisões Pertencem aos Modelos de Decisão?

Em 2009, The Decision Model (O Modelo de Decisão) foi revelado ao público. Em 2011, um novo tipo de software emergiu para suportá-lo. Recentemente, o guia BABOK v3 (Business Analysis Body of Knowledge, publicado pelo IIBA) trouxe a modelagem de decisões como uma técnica aprovada para substituir os modelos de processo na descrição da lógica de negócios. Em 2014, o Object Management Group (OMG) votou pela publicação do Decision Model and Notation (DMN-Notação e Modelo de Decisão) como um novo padrão para o desenvolvimento de software.

Então, o Que Há de Novo?

Decisões não são uma novidade, mas uma mudança está acontecendo. Modelos de decisão estão agora sancionados, e milhares estão funcionando em ambiente de produção em grandes corporações. A questão agora é: que tipo de decisões pertencem aos modelos de decisão? A tabela abaixo mostra os critérios mais comuns usados pelas organizações para responder a esta questão:

Sete Critérios para Modelos de Decisão

Governança do Negócio	Dar ao pessoal de negócios controle sobre a lógica para as decisões importantes para o negócio, desde o início até a implementação
Governança Externa	Gerenciar decisões cujos agentes de mudança de direito são externos à organização
Governança Personalizada	Gerenciar decisões que têm conjuntos diferentes de lógica baseados em contextos de negócio, como diferentes localizações geográficas,jurisdições legais e tributárias, ou categorias de clientes
Flexibilidade Tecnológica	Selecionar e mudar a tecnologia para a automatização de decisões, sem mudar a lógica do modelo de decisão
Retorno sobre o Investimento (ROI)	Prever e medir como uma decisão contribui para a saúde e bem-estar dos negócios
Agilidade e Velocidade de Mudança	Permitir mudanças na lógica de decisão efetivas, rápidas e frequentes
Complexidade da Lógica de Decisão	Simplificar a representação da lógica de negócio, mesmo em modelos de grandes dimensões, ou com lógica intricada

Uma forma de entender como o TDM suporta estes critérios é listar suas características e correlacioná-las com os benefícios que suportam os critérios acima:

As Quatro Características Principais do TDM

Estrutura do Modelo de Decisão	Formato único (embora não vinculado a uma notação específica) Bem delimitado (ponto de partida e de término pré-definidos pela estrutura, desde a decisão de negócio até os dados brutos) Formato simples e amigável para o pessoal de negócios (não afetado por considerações tecnológicas) Normalizado até as menores partes gerenciáveis e reutilizáveis Estruturas conectadas por dependências puramente lógicas Visões de modelos de decisão inteiros para suportar lógica personalizada Serve como um ponto único de mudança, sem a necessidade de mudanças no código dos programas
15 Princípios do TDM	Princípios Estruturais, Princípios (declarativos) Independentes de Tecnologia, Princípios de Integridade A combinação da estrutura com os princípios torna fácil e rápido criar e automatizar a lógica as decisões do que com outras abordagens de regras de negócio
Independência de Tecnologia	Glossário de termos de negócio, definições de negócio, tipos de fatos e valores de domínio Glossário de negócio independente da tecnologia de dados física Estrutura e conteúdo do modelo de decisão independente da tecnologia de execução
Fundação para Software Inovativo	Validação automática dos modelos de decisão em relação aos 15 Princípios, antes da implementação em tecnologia Geração automática de casos de teste e execução de modelos de decisão inteiros antes da implementação Gerenciamento do Ciclo de Vida das Decisões, desde o negócio até a TI Controle de versão das entradas do glossário e das partes do modelo de decisão Mensagens

Já Estivemos Aqui Antes?

Há muito tempo, um novo modelo para os dados, chamado modelo relacional, foi publicado e suportado por um novo tipo de software. Dados não era algo novo. Mas uma mudança se apresentava à frente, enquanto perguntávamos: que tipo de dados pertencia ao modelo relacional? Hoje, nós sabemos que a resposta é: todos os tipos, ou quase todos (especialmente, dados estruturados). As empresas priorizaram e migraram a maioria dos dados operacionais para o formato relacional, que entregou, então, todas as suas promessas.

Então, hoje, que decisões pertencem aos modelos de decisão? A resposta que se apresenta é: todas elas, ou quase todas elas (especialmente, decisões baseadas em condições que levam a conclusões). Assim sendo, é tempo de desenvolver os critérios que são importantes para a sua empresa, priorizar e começar a desenvolver os modelos de decisão que são importantes, com a certeza e a confiança que o modelo de decisão vai entregar as suas promessas.

Para conhecer mais sobre o Modelo de Decisão, acesse o site da Centus, ou solicite um contato.

Fontes: WHICH DECISIONS BELONG IN DECISION MODELS?  Barbara von Halle - SAPIENS Decision blog