This series of articles explores several options to insert ODM into a typical DevOps pipeline, by leveraging out-of-the-box features and showcasing sample code using provided APIs.

The overall plan of the series is the following:

• article 1 (this article): setting the context about ODM, DevOps, sources of truth
• article 2: building ODM decision artifacts when they are stored in source code control
• article 3: building and testing ODM decision artifacts when they are stored in Decision Center
• article 4: deployment, promotion, traceability

It is recommended for the reader to read articles 1 and 4, however one can skip one of 2 or 3 depending on the storage choice made. The articles assume that the reader has installed a local copy of ODM and is somewhat familiar with the steps involved by a Continuous Testing and Deployment pipeline. In order to help with the understanding, I’ve provided a few code samples in GIT repositories, linked from the article. This code is only intended to be used as a source of inspiration, but is not robust enough for building an entreprise-grade pipeline.

What is DevOps?

As companies have evolved their Software Delivery Life Cycle to increase both speed and quality at which software gets delivered to final users, they’ve followed different methods and styles of production and delivery.

The first meaningful evolution came in the 90s, with Agile. It did a very good job at tearing down the wall between the traditional development and test teams. Yet, if the software produced is of higher quality, one can still commonly see the model by which it gets “thrown over the fence” to the operations team.

DevOps is a cultural shift, which aims at tearing down that other wall. Developers need understand how software is operated. IT teams need understand how software is built.

To achieve this, DevOps offers a typical pipeline, supported by tooling, of which IBM Toolchain is an implementation.

What is ODM?

The ability to effectively automate decision-making within and across business systems helps maximize organizational efficiency. This helps increase employee productivity and improve the quality and consistency of operational decisions that are made repeatedly in the course of the business day.

IBM ODM helps addressing decision-automation challenges by enabling organizations to build highly flexible, adaptable solutions that can detect and react to threats and opportunities and quickly adapt to changing business conditions.

The ODM-DevOps challenge

Most programming languages are meant to be used by developers. Consequently, most systems are built following a pipeline which uses tools and techniques that developers can use, but which can not necessarily be exposed as such to more business-focused users.

Yet the challenge with ODM is that decision artifacts are intended to be authored and maintained by less technical users such as business analysts.

IBM ODM Business Console intends to hide the complexity of a typical DevOps pipeline to business users. The purpose of this series of articles is to show in detail how ODM can be integrated in your company’s pipeline, so that business users can get the best experience when authoring decisions, while still adhering to your company processes and tools.

DevOps is ensuring Developers and Operations work together. But with the empowerment of Business Users brought along by ODM, a third user group has to be considered.

Source Storage

One of the first questions that comes to mind when setting up a software factory is: where is the source code located? ODM offers two choices here.
The first option is to handle rule artifacts the same way as code. That is, they are stored in a source code control system such as SVN, GIT, or whatever has been chosen in your team for the rest of the java code. They can thus be checked-in and checked-out through the Eclipse Team Collaboration feature in the Rule Designer environment.

If this approach works fine and is very natural to developers, it can find limitations when comes time to let several users collaborate. Moreover, it is achieved through the Eclipse tooling, which is an environment suitable for developers, but not something that you would want to expose your business users to.

Consequently, the second option is recommended. In this approach, you can leverage the features of the ODM Business Console to help business users organize and version rule artifacts. Indeed, the Business Console allows for versioning of artifacts, maintains integrity between them, guarantees traceability of the authoring actions and handles collaboration between rule writers. Moreover, it offers more sophisticated governance features through DGF (Decision Governance Framework) when your project grows to several parallel releases and a wider author team, and you want to dispatch and trace work.

In this approach, decision artifacts are then persisted to the Business Console database, and consequently it is important to back it up, like you would any other database, as part of your policy of source code backup, since, should an outage occur, you would want to restore it for business continuity.

In the following sections, we will study the various steps of a typical DevOps pipeline, and how they can be implemented with the two aforementioned decision artifact storage options.

Continue to Article 2 - Building ODM decision artifacts when they are stored in source code control
or
Continue to Article 3 - Building and testing ODM decision artifacts when they are stored in Decision Center