Projeto EAGLE

Apresentação

Quando foi que perdemos o com.passo?

Aonde estão as chaves?

De minha primeira Grande Visão

Revolucionando a Gestão Teconológica

A Metáfora do Elefante

Em Busca de Equilíbrio e Lucidêz

Cloud Computing

Encarando a nossa realidade

A Informação em Perspectiva

O Projeto EAGLE e os seus Dados

Índice

Revolucionando a Gestão Tecnológica

Novas abordagens para a governança de TI.

en

Adaptado de “SaaC, CaaC Software Governance Strategies”.

Organizações que contam com a maioria de seus ativos e processos de negócios fortemente baseados em recursos de TI geralmente possuem um conjunto de artefatos de software proprietários, desenvolvidos internamente. Estes, via de regra, dependem de outros produtos (software-livres – de código-aberto – ou comerciais, adquiridos de terceiros), serviços, ferramentas etc. Idealmente, “ativos de TI” tão valiosos, sensíveis e essenciais, são submetidos a rigorosas, sistemáticas e formalizadas avaliações periódicas, que monitoram e garantem a continuidade de sua qualidade. Além disso, tais recursos são projetados, desde o início, para permanecerem estáveis e “saudáveis”, através da implementação de estratégias de governança coerentes e eficazes, fundamentadas na regulamentação e na aplicação de comprovados padrões, normas e diretrizes.

Em tese, uma abordagem de gestão tão competente e diligente produz um conjunto bem definido e estruturado de artefatos interdependentes, posicionados oficial e publicamente como Portfólio Corporativo de Recursos de TI. Um tal “estilo” de governança conduz potencialmente ao melhor dos mundos: facilidade na manutenção, aproveitamento (reutilização) e melhoria (evolução) de recursos; fácil introdução e integração de novos recursos, ferramentas e tecnologias ao “panorama geral” da organização; além de otimização do tempo de disponibilização no mercado (TTM – Time to Marketing), retorno sobre o investimento (ROI – Return of Investiment), custo total de propriedade (TCO – Total Cost of Ownership).

Consideremos então algumas estratégias que podem – de fato – nos conduzir a tal destino, através da óbvia opção pelo “caminho certo”, raramente percorrido.

TI como uma Empresa

ITaaC – IT as a Company

Idealmente, todo recurso de TI deve ser projetado, desenvolvido, mantido e gerenciado sob padrões, normas, diretrizes e melhores práticas (políticas) bem definidas e fundamentadas. Princípios e procedimentos de desenvolvimento e de gerenciamento devem ser periodicamente revistos e, na medida do possível, automaticamente reforçados (auditados). A manutenção de sua qualidade deve ser continuamente monitorada e controlada; formal e sistematicamente. Clientes (ou consumidores) devem participar ativamente de cada fase dos processos de desenvolvimento, avaliação, manutenção, evolução e “aposentadoria”.

Além disso, deveríamos posicionar cada projeto de TI – desde o seu primeiro dia e ao longo de todo o seu ciclo de vida, como um empreendimento em si mesmo. Tomando uma reunião corporativa de conselho como exemplo, consideraríamos o mesmo tipo de questões ou interesses (concerns), como:

  • Quais são as nossas metas, em relação a este projeto, para o próximo ano (dado o atual contexto, estado de desenvolvimento etc.)? E para os próximos 2, 3, 5 anos?
  • Quais são exatamente a real necessidade, a relevância e o valor deste projeto? E como vamos representar tais conceitos, a fim de avaliá-los e medi-los com objetividade?
  • Os seus objetivos são viáveis? Se sim, que estratégias, políticas, restrições, padrões e normas devem ser adotadas? E como serão aplicadas, asseguradas e monitoradas?
  • Como devem ser posicionados os recursos de TI gerados por este projeto, no contexto geral de ativos de negócio (portfolio) da organização? Em que cenários se encaixam? Com que os outros recursos ou estratégias se relacionam?
  • Existem outras iniciativas similares ou contraditórias em uso?
  • Será que já tentou algo parecido antes? Se sim, quais foram os resultados, então? E por que não entraram em vigor na ocasião? Existem alguma “lição aprendida” que também deve ser considerada?
  • Existem outras alternativas? Se sim, quais são os seus prós e contras?
  • Quando e como esta iniciativa e seus resultados serão medidos e avaliados? Quais serão as regras e métricas que determinarão o seu sucesso ou fracasso?
  • Que planos, estratégias e procedimentos de contingência e mitigação serão necessários? Estão já em curso, totalmente testados e operacionais?
  • Como este projeto depende, impacta e / ou se relaciona com outros projetos pré-existentes? O que é necessário para se assegurar que não vai interferir (impactar) qualquer outro recurso? Como e quando isso vai ser testado, comprovado e documentado?

