Arquitecturas de Sistemas de Informação. Pedro Sousa

Transcrição

1 Arquitecturas de Sistemas de Informação

2 O caminho mais curto para a ASI Aplicações Existentes sumo do Processo de Definição da quitectura de Sistemas de Informação Arquitectura de Negócio Informação e Repositórios O quê? Como? Porquê? Arquitectura de Informação Arquitectura de Aplicações Arquitectura Tecnológica Caderno Encargos Desenho das Arquitecturas

3 Arquitectura de Processos Identificação dos processos com base em critérios de valor e de Qualidade Agregação das actividades (manuais ou automáticas) em processos Representação dos processos que discrimine as actividades, a informação necessária, entre outros (quem, quando, porquê). A Arquitectura de processos não deve ser dependente da estrutura orgânica, dos pacotes aplicacionais, dos intervenientes, etc. Reparações Serviço Central Exemplo da notação proposta (BPMN) Associa OpLog ao Artigo e Loja Operador Logístico Eventos Origem Transporte Artigo com Agendamento Automático? Identificação Artigo, Origem, Destino e Op Log Não Solicitar Operador Logístico para o transporte Actividades Sim Informar intervenientes no transporte e recepção Preparar Artigo para Levantamento Guia de transporte Informação usada Informação produzida Destino Transporte Ordem de Reparação Recepção do artigo Pontos de decisão Registo Recepção Artigo Intervenientes Operador Logístico Log Levantamento Fluxos entre actividades Regista o Levantamento do Artigo na Origem Confirma a entrega no Destino Fecho Recepção Artigo Log entrega (*) A notação BPMN é um resultado da Business Process Management Initiative BPMI.org Agendar Transporte

4 Reparações Serviço Central Origem Transporte Artigo com Agendamento Automático? Identificação Artigo, Origem, Destino e Op Log Não Sim Destino Transporte Operador Logístico transporte e recepção Agendar Transporte Log Levantamento Associa OpLog ao Artigo e Loja Solicitar Operador Logístico para o transporte Preparar Artigo para Levantamento Artigo na Origem Operador Logístico Guia de transporte Recepção do artigo Confirma a entrega no Destino Log entrega Artigo Fecho Recepção Artigo Arquitectura de Informação Define e estrutura a informação necessária à execução das entidades numa Arquitectura de Entidades Informacionais. Arquitectura de Informação Arquitectura de Processos de Negócio Arquitectura Tecnoló gica Arquitect de Aplica Reparações Serviço Central Associa OpLog ao Artigo e Loja Operador Logístico Origem Transporte Artigo com Agendamento Automático? Identificação Artigo, Origem, Destino e Op Log Não Solicitar Operador Logístico para o transporte Sim Guia de transporte Informar intervenientes no Destino Transporte Operador Logístico Regista o Levantamento do Informar intervenientes no transporte e recepção Ordem de Reparação Agendar Transporte Log Levantamento Preparar Artigo para Levantamento Regista o Levantamento do Artigo na Origem Registo Recepção Ordem de Reparação Recepção do artigo Confirma a entrega no Destino Logentrega Registo Recepção Artigo Fecho Recepção Artigo Entidade Informacional Cliente Entidade Informacional Serviço Caracterizada de forma a satisfazer as diferentes necessidades dos vários processos, quer ao nível da execução, da decisão e da gestão. Listagem da Informação necessária à execução de cada actividade Análise, Estruturação e Sistematização da Informação Arquitectura de Informação

5 Arquitectura de Aplicações Indetifica as Aplicações de faz sentido ter Nasce da relação entre os Processos e as Entidades Informacionais Ainda não se fala de tecnologia nem pacotes!!! Entidades de Negócio Aplicação Processos de Negócio Entidades Informacionais missão Informação Funcionalidades Necessidades de Integração e Interoperabilidade

6 Arquitectura de Aplicações Tópicos a abordar Nível de detalhe na descrição das aplicações Critérios para a agregação das Entidades. Critérios para a agregação de Funções Que características da informação tem que ser levadas em consideração? Que características dos Processos tem que ser levadas em consideração? Qual é a arquitectura de SI geral de uma Organização? Qual o impacto de uma solução global de um ERP / CRM 6

7 Arquitectura de Aplicações (Matriz de CRUD) 7

8 Arquitectura de Aplicações Descrição das Aplicações

9 Arquitectura de Aplicações Baptismo de Aplicações Sistema de Processamento de Encomendas Sistema de Publicidade e Promoção Sistema de Controlo de Produção Sistema de Benefícios de Empregados Sistema de Recebimentos Sistema de Treino e Desenvolvimento Sistema de Informação de Clientes Sistema de Administração de Equipamentos Sistema de Gestão de Veículos Sistema de Informação de Recursos Humanos Sistema de Gestão de Contas Sistema de Inventário de Materiais O nome deve cobrir o propósito da aplicação Evitar nomes iguais ao das aplicações existentes As aplicações podem focar-se numa certa entidade As aplicações podem focar-se numa certa função 9

