Header Ads Widget

Ticker

6/recent/ticker-posts

Estudio de caso: la saga de API de ERP de PlanMill

 

Estudio de caso de API de PlanMill-01

Las API pueden acelerar la arquitectura empresarial antigua, pero para algunas organizaciones puede ser un proceso difícil. Enmascarar un sistema ERP de más de  10 años con una interfaz limpia no es una tarea fácil.

Sintonizando las lecciones de diseño aprendidas a lo largo de las etapas de investigación, desarrollo e implementación, en esta publicación estudiamos un caso que personifica la filosofía mullet in the back . Siga leyendo para saber qué procesos crearon una API fundamental para la asociación y totalmente funcional mientras estudiamos la historia de la API de PlanMill . Desde el desarrollo simultáneo de la interfaz de usuario, comer su propia comida para perros, hasta el razonamiento detrás de decisiones de arquitectura específicas, la consultora senior y gerente Marjukka Niinioja describe a las API nórdicas los detalles esenciales del desarrollo de una API de nivel empresarial desde cero.

¿Qué es un ERP?

planmill-caso-de-estudio-nordic-apis-doerrfeld

PlanMill es una aplicación de planificación de recursos empresariales (ERP) y gestión de relaciones con el cliente (CRM), una plataforma de gestión de proyectos de front-end y back-end en tiempo real para servicios profesionales. La API de PlanMill expone la plataforma ERP de Planmill, lo que permite el intercambio comercial entre varias aplicaciones comerciales para agilizar procesos como contabilidad y CMS. Tal vez debido a su gran peso y al tema orientado a los negocios, los ERP a menudo se consideran bastante aburridos. Según Niinioja:

"Los ERP a menudo se ven como el trineo del abuelo; a menudo son pesados ​​y difíciles de maniobrar"

Las API, por otro lado, son la ola del futuro : son rápidas y ágiles. Entonces, ¿cómo se puede combinar lo aburrido y lo ágil ?

El lanzamiento inicial lento

Como dice Niinioja, la API de PlanMill atravesó un doloroso "proceso de parto": un período de 12 meses de estrés y pruebas. Bastante temprano en el juego de la API, la API de PlanMill 1.0 se originó en 2009. Un lanzamiento muy silencioso funcionó bien, ya que le dio al equipo tiempo para crear documentación útil para desarrolladores , visualizar un modelo de precios , hablar con consultores y obtener una base de usuarios de clientes potenciales . .

Finalmente, algunos de los primeros casos de uso reales ocurrieron internamente, con proyectos más grandes e integraciones de informes de tiempo. A esto le siguió un primer gran caso de uso de API dentro de una aplicación más grande, incluidas mejoras masivas en la API. La primera asociación finalmente se hizo posible (Atlassian Confluence con Ambientia) utilizando la API de PlanMill. Según Niinioja, la presencia de una API se convirtió en un punto de venta inmediato en comparación con los competidores en el espacio ERP.

Vea a Marjukka Niinioja de PlanMill hablar sobre su API en un evento de API nórdicas

Problemas de usabilidad de API

Entonces, ¿qué aprendió el equipo de PlanMill en el camino hacia la versión 1.0? La experiencia del desarrollador es un componente crítico para su estrategia de API, y diseñar la documentación y la funcionalidad de API de una manera que satisfaga las necesidades del usuario es pertinente para el éxito en el espacio de API . Aunque existen ciertos estándares y guías de diseño de API , la implementación real es casi siempre una base única de caso por caso. Lo que PlanMill hizo correctamente fue escuchar las respuestas de sus clientes para mejorar la experiencia general y aumentar la usabilidad.

Como el sistema originalmente entremezclaba muchas funciones con un sistema backend que tenía más de 10 años, surgieron las siguientes preocupaciones de usabilidad en el uso inicial de la API:

  • Llamadas : "¿Por qué debería tomar 5 solicitudes? ¿No puedo consolidar en una sola llamada?"
  • Límites de velocidad : algunos usuarios enviarían 10 solicitudes por ms, bloqueando el sistema.
  • Exposición de backend : había demasiada confianza inicial en el antiguo JavaScript. La lección aprendida es que no todas las ideas son compatibles desde las perspectivas inicial y final.
  • Documentación : no todas las funciones granulares se documentaron inicialmente.
  • Mensajes de error : los usuarios recibían seguimientos de pila como mensajes de error en las respuestas de la API.
  • ID de respuesta : el ID no era la respuesta de lo que se acababa de crear con la API.