Além do mais, ao contrário de suas contrapartes na organização, projetos de governança de TI – com suas estratégias, processos, metas, regras e políticas – devem ser públicos, amplamente difundidos e bem conhecidos. Todos e cada um dos interessados devem saber, em detalhes: como é que a organização posiciona, valoriza e suporta os recursos de TI com os quais eu estou lidando?

Da perspectiva da arquitetura de software, eu visualizo recursos fundamentados em conceitos como POCO, N-Camadas, consulta-comando, padrões orientados a serviços e funcionalidades, mesmo quando esses padrões não são aparentemente necessário de imediato. Então – a partir de tal fundamento arquitetônico – vamos ampliar, melhorar e enriquecer os nossos projetos de desenvolvimento de recursos de TI – estejam eles relacionados a produtos e serviços de software e/ou a processos de negócios – de forma incremental, modularizado e iterativa, baseados em protótipos e em testes unitários, integrados etc.

Diretrizes fundamentais

As seguintes diretrizes (guidelines) devem [sempre que possível] ser consideradas inegociáveis:

  • Conceitos e procedimentos de encapsulamento, reutilização, independência [transparência referencial] e baixo-acoplamento devem sempre nortear nossos esforços de implementação (codificação), testes e integração.
  • Princípios e preceitos devem ser sempre aplicados. Expressões como “separação de interesses”, “aberto para a extensão, fechado para modificação” e “princípio da responsabilidade única” estão muito, muito longe de ser meros conceitos acadêmicos ou frases de marketing.
  • Melhores práticas devem ser sempre explicita e amplamente divulgadas, e consistentemente aplicadas. São chamadas de “melhores práticas” – e não de “melhores intenções”, ou de melhores “ideias” – por uma razão muito boa. Para funcionar, devem concretizadas, colocadas “em prática”. Caso contrário, simplesmente não funcionam de maneira alguma. Simples assim! E, assim como o item anterior, também deve ser coibida a utilização deste termo apenas como demagogia publicitária ou frase de efeito.
  • “Antes de mais nada, nós fazemos o melhor, e então (se, quando e onde necessário), refatoraramos”. Só assim podemos “garantir” – e monitorar (controlar) – a qualidade do resultado de nossos esforços. Esta deveria ser a nossa “cultura”.
  • “Falhar o quanto antes, para obter um rápido feedback!” Um ótimo “mantra”.
  • E tolerância zero para as mensagens de aviso do compilador (warnings).

Além disso, ao lidar com o legado (recursos pré-existentes), ou com dependências externas, tais como componentes de software de terceiros; não tocá-los. Ou seja, não invocá-los diretamente (e muito menos alterar o código-original, quando acessível). Ao invés disso:

  • Encapsular todas as funcionalidades requeridas em um conjunto bem definido de interfaces (service endpoints, component facades, proxies etc).
  • A sua colaboração (interface) com outros recursos de TI devem se dar apenas através destas interfaces/fachadas.

E, finalmente, os seguintes procedimentos devem ser sempre considerados, dada a sua fundamental importância para a “saúde” de nossos recursos de TI, bem como de sua total pertinência com os conceitos de governabilidade que estamos apresentando:

  • Testar tudo, sempre. Tão logo e frequentemente quanto possível. Usar testes de unidade, mocks e stubs.
  • Diagnosticar, acompanhar e gerir a cobertura de teste de código. Aplicar análise estática de código.
  • Planejar, projetar e aplicar – cuidadosa e criteriosamente – testes de componentes, sistemas e integração, bem como de aceitação, tanto interna como pública (UAT – User Acceptance Tests). E nunca negligenciar os testes de regressão (compatibilidade reversa).
  • Catalogar todos e cada recurso de TI. Criar e manter um catálogo (repositório, registro) centralizado de recursos de TI.
  • Criar e manter um sistema de controle de versão centralizado e formalizado, com estratégias, regras, políticas e processos padronizados. Isso é crucial, a fim de proporcionar o necessário controle sobre os processos de desenvolvimento de recursos de TI sensíveis e críticos, principalmente no que diz respeito a gestão de portfólio, testes de regressão, rollbacks e execução paralela (implantação de modelos blue-green).
  • Aplicar os conceitos de integração contínua, desde o início de cada projeto de desenvolvimento de recursos de TI. Minimizar a necessidade e as ocorrências de branches e de merges. Mantenha o recurso sempre funcional (verde) e pronto-a-ser-promovido para o próximo “ambiente”, na cadeia (pipeline) de especificação, codificação, implementação, teste, quality-assurance, staging, produção e aposentadoria (retirement).

