Este framework tem sido desenvolvido pelo International Standard Organization (ISO) no Comitê Técnico  TC 184, Subcomitê 5 e grupo de trabalho 1 (ISO TC184/SC5/WG1). Este comitê existe desde 1986 com o intuito de estudar padronizações na área de automação industrial e integração.  O framework, denominado ISO Reference Model consiste de três submodelos (VERNADAT, 1996):

• Um modelo de contexto que identifica as macro-funções da empresa (produção, finanças, marketing, etc..) e define o relacionamento entre elas. Este modelo é baseado no modelo de plantas de manufatura desenvolvido pelo então National Bureau Standard dos Estados Unidos, hoje denominado NIST (National Institute of Standards and Technology);
• 
  Um modelo do chão de fábrica (Shop Flor Production Model – SFPM), o qual representa numa O modelo de atividade genérica (GAM – Generic Activity Model) que descreve as atividades e fluxos (de materiais, informação e recursos) entre as atividades.
• Em 1990 este comitê iniciou o trabalho para desenvolver o “Framework for Enterprising Modelling”, iniciando com abertura de propostas. Os temas a serem desenvolvidos para a construção deste novo framework, segundo VERNADAT(1996), são: uma terminologia, escopo da modelagem de empresa, o processo de modelagem de empresas e aplicações para CIM (Computer Integrated Manufacturing).

Este framework foi desenvolvido pelo Comitê Europeu de Padronização (European Committee for Standardization)  dentro do grupo de trabalho em Arquitetura de Sistemas CIM, o qual faz parte do Comitê Técnico TC 310 e Grupo de Trabalho 1.  Sua proposta visa padronizar as atividades na área de modelagem de empresas dando suporte a Manufatura Integrada por Computador.

Este framework, que teve muita influência do CIMOSA que será descrito posteriormente, define três dimensões e procura padronizar os modelos existentes dentro delas. As dimensões são:

1. Dimensão da generalização: define o nível de abstração, representando a generalização das entidades descritas neste nível (CEN, 1990 apud VERNADAT, 1996). Esta dimensão é composta por três níveis. O nível Genérico, contendo os elementos básicos tais como componentes, restrições, regras, termos, serviços, funções, entre outros. O nível Parcial o qual contém os elementos de transição entre o nível anterior e o posterior, e o nível Particular, que especifica os elementos genéricos para a empresa específica que está sendo modelada.

2. Dimensão dos Modelos: especifica o nível de abstração dos modelos. É dividido em três níveis. O primeiro é o nível de requisitos onde são definidas as operações da empresa e as terminologias, informações e recursos sem qualquer referência às opções de implementação ou decisões tomadas. O segundo é o nível de projeto onde se define como são realizadas as operações das empresas, as entidades de informações, recursos e estrutura organizacional para atingir os requisitos especificados no nível anterior. Por fim o nível das especificações que descreve as formas e ou as regras para serem utilizadas na execução das operações definidas no nível anterior;

3. Dimensão das Visões:  definem o ponto de vista que o modelo descreve a organização. A primeira é a visão das funções, que permite a descrição hierárquica de todas as funções da empresa. O segundo é a visão da informação, que permite uma descrição estruturada dos objetos de informação e dados da empresa. Em seguida a visão dos recursos que descreve o conjunto de recursos necessários para a execução das operações da empresa.Por fim, a visão da organização que descreve a estrutura organizacional.

CIMOSA

