atsi 2007 sobre alinhamento.... ...... os exemplos que seguem são tirados ”tal qual” dos...
TRANSCRIPT
ATSI 2007
Sobre Alinhamento...
...
... os exemplos que seguem são tirados ”tal qual” dos resumos da aula teórica entregues pelos alunos...
Sobre Alinhamento Informação e Negócio...
Alinhamento Informação e Negócio
1 conceito de negócio é representado por 1 entidade de informação
• O que é uma “entidade”? Pode ser qualquer coisa passível de ser identificado: requisito, regra, processo, actividade, entidade de informação, aplicação, servidor, ... !!!
• Por isso, CUIDADO que não se trata apenas de “entidades de informação”
• É habitual definir-se, em ambiente digital, um recurso como sendo tudo aquilo a que se consegue atribuir um identificador
Alinhamento Informação e Negócio
Cada conceito de negócio instanciado numa só entidade
tem como 1º objectivo
Interrupção...
Notas sobre uma boa análise, conceito de
processo e de instância de processo, etc...
sobre “entidade” enquanto conceito e enquanto instância (ainda algum rescaldo da discussão da aula passada):
• Enquanto conceito, a mesma entidade pode ser associada a vários contextos, mas em cada contexto ela pode ter várias “vidas”...
• Por exemplo, a definição de um processo de compra será um conceito, mas a execução desse processo em diferentes departamentos corresponderá a diferentes instâncias do mesmo, as quais podem ser mesmo radicalmente diferentes na sua execução. Ex:– Se existir uma regra de negócio que diga que nalguns casos
um processo de compra requer “autorização superior” e só se faz por requisição, contra a alternativa de se fazer de imediato e a dinheiro, numa instância numa unidade orgânica sem autonomia terá de ser executada uma actividade ou processo para garantir essa autorização, mas se calhar essa mesma execução noutra unidade orgânica que só faz compras a dinheiro não é necessária. Ver exemplo ilustrado:
Processo de Compra
Início
Requisição
Fim
Analisarpréviamente
Aprovado?
Justificação
«BusinessProce...Arquiv ar
«BusinessProc...Comprar
Cabimentar
ProduzirRelatório
Decidiraprovação
Requer Aprovação?
Pedido de Compra
«BusinessProc...Comprar a Dinheiro
Sim
Não
Sim
Não
Início
Requisição
Fim
Analisarpréviamente
Aprovado?
Justificação
«BusinessProce...Arquiv ar
«BusinessProc...Comprar
Cabimentar
ProduzirRelatório
Decidiraprovação
Requer Aprovação?
Pedido de Compra
«BusinessProc...Comprar a Dinheiro
Sim
Não
Sim
Não
Instância do Processo de Compra para o caso de Compra a Dinheiro
Início
Requisição
Fim
Analisarpréviamente
Aprovado?
Justificação
«BusinessProce...Arquiv ar
«BusinessProc...Comprar
Cabimentar
ProduzirRelatório
Decidiraprovação
Requer Aprovação?
Pedido de Compra
«BusinessProc...Comprar a Dinheiro
Sim
Não
Sim
Não
Instância do Processo de Compra para o caso de Compra com Requisição
Mas então se é assim, então porque não definir dois processos separados, um para Compra a Dinheiro e outro para Compra com
Requisição?• De facto, tecnicamente o mesmo pode ser feito como dois processos
separados, mas isso pode ser uma causa de desalinhamento, pois poderia não ser claro onde ficaria definida a regra de negócio que decide o que deve ser uma compra a dinheiro ou uma compra com requisição.
– Provavelmente iria definir-se essa regra em duplicado nos dois processos– Ou pior ainda, ela iria ficar esquecida e não seria aplicada em lado algum
(levando a que compras a dinheiro pudessem ser feitas indevidamente –potenciais fraudes e abusos...-, ou compras com requisição fossem feitas desnecessariamente –uma táctica fixe quando se quer “chatear um chefe picuinhas...”).
– Uma alternativa seria ainda definir um 3º processo só para aplicar essa regra, o qual passaria então o fluxo aos outros dois (de certa forma o que já está representado no exemplo mostrado). Isso estaria formalmente correcto, mas passávamos agora a ter assim 3 processos (falta de pragmatismo)!!!
• Desta forma, tendo apenas 1 processo, com essa regra explícita num único local, garante-se por exemplo que uma futura alteração da mesma seja aplicada de forma consistente. E o resultado da análise fica expresso de forma mais condensada!!!
Sobre boas práticas para identificar processos, ou dividir processos em subprocessos...
• O caso apresentado é um bom exemplo sobre como uma única descrição num processo pode bastar para representar adequadamente a mesma coisa que formalmente até estaria bem como 3 processos separados!
• Boa prática: depois de definidos todos os processos que se julgam relevantes e ao nível mais detalhado, analisar o que pode acontecer se alguns processos de mais baixo nível forem consolidados num só. Se nada de importante se perder (não só ao nível das regras e informação representada, mas também ao nível da flexibilidade=alinhamento), então deve ser de ponderar aceitar esse resultado, numa perspectiva pragmática (perspectiva sempre útil em qualquer caso de modelação que se pretenda eficaz e não apenas eficiente - em grande parte aquilo que faz a diferença entre uma modelação prática, exequível e consequente e uma formal e teoricamente perfeita mas ineficaz).
...Fim da Interrupção!
Ainda sobre Alinhamento Informação e Negócio...
• Retomando o caso inicial, atenção que aqui o uso do termo “instanciado” pode confundir...
• Uma expressão mais correcta aqui poderia ser por exemplo “Cada conceito de negócio realizado numa só entidade”.
• De facto a relação “conceito de negócio” -> “entidade” deve ser de realização (conceito1 --realiza--> conceito2) e não de instanciação (objecto --instancia--> classe)
Alinhamento Informação e Negócio
Cada conceito de negócio instanciado numa só entidade
tem como 1º objectivo
Nova Interrupção...
Porque é que não faz sentido modelar as
entidades de uma AE num modelo de domínio UML, como se aprendeu a fazer
em ACSI?
CUIDADO, não confundir os níveis a análise e desenho:
• No contexto actual em estamos a desenvolver arquitecturas de alto nível, as relações que interessa detectar entre entidades (processos, entidades informacionais, aplicações, etc.), devem ser SEMPRE relações estruturais ou arquitecturais, tipicamente de realização ou dependência, vistas SEMPRE no contexto geral da organização, e não em qualquer contexto específico de concretização
• As relações de generalização ou especialização interessam é na análise e desenho das aplicações em si (o contexto de ACSI...), e dependerão sempre da tecnologia a usar.– Por exemplo, se não se recorrer a um paradigma OO, ou
a qualquer outro que permita generalização, uso de módulos, ou algo do género, nem vale a pena procurar modelar essas relações!!!
...Fim da Interrupção!
Sobre heurísticas de alinhamento...
As heurísticas de alinhamento servem de guião para aferir o estado do alinhamento entre as várias arquitecturas
• OK...• Já agora, porque se dizem “heurísticas”?
Exemplos de heurísticas de alinhamento (dos slides das aulas teó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, etc.)
• Por omissão, os processos diferentes devem ser suportados por aplicações computacionalmente independentes.
• ...
Isso mesmo:• Dizem-se heurísticas porque a análise e
desenho de arquitecturas empresariais está ainda longe de ser um ciência determinística...
• Por isso é importante os alunos aparecerem na aulas, para podermos falar de... heurísticas! ;-)
Sobre Alinhamento Informação e Negócio...
Alinhamento
CRUD
Heurística
Medidas
Recorre a... ???
Sobre alinhamento...
- Se para cada Processo de Negócio tivermos uma Entidade Informacional, está alinhado
• ??? Não faço mesmo ideia do que se pretenderia dizer aqui...
Sobre heurísticas de alinhamento...
Um exemplo de alinhamento entre Informação e Aplicação será um ERP a usar apenas uma base de dados
• OK... mais ou menos isso! Mas se calhar era melhor assim:• “Um exemplo de alinhamento entre Informação e Aplicação
será um ERP que gere cada entidade de informação apenas numa base de dados” (nada impede um ERP de ter mais que uma base de dados, e mesmo assim garantir-se alinhamento...).
...Fim! por hoje...