Projeto EAGLE

Apresentação

Quando foi que perdemos o com.passo?

Aonde estão as chaves?

De minha primeira Grande Visão

A Informação em Perspectiva

Os Dados do Passado

A Estratégia de Aquiles

A Informação do Presente

O Futuro da TI

O Projeto EAGLE e os seus Dados

Índice

A Estratégia Aquiles

Não há Aquiles que resista a dois calcanhares debilitados. Se apenas um deles já o afeta sobremaneira, dois simplesmente o derrubam. Pura física, pura lógica. Acredite: se apenas esses dois cenários (mais comuns do que se acredita) forem gerenciados com o profissionalismo que merecem e demandam, já teremos um ganho em produtividade [com um correspondente decréscimo de “obstáculos”] da ordem de 35–40%. Isso mesmo! Isso tudo. Então, na hora de analisar um sistema a fim de encontrar e corrigir as suas fragilidades e vulnerabilidades, comece sempre por ai.

Calcanhar #1: Ubiquitous Language.

— Os dados foram apropriadamente definidos, com clareza e correção, em dicionário de dados e de termos?
— Que [outros] sistemas têm acesso aos dados; com quais permissões de acesso [nenhuma, leitura, gravação]?
— Todos os usuários e stakeholders têm conhecimento e compreensão de seus significados, propósitos, propriedades e propósitos?

Nenhum dado é uma ilha; é de sua natureza ser compartilhado. Os problemas começam a surgir com a interpretação [sempre subjetiva] dos mesmos.             Esta cor, por exemplo, é mais verde ou mais azul? Nenhum dos dois (RGB 0 200 200). Mas se o processo X optar pelo verde, o serviço Y pelo azul, e a ferramenta Z por ambos, teremos [sérios] problemas. Cada um desses “sistemas” irá manipular este dado (cor) de acordo com a sua própria perspectiva particular; e cada uma delas estará sempre potencialmente impactando os resultados das demais, mesmo que inocuamente.

Definições, por outro lado, não são passiveis de interpretação; requerem “consenso”, visibilidade e controle. Todos devem concordar, sempre, que cor é essa, para que serve, etc. Certo? Mas dicionários de termos e de dados são considerados palavrões na maioria de nossas corporações. E Aquiles está mortalmente vulnerável.