O CIMOSA, European Open System Architeture for CIM, foi desenvolvido de 1986 até 1994 pelo Consórcio AMICE (Arquitetura Européia para CIM) dentro do projeto ESPRIT (EP688, 5288 e 7110) desenvolvido por um grupo de fornecedores de sistemas CIM, grandes usuários e acadêmicos (VERNADAT, 1996; KOSANKE, 1995; ZELM, VERNADAT & KOPSANKE, 1995). É um framework completo compreendendo tanto a modelagem propriamente dita como a metodologia de implantação CIM. É composto de uma definição geral do escopo e implantação de CIM, guias para a implantação; e um framework que define termos e padrões para modelagem e implantação.

 O framework de modelagem  consiste de um conjunto de níveis e abstrações parecido com o do ENV descrito anteriormente, a diferença é que ele separa claramente o que ele denomina de arquitetura de referência de uma arquitetura particular. A primeira refere-se a uma descrição genérica que procura envolver as melhores práticas e serve a um conjunto geral de empresas e corresponde aos dois primeiros níveis de instanciação. A arquitetura particular, por sua vez descreve uma empresa específica. A passagem pelos níveis é realizada por processos que esta arquitetura define como : derivação, que os modelos descrevem as necessidades dos usuários num momento e vão se especializando até especificar os detalhes da implementação do funcionamento para a empresa específica; instanciação, em que os diverentes tipos de visões da organização são implementadas tal que um nível menor representa uma das possíveis “instanciações” ou ocorrências do nível maior; e visões  que define as visões da empresa com que o modelo é baseado, as quais ele define como: visão das funções, visão da informação, visão dos recursos e visão da organização.
  IDEFX/SADT  

O framework de modelagem IDEFX, ou seja a família de modelos IDEF, é a ferramenta de modelagem de empresas mais utilizada na prática graças a sua enorme simplicidade, chegando mesmo a tornar-se um padrão de fato para este fim(CANTAMESSA & PAOLUCCI, 1998). Já o SADT (Structured analysis and design technic) não chega a ser uma arquitetura, e poderia ser melhor caracterizado como um formalismo de modelagem. Ambos são apresentados juntos pois tem origens e uma vida tão próximas que seus nomes são até mesmo são fundidos na prática.

O SADT “nasceu pelas mãos” de Douglas T. Ross num projeto de desenvolvimento de uma linguagem estruturada para programação de máquinas-ferramenta, no MIT, no fim da década de 60 (MARCA & MACGOWAN, 1988). Este formalismo trazia algumas características revolucionárias que auxiliaram sobremaneira a descrição e desenvolvimento dos sistemas de software complexos que começavam a aparecer. São elas a decomposição funcional e o fato de serem baseados numa representação esquemática simples (VERNADAT, 1996). Estas características disseminaram a aplicação deste formalismo e também o seu desenvolvimento em direção a abordagens estruturadas completas destinadas a diferentes aplicações, principalmente para a análise de sistemas.

Já o IDEF foi desenvolvido durante o projeto ICAM (Integrated Computer Aided Manufacturing) realizado pela Força Aérea Americana na década de 1980. Esta arquitetura foi elaborada compondo três diferentes modelos. O primeiro, denominado IDEF0, compõe-se da modelagem funcional do sistema e foi baseado (e portanto é idêntico) ao formalismo utilizado pelo SADT. O segundo modelo é denominado IDEF1x para modelagem de informações e é baseado numa versão inicial do modelo entidade-relacionamento. O modelo que completa esta arquitetura é denominado IDEF2 e modela a dinâmica do sistema.

O SADT e IDEF0 é baseado num diagrama conhecido como “ativigrama”. Este diagrama é composto por “caixas” que representam as atividades. Estas caixas são ligadas por linhas e dispostas tal a formar uma ordem de condução das atividades seguindo da esquerda para a direita. As linhas que chegam e saem na lateral das caixas representam inputs e outputs de informação. As que chegam no topo são controles e embaixo mecanismos. Com mais algumas poucas regras além das aqui apresentadas tem-se todo o formalismo necessário para descrever estes modelos.

