What's in a Name?

Over the years, I've written on the topic of application release on several occasions (here and here, for example).  The topic itself is generally straightforward in that automating your application release process provides several benefits:

• Increased reliability insofar that the deployment process is being managed by software, meaning that "friendly fire incidents" are less likely to occur
• Increased release velocity as the time to deploy the application in a single environment is reduced, sometimes substantially
• Increased release cadence as more frequent releases are now possible given the previous two points

Is ARA always about applications?

Not only this, but automating your CICD pipeline is a key enabler for DevOps, as it is one of the five tenets of that school of thought.  (The others, if you aren't aware, are cultural change; efficient processes that are void of wasteful, time and resource consuming steps; measurement of the effectiveness of your processes; and sharing the information in a feedback loop for continual service improvement.)

Lately, I've seen a few examples of alternate ways to apply the concept of application release automation (ARA) to effect process improvements:

Database DevOps.  This is a term I'm using to describe software solutions that automate the development and release of database objects.  Companies like Datical and DBMaestro recognize that, although databases are an essential component of any traditional 3-tier application, they are also able to stand alone in their own right due to the complex nature of the DBMS ecosystem.

Back-office Release Automation.  ERP and CRM solutions frequently offer the ability for organizations to customize the functionality of those systems to meet the unique requirements of that organization.  Well-known solutions such as SAP and Siebel are immediate examples of such back office solutions where custom module development has a process analogous to traditional software development.

But the most interesting area (to me, at least) where this is being applied is in non-traditional application release.  By this I mean applications that aren't comprised of binary executables or even scripts.  Instead, these are objects of other solutions like Informatica where they are developed and tested like any application and also have a life-cycle of environments that they traverse during their journey to a production deployment.

I realize that one could make the argument that these are just an extension of Database DevOps or Back-office Release Automation.  However, there are only elements of those other two categories while the majority of this use case is unique.

Consider the Informatica example.  Informatica has its own workflow objects that access databases and can execute shell scripts as part of their "execution."  All of these components are artifacts in the Informatica application, even though that term is a misnomer since Informatica is the application and not the workflow objects that it executes to perform standard ETL types of activities.

Yet, ARA can have a positive impact here because:

• The general release process is the same.  You copy artifacts to the target machines; deploy them by importing the Informatica objects into the repository; and you effect changes to the database that the Informatica workflows access.
• The non-automated process has the same challenges.  Manual deployments have several potential points of failure; manual approvals via email slow down the release velocity; and releases are often managed by spreadsheet or some other manually maintained ledger.

The point that I'm trying to make is that ARA doesn't have to be about applications that you write in some standard programming language like Java or C#.  Instead, this should be viewed through the lens of the challenges faced by an organization and the net benefits that can be realized using an automation solution such as CA-Automic's ARA.