As boas novas (e as nem-tanto assim)

A boa notícia é que já temos todos os necessários conhecimentos, tecnologias e ferramentas. Para citar apenas alguns: OOP, SOA, DDD, AOP, DI; IIS, WAS, ADFS, MVC, MVP, MVVM, PMO, CMMI, MSF, APM; UML, TFS, CI, MEF; DM/DW, SSIS e por aí vai.

O que parece ser difícil de aceitar é que nós temos que construir, organizar, compor, estruturar, a partir do zero, os nossos próprios recursos. E temos que adaptá-los às nossas necessidades específicas de negócios, baseadas em nossas metas corporativas de TTM, ROI etc. E temos ainda que rastrear, monitorar e administrar os nossos recursos. E sim, isso vai exigir esforço, sistemático e deliberado, além de investimento, coerente e contínuo; na definição, estruturação, formalização, padronização, publicação e divulgação de nossos recursos “oficiais” de TI, bem como para fazer cumprir as pertinentes normas, melhores práticas, processos e procedimentos. Sem mencionar o necessário e simultâneo esforço em promover uma adequada cultura empresarial e corporativa, que assegure posturas e mentalidades correspondentes, por parte de todos os interessados (stakeholders).

A má notícia (já conhecida e muitas vezes evitada): não vai ser fácil, ou rápido. Nada que “vale” aparece “de hoje para amanhã”. Vai demandar tempo, dinheiro, foco, comprometimento e disciplina; bem como uma visão mais ampla, e um sério, deliberado e continuado esforço. Pois particularmente aqui, no âmago de nosso panorama corporativo de recursos de TI, não há coisas como magia, balas de prata ou soluções pré-fabricadas.

stop

É claro que sempre poderemos fingir, falsear, negar ou negligenciar este fato, mas os resultados e as consequências de uma atitude tão “ingênua” acabarão sempre por se revelar; em geral mais cedo do que seria de se esperar.

Atrevo-me a dizer que este é exatamente o cenário mais comum hoje em dia, na maioria de nossas organizações que têm os seus ativos corporativos fortemente baseados (dependentes) de recursos de TI. Para o bem – ou com a desculpa – de nossos orçamentos, cronogramas e outros que tais; ainda estamos insistindo no velho padrão de comportamento que nos mantêm longe do “caminho correto, duro e direito”, e, assim, acabamos sempre por colher os nossos “nunca intencionais” e “aparentemente” inesperados – mas sempre “lógicos” – resultados.

E isto, como você já deve ter notado, não é desejável, nunca, de forma alguma. Na verdade, é exatamente isso o que nos leva para o mesmo tipo de “soluções” frágeis, difíceis de manter, fracas, acidentais e perigosas, que sempre tentamos evitar e superar (ou assim o dizemos); para bem longe de nossos bem-intencionados objetivos iniciais de qualidade, satisfação, padrões de produtividade, rentabilidade etc. etc. Com isto, estamos constante e continuamente perdendo nossas metas e objetivos, enquanto desperdiçamos o nosso tempo e o dinheiro dos “patrocinadores”. E, no final do dia, acabamos não cumprindo a nossa missão, nossa própria vocação – de proporcionar boas, gerenciáveis, escalonáveis e robustas de soluções de TI.

A raiz dos nossos problemas, a meu ver, está em nossa “falta de percepção” de que, em última análise, um recurso de TI deve ser considerado como um valioso, crítico e sensível “ativo” da organização. E deve ser tratado (gerido) como tal. Cada projeto de desenvolvimento de recursos de TI deve ser governado de acordo com padrões e modelos (standards) formalizados e bem conhecidos, além de ser periódica e regularmente revisados e reavaliados, em relação aos seus objetivos de curto-médio-longo prazos; bem como estratégias, restrições etc.

