Evolución y desarrollo inicial del software
En la era del desarrollo de software, entre 1980 y 1990, las herramientas y arquitecturas utilizadas por los desarrolladores dificultaban el intercambio eficaz de código. El uso de funciones y procedimientos evolucionó hacia construcciones orientadas a objetos que ayudaron a los desarrolladores a pensar en las soluciones que estaban desarrollando como una serie de objetos unidos entre sí. Estos objetos construían la solución y mejoraban la capacidad de compartir código.
Con el tiempo, este concepto evolucionó hacia la Arquitectura Orientada a Servicios. Estas Arquitecturas Orientadas a Servicios no sólo creaban construcciones autónomas, sino que también facilitaban el acceso desde otros sistemas que querían utilizar la funcionalidad.
Los conceptos han seguido evolucionando hasta convertirse en arquitecturas de microservicios que han simplificado el despliegue y la gestión de los bloques de construcción de la solución. En conjunto, permiten una arquitectura en la que los desarrolladores pueden incorporar nuevos componentes a su solución de forma fácil y segura.
A medida que las arquitecturas evolucionaban para promover una reutilización del código mejor, más flexible y segura, la mentalidad de los desarrolladores respecto a compartir su código ha evolucionado y madurado.Los desarrolladores mantenían su código en secreto, llegando incluso a ofuscarlo para evitar que otros utilizaran lo que ellos habían creado.
A medida que se fue aceptando el código modular, los desarrolladores empezaron a presionarse mutuamente para crear código reutilizable. Los desarrolladores se sintieron cómodos con otros desarrolladores de su organización que creaban a partir de su código y lo mejoraban.Este cambio de mentalidad dio lugar a la participación en código de fuente abierta, pero sobre todo sólo para proyectos favoritos, no para código de verdadera calidad de producción, y no se practicaba para código comercial.
A medida que las arquitecturas permitieron técnicas más eficaces para compartir, los desarrolladores (y sus organizaciones) empezaron a sentirse cómodos aprovechando el código de fuente abierta. Hoy en día, algunas de las mayores empresas de desarrollo de software comercial no sólo comparten su código abiertamente, sino que a menudo hacen grandes contribuciones a la comunidad de código abierto y aprovechan las aportaciones de la comunidad para ampliar las capacidades de sus soluciones.
Maduración y cambio de mentalidad en el desarrollo de software
La madurez de las arquitecturas ha ido de la mano de la madurez de la profesión de desarrollador.Esto ha provocado un cambio fundamental en el debate comprar frente a construir.
En décadas anteriores, los desarrolladores podían considerar el uso de un marco para proporcionar funcionalidad clave dentro de su solución.Algunos equipos de desarrollo consideraban la posibilidad de comprar una solución e integrarse con ella para proporcionar la funcionalidad que necesitaban. Esta mentalidad de "comprar en lugar de construir" se consideraba una buena alternativa.
Sin embargo, a menudo generaba costes significativos cuando la solución evolucionaba y cambiaba drásticamente. Esto hacía que el equipo de desarrollo dedicara una gran cantidad de tiempo a mantener su solución funcionando con la solución subyacente, en lugar de dedicar tiempo a crear las funciones que su empresa necesitaba.
A medida que la disciplina de desarrollo de software ha evolucionado, también lo han hecho los enfoques de comprar frente a construir.Más allá de los marcos de trabajo, las soluciones actuales abarcan ofertas de servicios, soluciones SaaS, plataformas y combinaciones de cada una de ellas (Salesforce Platform, Microsoft Dynamics 365, etc.).
Con la facilidad de integración de las soluciones basadas en la nube, la cuestión de comprar o crear ya no es una decisión binaria.Más bien, es una decisión basada en qué partes de su sistema desea comprar y en qué partes debe gastar capital.
Improving ayuda regularmente a sus clientes a resolver estas cuestiones. Hemos visto que los equipos que adoptan arquitecturas de microservicios son mucho más eficaces a la hora de integrar en sus soluciones las capacidades de las soluciones basadas en la nube.
Tener la experiencia de dividir una solución en componentes clave permite a estos equipos identificar las partes de su sistema que pueden ser proporcionadas eficazmente por soluciones ya construidas.De este modo, los equipos pueden centrar su tiempo en los valores empresariales clave de su solución y desarrollar código que sea realmente un diferenciador para su empresa.
Soluciones de software modernas
En Improving, hemos visto a algunos clientes luchar con los detalles de la solución de terceros que eligen integrar.Con demasiada frecuencia, los equipos de desarrollo se obsesionan con la forma en que la solución proporciona sus capacidades y empiezan a buscar formas de trabajar en torno a ella.
Es importante que los equipos se centren en lo que proporciona la solución, no en cómo lo hace. Si le preocupa específicamente el "cómo" de la solución (por ejemplo, cuestiones de seguridad especiales), no espere que el proveedor haga cambios en la solución para satisfacer sus necesidades. En su lugar, busque otras soluciones que satisfagan sus requisitos de "cómo".
No dedique mucho tiempo de desarrollo a intentar solucionar el "cómo". Si no puede aceptar su funcionamiento, busque otro proveedor o reevalúe si el "cómo" es realmente importante para su solución. En algunos casos, este "cómo" puede ser su salsa secreta: los aspectos que hacen que su empresa sea diferente de las demás y la razón por la que debe construirla.
Resumen: ¿Construir o comprar? Las dos cosas.
La tecnología en la nube y las arquitecturas de microservicios han simplificado la decisión de comprar o construir. Estos cambios han permitido a los equipos de desarrollo integrar soluciones de forma eficaz.
En el mundo actual en el que prima la nube, los desarrolladores a menudo se ven empujados a una estrategia de compra Y creación. Los equipos de desarrollo que buscan proporcionar valor empresarial deben ser expertos en identificar dónde deben centrar sus esfuerzos para desarrollar código personalizado.
Cuando tiene más sentido comprar e integrar una solución de terceros en su propia solución, los equipos de desarrollo deben tomar buenas decisiones sobre las soluciones de terceros que se utilizan.
Si su equipo de desarrollo aún no está aprovechando la tecnología de nube o las arquitecturas de microservicios, Improving puede ayudarle a adquirir destreza, para que sus equipos puedan utilizar la estrategia de comprar y crear en lugar de tomar una decisión binaria sobre comprar o crear. Póngase en contacto con nosotros hoy mismo para empezar con su próxima solución de software moderna