10 Arquitectura de Aplicações Definição de Aplicações BUSINESS ANALYSIS SYSTEM (28) PURPOSE: SAMPLE APPLICATION Decision making and impact assessment for analyzing business opportunites. DESCRIPTION/CAPACITIES: 1. Access external and internal financial market, technical, and business information for analysis to assist the correct business decision. 2. It will also identify required business resources, functions, and government regulations. 3. The application will be able to perform what if analysis. BENEFITS: 1. Ability to perform what if analysis rapidly using various scenarios. 2. Provides electronic access to key business information. DETAILED BUSINESS FUNCTIONS SUPPORTED: 1. ANALYSE & IMPROVE EXISTING FUNCTION (224) 2. ANALYSE & IMPROVE EXISTING PRODUCTS & PROCESSES (221) 3. COORPORATE PRODUCT RATIONALIZATION (222) 4. DEFINE & DEVELOP NEW PRODUCT PROCESSES (226) 5. DETERMINE RESOURCE REQUIREMENTS (115) 6. ESTABLISH BUSINESS GOAL (13) CURRENT IRC APPLICATION AFFECTED: impact HEAD COUNT BY DEPARTMENT (282) R MANPOWER PLANNING ( P MATERIALS POPULATION (245) R ZERO-BASED RESOURCE BUDGET (252) C DATA ENTITY RELATIONSHIPS Data usage BUSINESS PROCESSR (19) DOCUMENT (32) EQUIPEMENT TYPE (28) FACILITY (38) GOODS AND SERVICES TYPE (27) INCIDENT (34) LOCATIONS (14) ORGANIZATION UNIT (2) PERFORMANCE MEASURES AND STANDARDS (224) PLAN (13) POSITION (18) PRODUCT TYPE (9) SKILL (4) SUPPLIER (25) R 10 R R R R R R R R R C R R R

11 Arquitectura de Aplicações Descrição de Aplicações APPLICATION ARCHITECTURE APPLICATION NAME: Production Control System APPLICATION NUMBER: 138 PURPOSE: To monitor and access real-time production information an performance indicators related to the manufacturing proce Management will use this information to oversee productio DESCRIPTION: 1. Report actual measurements as well as target in both graphical and text displays covering specific periods 2. Quality reports will include shipped product quality, internal an external quality measurements by work group, test results for a given period, incidents occurrences, quality history by product line, product item, and production process [Additional objectives will be listed] BENEFITS: 1. Enable organization units to track and easily report quality, service, and cost metrics 2. Efficient, timely management of manufacturing by access to rea time data [Additional benefits will be listed] 11

12 Arquitectura de Aplicações Critérios para a agregação de Processos e de Entidades

13 Análise de Afinidade de Entidades AFINIDADE de E1 para E2 = a(e1, E2) / a(e1) a(e1) = Nº de funções que usam a entidade E1 a(e1, E2) = Nº de funções que usam E1 e E2 Afinidade Pesada de E3 para o Cluster E1, E2 = ( a(e3, E1)*a(E1) + a(e3, E2)*a(E2) ) / ( a(e1) + a(e2) )

14 Que critérios devemos usar para agregar Processos e Entidades? Critérios de Agregação das Entidades Por afinidade entre Entidades Por afinidade de utilização com os processos (CRUD) Por criação em processos comuns Critérios de Agregação de Processos Por afinidade de utilização das entidades (CRUD) Por criação de dados comuns Processamento de Transações de negócio Comuns

15 ASI - Alinhamento

16 Dimensões do Alinhamento O alinhamento entre estas 4 Arquitecturas fundamenta-se em 5 dimensões, podendo cada uma delas estar alinhada/desalinhada independentemente das restantes Arquitectura de Negócio Alinhamento Arquitectura de Informação Arquitectura de Aplicações Arquitectura Tecnológica

17 Alinhamento entre o Negócio e a Informação de Negócio Foco na estruração da informação necessária à condução do negócio, tanto nas operações como na informação de gestão. Entidades de Negócio Um exemplo simples é a decisão de aprovação de uma ordem de encomenda num processo de procurement. Qual é a informação que o decisor vai usar para aprovar ou não a ordem de encomenda? Processos de Negócio O alinhamento entre os Processos de Negócio e a Informação de Negócio não implica necessariamente que haja um sistema que forneça a informação necessária com um simples click. Implica antes de mais a explicitação desta informação nas Entidades. Os sistemas de Suporte à Decisão e os Data Warehouses são projectos que obrigam as organizações a pensar e explicitar a informação necessária ao negócio, nomeadamente ao suporte às decisões de negócio. Ao nível do acesso à informação, existem várias famílias de sistemas focados na disponibilização da informação, que vão deste os Sistemas de Suporte à Decisão, até aos sistemas de Gestão Documental e os sistemas de Reporting.

18 Alinhamento entre o Negócio e as Aplicações Foco na automação das actividades dos Processos de Negócio. Quanto maior for o alinhamento menor é o esforço despendido em operações mecanizáveis. Entidades de Negócio Visa optimizar a relação (custo operação)/(investimento) para um determinado nível de serviço requerido. O alinhamento não é sinónimo da automação extensiva e obrigatória dos processos de negócio, devendo ser justificado pelo retorno (valor) para a organização. Os sistemas de workflow são exemplos de sistemas que promovem fundamentalmente este tipo de alinhamento. Estes motores de workflow podem ser aplicações autónomas ou integradas numa suites aplicacionas, como por exemplo um ERP ou uma suite de CRM. Conduto, não é assegurado a minimização da redudância da informação, nem a disponibilização da informação. Processos de Negócio

19 Alinhamento entre Informação e Aplicações Fundamenta-se na eficácia dos Sistemas de Informação na gestão Informação de Negócio. Entidades de Negócio A existência de várias réplicas da mesma informação em diversos sistemas é uma situação bem conhecida por todos. O problema é que cada réplica tem estrutura, sintaxe e semântica diferente em diferente sistemas, tornando muito difícil a sua integração ou compatibilização. As soluções de ERPs ou outras suites integradas são exemplos que asseguram este alinhamento. De facto, quem implementa um ERP a todo o negócio, deixa de ter problemas induzidos por incoerência de informação. O ERP pode não suportar os processos pretendidos, pode não disponibilizar a informação necessária ao negócio, mas garante que a informação que gere está sempre coerente. Processos de Negócio

20 Heurísticas de Alinhamento As heurísticas servem de guião para aferir o estado de alinhamento, pois evitam cair-se em cenários de implementação mais difícil. Se todas as heurísticas fossem cumpridas, o custo de implementação, operação e manutenção da IT era mínima. Têm o grande mérito de obrigar a pensar/justificar melhor as decisões que as contrariam. Em muitos casos, as heurísticas detectam situações de erro/omissão. Têm de ser ajustadas ao modelos e níveis de representação existentes em cada organização.

21 Alinhamento entre o Negócio e a Informação de Negócio Exemplos de heurístias genéricas: As Entidades contêm toda informação necessária ás actividades dos Processos (automática ou manuais). Entidades de Negócio Todos os Processos que partilham entidades de Negócio, concordam com os conceitos que lhe estão subjacentes. Processos de Negócio Todos os processos criam, actualizam/apagam entidades de informacionais. Os processos que criam entidades gerem todo o ciclo de vida das mesmas. Cada entidade é lida por pelo menos um processo. Para manter este alinhamento, tem de haver um responsável por assegurar a sua qualidade, disponibilidade, regras de disseminação, e segurança de cada entidade

22 Alinhamento entre o Negócio e as Aplicações Exemplos de heurístias genéricas: Todos os processos/actividades são suportados preferencialmente por uma única aplicação. Cada transacção de negócio não deve envolver mais do que uma aplicação. Todas as funcionalidades das aplicações suportam em exclusivo alguma actividade. As características das actividades devem corresponder às características das aplicações (escalabilidade/disponibilidade/..) Processos de Negócio Entidades de Negócio Por omissão, os processos diferentes devem ser suportados por aplicações computacionalmente independentes.

23 Alinhamento entre Informação e Aplicações Exemplos de heurístias genéricas Cada entidade é gerida por uma única aplicação. Gerir significa criar e identificar. Cada atributo de uma entidade não deve ser actualizado por mais do que uma aplicação. (diferentes atributos da mesma entidades podem ser actualizados por diferentes aplicações) Uma transação aplicacional não devem actualizar atributos de entidades diferentes. Processos de Negócio Entidades de Negócio As aplicações devem sempre aceder à informação directamente nas aplicações que as gerem, mas de forma a presenvarem a independência computacional. O acesso à informação não deve implicar uma dependência computacional entre as aplicações As características da informação deve estar em conformidade com as características da aplicação que a gerem. Cada aplicação deve disponibilizar interfaces para a disseminação/validação das Entidades que gerem

24 Arquitectura Ideal vs a melhor Arquitectura A Arquitectura Aplicacional ideial é apenas um objectivo a longo prazo. Mas o ponto de partida é á realidade existente na organização, quer em aplicações, quer em tecnologias quer em competências Cada Aplicação deverá ser equacionada no contexto das aplicações que: existem na organização existem no mercado são desenvolvidas à medida Cada aplicação deverá estar analisada quanto ao seu custo /benefício (de fazer ou não cada aplicação). Esta é uma decisão de planeamento Estratégico de Sistemas de Informação Mas a Matriz de CRUD e as Heurísticas são os instrumentos para aferirem o impacto das potenciais decisões (cenários aplicacionais).

25 Sistemas típicos das Organizações Clientes Portais A Organização ERPs Sistemas de Suporte à Decis Soluções CRM Extranets Data Stages Data Mar Data Warehouse Fornecedores Soluções B2B

26 Aplicacões Comerciais ERP s Arquitectura Componentes Data Warehouses Data Marts OLAP B2C Portais Empresariais Portais Intranets Portais Extranets B2B eprocurement SellSide Marketplaces Suply Chain Management Collaborative Planning Forecasting Replenishment (CPFR) Supply Chain Management (SCM) Catálogos Leilões B2E Gestão Documental Gestão do Conhecimento Sistemas de Arquivo CRM Força de Vendas Services ecare Marketing Automation GroupWare Worlflow Collaborative Systems

27 FIM

28 Padrões Arquitecturais App - 4 R 4 App - 1 App - 2 Repositório Integrado Common Data Interface App - 5 App - 6 R 5 R 6 App - 3 Suites Integradas (ERP, CRM, etc) Alta afinidade entre as entidades: a maioria das entidades criadas por uma aplicação são usadas pelas outras aplicações Data Warehouse EIS, DSS, etc App - 7 App - 8 App - 9 Forte indices de leitura de outras entidades e as eventuais entidades criadas não são lidas por nenhuma outra Pedro aplicação Sousa Outros SistemasOperacionais Baixa afinidade entre as entidades: a maioria das entidades criadas por uma aplicação não são usadas pelas outras aplicações

29 Padrões Arquitecturais App - 1 App - 2 App - 3 Repositório Integrado (ex ERP) Common Data Interface App - 4 App - 5 App - 6 R 4 R 5 R 6 App - 10 App - 11 App - 12 Repositório Integrado (ex CRM) Data Warehouse App - 7 App - 8 Outros SistemasOperacionais App - 9 Podem existir várias Suites Integradas (ERP, CRM, etc) EIS, DSS, etc

30 Padrões de Arquitectura

31 Aspectos Arquitecturais da Integração Information Bus As Aplicações acedem on-line aos dados das outras Os processos são ligados por MSQ Aspectos importantes Acesso à on-line

32 Aspectos Arquitecturais da Integração Common Data Interface Os Dados são Publicados num Base de Dados Os processos são ligados por MSQ Aspectos importantes 1. Independência Computacional 2. Segurança 3. Independência entre os produtores e consumidores da Informação

33 Um exemplo de uma Arquitectura App - 1 App - 4 R 4 App - 2 App - 3 Repositório Integrado Common Data Interface App - 5 App - 6 R 5 R 6 ERP Data Warehouse App - 7 App - 8 Outros Sistemas Operacionais App - 9 EIS, DSS, etc

34 Um exemplo de uma Arquitectura A Arquitectura de Integração deverá exibir de forma clara: As Interfaces pré-definidas, tanto do ponto de vista funcional como tecnológico. A Consolidação na holding. A visão de um DW corporativa As Integrações com os sistemas outras empresas, como por exemplo para as integrações B2B Clientes Fornecedores Holding Empresa Participadas

35 Um exemplo de uma Arquitectura App - 1 Clientes Fornecedores App - 4 R 4 Empresa participada Clientes Fornecedores App - 1 App - 4 R 4 App - 2 Repositóri o Integrado Common Data Interface App - 5 R 5 App - 2 Repositório Integrado Common Data Interface App - 5 R 5 App - 3 App - 6 R 6 App - 3 App - 6 R 6 App - 7 Data Warehous e App - 7 App - 8 Data Warehouse App - 8 App - 9 Empresa mãe App - 9 Empresa participada Clientes/ Fornecedores Corporate Data Warehouse App - 1 App - 2 App - 3 Repositório Integrado Common Data Interface App - 4 App - 5 App - 6 R 4 R 5 R 6 App - 7 Data Warehouse App - 8 App - 9

36 Dimensões do Alinhamento Business Goals Arquitectura de Negócio Business Strategies Business Information Application Data Business Information Arquitectura de Informação Business Processes Arquitectura de Aplicações Application Processes Application Functionalities Application Data Arquitectura Tecnológica Tecnologicas comuns (ex: motores de WF, Gestão Documental, Exploração de Dados, Sistema de Autenticação, Bases de Dados, Application Servers, etc) Arquitectura de Produtos (Pacotes vs Desenvolvimento à medida)

37 A correspondência com a arquitectura de Processos Arquitectura de Negócio Arqutectura de Informação Arquitectura de Aplicações

38 A correspondência com a arquitectura de Processos