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

Finding Clarity in the Chaos of a Job Search

Job searches are humbling. They test your confidence, your patience, and your ability to stay motivated when things don’t move as quickly as you’d like. But they also teach you things about yourself that you might not have learned any other way. For me, the past few months have been a crash course in rediscovering what really matters: not just in a résumé, but in relationships, self-perception, and how we use technology to help tell our stories. Here are three lessons that stood out. Reach Out to Your Network (Long Before You Need It) Your network is a living thing. It requires upkeep, time, and attention, just like a flower garden. You can’t ignore it for years and expect it to bloom the moment you need it. Start planting early. Stay in touch with people whose paths you’ve crossed - colleagues, mentors, partners, even those you only worked with briefly. Drop a note once in a while. Comment on their posts. Share something that made you think of them. These small gestures are the sunl...

Time to Level Up!

With the recent news out of Salesforce and Oracle, it’s easy to understand why folks affected by layoffs might feel discouraged. Not only are they leaving companies they may have called home for years, but they’re also facing the daunting prospect of job hunting while headlines scream about “AI taking over human jobs.” Not long ago, another company I follow - let’s call it Acme  - went through a similar round of layoffs. Two employees in particular (we’ll call them Jim and John) showed how mindset can make all the difference. Jim had been at Acme for over 20 years. He was reliable, steady, and well-liked, but not exactly the standout type. When he was laid off, he decided to take some time off before even thinking about his next move. After all, he had a severance package. Didn’t he deserve a break after two decades of hard work? John’s story was different. Though he hadn’t been at Acme as long, he’d built a strong reputation and had both technical and leadership skills. Instead of...

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...