Arquitecturas de Sistemas de Informação. Pedro Sousa

(1)

Pedro Sousa

(2)

Pedro Sousa

O caminho mais curto para a ASI

Resumo do Processo de Definição da Arquitectura de Sistemas de Informação

Caderno Encargos Desenho das Arquitecturas Arquitectura Tecnológica Arquitectura de Negócio Informação e Repositórios Aplicações Existentes Arquitectura de Informação Arquitectura de Aplicações

O quê?

Como?

Porquê?

(3)

Pedro Sousa

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.

– Exemplo da notação proposta (BPMN)

• Eventos • Actividades • Informação usada • Informação produzida • Pontos de decisão • Intervenientes

• Fluxos entre actividades

Reparações Operador Logístico Origem Transporte Destino Transporte Serviço Central Confirma a entrega no Destino Regista o Levantamento do Artigo na Origem Recepção do artigo Agendar Transporte

Preparar Artigo para Levantamento Informar intervenientes no transporte e recepção Identificação Artigo, Origem, Destino e Op Log Solicitar Operador Logístico para o transporte Associa OpLog ao

Artigo e Loja Operador

Logístico Registo Recepção Artigo Log entrega Log Levantamento Ordem de Reparação Guia de transporte

Fecho Recepção Artigo Artigo com Agendamento Automático?

Sim Não

(4)

Pedro Sousa

Arquitectura de Informação

Define e estrutura a informação necessária à execução das entidades

numa Arquitectura de Entidades Informacionais.

Reparações Operador Logístico Origem Transporte Destino Transporte Serviço Central Confirma a entrega no Destino Regista o Levantamento do Artigo na Origem Recepção do artigo Agendar Transporte Preparar Artigo para

Levantamento Informar intervenientes no transporte e recepção Identificação Artigo, Origem, Destino e Op L o g Solicitar Operador Logístico para o transporte Associa OpLog ao

Artigo e Loja Operador Logístico Registo Recepção Artigo Log entrega Log Levantamento Ordem de Reparação Guia de transporte

S i m N ã o Análise, Estruturação e Sistematização da Informação Entidade Informacional Cliente Entidade Informacional Serviço Reparações Operador Logístico Origem Transporte Destino Transporte Serviço Central Confirma a entrega no Destino Regista o Levantamento do Artigo na Origem Recepção do artigo Agendar Transporte Preparar Artigo para

Levantamento Informar intervenientes no transporte e recepção Identificação Artigo, Origem, Destino e Op L o g Solicitar Operador Logístico para o transporte Associa OpLog ao

Artigo e Loja Operador Logístico Registo Recepção Artigo Log entrega L o g Levantamento Ordem de Reparação Guia de transporte

S i m Não Listagem da Informação necessária à execução de cada actividade Arquitectura de Informaçã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. Arquitectura de Informação Arquitectura de Processos de Negócio Arquitectura Tecnoló gica Arquitectura de Aplicações

(5)

Pedro Sousa

Aplicação

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”!!!

Informação Funcionalidades Necessidades de Integração e Interoperabilidade Entidades Informacionais Entidades de Negócio Processos de Negócio missão

(6)

Pedro Sousa 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 ?

(7)

Pedro Sousa 7

Arquitectura

de Aplicações

(8)

Pedro Sousa

Arquitectura de Aplicações

(9)

Pedro Sousa 9

Arquitectura de Aplicações

Baptismo de Aplicações

• 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

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

(10)

Pedro Sousa 10

Arquitectura de

Aplicações

Definição de

Aplicações

SAMPLE APPLICATION

BUSINESS ANALYSIS SYSTEM (28)

PURPOSE: 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 (224238 P MATERIALS POPULATION (245) R ZERO-BASED RESOURCE BUDGET (252) C

DATA ENTITY RELATIONSHIPS Data usage

BUSINESS PROCESSR (19) R

DOCUMENT (32) R

EQUIPEMENT TYPE (28) R

FACILITY (38) R

GOODS AND SERVICES TYPE (27) R

INCIDENT (34) R

LOCATIONS (14) R

ORGANIZATION UNIT (2) R

PERFORMANCE MEASURES AND STANDARDS (224) R

PLAN (13) C

POSITION (18) R

PRODUCT TYPE (9) R

SKILL (4) R

(11)

Pedro Sousa 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 and

performance indicators related to the manufacturing process.

Management will use this information to oversee production.

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 and

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 real

time data

(12)

Pedro Sousa

Arquitectura de Aplicações

Critérios para a agregação de

Processos e de Entidades

(13)

Pedro Sousa

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)

Pedro Sousa

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

(15)

Pedro Sousa

(16)

Pedro Sousa

Dimensões do Alinhamento