Por sua simplicidade e facilidade de uso (existência de ferramentas computacionais para auxílio da modelagem) o SADT/IDEFX é uma das principais ferramenta de modelagem de empresa(VERNADAT, 1996; CANTAMESSA & PAOLUCCI, 1998). Uma ferramenta que traz consigo grandes desvantagens. Segundo VERNADAT(1996) possuem semântica imprecisa, não provê com clareza o comportamento dinâmico do sistema, não manipula fluxos mas dependências entre as atividades, a modelagem de informações é limitada e baixa consistência devida a não integração entre os diferentes modelos.    Já CANTAMESSA & PAOLUCCI (1998) aludem principalmente à necessidade de grande cuidado no desenvolvimento do modelo, alta possibilidade de desvios causados e tempo grande para a modelagem devido a necessidade excessiva de revisões para garantir a consistência do modelo.

Assim, VERNADAT(1996) sugere que esta arquitetura seria mais apropriada para modelos pequenos e restritos às visões de maior nível de abstração, portanto, com menor complexidade. Já CANTAMESSA & PAOLUCCI (1998) apresentam propostas de diversos autores para a alteração nesta arquitetura afim de saltar estes obstáculos e propõem um novo caminho complementando o formalismo IDEF0/SADT com com outros modelos.

ARIS (ARchiteture for Integrated Systems)

ARIS é a sigla para ARchitecture of Integrated Information Systems e foi desenvolvida pelo Prof. Scheer na Alemanha entre 1992 até 1994, sendo um framework de modelagem que enfatizando os aspectos de engenharia de software e organizacionais da empresa (VERNADAT, 1996; ARIS, 1995).
No ARIS são definidos quatro visões e três níveis de modelagem.
 
As visões são do ARIS são:

1. Visão Funcional:  a qual permite construir modelos que definem de maneira hierárquica todas as funções da empresa começando das mais macro e decompondo-as até o nível de detalhe que permite especificar funções de programação específicas dentro de aplicativos de software;

2. Visão dos Dados: é utilizada para definir os modelos de dados partindo das definições das informações mais complexas (relatórios ou conjunto de informações) passando pelo modelo de dados e seus relacionamentos, a definição de esquemas e definindo a própria base de dados;

3. Visão Organizacional: permite especificar e detalhar a estrutura organizacional da empresa desde a definição das divisões e unidades de negócios, a estrutura de cargos e seus ocupantes, até a estrutura física com os equipamentos, com ênfase especial à estrutura de informática na medida que há métodos específicos para a modelagem da rede de computadores da empresa;

4. Visão de Controle:  é a visão que permite relacionar as três visões anteriores. Nesta visão há métodos de modelagem específicos para definir a relação entre funções e dados; funções e organização; organização e dados e, principalmente, capazes de integrar as três funções utilizando-se principalmente do conceito de evento.

Em cada uma das visões há três níveis, que lembram os níveis do CIMOSA, que são: o da Definição dos requisitos onde são realizadas as definições mais gerais dos termos do sistema; o nível de Projeto onde se define uma das formas de encontrar os requisitos e nível de Implementação onde se define detalhadamente como o determinado elemento ocorre dentro da organização.

Os principais métodos da arquitetura ARIS são apresentados na figura 6 de forma a tornar mais claro o conteúdo de cada visão e nível. No nível da especificação dos requisitos e visão da organização temos um método que descreve as divisões do negócio da empresa (unidades, mini-fábricas, setores, etc..) e outro que descreve a hierarquia organizacional com cargos, responsabilidades e nomes de pessoas. Ainda na visão organização, porém no nível de projeto, temos um método onde se pode especificar a topologia da rede e no nível de implementação a possibilidade de descrever a rede modelando cada dispositivo de cada ponto a partir de diversas características e também um método para descrever os materiais do chão de fábrica como máquinas e equipamentos de movimentação.

Na visão de funções o método Árvore de Funções (Function Tree) permite descrever a hierarquia de funções da empresa até um nível de atividade, por exemplo, projetar, movimentar, etc.. .e o Objective Diagram que permite modelar os objetivos da empresa em termos gerais.

