¿Qué dice su tecnología sobre su negocio?
Publicado: 2021-12-22
Las corporaciones se esfuerzan regularmente por ser mejores con mucha más innovación y ganancias financieras. Al identificar posibles problemas empresariales, las empresas generalmente apuntarán a la imagen más grande, mirando a la empresa como una mirada completa y lenta hacia adentro. De hecho, comenzar en la maleza con las tecnologías de la compañía puede ofrecer un conocimiento mucho más amplio, completo y más profundo de esa fotografía más grande.
Con empresas que evolucionan rápidamente a raíz de la pandemia e intentan tareas de transformación electrónica, con una proporción significativa que no puede terminarlas correctamente, es importante estar familiarizado con cómo las conclusiones que ha diseñado con su tecnología ayudarán o dificultarán desarrollo.
¿Qué podemos saber específicamente de una empresa a partir de su innovación tecnológica?
La forma en que los grupos se reúnen, interactúan y actúan entre sí puede tener un profundo impacto en el estilo restante de su mercancía. Nos referimos a esto como la Regulación de Conway: la construcción de software reflejará inadvertidamente el modelo de interacción de la fuerza laboral que lo desarrolló. Podría decirse que el negocio de la corporación es el principal factor a tener en cuenta al planificar un producto o servicio.
Los procedimientos y la arquitectura organizacionales están intrínsecamente conectados, lo que indica que se impactan y limitan entre sí. Debemos tener esto en cuenta al diagnosticar cualquier posible problema que surja y utilizar ese conocimiento para lograr conocimientos esenciales sobre cómo está estructurada la corporación, por qué surgen las dificultades y cómo podemos superarlas. Si su fuerza laboral de ingeniería no está logrando sus objetivos, podría valer la pena examinar cómo se organiza el equipo y qué puede significar esto necesariamente para obtener los resultados deseados.
Arquitectura monolítica vs microservicios
Hay varias construcciones de arquitectura distintas que se pueden generar dependiendo de cómo se organicen los grupos. Es muy probable que los grupos pequeños y distribuidos generen una arquitectura modular centrada en microservicios. Si el equipo es más grande y no está alineado con partes de la arquitectura del elemento, es probable que hagan una arquitectura monolítica. La arquitectura monolítica es familiar para muchos, ya que los programas de TI comunes o los propósitos de la empresa generalmente se crean de esta manera. Para variedades igualmente de arquitectura, existen importantes fortalezas y desventajas que deben tenerse en cuenta.
Para las empresas que se han embarcado en trabajos de transformación digital, parte del proyecto puede ser separar aplicaciones monolíticas heredadas en favor de microservicios nuevos y modernos. Hay fortalezas significativas en esta variedad de diseño, ya que permitirá una mayor flexibilidad general para implementar ajustes sin interrupciones y puede ayudar a mejorar la escalabilidad. Aun así, la arquitectura monolítica es considerablemente menos complicada de emplear e implementar. Por lo general, esto lo convertiría en el mayor favorito para el desarrollo de aplicaciones más pequeñas y simples, y generalmente se descubre en las primeras etapas de puesta en marcha. A diferencia de los microservicios, la arquitectura monolítica es más difícil de escalar porque el trabajo exige alinearse entre grupos distintos con muchos objetivos. Obtener la composición del personal completamente incorrecta podría ralentizar el proceso de diseño y provocar mayores desafíos en el futuro.
La implementación próspera o infructuosa de la arquitectura de microservicios de una organización revela mucho sobre las conclusiones que han diseñado y si hay algún problema arraigado con la estructura de comunicaciones en el negocio. Al considerar si tiene que dividir un monolito y cambiar a la arquitectura de microservicios, es esencial asegurarse de que la anatomía de su empresa ayudará a cualquier arquitectura que elija.
hinchazón de asistencia
En algunas condiciones, es posible que se descubra que la cantidad de microservicios es mayor que la variedad de ingenieros. Esto se conoce como aumento de la asistencia, lo cual es problemático, porque provocará una disminución de la velocidad y la disponibilidad del desarrollador. Esta es una explicación importante de por qué es arriesgado construir microservicios sin una estructura muy cuidadosa y garantizar que la construcción del equipo respalde este enfoque.
El exceso de asistencia es una señal de que el equipo no ha aplicado una lente arquitectónica considerada: muestra que hay poco conocimiento de cómo todos y cada uno de los servicios dependen del otro. Esto normalmente dará como resultado anti-estilos de microservicios que disminuirán la disponibilidad y provocarán retrasos al intentar implementar nuevas funciones. Preferiblemente, a ninguna organización le gustaría terminar en esta condición.
Realización de un paseo por la arquitectura
Además de tomar nota de la anatomía organizacional y los efectos que esto tiene en la arquitectura, también es crucial evaluar cómo se conecta todo para reconocer los resultados de raíz de posibles problemas con su producto. Para ello, realiza un sencillo paseo de arquitectura. Para realizar un paseo por la arquitectura, deberá observar cómo está conectado todo desde el dispositivo o el software, hasta el nivel de datos y nuevamente con la respuesta. Hay un par de cosas importantes a tener en cuenta al realizar un paseo por la arquitectura:
- Es importante buscar puntos solitarios de falla, servicios que dependen unos de otros a la hora de operar y componentes que no crecerán con una necesidad elevada.
- Considere el estado: esto incluye analizar dónde se almacenan los datos de una sesión a otra que involucre a personas y cómo se conservan esos datos.
- Esté atento a las grandes bases de datos que no están fragmentadas y a las llamadas que se fabrican en todas las ubicaciones como parte de una nube pública o centros de información autohospedados.
- Busque el uso de la plataforma como servicio (PaaS) o las bases de datos en la nube como soporte (DBaaS) donde las fallas de la nube pública crean llamadas telefónicas entre regiones.
Todos los factores anteriores son solo algunas partes que deben tenerse en cuenta para remediar cualquier obstáculo potencial con sus productos. El momento para emplear realmente solo debe tener en cuenta tanto las características como las necesidades de la arquitectura para un éxito ideal factible.
¿Qué deben saber los ingenieros de productos sénior sobre esto?
Un enfoque para los líderes senior de ingeniería de productos debe ser asegurarse de que la organización de la escalabilidad y la disponibilidad y el inventario complejo de la deuda financiera se lleven a cabo sobre una base común para solucionar posibles problemas antes de que surjan. Un arquitecto de soluciones o un pequeño grupo de ingenieros sénior debe establecer reglas que los equipos de productos puedan usar para diseñar y diseñar para el nivel correcto de escala y alta disponibilidad.
Se pueden utilizar instrumentos como CodeScene para detectar dependencias entre proveedores y ayudar a resolver problemas de stock en el comportamiento del código base. El soporte de beneficios para notificar la acumulación de requerimientos de refactorización y deuda de tarjeta de crédito especializada.
Con las necesidades de las empresas en constante evolución para alinearse con un sector tecnológico en rápido desarrollo, es de vital importancia tener un conocimiento sólido de lo que sus conocimientos tecnológicos revelan sobre las opciones anteriores. Estos aprendizajes se pueden utilizar para detectar y evitar que ocurran fallas muy similares en el futuro, así como para ayudar a su grupo a comprender cómo su diseño grupal se puede aplicar como una herramienta para ayudar a alcanzar objetivos y alcanzar nuevas alturas.
Dave Berardi, esposo o esposa, AKF Partners