O desafio inicial

Uma iniciativa deste porte implica em importantes e continuas atividades, e demandam a alocação de uma equipe (team) de governança formalmente definida, com membros dedicados, em tempo integral (task-force). Após os primeiros testes e projetos-piloto bem sucedidos, é imprescindível o estabelecimento de um ambiente mais estruturado: um escritório (office) e/ou departamento.

IT Resources Portfolio Lifecycle

Figura 1. Implementando o Portfólio de Recursos de TI

  1. Levantamento – agrupa, estrutura e registra todos os recursos de TI; em uso, disponíveis e/ou necessários – conhecimentos, legados, tecnologias e ferramentas – organizados em um portfólio (repositório centralizado) coerente/consistente, significativo, formal e padronizado. De início, uma simples listagem e/ou tabela bem estruturada é o suficiente (mais detalhes a seguir).
  2. Catalogação – define e descreve o perfil de cada um dos recursos reunidos na atividade anterior; estabelecendo o seu valor para a organização, as suas dependências, especificações, requisitos, status, etc.; em formulário padronizado. Documento Word, não Excel; inicialmente (consulte a próxima seção, abaixo).
  3. Avaliação – classifica e avalia cada recurso de TI catalogado anteriormente; tanto em relação uns com os outros como um valioso ativo de negócio corporativo e formal. Esta atividade deve incluir as perguntas constantes na primeira lista acima (intenções, ou concerns). O mesmo Formulário de Perfil (FP) utilizado na atividade anterior deve ser complementado aqui, a fim de garantir a consistência e a centralização das informações.
  4. Posicionamento – reavalia os recursos avaliados anteriormente, desta vez com o foco voltado para um duplo objetivo, sintetizados nas seguintes questões:
    • Como este recurso pode/deve ser posicionado, neste momento, no âmbito da organização como um todo, e em função de seus valor/relevância para os negócios, status de desenvolvimento, dependências etc.?
      e/ou
    • Como este recurso pode ser melhor posicionado – considerando seu papel e status atuais, no contexto global da organização – em relação ao próximo cenário (panorama, patamar) desejado e/ou requerido pela organização? Que alterações são necessárias? Quais são as novas especificações (requerimentos etc.) para tanto?

    Esta atividade deve incluir as duas listas anteriores (intenções/concerns e diretrizes/guidelines). Aqui, o FP criado na segunda atividade, e complementado na terceira, deve ser estendido, de modo a “isolar”, ou “classificar” tal informação, a partir da descrição do que já está definido (dados fixos, aprovados e estáveis e/ou em uso) e do que não está aprovado e/ou implementado (dados de estados mutáveis, incompletos e/ou “transientes”).

  5. Planejamento – analisa os dados reunidos até o momento, agrupando e selecionando os recursos necessários para um plano de extensão do portfólio oficial de recursos de TI da organização. Elabora e estabelece um projeto de desenvolvimento que descreve, justifica e fundamenta tal planejamento, definindo suas estratégias e alternativas. Tal projeto é então encaminhado, apresentado e/ou submetido à avaliação da alta-gerência – “dona” e/ou “patrocinadora” da iniciativa representada pelo projeto apresentado. O resultado (output) desta atividade deve ser a aprovação ou rejeição da proposta de projeto apresentada.
  6. Reposicionamento – implementa os projetos aprovados, revisando e atualizando todos os recursos e artefatos relacionados; bem como a sua documentação Esta atividade inclui algumas tarefas (tasks) críticas, já que “conecta” recursos pré-existentes [em uso/produção, “oficiais” e “certificados”] a recursos (interfaces, software, processos, serviços etc.) contemplados pelos projetos em questão; devendo, portanto, garantir tanto que isto ocorra sem problemas como que não impacte o comportamento e a qualidade de quaisquer recursos pré-existentes.
  7. Retrospectiva – fecha o ciclo atual de desenvolvimento de recursos de TI e reinicia um novo ciclo, retomando a primeira atividade acima; desta vez com o conhecimento adquirido com as últimas conquistas e com um portfólio enriquecido pelos resultados obtidos pelos esforços desenvolvidos anteriormente. Uma tarefa importante aqui é a recapitulação, através de um “spring meeting”, para:
    • Avaliar as atividades realizadas durante este último “loop” (iteração),
    • Registrar as lições aprendidas,
    • Planejar, formatar e/ou esboçar a próxima iteração
    • Comemorar (e gratificar) os últimos resultados.