Então:

  • PTI – Política de TI #1

    “Garantir que todos os recursos (assets) de negócio (como processos, serviços, sistemas, repositórios etc) estejam designados a pelo menos um responsável (custodian), que deverá supervisioná-lo e responderá pelos seus estados e comportamentos, bem como por sua conformidade a todas as regras, políticas e restrições a ele relacionadas, ao longo de todo o seu ciclo de vida”.

  • PTI – Política de TI #2

    “Manter, monitorar e controlar (gerir) um dicionário corporativo hierárquico de termos e de dados (DHTD) que contemple regras de permissões de acesso, mapeamento com o seu repositório permanente (databases etc) e dependências”.

  • PMR – Processo de Mitigação de Risco #1

    “Garantir que os responsáveis pelos sistemas (custodian, cf. PTI #1) tenham o seu acesso ao DHTD assegurado, incentivado, e registrado”.

Pronto.

Agora Aquiles está mais forte, menos vulnerável. Asseguramos que todos os nossos sistemas e stakeholders, (por meio de uma espécie de “CCBoK – Corporate Common Book of Knowledge”, data-centric [não content-centric]) dispõem dos recursos necessários a uma compreensão (conhecimento, nas pirâmides acima) comum e compartilhado. Ainda não podemos garantir que o farão, ou a frequência com que o farão, mas com certeza nos posicionamos no caminho e na direção certos.

best sign

Os artefatos resultantes de uma gestão assim “desenhada”, quando “governados” adequadamente, deixam de ser simples artefatos [potencialmente desatualizados e/ou em desuso]; assumindo o status de confiáveis bens, valores, patrimônio (assets) de negócio — fundamentais, críticos e sensíveis às estratégias corporativas de negócio.

Calcanhar #2: SoC – Separation of Concerns.

— As regras de negócio (BRs) foram apropriadamente implementadas e posicionadas?
— Ou elas estão simplesmente “vazando” indiscriminadamente para o database (DB)?
— Como se define e/ou se caracteriza, exatamente, uma BR? Como determinar se uma BR vazou para o DB?
— Se existem BRs no DB, elas foram devidamente implementadas (loose-coupling etc.) e testadas, fora e dentro do DB?
— De que artefatos de negócio as BRs implementadas no DB derivam e/ou estendem?
— A que requisitos e/ou requerimentos satisfazem?

Certa vez eu escutei que a coisa certa, no lugar errado, é lixo. Então, se tirarmos o “lixo” de nossos DBs, e “limparmos a casa”, posicionando “cada macaco no seu galho” e alocando nos DBs apenas as regras apropriadas [segurança, integridade, consistência etc]; então teremos DBs muito mais “claros”, inteligíveis, e mais facilmente gerenciáveis [eu sempre associo controle/monitoração a gestão/gerenciamento]. Haverá exceções? Sim. Em certos casos, não é aceitável – ou mesmo aconselhável e requerido – que certas BRs sejam “confirmadas” ([re]asseguradas) no contexto do DB? Certamente; mas nesses casos os cuidados deverão ser [re]dobrados, e a sua gestão ainda mais criteriosa.

best sign

Deve haver uma clara distinção entre os tipos de BR: as que são específicas aos DBs [estão em casa, moram aqui]; e as que não o são [“exceções” “extraordinárias”, não estão em seu local “natural”, ou “primário”].

Neste último caso, as BRs devem, obrigatoriamente:

  1. Derivar de um outro recurso ou artefato de negócio previamente implementado, testado e aprovado (cf. as 3 últimas questões do parágrafo anterior);
  2. Ser “plugáveis”, de modo que o seu acréscimo ou remoção do DB não impacte o DB de maneira alguma [elas dependem do DB, o DB não depende delas]; e
  3. Ser criteriosamente avaliadas, validadas e gerenciadas.

Ao garantirmos que o DB (ou melhor, a sua estrutura) derive do DHTD (ou seja, o DB depende do DHTD [que tem precedência e prevalência], não o contrário), estamos começando a “pavimentar” o caminho certo, recém “descoberto”. Para tanto, contudo, é necessário mais alguns “cuidados”:

  • PTI – Política de TI #3

    “Manter, monitorar e controlar (gerir) repositório(s) e sistema(s) de gestão de requerimentos e de regras de negócio (BRRR e BRRS)”;

  • CBR – Corporate Business Rule #1

    “Todas as regras de negócio, inclusive esta, derivam de Requerimentos de Negócio registrados [no BRRR, através do BRRS] (cf. PTI #3)”.
    [E isso inclui, é claro, todos os tipos de BRs, inclusive os mencionados acima.]

  • CBR – Corporate Business Rule #2

    “Todas as regras de negócio devem ser devidamente definidas, classificadas e registradas, facilmente identificáveis e totalmente rastreáveis.”

  • CBR – Corporate Business Rule #3

    “Todos [os catálogos de todos] os databases terão a sua estrutura derivadas do DHTD corporativo (cf. PTI #2)”;

  • CBR – Corporate Business Rule #4

    “Todos os databases deverão contemplar regras que garantam as suas escalabilidade e robustez (fault recovery)”;

  • CBR – Corporate Business Rule #5

    “Todos os databases deverão contemplar, primariamente, regras que garantam a segurança, a integridade e a consistência de seus dados”;

  • CBR – Corporate Business Rule #6

    “Os databases poderão hospedar, secundariamente, e em caráter extraordinário [de exceção], regras de negócio relacionadas a processos de negócios corporativos. Caberá ao BRRS (cf. PTI #3) controlar e monitorar os ciclos de vida de tais BR.”

É isso. Agora Aquiles está forte, ou pelo menos “se recuperando”. Agora ele pode caminhar com segurança, conforto e confiança nos caminhos que acabamos de viabilizar. Ainda não pode sair por aí correndo, ou parar para fazer um lanche e/ou apreciar a paisagem (ainda não disponibilizamos tais opções [contextos]); mas podemos observar que seu semblante é mais sereno, ele está mais tranquilo, relaxado, quase feliz.

Em poucos parágrafos definimos toda uma série de importantes artefatos/assets corporativos de negócio. De fato, modelamos o primeiro-rascunho (first-draft) de uma solução que, se bem implementada e gerenciada, tem o potencial de tirar até 40% do “peso de nossas costas” [ou mais… Infelizmente não existem dados concretos conhecidos que descrevam as medidas de desempenho e de incidências antes e depois da implementação de uma iniciativa como essa, ainda. Recomendamos fortemente, então, a inclusão desse requerimento em um eventual projeto de desenvolvimento que contemple as sugestões aqui propostas.]

  • PTI – Política de TI #4

    “Manter, monitorar e controlar (gerir) repositório(s) e sistema(s) de coleta, processamento e apresentação de dados e informações relacionas a medidas de desempenho (KPIs – Key Performance Indicators)”.

  • E finalmente:

  • PTI – Política de TI #5

    “Manter, monitorar e controlar (gerir) repositório e sistema de coleta, processamento e apresentação de dados e informações relacionas a estratégias e programas de negócios corporativos”. Tal sistema deverá, inclusive, contemplar a definição, implementação e gestão de uma estratégia e/ou programa que satisfaçam às CBR #3, 4, 5 e 6.

Não é difícil perceber que tais posturas (mindsets), políticas, padrões (standards) e requerimentos organizacionais requerem constante e diligente monitoração, controle, comprometimento e disciplina; tomam tempo e demandam investimentos. E também implicam – pelo menos em alguma medida – mudança cultural, de comportamento e paradigma.

Não existe mágica; e nada é de graça. Mas pense bem: não vale a pena? Vamos lá! Olhe bem para o pobre do Aquiles: sofrendo, de joelhos, gritando de dor e com ambos os calcanhares sangrando. Do jeito que está ele não aguentará muito mais, não é mesmo? E se em algum ponto no período entre seis e doze meses [um mês por requerimento?] nós o víssemos voltar a sorrir de novo, como resultado de nossos esforços e cuidados? Isso não seria muito bom? Não seria ótimo? Se lembra quando Aquiles costumava sorrir e cantarolar, como era contagiante e motivadora a sua alegria, o seu entusiasmo?

De mais a mais, não precisamos – e nem devemos, em verdade – fazer tudo do dia para a noite. Além de tratarmos um “calcanhar” por vez (estratégia), nós dispomos de uma série de “técnicas” de tratamento pouco intrusivas e de eficiência comprovada; todas amplamente testadas, aprovadas e recomendadas, e largamente utilizadas: Projeto Piloto, Prototipação Evolutiva, Desenvolvimento Iterativo (Sprints), Reuniões de Revisão e Avaliação, e Pesquisas de Opinião, entre outras.

Precisaremos, é claro, de bom planejamento, alguma autonomia [autoridade], e uma gestão diferenciada; além da colaboração de todos, do apoio muitos, e do financiamento de alguns. Mas com isso teremos o necessário para promover uma transição suave e sem [grandes] traumas para o estado almejado, uma significativa melhora do nosso paciente “paciente”, em período não superior a um ano. Não vale o investimento (principalmente em face de seu diagnóstico atual e de seu histórico de saúde)?

Além do mais, quais são as alternativas (sustentáveis, de qualidade, na realidade)?

↑ Topo ↑
 

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: