Shortsightedness in IT – Thomas Erl

Olá pessoal!

Oracle Technology Network ArchBeat PodCastQuantas vezes nos deparamos com as frustrantes situações em que uma determinada solução tecnológica, aderente aos padrões corporativos e que melhor atende aos requisitos não-funcionais estabelecidos, não pode ser aplicada em um projeto, seja por não haver tempo hábil, por exemplo, levando a adoção de abordagens que nem sempre trazem bons resultados a longo prazo?

Neste post gostaria de compartilhar um trecho de um podcast publicado pelo Oracle Technology Network, em seu canal ArchBeat Pod Cast, onde Thomas Erl – best selling SOA author, explica como tais situações normalmente se originam. Segundo Thomas, existe o que ele chama de miopia na perspectiva considerada na avaliação dos resultados de projetos, onde acaba-se sendo considerado apenas prazo, orçamento e atendimento dos requisitos funcionais como critérios que definem se um projeto foi ou não bem-sucedido, deixando de lado a qualidade da arquitetura implantada, o que acaba resultando em defasagem tecnológica, projetos que geram silos de informação e aplicações que atendem apenas a um propósito, consequentemente aumentando o custo de propriedade do produto produzido pelo projeto. Confira abaixo.

Miopia em TI

“… the criteria organizations use to evaluate project team performance, I think there still a lot of tactical emphasis on determining what was and what was not a successful project and by that I mean did it come under budget, did it come on time, did it meet functional requirements and those tend to be focal points when projects are assessed and it is easy to lose sight of the importance of what you are designing and the long term implications of what you are building when you are focusing more on the timeline, the budget and meeting the functional requirements within the primitives of that budget and timeline. And it is easier to meet those goals as you are being assessed by bypassing proper technology architecture and just getting developers to build something that works as per the immediate functional requirements and if you as a project manager are not being assessed based on the quality of the technology architecture, its compatibility with the surrounding IT enterprise architecture, its compliance to predefined standards, then there is no means of assessing that or regulating that, then there is no motivation to really emphasize that or make that part of the project cycle, because it will just use up more time and resources and will go against the other points which you are being evaluated. So I think that assessment from a strategic perspective is also lacking in some IT environments and that is to their detriment in the long term, because it is not part of how they assess project, applications, delivery projects, then those projects do became very much silo based, single purpose and then, consequently, impact the subsequent governance and ownership burden that IT enterprise assumes and it is that shortsightedness that I think also leads to situations like that where IT architects are not given the level of responsibility that they should.”

A não mudança de tal cultura leva a geração de conflitos constantes entre os times de projetos e os times de arquitetura, pelos seus diferentes interesses. A convivência em projetos com tais conflitos acaba não sendo saudável para nenhum dos envolvidos, nem tão pouco para o próprio projeto. Decisões de design que deveriam ser facilmente tomadas precisam ser escaladas para a gestão, o que acaba gerando ainda mais desgaste – quando não há politicagem – atrasos e posterior pressa para implementar o design decidido.

E por esta razão, acredito que organizações hoje tenham chegado a um nível de maturidade onde já enxergam a necessidade e os benefícios da adoção das disciplinas de arquitetura, porém, ainda precisam evoluir para um próximo nível, onde estarão aptas a de fato empregar eficientemente tais áreas em seus projetos.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *