2025-11-09. The Economics of Hyper Automation, or a Tale of Two departments
> Back to Main > Demo of Omni-Environment Oracle Database Refreshes (2025)
In the previous post, I demo-ed a hyper-automated process from a very high level. This time, we will look under the hood. We will compare two database management departments, Database Sand Diego, a conventionally run team of nine excellent administrators, and Database Atlanta, a hyper automated group with just one employee.
Lets see how the well-staffed group's performance compares to the one on the cutting edge of technology.
Here is the scorecard for my previous demo, to refresh your memory.
Enterprise omni-vendor (AWS, Oracle OCI, Azure, and Google) emergency database password rotation
The scorecard shows that hyper automation emerged victorious. But how did it manage to shorten a 34-year-long (projected) IT process to 2 hours, slashing the cost from $19 million to $0 and reducing errors to virtually none?
Quite simply, to exhibit any sort of decent ROI, an automation endeavor has to be:
1. Closed-loop (meaning it excludes any human participation other than its design);
2. Vertically and horizontally integrated with the enterprise.
The concept of closed-loop automation isn't new; it began in networking. Here is a 30-second video explaining the difference between open-loop, or incomplete, and closed-loop hyper automation:Open-loop vs closed-loop automation
The concepts of vertically and horizontally integrated automation are relatively new. The terms have nothing to do with market segments or the supply chain. In the context of automation, the term "vertical integration" means automating the entire life cycle of a change, from top to bottom. That implies automation is event-driven and all-encompassing, from detecting the need to open an incident or change request, through obtaining all necessary approvals, routing, assigning, executing the change entirely unattended, verifying the implementation, and finally closing the incident or change request. All unattended. All in real-time, via an API.
Horizontally integrated automation enables the unattended maintenance of all software and hardware products and technologies the enterprise has at its disposal to maintain its assets. Conventional automation software typically supports only a specific cloud, product, or vendor, such as AWS or GCP, and even then, only specific subtasks within certain sub-steps are supported, such as batch execution, alerts/notifications or assignments/approvals.
Here is the life cycle of a conventional personnel-based IT change (with or without open-loop automation):
Life cycle of an IT change
To reiterate, the ROI for partial, open-loop task automation is too low to justify the expense. Process automation, on the other hand, affects every technology or product the enterprise may have, across the entire life cycle of the IT change. Top to bottom. Left to right. All in real-time, event-driven, executed in parallel.
Now, to the demo. Today, we will use the same closed-loop hyper automation demo (an emergency enterprise-wide omni-vendor password rotation). It didn't have to be the passwords or even the databases. It could have been any IT incident or change, from hardware to software, in the cloud or on-prem. High-volume password rotation is ideal demo material because it is vendor-agnostic and spans the entire change life cycle, which is what hyper automation is all about.
1. How the incident came to be
Usually, an incident has to be reported by a person. Hyper automation did that by itself. It is event-driven. A software probe detected a vulnerability or threat, prompting an immediate password rotation.
2. How the incident auto-triggered its master change requests
Here is the hyper-automated incident in a familiar ServiceNow interface.
A password rotation incident opened by hyper automation
Next, hyper automation opens change requests to address the incident and gets to work immediately.
Separate change requests opened by automation are all linked to the original incident
All of the auto-opened master change requests are linked to the original incident.
This is an AWS RDS master change request CHG0030253 to take care of the AWS RDS part of the original incident INC0010139
Let's take a moment to appreciate what just happened. Usually, in an unautomated enterprise, it takes a day even to detect the threat and open an incident. It takes another day or two to route it appropriately. Otherwise, the incident will spin in the wrong queue forever.
Now, to the assignment phase.
3. How the linked change requests get assigned
If we had assigned the change requests manually, here is what we would have seen.
A picture of the Database San Diego department showing 9 database administrators
In the example above, we manually assign the AWS RDS master CR (Change Request) to the San Diego Database department group. This department is not automated, of course. It employs 9 database administrators at a cost of slightly over $1 million per year, plus benefits. These people work only certain hours a day and certain days a week. Their knowledge and experience are not interchangeable, meaning that what one employee knows and does, the next may not be able to replicate immediately. They are getting paid whether they are working, coasting, or entirely at rest. Even ServiceNow shows the hourly cost of the unautomated San Diego database department at $114/hr ($1,000,000 divided by the number of hours in a year, 8,760).
The unautomated Database San Diego department's hourly cost is $114.15 an hour
But that was a conventional, unautomated department. Let's assign the same AWS RDS master change request to a hyper automation module rather than a person. This department happens to be hyper-automated: Database Atlanta. It employs only one administrator, Bow Ruggeri, and the second employee is a hyper-automation module ("Replayable" is the name of a product).
The Database Atlanta department group is hyper automated, it has one person and one machine named "Replayable"
Yes, hyper automation software appears as an employee in ServiceNow, but a very special one. This employee never eats, sleeps, has personal issues, or asks for a raise. This employee does not understand the concept of "good enough" and honestly thinks that 9-5 is just a number. Another way to describe hyper automation is that it is always at its best, 24x7x365. Forget that —not just at ITS best, but at the INDUSTRY's best, because whatever the technology, hyper-automation modules have vendors' best practices embedded. Here is how much the hyper-automated Database Atlanta group costs the enterprise.
Dept Database Atlanta costs the enterprise only $17.12 per hour
Lets see what we got so far. Hyper automation has already saved the enterprise more than a quarter of a million, and we have not even begun working on the change!
4. How the change requests are auto-executed in parallel
So, we assigned the change requests to the Database Atlanta department, which is hyper-automated.
A ServiceNow view of the hyper automation module
The manual assignment was optional and was only done for demo purposes. In practice, all incoming Atlanta incidents or change requests are auto-assigned to the hyper automation software by default. The hyper automation handles 99% of the work, 24x7x365, working on up to 1,000 tickets in parallel, while Bow Ruggeri handles only overflow assignments (what hyper automation couldn't execute or auto-resolve). Here is what happens next. Hyper automation opens four change requests to resolve the incident—one for each cloud technology or vendor the enterprise is licensed for. For each change request, it opens three tasks - one for each cloud product.
Incident (one) => Change requests (four) => Tasks (fifteen)
Here is a screenshot of the three tasks to reset passwords in Google Cloud products (AlloyDB, CloudSQL, and Spanner) opened on behalf of the master Google Cloud change request to address the main incident.
Tasks to close the change requests triggered by the incident
5. How tasks are getting executed in parallel, and in real time (meaning as soon as the incident and all of its linked change requests are opened)
This is where the rubber meets the road. This is where the ROI of hyper automation is most evident.
So far, we have only seen the ServiceNow aspects of the demo. Now technology comes into play. Our event-driven hyper automation module opened an incident. Then four master change requests (AWS, OCI, GCP and Azure). It then opened 15 tasks for the four change requests. It then went to work on actually rotating the database instances' passwords - across different cloud technologies, vendors, and endpoints.
- AWS - 2,488 instances (RDS Oracle, MySQL, PostgreSQL, MariaDB)
- Oracle OCI - 2,512 instances (Autonomous database, Exadata, Oracle RDBMS, NoSQL)
- Google GCP - 2,498 instances (Spanner, AlloyDB, CloudSQL, Bare Metal)
- Azure - 2,552 instances (MySQL, db SQL, Cosmos, SQL Server)
Up to this point, before the 15 tasks are executed in parallel and immediately as soon as the original incident is opened, an unautomated department Database San Diego would have wasted 3-5 business days on routing, assignments, and approvals at a cost of $13,698.
A simple fact is that assigning the incident to the Database Atlanta department drastically changes the cost.
Because hyper automation works in real time and in parallel, it only spent 3 seconds on all of the routing, assignment and approval steps at a cost to the enterprise of $0.00284. Let's put that in perspective. Five business days, thirteen grand versus three seconds and one fifth of a cent. That is hyper automation, and it isn't at its best yet.
The best part is the execution. That is where hyper automation shines the brightest.
First, let's calculate how long it will take a conventional, unautomated Database San Diego team to handle the 10,000 database instance password rotation change requests, and what the cost will be? Here is the answer: 34 years and $19,200,000. Keep in mind that group is 9 times as expensive because it employs nine database administrators instead of one, as in Database Atlanta.
Now, a hyper-automated Database Atlanta can do this in less than 2 hours. Cost to business? $17.2 x 2 = $34.40.
How does it do that? Again, only if automation is closed-loop and all-encompassing does it begin to bear fruit. First of all, the tasks are executed immediately the incident and its change requests are opened. Second, the tasks are executed in parallel across all 10,000 instances.
A word on the approval process. Because all of the task variables and execution workflows are defined ahead of time, the approvals can be provided to the entire process in perpetuity, as opposed to its separate tasks executed only once. In other words, hyper automaton does not deviate because it excludes the only source of a possible deviation - a human.
For each of the 10,000 password resets, regardless of the cloud or database product vendor, hyper automation performs two steps: it tests the current password stored in the encrypted Vault; if the test is successful, it changes it, overwriting the Vault entry. If it isnt- it opens a new incident which triggers a separate overflow hyper automated change request, and so on.
Here is a top view of the technologies for todays' demo:
These are the database vendors and technologies the Database Atlanta hyper automation handles (CMDB, cloud tags, custom facts)
Here is a more detailed view of a single cloud vendor (AWS) and a single database product (RDS).
We don't have enough time to describe everything. So, what follows describes only the AWS part, not OCI, GCP or Azure. The creation of incident INC0010155 triggered the AWS RDS master change request, which in turn, triggered three tasks for each RDS product the enterprise is licensed for, Oracle RDS, MariaDB RDS and PosgreSQL RDS. This is only one of the four change requests opened in real-time via an API. There are Google GCP, Oracle OCI and Azure change requests as well. All four are executed simultaneously. All four generate product-specific scripts, as shown below.
AWS RDS change request triggers three tasks
Here is the ServiceNow view of the same master AWS RDS change request:
AWS RDS Change Request CHG003282
AWS RDS tasks for the master change request resolution
At this point hyper automation executes fifteen tasks in parallel, only three seconds after the initial incident is opened. It takes 2 hours to complete all 10,000 omni-vendor database instances' password rotations. Here is what that looks like (this is a view from one automation cluster node; there are nine more, all working in parallel to open, execute, and close incidents and change requests in real-time). This is the end result: a successful password rotation log. The instances are named as follows: "<number>_<vendor>_<product>" :
Ansible parallel execution log
To summarize.
- 34 years vs two hours.
- $19,200,000 vs $34.
- 400 errors vs 0.
- Having to hire additional help despite having 9 times more administrators on payroll, vs being able to scale almost infinitely on a shoestring budget.
The choice is yours.
Key Performance Indicators, side by Side
Time consumed
Cost
Errors
Scalability
The following is a 30-minute video capture of the demo in two parts, with comments.
Part 1 of 2. Introduction to hyper automation of the life cycle of an IT change.
Part 2 of 2. The hyper automation demo: Enterprise omni-vendor (AWS, Oracle OCI, Azure and Google) emergency 10,000 passwords rotation.