Build vs buy para consultar infracciones de una flota
Construir integra control y costos de mantenimiento; comprar acelera cobertura pero agrega dependencia. La decisión mejora cuando se evalúa evidencia, seguridad, salida y resultados parciales.
Por Marco Ferreiro ·
Una flota que necesita consultar infracciones puede desarrollar conexiones propias, contratar una API o combinar ambos enfoques. La comparación suele reducirse al precio por consulta frente a horas de programación. Ese cálculo deja afuera lo más caro: mantener cobertura, interpretar fallas y operar el servicio durante años.
“Build vs buy” es una decisión sobre ciclo de vida, no sobre una llamada HTTP.
Definí la capacidad antes de comparar soluciones
Escribí qué problema debe resolver la empresa:
- jurisdicciones y tipos de vehículo;
- consulta por patente, persona o ambos;
- frecuencia y ventana de procesamiento;
- uso operativo del resultado;
- tolerancia a respuestas parciales;
- retención y auditoría;
- volumen normal y picos;
- plazo para incorporar una fuente nueva.
Una API rápida que cubre pocas fuentes no compite con una solución más lenta pero adecuada al recorrido de la flota. Tampoco todas las consultas necesitan la misma criticidad: una alerta mensual no tiene el mismo presupuesto de tiempo que aprobar la recepción de un usado.
Qué implica construir
El desarrollo interno ofrece control sobre reglas, despliegues y datos. El equipo puede priorizar sus jurisdicciones, integrar con el maestro de vehículos y adaptar la experiencia de operación.
Pero el alcance real incluye:
- descubrir y verificar fuentes oficiales;
- implementar accesos y cambios de formato;
- manejar desafíos, límites y caídas;
- normalizar sin perder procedencia;
- evitar duplicados;
- mantener seguridad y observabilidad;
- responder incidentes y cambios normativos;
- documentar resultados parciales.
El costo continúa después del lanzamiento. Cada portal externo es una dependencia aunque no exista contrato con él. Si cambia sin aviso, alguien debe detectarlo, distinguir un cero de un error y actualizar la integración.
Qué implica comprar
Un proveedor puede concentrar esa especialización y reducir el tiempo inicial. La empresa recibe un contrato estable, soporte y una sola integración. A cambio, incorpora dependencia técnica, contractual y de cadena de suministro.
La guía NIST para riesgo de proveedores recomienda establecer y comunicar requisitos, evaluar dependencias y monitorear el desempeño. Para una API de infracciones eso se traduce en preguntas concretas:
- ¿cómo demuestra que una fuente es oficial?
- ¿qué estados informa cuando una fuente falla?
- ¿cómo versiona cambios de esquema?
- ¿qué datos conserva y dónde?
- ¿cómo notifica incidentes?
- ¿qué sucede al terminar el contrato?
Comprar no transfiere la responsabilidad de interpretar el resultado. La flota sigue decidiendo si un parcial habilita o bloquea un proceso.
Compará costo total y no sólo tarifa
Para construir, incluí personas de desarrollo, producto, seguridad, soporte y cumplimiento; infraestructura; pruebas; guardias; mantenimiento y costo de oportunidad. Para comprar, sumá consumo, mínimos, implementación, revisión de proveedor, soporte interno, contingencia y migración futura.
Medí en un horizonte común. Un desarrollo inicial barato puede acumular mantenimiento; un proveedor conveniente puede cambiar precio o dejar una fuente. No inventes una precisión financiera imposible: documentá supuestos y hacé análisis de sensibilidad.
Exigí un contrato observable
OpenAPI permite describir operaciones, esquemas y respuestas esperadas. Pedí ejemplos de consulta completa con y sin actas, parcial y fallida. RFC 9457 aporta una estructura estándar para errores accionables sin exponer detalles internos.
El DTO debería incluir procedencia, fecha de verificación y estado por fuente. Una lista vacía no debe representar un timeout. También necesitás identificadores idempotentes o mecanismos equivalentes para que un reintento no duplique alertas y costos sin control.
Los cambios incompatibles requieren versión y ventana de migración. Probá el cliente contra esquemas, no sólo contra ejemplos felices.
Privacidad y seguridad son criterios de producto
La Ley 25.326 exige datos adecuados, pertinentes, exactos y protegidos. Verificá finalidad, acceso, cifrado, retención, subencargados, respuesta ante incidentes y eliminación al finalizar.
Una prueba no debería usar una exportación completa de la flota si alcanza un conjunto controlado y autorizado. Los logs no deben guardar patentes, DNI o cuerpos de terceros indiscriminadamente. Separá identificadores para soporte de datos visibles para el usuario.
Diseñá una prueba de concepto que pueda fallar
No evalúes sólo consultas con resultados conocidos. Incluí:
- patente válida sin actas informadas;
- varias actas parecidas;
- fuente caída o lenta;
- cambio de estado después de un reintento;
- volumen sostenido y pico;
- revocación de credenciales;
- exportación y borrado al cierre.
Definí por adelantado qué se medirá: fuentes completadas, latencia, consistencia, trazabilidad y facilidad de operación. No conviertas parciales en completos para mejorar una tasa.
El modelo híbrido
Una alternativa frecuente es contratar la adquisición y normalización, mientras la empresa conserva el maestro de vehículos, reglas de negocio, conciliación y experiencia del usuario. También puede mantener una verificación oficial directa para procesos críticos.
El modelo híbrido reduce desarrollo especializado sin ceder toda la lógica. Requiere límites claros para no terminar pagando y manteniendo dos soluciones completas.
Prepará la salida desde el inicio
Documentá cómo exportar historial, estados, evidencias y configuración; qué datos serán eliminados; cuánto tarda la transición; y qué ocurre si una fuente crítica deja de estar disponible. Evitá que identificadores propietarios sean la única forma de reconocer un caso.
La mejor elección no es universal. Es la que puede demostrar cobertura, costo y riesgo para los recorridos reales de la flota, comunicar lo que no sabe y seguir operando cuando cambian una fuente o un proveedor.
Metodología
- Alcance
- Marco de decisión tecnológica y operativa para consultar infracciones de vehículos de flota mediante desarrollo interno o proveedor externo.
- Unidad de análisis
- Una capacidad de consulta con fuentes, contrato de API, operación, datos, personas, costos y riesgos durante todo su ciclo de vida.
- Cobertura
- Interoperabilidad, manejo de errores, privacidad y riesgo de terceros; no presenta precios ni disponibilidad de proveedores concretos.
Limitaciones
- El costo total depende del volumen, jurisdicciones, frecuencia, criticidad y capacidades existentes de cada organización.
- Una prueba técnica no reemplaza la revisión contractual, legal, de seguridad y continuidad del negocio.
Fuentes
- OpenAPI Specification 3.1.2 — OpenAPI Initiative (consultada el )
- RFC 9457 — Problem Details for HTTP APIs — RFC Editor (consultada el )
- NIST Cybersecurity Framework guidance for supply chains — National Institute of Standards and Technology (consultada el )
- Ley 25.326 de Protección de los Datos Personales — Argentina.gob.ar (consultada el )
Preguntas frecuentes
¿Comprar una API elimina todo el trabajo técnico interno?
No. La empresa sigue necesitando integrar, controlar accesos, interpretar parciales, conciliar resultados, atender excepciones y supervisar al proveedor durante todo el ciclo de vida.
¿Construir internamente garantiza más cobertura?
No. Da control sobre la implementación, pero cada jurisdicción requiere mantenimiento, monitoreo y validación continuos. La cobertura debe probarse con una matriz y casos reales autorizados.
¿Qué debería exigir una prueba de concepto?
Un contrato de datos documentado, estados por fuente, evidencia de procedencia, pruebas de fallas, seguridad, límites, tiempos de actualización y un método reproducible para medir cobertura sin usar datos innecesarios.
Notas relacionadas
Cobertura de una API: cómo comunicar fuentes caídas y resultados parciales
Una integración de infracciones necesita informar qué fuentes respondió, cuáles fallaron y si el resultado es completo. Un cero sin cobertura comprobada puede inducir decisiones incorrectas.
Timeout no significa “sin multas”: cómo informar resultados parciales en una integración
Cuando una fuente no responde, el resultado es parcial o indeterminado, nunca cero. Un contrato explícito permite reintentar, alertar y decidir sin producir falsos negativos.
Polling de consultas sin saturar la API: Retry-After, ETag y espera con jitter
Consultar el estado cada segundo no hace que una búsqueda termine antes. Un contrato con Retry-After, ETag y una espera aleatoria reduce solicitudes repetidas, bytes y picos de clientes sincronizados.