El camino del socio a las API públicas

 Hay muchas vías para la creación y el diseño de API. Algunas empresas pueden comenzar con API privadas y luego hacerlas públicas (pero esto es raro). Otros pueden saltar directamente y comenzar a crear una API abierta (pública) (esta es a menudo la norma).

Pero un camino hacia la creación de API no se explora con tanta frecuencia, pero puede parecer más natural para las empresas establecidas y no puramente lúdicas. Este camino es comenzar con una API de socio y, cuando la empresa se sienta lo suficientemente segura, tal vez abrirla como una API abierta (o pública). Hablamos con Peter Jervgen, director de estrategia y arquitectura en las oficinas suecas de la compañía energética internacional 

E.ON , y Marjukka Niinioja, consultora senior y gerente de la startup finlandesa PlanMill. para obtener información sobre cómo las empresas están pasando de las API de socios a las API públicas. Si bien ambas empresas tienen una presencia en línea significativa (con PlanMill incluso como un producto de software como servicio), también están firmemente arraigadas en el trabajo en sectores comerciales más tradicionales, donde sus socios y clientes pueden no ser tan API. versado en.

Marjukka también hablará en nuestro evento de Helsinki donde, dice, “Voy a contar cómo hemos hecho las cosas con nuestra API actual y cómo estamos en el proceso de renovación de la API. También voy a discutir el lado organizacional de las cosas: cómo cambiar las ventas, el servicio al cliente y los consultores a ventas de API, servicio al cliente de API y consultores de API. Luego, incluyo algunos problemas de integración que tenemos, o no hemos resuelto, con nuestra API y por qué, cosas como integraciones de facturas y contabilidad con sistemas financieros. Y, si tenemos tiempo, compartiré algunas ideas sobre cómo diseñar una API utilizable (en lugar de concentrarme en dónde colocar el campo de entrada o el botón en la interfaz de usuario) ".

Comenzando con las API de socios

En una conversación anterior con Mark O'Neill, vicepresidente de innovación de Axway , señaló que un camino estratégico que tiene mucho sentido para las empresas que comienzan con API es comenzar con la fruta más fácil que mejore las relaciones con los socios. Esto a menudo incluye hacer que los datos del catálogo de precios estén disponibles a través de API, o permitir el acceso a procesos como información de pedidos y envíos a través de API para que los socios puedan buscar los detalles de sus pedidos ellos mismos, todo a través de su API. El punto de vista de Mark es que una vez que estas API funcionan bien con los socios, también son ideales para luego abrirse como API más públicas.

Ronnie Mitra de Layer 7 tuvo un comentario similar . Insta a las empresas a asegurarse de que la infraestructura básica esté en su lugar, y construida con los principios de las mejores prácticas en mente, para las API de socios (cosas como una puerta de enlace de seguridad de API, un portal para desarrolladores y una instancia de API), de modo que si una empresa decide abrir de forma más amplia, son lo suficientemente robustos y seguros para que los desarrolladores de terceros puedan acceder a ellos y utilizarlos.

“Nombrar nuestra API como la API abierta de PlanMill fue una de las señales de ser un 'desarrollador de API accidental'” , nos dijo Marjukka (este es también el nombre de su presentación en las API nórdicas ). “La 'API abierta' no era realmente un concepto claro hace 5 años y el concepto de público versus privado es un poco problemático cuando nuestro cliente posee los datos dentro de su sistema PlanMill y decide con quién quiere jugar, incluso si decimos nuestra API está abierta para que cualquiera pueda crear una integración ".

PlanMill es una plataforma de software como servicio de servicios empresariales con componentes como CRM, facturación y gestión de proyectos. Por lo tanto, los clientes almacenan muchos de sus datos comerciales en el sistema.

“Si es nuestro cliente, puede utilizar nuestra API de forma gratuita o casi gratuita para conectarse a cualquiera de sus propios sistemas o sistemas de terceros. También puede dar acceso a cualquiera de sus clientes y socios para acceder a su sistema a través de la API. También permitimos que los socios y las empresas en las que estamos interesados ​​en convertirse en nuestros socios utilicen la API ”, explica Marjukka.

Para la empresa de energía y servicios públicos E.ON, Peter Jervgen dice que recién están comenzando con las API de socios, pero tienen una 'API semiabierta' en la mira. "Por el momento, nos estamos centrando en las API internas y de socios", nos dijo Peter. “Sin embargo, E.ON reconoce el empoderamiento del usuario que viene con las API abiertas. E.ON quiere que los clientes y socios participen en el futuro de Energy Solutions. Pero, el aumento hacia API abiertas se realizará de forma controlada y de acuerdo con las directivas de la estrategia empresarial de E.ON ".

Decidir qué API pasar de socio a público

En ambos casos de estudio, las empresas han comenzado con API de socios y, a medida que aprenden cómo implementar y administrar la API con algunos integradores externos, avanzan hacia una apertura más amplia como API públicas.

PlanMill es particularmente interesante en este sentido. Una de las razones clave por las que las empresas ofrecen una API pública (abierta) es permitir que los desarrolladores externos creen nuevas aplicaciones y soluciones de integración que permitan al proveedor de API ingresar a nuevos mercados de clientes. Al trabajar primero con su red de socios comerciales, PlanMill ha terminado con un conjunto de aplicaciones de terceros que los ayudan a conectarse con nuevos mercados y, en algunos casos, a compartir los ingresos de ingresar a esos mercados con sus socios. Luego, la infraestructura se prueba y se coloca a medida que PlanMill abre el acceso a la API a los desarrolladores con los que aún no tienen una relación existente.

