The Order Management API 1.0 has been released. The Order Management API is (as far as we in the JSR264 Expert Group (EG) know) the only open and standards based API available for order management and is relevant for any organization developing an order management solution. By using this API as a basis for your Order Management solution you can reuse the knowledge of others (not reinventing the wheel), reduce your integration costs and create a flexible Order Management solution.
In a previous blog post I already described the features of the API in detail, so I'll just repeat the most important features:

The JSR264 specification can be downloaded from the JCP website. The Reference Implementation (RI) and Technology Compatibility Kit (TCK) are available at the TelemanagementForum website. More information on JSR264 can be found at the JSR264 java.net site.

Order management is a common process and virtually every organization does some sort of order management to ensure that it can process requests from it’s customers and deliver the requested product (for example book, car, drivers license) or service (for example telephony, health insurance, TV). Although the Order Management API originates from the OSS/J family of APIs (which are targeted at Communication Service Providers) we made sure that the API is not limited to this industry.

The key features are:

• Supports both simple and complex use cases
• Supports long running transactions
• Defines the managed entities on which the Order Management operations work (Order, OrderItems, etc). These are extended from the Telemanagement Forums Shared Information/Data Model, the items used from the TMF SID are the non Telecommunications specific ones.
• Defines the (extensible) state model for Orders.
• Support for creation, starting, updating and removing Orders.
• Support for bulk operations to create, update, remove orders. These are available in an atomic (all must succeed) or best effort (failing ones will be reported back) flavor.
• Support for notification to keep clients informed of progress of an Order (not only clients that submitted an order but also other interested clients).
• Notifications that requests the client for validation of certain aspects of the order (before it continues processing).
• Notifications that requests the client for additional input (before it continues processing).
• Extensibility. The types of orders (and all contents) and the order states can be extended for your specific needs.
• Flexible query possibilities like query by key, query based on a template and defining named queries (comparable to JDBC Prepared Statements).
• Support for static and dynamic typing of attributes of an Order.
• Support meta-operations that (for example) enable a client to discover at runtime what orders are available.

While participating in the JSR264 Expert Group (EG) I was in the lucky position to be engaged at a customer that was increasing it's usage of OSS/J based API's. At that customer we designed a solution based on the drafts of the Order Management API together with one of their vendors. Great advantage for me was being able to combine theory from the JSR 264 EG with real life experience from the customer project. This was beneficial for both the customer and the JSR264 EG.

A little background on the road to the 1.0 version....
The JCP defines the milestones and deliverables (Specification, Reference Implementation (RI), Technology Compatibility Kit (TCK)) that each EG has to deliver for a Java Specification Request (JSR), but it does not define how an EG should organize itself internally. In our case we used Scrum. Challenges we faced were:

• The members of the were distributed over the globe (Europe, US/Canada, Australia) and working for different companies.
• Everybody in the EG was doing that on a part-time basis. Most of them doing it next to their regular jobs. Some people had allocated time from their employers to spent on the JSR, but this was never more then 2 days per week. It was hard to sync working times.
• The core team was around 5 people and with each having only limited time available, progress sometimes felt slow.
• There was no product owner.

To deal with this we:

• Had the spec lead (Andreas Ebbert-Karroum) of the JSR act as product owner.
• Used short 2 week sprints such that we could quickly adapt and still get some work done in a sprint.
• Had 2 scrum calls a week, one in the (European) morning and one in the (European) evening such that people from all timezones could join at least once. During the last couple of sprints we had daily scrum calls.
• Assigned the tasks from the backlog such that people in the same timezone were working on the same or related tasks (usually organized around the RI, TCK, specification documentation).
• Used instant messaging a lot.
• Ended each sprint on Friday with a 2 hours combined retrospective/planning call.
• Had a face to face workshop in Düsseldorf every 8 weeks. This workshop was only attended by the EG members that could easily travel there, but was crucial to align views and discuss issues in depth.

28 sprints, hundreds of conference calls, 3600+ mails, and voila, the Order Management specification passed the JCP Ballot.

All in all is and been a great and fun experience to work on this specification. It is a perfect way to extend your network, learn from others, market your company and yourself. And yes, Artur Uzieblo was right when he told me that "it is more hard work than fame"... at least for the "hard work" part.

I also have to thank Xebia for allowing me to work on this specification, without the allocated time from the Xebia Tasking budget I would not have been able to participate as much as I did. Would I do it again... definitely!

Filed under Agile, Java, Telecommunications | 2 Comments »