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

Instância do Processo de Compra para o caso de Compra a Dinheiro

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