“Dejar que los socios y clientes creen integraciones ellos mismos con muy poca participación de nosotros hubiera sido totalmente imposible de otra manera”, dice Marjukka. “Por ejemplo, la integración con Confluence wiki de Atlassian o Jira fue realizada principalmente por nuestro cliente Ambientia y estamos vendiendo la integración de Confluence juntos. Además, pudimos brindarle a Administer Oy la posibilidad de codificar la integración de facturas de compra con PlanMill, y nuestro cliente Futurice creó una aplicación móvil y una interfaz de usuario (FutuHours) de informe de tiempo completo sobre nuestra API. En términos de externalizar el desarrollo y acortar el tiempo para desarrollar cosas, una API es imprescindible. Las integraciones en tiempo real simplemente no se pueden realizar con una importación o exportación de archivos ".

E.ON piensa en líneas similares. A nivel mundial, en el último trimestre de 2013, las empresas de energía y servicios públicos fueron el sector de más rápido crecimiento en la creación de aplicaciones móviles que enrutaban datos sobre el consumo y el uso de energía desde sus API. “Creemos que 'Home Energy Management' y 'Smart Cities' son dos ejemplos en los que podemos esperar que aparezcan pronto API abiertas”, confirma Peter. "Esto también está de acuerdo con la ambición de E.ON de mantenerse a la vanguardia en términos de inversiones para mantener nuestro planeta y el clima sostenibles".

API abiertas: utilice los flujos de trabajo de su empresa para lograr el éxito

Una característica que tanto PlanMill como E.ON enfatizan al crear API abiertas es tener claridad sobre los flujos de trabajo y la lógica empresarial. En muchos casos, puede ser más fácil resolver estas preguntas cuando primero se crea una API con socios, de modo que cuando llegue a una audiencia más pública, tenga la seguridad de que es sólida.

“El primer pensamiento [en nuestro negocio] cuando hablamos de API es que es algo tecnológico y solo una capa de integración”, compartió Marjukka con nosotros. “Para muchos usuarios y gerentes comerciales, ha sido realmente difícil pensar en ello desde la perspectiva de los requisitos comerciales”.

“Muchas veces, recibimos una solicitud de una empresa cliente relacionada con nuestra API donde un desarrollador (generalmente recién salido de la escuela o haciendo su tesis) se le ha encomendado la tarea de 'obtener nuestros informes de tiempo y las cosas XYZ integradas entre PlanMill y nuestro Sistema X '. Comienzan a abordarlo como una tarea de programación únicamente y luego se dan cuenta de que necesitan saber realmente un poco de qué es el proceso, dónde, cuándo, cómo se crean, editan y eliminan las cosas y, por ejemplo, qué sistema es el maestro de los datos? Esto nos lleva a la cuestión de todo el proceso empresarial ".

Al usar primero las API de socios, una empresa también puede familiarizarse con los requisitos de soporte que pueden ser necesarios para administrar si lanza la API de manera más pública. “Ha sido, y sigue siendo, una gran experiencia de aprendizaje internamente sobre cómo respaldar, consultar y vender la API porque es muy diferente de nuestros productos base con interfaces de usuario”, dijo Marjukka. "Más el desarrollo: recordar que todas las comprobaciones de la lógica empresarial realizadas en la interfaz de usuario también deben realizarse en el backend, porque hay que comprobar la integridad de los datos".

Peter está de acuerdo. “Intentamos desde el principio introducir la gestión del ciclo de vida para las API implementadas. Creemos que se puede obtener mucha competencia y experiencia adoptando las mejores prácticas ya presentes en la organización de línea actual dentro de E.ON IT. La unidad maneja los servicios de TI a nivel macro de acuerdo con el marco de ITIL, donde los acuerdos de nivel de servicio, la liberación y la gestión de cambios son ingredientes fundamentales ".

Pasar a API abiertas

PlanMill actualmente está pensando en los 'qué pasaría si' que se han vuelto más concretos ahora que han comenzado su viaje de API. "Estamos explorando posibilidades para abrir parte de nuestra localización y otros datos más al público, a clientes que de otra manera no son usuarios de PlanMill, aunque requeriremos registro y probablemente una cierta cantidad de tarifas, posiblemente según el uso".

E.ON está trasladando las API de sus socios a un tipo de acceso semipúblico: “Creemos que comenzaremos a introducir API semiabiertas para grandes clientes y cuentas clave. Estas categorías de clientes suelen tener una estrecha asociación con E.ON, por lo que puede haber una fructífera situación de "toma y daca". Todas las partes pueden beneficiarse de un estilo de desarrollo ágil y refactorial. E.ON también participa en la iniciativa de la UE Finesce que tiene como objetivo la Internet del futuro para la energía inteligente, incluida la comunicación de máquina a máquina (M2M) y la Internet de las cosas ".

Pero como cualquier empresa que abre sus API, E.ON señala una discusión que esperamos ayudar a resolver con nuestras agendas para la próxima gira de las API nórdicas: “Nuestras consideraciones clave están relacionadas con la seguridad y los derechos de propiedad intelectual. Dado que las futuras soluciones de energía de E.ON incluirán más servicios relacionados con TI y muchos de estos servicios serán agregados de servicios de terceros, E.ON necesita garantizar que las API expuestas sean sólidas, seguras y no violen ningún acuerdo comercial ".

Esperamos continuar esta conversación sobre el papel de las API públicas, privadas y de socios, y ayudar a las empresas a navegar por un camino exitoso a medida que abren cada vez más sus datos y capacidades a través de API. Únase a nosotros en Estocolmo , Copenhague , Helsinki y Oslo en las API nórdicas la semana que viene.