Skip to main content

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.

Popular posts from this blog

It's Easier to Fail at DevOps than it is to Succeed

Slippery when wet Since the term DevOps was coined in Belgium back in 2009, it is impossible to avoid the term whether in discussions with colleagues or in professional trade magazines.  And during the years while this movement has gained momentum, many things have been written to describe what elements of a DevOps strategy are required for it to be successful. Yet in spite of this, there is an interesting data point worth noting: not many organizations feel there is a need for DevOps.  In a Gartner report entitled DevOps Adoption Survey Results (published in September 2015),  40%  of respondents said they had no plans to implement DevOps and 31% of respondents said they hadn't implemented it but planned to start in the 12 months after the survey was conducted. That left only 29% who had implemented DevOps in a pilot project or in production systems, which isn't a lot. "Maybe it's because there truly isn't a need for DevOps," you say.  While t...
Read more

So What is this IPaaS Stuff, Anyway?

 In my last post , I discussed how no-code/low-code platforms fulfill rapid development of business applications - addressing the needs of the Citizen Developer (a Gartner term  first used around 2009).  I also commented on how this specific objective limits their ability to provide true integration capabilities, which require the flexibility to adapt to the myriad variations of infrastructure.  This is a concern because companies often have acquired legacy systems via M&A activity while simultaneously investing in new technology solutions, resulting in a mishmash of systems with multiple ways of accessing them. In this post, I'd like to examine how the needs of the latter group are met by describing some key capabilities that are "must-haves" for any company looking to execute on a digital transformation strategy.  In order to do this, let's define who the target user base is for such a technology platform. Disclaimer:   I work for MuleSoft (a division...
Read more

Application Development Done Right

In a previous article, entitled DevOps as the Ultimate Panacea? , I described how developing code without thinking about the current needs of the end user as well as the future needs once they've become accustomed to using your application ends up not only frustrating them but also can result in customer churn and ultimately lower revenues.  In this article, I'd like to describe something simple that I came across today that shows a definite degree of effort to do quite the opposite. Recently, we had a severe snowstorm, one with blizzard-like conditions, which is unheard of in central New Jersey.  Being responsible adults, my wife and I went to the grocery store to stock up on essentials (read:  chips, chocolate, etc.) in case we get stuck at home. As we were ringing up our order, the cashier mentioned to us that the store has a mobile application.  Since both of us are in technology oriented professions, we were skeptical about the need for a grocery store mob...
Read more