Las interfaces de programación de aplicaciones, o API, son la forma en que un desarrollador interactúa con el código de otro. Puede ser tan simple como la interfaz de una clase. O podría ser tan compleja como la fachada de una biblioteca, o incluso la API REST del microservicio de un proveedor. Al igual que esa valla, hay un puñado de puntos de entrada aprobados. Y la API hace una clara distinción entre lo que es mío y lo que no lo es. Esto es increíblemente útil, pero también potencialmente limitante. ¿Qué pasa cuando estoy usando la API de otro equipo interno y descubro un error justo después del punto de entrada? Esta API marca una clara distinción entre la mía y la suya. Así que no puedo meter la mano en su patio y arreglarlo... ¿o sí? Después de todo, está claramente en su lado de la valla.
La ingeniería de software depende en gran medida de la abstracción. Tendemos a envolver muchos detalles en cajas metafóricas. Luego interactuamos con esa abstracción/caja de maneras más predecibles. A veces, apilo mis cajas con mis vecinos para construir nuestro fuerte de cajas. Puede ser increíblemente útil con sistemas grandes, pero ¿qué hace con nuestra comunicación? En el ejemplo anterior, la abstracción, también conocida como la valla, me animó a *no* arreglar el fallo y dejárselo a mi vecino. En otro sentido, el diseño de mi sistema fomentaba un patrón de comunicación humana. Es la Ley de Conway ¡trabajando duro! Las organizaciones tienden a desarrollar sistemas que reflejan su propia estructura de comunicación.
Algunas organizaciones cogen este asunto por los cuernos. Amazones un ejemplo. Al hacer que el tema de las API pasara de ser un mero reto de software a un reto de "cómo hacemos negocios", Bezos cambió radicalmente el funcionamiento de su organización. Apócrifamente, ese memorándum sentó las bases del gigante que es AWS. Pero no hace falta que el CEO escriba un memorándum para que su software condicione el futuro de su empresa. Pensemos en los bancos. La mayoría de los bancos actuales siguen ejecutando aplicaciones COBOL de finales de los 70 y los 80. Alrededor de 3 billones de dólares en transacciones diarias tocan esos sistemas hoy en día. Tienen un éxito increíble, pero ese software limita ahora el funcionamiento de la empresa.
Esto revela una nueva pregunta que deberíamos hacernos a la hora de diseñar software. "¿Fomenta esta arquitectura el tipo de comportamientos que necesita la empresa?". Nuestros diseños pueden fomentar una mejor comunicación o dificultarla. ¿Qué significa ser "buenos vecinos" en tu organización? ¿Quieres apoyo mutuo, como con InnerSource Commons? ¿O cree en las vallas sólidas de la API y en una fuerte separación de funciones? Lo que usted entiende por "buenas vallas" le dice lo que usted entiende por "buenos vecinos".
Si desea empezar a construir mejores "vallas" dentro de su organización, unas que fomenten la colaboración eficaz y la agilidad, póngase en contacto con nosotros en Improving. Vamos a crear API que no sólo hagan el trabajo, sino que creen buenos vecinos dentro de su organización. Póngase en contacto con nosotros hoy mismo y empecemos a construir un futuro mejor, API a API.