Arquitectura Tecnológica

• O alinhamento entre estas 4 Arquitecturas fundamenta-se em

5 dimensões, podendo cada uma delas estar

alinhada/desalinhada independentemente das restantes

Arquitectura de Aplicações Arquitectura de Informação Arquitectura de Negócio

Alinhamento

(17)

Pedro Sousa

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.

• 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 ?

• 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.

Entidades de Negócio

Processos de Negócio

(18)

Pedro Sousa

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”.

• 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.

(19)

Pedro Sousa

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.

• 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.

(20)

Pedro Sousa

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)

Pedro Sousa

Alinhamento entre o Negócio e a Informação de Negócio

Entidades de Negócio Processos de

Negócio

•As Entidades contêm toda informação necessária ás actividades dos Processos (automática ou manuais).

•Todos os Processos que partilham entidades de Negócio, concordam com os conceitos que lhe estão subjacentes.

•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.

Exemplos de heurístias genéricas:

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)

Pedro Sousa

Alinhamento entre o Negócio e as Aplicações

Entidades de Negócio Processos de

Negócio

•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/..)

•Por omissão, os processos diferentes

devem ser suportados por aplicações

computacionalmente independentes.

(23)

Pedro Sousa

Alinhamento entre Informação e Aplicações

Entidades de Negócio

Processos de Negócio •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.

•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)

Pedro Sousa

• 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)

Pedro Sousa

Sistemas típicos das Organizações

Portais

Sistemas de

Suporte à Decisão

Data Warehouse

A Organiza ção

Extranets

Clientes

Soluções CRM

Soluções B2B

Data Marts

Data Stages

ERPs

Fornecedores

(26)

Pedro Sousa

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)

Pedro Sousa

(28)

Pedro Sousa

Alta afinidade entre as

entidades: a maioria das

entidades criadas por uma

aplicação são usadas pelas

outras aplicações

Baixa afinidade entre as

entidades: a maioria das

entidades criadas por uma

aplicação não são usadas

pelas outras aplicações

Padrões Arquitecturais

Common

Data

Interface

R 4 App - 4 R 5 App - 5 R 6 App - 6

Repositório

Integrado

App - 1

App - 2

App - 3

Data

Warehouse

App - 7 App - 8 App - 9

Suites Integradas

(ERP, CRM, etc)

EIS, DSS, etc

Outros

SistemasOperacionais

Forte indices de leitura de

outras entidades e as

eventuais entidades criadas

não são lidas por nenhuma

outra aplicação

(29)

Pedro Sousa

Common

Data

Interface

R 4 App - 4 R 5 App - 5 R 6 App - 6

Repositório

Integrado

(ex ERP)

App - 1

App - 2

App - 3

Data

Warehouse

App - 7 App - 8 App - 9

Podem existir várias

Suites Integradas

(ERP, CRM, etc)

EIS, DSS, etc

Outros

SistemasOperacionais

Repositório

Integrado

(ex CRM)

App - 10

App - 11

App - 12

Padrões Arquitecturais

(30)

Pedro Sousa

(31)

Pedro Sousa

Aspectos Arquitecturais da Integração

• Information Bus

– As Aplicações acedem on-line aos dados das outras

– Os processos são ligados por MSQ

Acesso à “on-line”

Aspectos importantes

(32)

Pedro Sousa

Aspectos Arquitecturais da Integração

• Common Data Interface

– Os Dados são Publicados num Base de Dados

– Os processos são ligados por MSQ

1. Independência

Computacional

2. Segurança

3. Independência entre os

produtores e consumidores

da Informação

Aspectos importantes

(33)

Pedro Sousa

Um exemplo de uma Arquitectura

Repositório

Integrado

Common

_Data

Interface

R 4

App - 4

R 5

App - 5

R 6

App - 6

App - 1

App - 2

App - 3

Data

Warehouse

App - 7

App - 8

App - 9

ERP

EIS, DSS, etc

Outros

Sistemas

Operacionais

(34)

Pedro Sousa

Empresa

“Participadas”

“Holding”

Clientes

Fornecedores

• 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

(35)

Pedro Sousa

Repositóri o

Integrado CommonData Interface R 4 App - 4 R 5 App - 5 R 6 App - 6 App - 1 App - 2 App - 3 Data Warehous e App - 7 App - 8 App - 9 Repositório

Integrado Common_Data Interface R 4 App - 4 R 5 App - 5 R 6 App - 6 App - 1 App - 2 App - 3 Data Warehouse App - 7 App - 8 Repositório

Integrado Common_Data Interface R 4 App - 4 R 5 App - 5 R 6 App - 6 App - 1 App - 2 App - 3 Data Warehouse App - 7 App - 8 App - 9