Leer más: Cómo las API están evolucionando la comunicación B2B

Proceso mejorado para API 2.0

Para la API versión 2.0, era necesario un proceso de desarrollo nuevo y mejorado. Preparándose para un nuevo ciclo de vida del producto , el equipo de PlanMill realizó una impresionante investigación de clientes para determinar lo que sus clientes deseaban. El equipo de PlanMill hizo hincapié en los cambios iterativos reforzados por etapas continuas de modelado del producto tanto interna como externamente para recibir comentarios de la comunidad de desarrolladores mediante demostraciones y asistencia a eventos relacionados con la API.

  1. Proyecto de investigación : el equipo creó un proyecto de investigación formal impulsado por tesis para investigar las necesidades de sus clientes, pidiendo a los socios que compartan sus propias experiencias utilizando la API y sus pensamientos sobre cómo mejorar la API. Descubrieron, en general, que los clientes estaban ansiosos por compartir si eso significaba ayudar a mejorar el sistema.
  2. Tecnologías piloto y primer servicio : utilizando la investigación, el equipo hizo una lluvia de ideas sobre qué podrían hacer de manera diferente si pudieran comenzar desde cero. Rediseñaron su pila de tecnología y enmascararon cosas viejas que no estaban bien diseñadas para ofrecer una interfaz limpia a sus clientes. Elegante por delante, salmonete por detrás .
  3. Demos : lo que siguió fue un debate interno, el intercambio de conocimientos, la asistencia a seminarios y la demostración de la API.
  4. Investigación adicional : el equipo leyó las API nórdicas, investigó la comunidad, probó nuevos enfoques, se decidió por la arquitectura y las tecnologías, asistió a seminarios adicionales e investigó estrategias de monetización.
  5. Beta interna : versión operativa desarrollada para pruebas internas.
  6. Se comió su propia prueba interna con nueva interfaz de usuario : se diseñó una nueva interfaz de usuario simultáneamente con el desarrollo de backend. El equipo descubrió que los conocimientos desde una perspectiva de UX eran fundamentales para crear una API diseñada de forma intuitiva.
  7. Beta pública 1.5 : esta etapa implicó pruebas de la comunidad de desarrolladores y la apertura de la API para que la utilicen desarrolladores externos. Llevaron a cabo un seminario de uso, alcanzaron una versión 1.5 e hicieron actualizaciones incrementales.
  8. Comentarios de la comunidad de desarrolladores : actualmente el equipo se encuentra en esta etapa.
  9. Publicar 2.0 : planes para publicar la plataforma completa pronto. El equipo tiene como objetivo utilizar su investigación, comentarios, nueva interfaz de usuario, decisiones de arquitectura, estrategia de monetización y más para culminar en una versión 2.0 bien informada y bien preparada.

"Comimos enormes cantidades de comida para perros, no quiero volver a ver comida para perros nunca más"

Decisiones de arquitectura específicas tomadas a lo largo del camino

Se pueden ver los muchos puntos en los que PlanMill volvió a visitar la etapa de análisis para comprobar el pulso de los usuarios y hacer pivotar su producto en consecuencia. Echemos ahora un vistazo bajo el capó para examinar qué elecciones de arquitectura específicas se tomaron en respuesta a su investigación.

Autenticación: claves HMAC y API

PlanMill optó por HMAC como esquema de autenticación, ya que permite la comunicación B2B a través de capacidades de integración a nivel de sistema. Para los servicios de PlanMill, se prefiere el uso compartido de archivos de servidor a servidor para la transferencia de nóminas, por ejemplo. Aunque PlanMill reconoce que todavía necesitan mejorar su proceso de administración de identidad unificado con tecnologías adicionales , HMAC es adecuado para su situación actual que involucra a un usuario y un conjunto de credenciales para hablar con otro usuario único y un conjunto único de credenciales.

Formato de datos: JSON (y más) sobre XML