Os demais diagramas são específicos para algumas aplicações, o primeiro para o software de integração R/3 da SAP e o outro que descreve as tarefas ou funções da empresa conforme o modelo de integração de empresa Y-CIM proposto por Scheer, de uma forma altamente agregada e concisa. No nível de projeto desta visão pode-se especificar, no Application System Type Diagram cada tipo de aplicação, por exemplo CAD, planilha, processador de texto, entre outros. E , no nível de implementação pode-se especificar no Application System Diagram cada licença de cada aplicação da empresa, além de existirem outros diagramas onde é possível especificar funções de aplicações desenvolvidas in house pela empresa.

Na visão de dados existe uma grande quantidade de diagramas e notações possíveis, sendo o principal o MER clássico e o MER extendido que contém todas as suas variações, incluindo uma notação especial denominada Cluster  que permite especificar um conjunto complexo de dados que, por exemplo, pode representar um MER inteiro. No nível de projeto o Relation Diagram permite especificar o modelo relacional, sobre as quais a base de dados será construída e o Modelling of Systens Inteface, que permite compor hierarquicamente entidades, eventos, termos técnicos, hieraraquicamente conforme o seu processamento no sistema.

No nível mais baixo, o de implementação, é possível especificar as tabelas. Na visão de controle existem uma quantidade muito grande de modelos específicos para relacionar diferentes visões. O diagrama mais importante é o EPC (Event Drive Process Chain) o qual introduz o conceito de evento como uma alteração significativa do status de um objeto. Com este conceito e método pode-se especificar o fluxo de todas as funções intercaladas por eventos que resultam de sua ação e que as disparam.

Este diagrama é a espinha dorsal a partir da qual é possível relacionar todos os elementos, sua ocorrência (especificadas pelos eventos) e permite agregar quem é o responsável por fazê-la (visão organizacional) e as informações e dados necessários (visão dos dados). O eEPC é o EPC extendido com mais notações específicas e o Information Flow Diagram permite especificar o fluxo de dados. O Access Diagram mostra o fluxo de dados entre aplicações no nível de projeto mostrando como os diferentes tipos de aplicações se comunicam. O Modelling System Interfaces mostra o relacionamento entre as Aplicações de Software, os Módulos de Software (partes de programas) e as Funções de Software, ou seja, integra os níveis de projeto e implementação da visão função.

No nível de implantação o Access Diagram pode ser utilizado para especificar a ligação entre dados, funções e organização no nível de implementação (ligando, respectivamente campos de tabelas com funções de programas e a alocação, ou sua localização física). Deve-se notar que estes são os métodos mais importantes, havendo a existência de muitos outros.
 
A partir desta figura 6 é possível também perceber porque diz-se que este framework coloca uma ênfase na dimensão de software. Note que um modelo de empresa desenvolvido dentro deste framework e utilizando estes métodos poderia especificar, no nível de implementação, a própria estrutura de hardware e software da empresa. Na visão organização estaria especificado o hardware com a definição da rede e de cada dispositivo (computador, impressora, etc..) existente. Na visão de dados a base de dados e na visão de funções cada licença de software comprado e as funções das aplicações especificamente desenvolvidas na empresa. E, na visão de controle a especificação da alocação (onde roda cada software e função, relação função-organização) e de controle do programa o fluxo de informações entre as funções (relação dado - função). Em todas as visões e níveis a maioria dos métodos apresentam

Para o auxílio na manipulação de todos estes métodos e visões foi desenvolvida uma ferramenta computacional pela empresa IDS, denominada ARIS Toolset, que tem interface gráfica for windows e disponibiliza uma grande quantidade de métodos para cada visão e nível do framework ARIS. Ela permite o desenvolvimento e gerenciamento de todos os modelos de maneira integrada numa meta-base de dados. Desta forma uma entidade tem uma existência única mesmo que com ocorrência em vários modelos ao mesmo tempo. Isto facilita o gerenciamento e aumenta a consistência tal que a edição da entidade em um modelo específico se reflete em todos os demais.
  ]