DevOps and Bimodal IT: myths & truths


Interview to Eddy Pauwels - Devops and bimodal IT - , VP of Sales and Marketing at Clarive SoftwareDevOps and Bimodal IT are two terms which have recently come onto the radar in the world of enterprise IT.  Confusion surrounding the definition and use of these concepts is rife so we sought to demystify these terms and understand how analysts such as Gartner see them in play over the next few years.

Eddy Pauwels, VP of Sales and Marketing at Clarive Software, were interviewed by Enterprise Management 360º a few days ago…

“This is why I often speak about lean application and service delivery when an organization is serious about DevOps. I believe they should look at the following things; first of all, they should look at application delivery from an end-to-end or a holistic perspective and try to orchestrate it like this. It should try to automate whatever can be automated so that one can deliver at a speed of business and that can be ranging from a few times a year or frequently a few times a day or even an hour if really need be.”

“I believe that DevOps is one of the key answers to support a Bimodal IT organization providing of course that it’s implemented properly and supported by the right infrastructure tooling. As we’ve seen DevOps improve the collaboration and communication between development and operations and try to increase the level of automation in order to support the delivery at the speed of business.”

“A good DevOps tool or solution supporting Bimodal IT for me should at least have one of the following characteristics. Firstly, it should allow you to define and automate any discussion topic between development and operations, whether these are called releases, projects, springs, test cases, change requests or defects, you name it. Secondly, it should be able to provide you with dynamic end-to-end insight into status and activity within the delivery process regardless of the mode being used, so that you really get a deep understanding from a customer perspective inside the delivery process.”

To listen to the full interview, please click here

How to Model Environments

The foundation of the configuration managed by Clarive for its delivery pipelines and changesets are stored in its powerful Configuration Database.

Environments and their resources are managed in the Clarive Configuration Database as graphs. Each resource is defined as a Configuration Item (CI). Configuration items belong to Classes (ie. TomcatInstance or a OracleDB classes), and each class may belong to one or more families, such as Database or Middleware families.


CIs can be connected to one another through relationships. For instance, an application may depend on a certain DB CI instance when deploying, so there exists a relationship between both.

Here are a sample list of possible relationships among CIs:

  • A release (topic) may contain require certain infrastructure to be deployed
  • A changeset contains repository changes, such as Git revisions
  • An application (itself a CI) may depend on certain microservice CIs
  • A pipeline rule may depend on Variables (which are CIs)
  • Variables may have different values depending on which target Environment (another CI) the Variable is being invoked for.

Relationships are created by associating one entity with another, ie. adding a changeset to a release. Clarive also curates the relationships and removes them if one of the CIs is deleted or deprecated.


Relationships may be visualized with any one of the CI Graph representations. These representations may be opened on the fly as properties of a CI (or Topic).

Graphical visualization of the relationship between CIs in Clarive

Application and Service Configuration

Any Clarive Project, which is used to represent applications and services in a organization, can be modeled from available configuration templates using the project configuration editor:

Application models are stored in the Clarive graph database and can then be displayed using the same CI visualizations mentioned above.



Database Release Automation

Database Release Automation

Implementing a fully automated, continuous application delivery process requires that ALL configuration items, including those that are stored in a database, be version controlled and deployed as part of the full cycle.

Unfortunately, a recent survey showed that many companies which implement continuous delivery for their application code do not do the same for their database code.

Here are some of the database configuration items that Clarive is capable of managing:

1) DDL, schema

2) DB Scripts, Stored-Procedures, Functions and Triggers, such as PL/SQL or Mongo Javascript

3) Application Configuration stored in the Database


Why is Clarive concerned about managing data? Well, the answer is rather simple: a great number of applications, be it in-house or closed ERP products, store their configuration in the database. Configuration that affects how the application logic and interface behaves. Usually this means inserting or updating a few rows of data from one environment to the next.

Read more

Use of cookies

This web site uses cookies to give you the best user experience. If you continue browsing you are giving your consent for the acceptance of the aforementioned cookies and the acceptance of our cookies policy, click at the link for more information.