Cada uma dessas atividades revisa, complementa e valida as anteriores, levando-nos natural e logicamente a um processo iterativo, a uma abordagem progressiva e evolutiva. Além disso, após cada “re-evolução” (spin ou loop), contaremos com um “corpo de conhecimento” corporativo, centralizado, atualizado e bem definido, com suas pertinentes e importantes informações a respeito de nossos recursos “oficiais” de TI – bem como de seus estados (status), requerimentos (dependências) etc. – à disposição de todos os interessados (stakeholders), como um confiável (e certificado) subsídio para processos de tomada de decisões.

Faz sentido?

Não. Não é nem fácil, nem barato e nem é simples. Mas é certamente o caminho mais lógico, se formos de fato “orientados para (ou motivados pelo) sucesso”, coerente e consistentemente planejado, construído e gerenciado (monitorado e controlado). As atividades e processos aqui descritos atuam como procedimentos e operações “táticas”, com vistas a metas e objetivos corporativos mais “estratégicos”; através de um “metodologia” mais “sábia”: sólida, robusta, significativa e “valiosa”.

Porém, tudo o que foi descrito até o momento representa apenas a metade do verdadeiro (ou, digamos, “real”) “caminho”. Uma conquista muito valiosa e útil por si só, de fato, mas que representa apenas uma das faces de nossa “moeda de ouro”. Vamos então explorar a outra face da moeda, a outra metade do caminho.

A Organização como um Cliente

CaaC – Company as a Client

O princípio (raciocínio, mentalidade) aqui é muito simples, e bem conhecido:

“Se você quer ‘vender’ algo, ‘consuma-o’!”

Nós, os “especialistas”, estamos acostumados a indicar um monte de ótimas e “perfeitas” soluções para nossos [às vezes potenciais] clientes: “a fim de atender às suas necessidades, vamos modelar isso, automatizar aquilo, unir, montar e distribuir isso, publicar e compartilhar aquilo. A arquitetura da solução com certeza irá garantir tudo o que for necessário; e nós vamos utilizar todas as tecnologias, ferramentas e recursos necessários, para entregar a esperada e contratada qualidade, eficiência e satisfação”. Então, quando o cliente animado e espantado “compra” nossa proposta, rapidamente corremos de volta para os nossos habituais “martelos e pregos”, usando sempre as mesmas velhas e tradicionais ferramentas de desenvolvimento; bem como os nossos mesmos não-modelados-nem-tampouco-automáticos-e-muito-menos-garantidos processos de desenvolvimento. Certo?

De vez em quando tentamos “melhorar” os nossos métodos e processos de desenvolvimento, quando nossos orçamento e agenda permite, ou algum tipo de crise nos obriga. Então vamos atrás das “melhores práticas” e das mais recentes metodologias de desenvolvimento (PMI, Scrum, CI, System Center etc. etc.). Embora isto seja previsível e até desejável, nós ainda continua errando o “alvo”, enquanto esperamos pela próxima “onda” (moda) de melhorias, para a próxima “geração” de ferramentas, recursos, padrões etc.; ou seja, um outro conjunto de pregos, um martelo “novinho em folha”.

Então, que alvo é este, que nós ainda estamos errando, a cada nova tentativa, toda vez?

“Se você quer ‘vender’ algo, ‘consuma-o’!”

“Vendedor, consuma os seus próprios produtos!”

“Doutor, tome o seu próprio remédio!”

“Curador, cure a si mesmo!”

Ou:

“Desenvolvedor, automatize as atividades de sua própria organização!”

“Analista, modele os processos de sua própria corporação!”

“Gestor, defina e padronize o seu próprio negócio!”

Será que faz sentido? Não é este o caminho mais lógico, dado que somos tão voltados para o sucesso? Mais uma vez: não é uma solução nem uma simples nem barata, principalmente no início; mas é o passo mais básico e fundamental, sem o qual todo o resto não passa de falácia e demagogia. Pois nós mesmos somos o nosso mais importante, valioso e valoroso “cliente”, certo? Então, vamos levar isso a sério, profissionalmente (na verdadeira acepção desta palavra).

Então, de volta à metáfora do cliente:
— Nós não temos clientes, projetos, bancos de dados etc.?
— Bem, deveríamos ter….
— O nosso “domínio”, de desenvolvimento de recursos de TI, está devidamente “modelado”?
— Deveria estar…
— Os nossos processos, de desenvolvimento de recursos de TI, estão automatizados?
— Deveriam estar….
— Os nossos requisitos e requerimentos são bem-conhecidos?
— Então vamos defini-los e documentá-los!
— Estão todos os nossos cenários e casos de uso (ou user stories) definidos e especificados?
— Então vamos especificá-los!

E assim por diante…

Esboçamos anteriormente um conjunto de desafios e atividades que descreve um “processo de negócio, certo? De fato, o processo descrito na seção “O desafio inicial” exemplifica o mesmo tipo de processo que estamos tão acostumados a modelar, automatizar, empacotar e disponibilizar aos nossos clientes A única diferença é que diz respeito aos nossos próprios processos de desenvolvimento, neste caso (uma proposta de padronização de) de desenvolvimento de recursos de TI. Então, por que não “experimentar do nosso próprio remédio”? Não parece “lógico”?

Neste caso, teríamos algo como:

  • Quais são os conceitos centrais/básicos da proposta?
  • Quais são os principais “substantivos e verbos”?
  • Quem são os “atores”?
  • Quais são os “cenários”?
  • Quais são os candidatos a tipos/classes, propriedades, métodos/operações, serviços, processos, interfaces, proxies, e assim por diante?
  • Quais são as regras, restrições, dependências (explicitas e/ou implícitas) etc.?
  • Como tais participantes colaboram ou se relacionam uns com os outros?
  • Há necessidade de uma interface gráfica de usuário (GUI)? Se sim, de que tipo? Se não, por quê?
  • Que (tipo de) ambiente deve ser hospedar esta (nova) “solução”?
  • Como os dados serão mantidos, recuperados, processados etc.?
  • E assim por diante…

Durante o desenvolvimento de nossa nem tão hipotética nova “solução”, alguns “imprevistos” (unknowns) certamente irão se revelar. Provavelmente vamos nos deparar com a ausência de alguns modelos ou conceitos, não contemplados anteriormente. E mais: como uma “evolução” natural de nosso esforço, logo iremos nos ver modelando toda a nossa empresa: matriz, escritórios, filiais, departamentos, clientes, fornecedores, usuários etc. E daí? Ninguém disse que esta seria uma iniciativa rápida, ou fácil. De mais a mais, isto está completamente “alinhado” com a abordagem (aqui proposta) CaaC, não está? Além disso, não é exatamente este “o tipo” de “abordagem”, que nós sugerimos – tão orgulhosamente – a nossos clientes, a fim de “otimizar” os seus ambientes e processos?

clipNote

Note que isto pode – e na verdade deve – ser feito de forma incremental, através da definição tanto de “pontos de controle e revisão” (milestones), como de “marcadores” (placeholders) e “pontos de extensão” – a fim de garantir uma contínua e rápida demonstração do progressivo estado evolutivo (status) da solução.

A abordagem CaaC de fato complementa e dá suporte à SaaC, que impõe alguns requerimentos sobre CaaC. CaaC atua então como uma camada “utilitária”, comum a esta e provavelmente a muitas outras iniciativas da equipe de governança de recursos de TI da corporação.

Estratégias de Governança de Software

Quando pensamos a respeito de CaaC, uma questão muito razoável pode surgir: e quanto aos tantos outros catálogos (databases) mantidos pela corporação? Já temos (investido muito em) CRMs, SAPs, Active Directories, catálogos BizTalk, bases de dados customizadas/proprietárias etc. Não faria sentido adicionar “mais um” item à lista, certo? Sim, absolutamente certo! Mas este é exatamente o ponto!

Todas estas soluções tão úteis já implementadas nos impõem o seu próprio modelo de dados. Então, nós acabamos com uma série de modelos “afins” – cada um deles representando os mesmos conceitos empresariais – espalhados por toda a organização. E dado que tais soluções e modelos não “conversam” entre si, suas informações – algumas delas muito importantes e sensíveis – logo se tornam fora de sincronia. Com os dados fora de sincronia, as equipes de ficam fora de sincronia; os serviços saem de sincronia; departamentos e escritórios ficam fora de sincronia – a empresa sai de sincronia. Você pode prever os resultados?

Embora nós não estejamos defendendo aqui a utilização de um único banco de dados centralizado, consideramos a “consolidação” de todos os modelos existentes – em um “modelo” unificado e centralizado – um requisito fundamental. E este é exatamente o principal objetivo do CaaC. Na verdade, todos os modelos (legado) isolados (e/ou independentes) devem servir como input para a tarefa “normalização” de dados do CaaC. O CaaC deve, ainda, registrar e mapear quais são os recursos de TI que podem gerar cada tipo de informação; e quais recursos de TI podem acessar ou alterar tais dados.

Então, o ITaaC, ou mais precisamente, alguns recursos de TI ITaaC-orientados – devem entrar em cena e assumir a responsabilidade de integrar os modelos relacionados aos recursos de TI, mantendo os seus dados em sincronia; de forma controlada, centralizada, unificada, monitorável e gerenciável. Além disso, para satisfazer os requerimentos iterativos e incrementais do ITaaC, os recursos de TI “participantes” previamente “registrados” no repositório (portfolio) CaaC, o que por sua vez permitirá ao SaaC suportar tais processos de integração e sincronização.

Faz sentido, agora?

Finalmente…

Ao considerar a CaaC, o ITaaC, e as estratégias de governança de recursos de TI da corporação, como um todo; podemos pensar nesta iniciativa como a evolução de nossas mais valiosas as melhores práticas atuais, tais como a separação de interesses e baixo-acoplamento por exemplo; uma espécie de refactoring de todo o nosso (eco)sistema, de todo o panorama, ambiente, macro contexto – um passo adiante, o próximo e mais lógico passo, em nosso já pavimentado caminho para o sucesso e – principalmente – rentabilidade.

Usando uma analogia de engenharia civil, eu diria que os alicerces já estão todos a postos, todas as ferramentas e todo o maquinário, disponíveis. Por isso, compete a nós, agora, arregaçar as mangas e começar a construir o que é necessário, mesmo que isso nos exija explodir algumas velhas paredes, muros e pontes (e/ou mesmo contratar algumas novas equipes, melhor qualificadas, para os objetivos em pauta). E é claro que haverá um pouco de poeira e um certo período de aparente caos (principalmente), enquanto o trabalho está sendo executado. Mas, no final, um cenário e uma paisagem novinha em folha estaria lá, permitindo-nos beneficiar de seus resultados.

É um esforço enorme, inovador e ousado, sem dúvida, mas com uma promessa de lucros e satisfação equivalente, para todos os interessados, de usuários/clientes a analistas de negócios e de processos, desenvolvedores, testes, administradores de sistema, operadores, gerentes, CIOs, CEOs etc.

Um importante (e crucial) último lembrete

Se há algo que eu aprendi e testemunhei, durante os mais de 20 anos atuando na área de TI, é que não há nenhum valor ou ganho na oferta de mentiras ou equívocos, não importa o quão atraentes os apresentemos.

Se, fora do computador, o nosso sistema – o nosso conjunto de domínios, modelos e processos de negócios – é fraco, desorganizado ou inconsistente, ele vai continuar sendo a mesma, digamos, “bagunça”, depois de automação. Uma “bagunça mais rápida”, não mais que isso. E a sua fraqueza logo se revelará e será exposta, apesar de todos os nossos maiores esforços e apesar de nossas melhores intenções.

Então, neste caso a primeira coisa a fazer é limpar/organizar a bagunça. E o primeiro requisito deve ser definir e estruturar as nossas “coisas”, a fim de adquirir controle sobre eles, melhorando e reforçando a sua visibilidade e correção. Faz sentido?

Dado que não há mágica, bala de ouro ou prata, ou solução pronta para uso; cabe a nós fazer a lição de casa, o nosso próprio trabalho; e trilhar “o caminho difícil, mas correto”.

Nós vamos sempre colher o que plantamos. A boa notícia é que podemos escolher o que plantar, como semear, e o que fazer em seguida. Então, escolha bem, abrace o caminho, e aprecie o trabalho. Ou abrace o trabalho e aprecie o trajeto; mas, escolha bem!

↑ Topo ↑
 
Anúncios

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: