Arquitecturas de Sistemas de Informação - Autenticação · Levantamento Ordem de Reparação...
-
Upload
truongdung -
Category
Documents
-
view
219 -
download
0
Transcript of Arquitecturas de Sistemas de Informação - Autenticação · Levantamento Ordem de Reparação...
Pedro SousaATSI 2005
O caminho mais curto para a ASI
Resumo do Processo de Definição da Arquitectura de Sistemas de Informação
Caderno Encargos Desenho dasArquitecturas
ArquitecturaTecnológica
Arquitecturade Negócio
Informação e Repositórios
AplicaçõesExistentes
Arquitecturade Informação
Arquitecturade AplicaçõesO quê?
Como? Porquê?
Pedro SousaATSI 2005
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 noDestino
Regista oLevantamento doArtigo na Origem
Recepção do artigo
Agendar Transporte
Preparar Artigo paraLevantamento
Informarintervenientes no
transporte e recepção
Identificação Artigo,Origem, Destino e Op
Log
Solicitar OperadorLogístico para o
transporte
Associa OpLog aoArtigo e Loja Operador
Logístico
RegistoRecepção
Artigo
Log entrega
LogLevantamento
Ordem deReparação
Guia detransporte
Fecho Recepção Artigo
Artigo com Agendamento Automático?
Sim
Não
(*) A notação BPMN é um resultado da Business Process Management Initiative – BPMI.org
Pedro SousaATSI 2005
Arquitectura de InformaçãoDefine 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 noDestino
Regista oLevantamento doArtigo na Origem
Recepção do artigo
Agendar Transporte
Preparar Artigo paraLevantamento
Informarintervenientes no
transporte e recepção
Identificação Artigo,Origem, Destino e Op
L o g
Solicitar OperadorLogístico para o
transporte
Associa OpLog aoArtigo e Loja Operador
Logístico
RegistoRecepção
Artigo
Log entrega
LogLevantamento
Ordem deReparação
Guia detransporte
Fecho Recepção Artigo
Artigo com Agendamento Automático?
S im
Não
Análise, Estruturação e Sistematizaçãoda Informação
Entidade Informacional
Cliente
Entidade Informacional
Serviço
Reparações
Operador Logístico
Origem Transporte
Destino Transporte
Serviço Central
Confirma a entrega noDestino
Regista oLevantamento doArtigo na Origem
Recepção do artigo
Agendar Transporte
Preparar Artigo paraLevantamento
Informarintervenientes no
transporte e recepção
Identificação Artigo,Origem, Destino e Op
Log
Solicitar OperadorLogístico para o
transporte
Associa OpLog aoArtigo e Loja Operador
Logístico
RegistoRecepção
Artigo
Log entrega
LogLevantamento
Ordem deReparação
Guia detransporte
Fecho Recepção Artigo
Artigo com Agendamento Automático?
Sim
Não
Listagem da Informaçãonecessária
à execução de cada actividade
Arquitecturade 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
Pedro SousaATSI 2005
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
Pedro SousaATSI 2005
6
Arquitectura de AplicaçõesTó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
Pedro SousaATSI 2005
9
Arquitectura de AplicaçõesBaptismo 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 EncomendasSistema de Publicidade e PromoçãoSistema de Controlo de ProduçãoSistema de Benefícios de EmpregadosSistema de RecebimentosSistema de Treino e Desenvolvimento
Sistema de Informação de ClientesSistema de Administração de EquipamentosSistema de Gestão de VeículosSistema de Informação de Recursos HumanosSistema de Gestão de ContasSistema de Inventário de Materiais
Pedro SousaATSI 2005
10
Arquitectura de AplicaçõesDefiniçã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 businessinformation for analysis to assist the correct business decision.
2. It will also identify required business resources, functions, and governmentregulations.
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: impactHEAD COUNT BY DEPARTMENT (282) RMANPOWER PLANNING (224238 PMATERIALS POPULATION (245) RZERO-BASED RESOURCE BUDGET (252) C
DATA ENTITY RELATIONSHIPS Data usageBUSINESS PROCESSR (19) RDOCUMENT (32) REQUIPEMENT TYPE (28) RFACILITY (38) RGOODS AND SERVICES TYPE (27) RINCIDENT (34) RLOCATIONS (14) RORGANIZATION UNIT (2) RPERFORMANCE MEASURES AND STANDARDS (224) RPLAN (13) CPOSITION (18) RPRODUCT TYPE (9) RSKILL (4) RSUPPLIER (25) R
Pedro SousaATSI 2005
11
Arquitectura de Aplicações
Descrição de Aplicações
APPLICATION ARCHITECTURE
APPLICATION NAME: Production Control SystemAPPLICATION NUMBER: 138PURPOSE: 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 periods2. Quality reports will include shipped product quality, internal and
external quality measurements by work group, test results for agiven period, incidents occurrences, quality history by productline, product item, and production process
[Additional objectives will be listed]
BENEFITS:1. Enable organization units to track and easily report quality,
service, and cost metrics2. Efficient, timely management of manufacturing by access to real
time data[Additional benefits will be listed]
Pedro SousaATSI 2005
Arquitectura de Aplicações
Critérios para a agregação de Processos e de Entidades
Pedro SousaATSI 2005
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) )
Pedro SousaATSI 2005
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
Pedro SousaATSI 2005
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
Pedro SousaATSI 2005
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
Pedro SousaATSI 2005
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.
Entidades de Negócio
Processos de Negócio
Pedro SousaATSI 2005
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.
Entidades de Negócio
Processos de Negócio
Pedro SousaATSI 2005
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.
Pedro SousaATSI 2005
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
Pedro SousaATSI 2005
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.
Exemplos de heurístias genéricas:
Pedro SousaATSI 2005
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
Exemplos de heurístias genéricas
Pedro SousaATSI 2005
• 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).
Arquitectura Ideal vs a melhor Arquitectura
Pedro SousaATSI 2005
Sistemas típicos das Organizações
Portais
Sistemas deSuporte à Decisão
Data Warehouse
A Organização
Extranets
Clientes
Soluções CRM
Soluções B2B
Data MartsData Stages
ERPs
Fornecedores
Pedro SousaATSI 2005
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
Pedro SousaATSI 2005
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
CommonData
Interface
R 4App - 4
R 5App - 5
R 6App - 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
Pedro SousaATSI 2005
CommonData
Interface
R 4App - 4
R 5App - 5
R 6App - 6
Repositório Integrado
(ex ERP)
App - 1
App - 2
App - 3
Data Warehouse
App - 7
App - 8
App - 9
Podem existir váriasSuites Integradas (ERP, CRM, etc) EIS, DSS, etc
Outros SistemasOperacionais
Repositório Integrado(ex CRM)
App - 10
App - 11
App - 12
Padrões Arquitecturais
Pedro SousaATSI 2005
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
Pedro SousaATSI 2005
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ça3. Independência entre os
produtores e consumidores da Informação
Aspectos importantes
Pedro SousaATSI 2005
Um exemplo de uma Arquitectura
Repositório Integrado
CommonData
Interface
R 4App - 4
R 5App - 5
R 6App - 6
App - 1
App - 2
App - 3
Data Warehouse
App - 7
App - 8
App - 9
ERP
EIS, DSS, etc
Outros Sistemas
Operacionais
Pedro SousaATSI 2005
Empresa
“Participadas”
“Holding”
ClientesFornecedores
• 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
Um exemplo de uma Arquitectura
Pedro SousaATSI 2005
Repositório
IntegradoCommon
Data Interface
R 4App - 4
R 5App - 5
R 6App - 6
App - 1
App - 2
App - 3
Data Warehous
e
App - 7
App - 8
App - 9
Repositório Integrado
CommonData
Interface
R 4App - 4
R 5App - 5
R 6App - 6
App - 1
App - 2
App - 3
Data Warehouse
App - 7
App - 8
App - 9
Repositório Integrado
CommonData
Interface
R 4App - 4
R 5App - 5
R 6App - 6
App - 1
App - 2
App - 3
Data Warehouse
App - 7
App - 8
App - 9
CorporateData
Warehouse
Empresa mãe
Empresaparticipada
Um exemplo de uma Arquitectura
ClientesFornecedores Clientes
Fornecedores
Clientes/Fornecedores
Empresaparticipada
Pedro SousaATSI 2005
Dimensões do Alinhamento
Business Information
Application Data
Business Goals Business Strategies
Business Information Business Processes
Application Processes
Application Functionalities
Application Data
Arquitectura de Negócio
Arquitectura de InformaçãoArquitectura de Aplicações
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)
Arquitectura Tecnológica
Pedro SousaATSI 2005
A correspondência com aarquitectura de Processos
Arquitectura de Aplicações
Arquitectura de NegócioA
rqut
ectu
ra d
e In
form
ação