El equipo de PlanMill eligió JSON elegante , un formato que es más simple de entender y requiere menos sobrecarga de configuración que XML. Algunos pueden burlarse cuando escuchan que, además de devolver JSON, la API de PlanMill produce formatos como CSV y… PDF. En su caso, este tipo de devolución tiene sentido, ya que cierto software de inteligencia empresarial recibe formatos PDF o CSV para sus operaciones.

Verbos HTTP utilizados correctamente

La API de PlanMill utiliza verbos HTTP estándar (GET, POST, PUT, DELETE). Aunque no está implementado en PlanMill API v1.5, Niinioja aboga por el uso de PATCH , por la razón de que puede aliviar los dolores de cabeza y la hinchazón que pueden ocurrir al intentar actualizar los registros delta . Los cambios mínimos en grandes conjuntos de datos, como una pequeña edición de la información del usuario, se pueden convertir en pesados ​​con solicitudes GET y POST redundantes. El equipo planea adoptar los estándares PATCH adecuados con la versión 2.0.

Documentación RAML

PlanMill decidió optar por RAML en lugar de Swagger , Blueprint API u otros formatos de especificación para las API REST.

“Decidimos ir con RAML porque era un nuevo estándar… era bastante fácil de adoptar. Incluso entonces, había muchas herramientas para generar documentación a partir de él. Es fácil generar SDK en varios idiomas "

PlanMill también aprovecha APImatic para generar SDK en varios lenguajes de programación.

¿DESCANSO o JABÓN?

¿ REST es realmente mejor que SOAP? ¿ SOAP es mejor para transacciones comerciales críticas? Hay un argumento para ambos lados. Para PlanMill, SOAP y WSDL tienen un lugar en su plataforma para facturas, cuentas y nóminas. Sin embargo, como describe Niinioja:

”Una buena API REST con documentación adecuada, incluidos esquemas JSON, muestras JSON, documentación RAML, o algún otro formato, y también códigos de error, es mucho, mucho mejor. También es algo que obliga a las personas a diseñarlo de manera más simple ".

¿Quién usa mi API? Leer: Comprensión de su audiencia de desarrolladores

Compartir datos de forma cuidadosa y segura

Es importante tener en cuenta que en el entorno B2B, algunos datos de nivel crítico o secretos de la empresa no pueden escapar del sistema, pero aún deben compartirse a través de API a través de los canales de los socios.

Cosas como números de cuentas bancarias, bajas por enfermedad, datos de nómina, etc., deben compartirse con los sistemas, pero no pueden escapar de esos límites. También tiene control gubernamental y de tratados comerciales, como en Finlandia, la base de PlanMill, donde las leyes de datos personales establecen límites estrictos sobre lo que se puede compartir legalmente. Una empresa también puede tener una política interna que controle los datos compartidos. Todo esto puede inhibir la integración abierta con plataformas como Zapier o IFTT.

Al final, Niinioja reconoce que una empresa necesita apoyar tanto la apertura para compartir información de contacto básica u otros datos similares que se pueden compartir libremente, como rutas punto a punto , para compartir datos API entre sistemas asociados a través de conexiones seguras .

Banner básico-01

Comprender la vida de una API

PlanMill comprendió el ciclo de vida de su API, aportando una mentalidad ágil a la plataforma de API empresarial a  través de la investigación y el intercambio. Cada etapa de este proceso juega un papel importante en el avance del proyecto en su conjunto, a través del análisis, el desarrollo, las operaciones y el control de versiones.

Aunque PlanMill todavía tiene mucho trabajo por delante, es de esperar que este estudio de caso pueda dar una idea de qué errores se cometieron al principio del proceso y cómo se rectificaron, con la esperanza de que los nuevos profesionales de API puedan tener una versión exitosa armados con esto conocimiento. Deseamos a PlanMill una versión 2.0 exitosa y esperamos que su saga de producción pueda servir de modelo para que otros tengan éxito en el espacio API.

Recursos adicionales:

  • Documentación de PlanMill API v1.5
  • Desarrollador de API accidental: presentación de diapositivas

[PlanMill ha participado en eventos anteriores de API nórdicas, pero no patrocinó esta publicación]

Publicar un comentario

0 Comentarios