Hay buenos argumentos a favor de departamentos de tecnología corporativos tanto centralizados como descentralizados. Sin embargo, las tendencias recientes pueden indicar que es hora de una menor centralización.
El surgimiento de un departamento de TI en muchas organizaciones en las décadas de 1980 y 1990 indicó que una función tecnológica centralizada para toda la empresa era la forma "correcta" de implementar y gestionar la tecnología en la mayoría de las organizaciones. La tecnología era generalmente costosa y compleja y la mayoría de los trabajadores de esta época no crecieron utilizando la tecnología en su vida cotidiana.
En muchos casos, las cajas beige que caían sobre sus escritorios eran una adición no deseada o mal tolerada. Por supuesto, sería mejor dejar su funcionamiento interno y el software que contiene a expertos de otro departamento.
A medida que las nuevas generaciones ingresaron a la fuerza laboral y aportaron experiencia tecnológica adicional, las funciones tecnológicas centralizadas en la mayoría de las organizaciones continuaron. La adquisición de hardware se benefició de la centralización, mientras que la adquisición de experiencia en desarrollo de aplicaciones siguió siendo demasiado compleja y desafiante para la mayoría de las líneas de negocios.
Asimismo, en la mayoría de las empresas se estaba dando un amplio impulso a la estandarización . Los departamentos de TI se han convertido en “talleres Dell” u “talleres Oracle” y utilizan un conjunto limitado de hardware y software para impulsar la interoperabilidad y reducir costos. Dado que el desarrollo y el mantenimiento de software suponen un gasto tan importante, un pequeño grupo de expertos en un puñado de herramientas facilitó la adquisición de nuevas herramientas.
Más recientemente, el deseo de estandarización y reducción de costos ha apuntalado el argumento comercial a favor de la centralización. Áreas costosas y complejas, como la ciberseguridad, se benefician tanto técnicamente como financieramente de una gestión centralizada. Muchos líderes tecnológicos también han aplicado estos supuestos a su enfoque de desarrollo de aplicaciones, tratando de reunir y gestionar a los tecnólogos de la empresa para ejercer control sobre los estándares de la empresa y reducir costos.
API y cuellos de botella: el caso de la descentralización
Si bien reducir costos y promover estándares comunes son esfuerzos nobles, la TI se ha convertido en un cuello de botella para la innovación en muchas organizaciones. Después de que le dijeran que TI ejecutaría con gusto su solicitud de crear una nueva aplicación orientada al cliente después de que el grupo apropiado resolviera su trabajo pendiente de 18 meses, el líder de una unidad de negocios con la que trabajé bromeó diciendo: “Ahí es donde morirán los sueños. "
Además, uno de los mayores impulsores de la tecnología centralizada se ha vuelto esencialmente obsoleto. Durante años, un pilar del argumento de la centralización fue que permitía aplicar estándares comunes a cómo se desarrollaban las aplicaciones, qué conjuntos de herramientas se utilizaban y cómo se soportaban.
Este era un objetivo noble en una época en la que el software y el hardware rara vez funcionaban juntos, incluso cuando se compraban al mismo proveedor, y los esfuerzos de integración eran costosos y consumían mucho tiempo. El auge de las API RESTful ha eliminado en gran medida la preocupación por el software moderno, permitiendo que las aplicaciones y servicios se comuniquen a través de interfaces estándar independientemente de la tecnología subyacente.
Así como cualquier cosa, desde un dron de consumo hasta una herramienta de diagnóstico industrial, puede conectarse a una computadora portátil a través del ahora omnipresente puerto USB, diversas tecnologías y aplicaciones pueden interoperar a través de una interfaz común.
Con esta técnica, TI ya no es un guardián del desarrollo tecnológico y ahora puede asumir el papel de consultor estratégico.
Catálogos de servicios centralizados, no gestión centralizada
Quizás la innovación técnica más significativa en empresas como Amazon haya sido la explotación de esta interoperabilidad hasta un nivel extremo. A medida que Amazon crecía, sus líderes tecnológicos contrarrestaron la tendencia hacia la estandarización en un conjunto limitado de proveedores de tecnología. En cambio, la empresa insistió en que cualquier tecnología nueva proporcione una colección publicada de interfaces .
Inicialmente, esta decisión política permitió a las unidades de negocios de Amazon tomar sus propias decisiones técnicas, siempre y cuando proporcionaran una interfaz bien documentada y la mantuvieran a medida que evolucionaba. En última instancia, este enfoque se centra en las interfaces estándar en lugar de en la tecnología común integrada en Amazon Web Services.
Hoy en día, las empresas no necesitan tener la sofisticación o el presupuesto del nivel de Amazon para beneficiarse de la creación de servicios tecnológicos con interfaces estándar. Este cambio permite que las unidades de negocios individuales diseñen e implementen servicios que mejor satisfagan sus necesidades comerciales, al mismo tiempo que brindan puntos de integración en la organización más grande.
Estas unidades pueden adquirir experiencia técnica o aprovechar un socio y eliminar el costoso trabajo de hacer que TI seleccione, examine y administre todas las empresas relacionadas con la tecnología. El departamento de tecnología corporativo puede seguir brindando todo tipo de servicios, pero centrarse en la integración ofrece otras opciones para las unidades de negocio y coloca a TI en el papel de facilitador y guía, en lugar de ser un cuello de botella.
La clave del éxito de este cambio es mantener un catálogo centralizado de servicios que exista en toda la organización. Después de todo, probablemente no necesitará que cada unidad de negocio desarrolle sus propios servicios de gestión financiera o que permanezca completamente desconectada de la organización en su conjunto. Proporciona directrices para servicios internos y externos centrándose en aspectos como seguridad, autenticación y validación.
Una vez evaluado y publicado un servicio, TI debe agregarlo a un catálogo de servicios de fácil acceso. Bien hecho, este catálogo sirve como una especie de mercado que permite a cualquier miembro de la organización identificar e integrar la tecnología existente de formas nuevas y útiles. Por ejemplo, si proporciona un servicio de estado de pedido estándar que está bien documentado en un catálogo, su equipo de marketing puede crear una nueva campaña interesante sin ninguna intervención de TI, mientras que su equipo de servicio al cliente puede crear una nueva aplicación de "autoayuda". que utiliza datos de pedidos.
Si es una organización más pequeña, invertir sus escasos recursos en proporcionar un catálogo de servicios y ayudar a socios seleccionados a crear nuevos servicios multiplica su valor significativamente . Un desarrollador de software junior probablemente pueda integrar un conjunto de servicios bien definidos en una nueva herramienta útil mucho más rápido de lo que el mejor equipo del mundo puede empezar desde cero con la recopilación de requisitos, el análisis y la creación de una nueva herramienta.
Si bien muchos líderes tecnológicos se consideran consultores, el cambio hacia el diseño y la construcción descentralizados acelera el proceso. La TI puede pasar de una organización que gestiona recursos escasos y de alta demanda a un centro comercial de servicios prediseñados y orientación experta sobre cómo trabajar con un socio interno o externo para realizar el trabajo.
Si le gustó esto, asegúrese de consultar nuestros otros artículos sobre DevOps.
- Por qué las empresas están adoptando la 'TI como servicio'
- Lo que sus desarrolladores necesitan saber antes de empezar a trabajar con Kubernetes
- ¿Qué es la ingeniería de confiabilidad de sitios web y cómo puede impactar positivamente en DevOps?
- Cómo acelerar el desarrollo de software adoptando la cultura DevOps
- La ola de MLOps (machine learning y Devops)