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.

[ Próximo tópico: Diretrizes fundamentais ]

Texto completo

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: