Object oriented programming paved the way for a new era of simpler, more efficient and more readable code. It is centred around classes, which describe objects. The class defines which attributes an object has, and which methods are associated with it. Object-oriented programming languages like Java are now the most commonly used programming languages in the world.
With Cloudomation Engine, we introduce the same concept to automation.
In Cloudomation Engine, users can create object templates, equivalent to classes, which describe custom objects. These objects can be anything: a server, a customer, an order, or the payroll of a company.
The object templates determine the attributes of an object, as well as lifecycle hooks. Attributes describe the basic characteristics of an object. Lifecycle hooks trigger automated processes. There are three lifecycle hooks: on-create, on-update and on-delete.
The idea of object-oriented automation is that automation is modelled around objects which mirror their equivalent in the real world – somewhat similar to digital twins.
Digital twins digitally represent objects in the real world through the use of sensors that observe the status of its real-life equivalent. The digital twin is therefore a mere copy.
In contrast, objects in object-oriented automation are functionally tied to their real-world equivalents: Creating the digital object in Cloudomation Engine triggers an automated process that creates its real-world equivalent. Modifying the digital object in Cloudomation Engine triggers an automated process that modifies its real-world equivalent. The object is therefore not a mere copy, but a digital representation that allows interaction with its real-world equivalent.
Though the definition of “real world” is broad in this context. Typically, software automation deals with digital entities, such as virtual machines (which could be modelled as “servers”) or the data a company has about a customer (which could be modelled as “customer”).
Let’s take a look at an example to make more tangible how this works.
Example: server automation
A common process in system administration is to set up a virtual machine and install some software on it. Often, these virtual machines then need regular maintenance, i.e. changes need to be applied to them such as software updates. Sometimes, virtual machines need to be deleted again. This group of processes is what I mean by “server automation” for the purpose of this example.
Server automation is typically done in one of two ways in most companies, depending on how frequently it is necessary and how standardised the process is (e.g. if always the same software needs to be installed on a server, or always different software). It would either be done manually, or it would be automated. In both cases, the system administrator would “do the process”, and that’s it. As a result:
- Information about the VM is distributed. To find out which software runs on it, the system administrator would have to log in and look, which is not feasible when managing many VMs. If there is documentation (manual or automatically created on creation of the VM), it is likely to be outdated quickly, since it is only ever a snapshot of one point in time. Whenever there is a change, the documentation would have to be updated, which often doesn’t happen.
- To set up a VM and install software on it, a system administrator would have to learn the steps from another system administrator, which takes time and is error prone, or she would have to read and understand scripts in an automation software, which is difficult and time consuming. Most likely, many system administrators will have only very limited or no understanding of many of the company’s IT processes, even if they use automation software to execute them. As a result, it will be hard for them to troubleshoot issues, and to make changes to existing automations.
All of this is very normal. It is what happens when people have to manage complex processes.
Object oriented automation doesn’t make any of this less complicated. It just makes it easier to manage.
With object oriented automation, the system administrator would create a “server” object in an object-oriented automation platform (i.e. Cloudomation Engine, currently the only one in existence 🙂). This would trigger creation of the VM and installation of the software. At the end, the system administrator would have the server object in Cloudomation Engine to see which status the VM is in, which software is installed etc. If the system administrator needs to make a change, she changes the object in Cloudomation Engine, which applies the change to the VM. As a result:
- Information about the VM is collected in the object in Cloudomation Engine. There is no separate documentation step. Changing the information in Cloudomation Engine ensures that this change is applied to the server, ensuring that this information is always up to date. This also makes it a lot easier for the system administrator to make a change, since she knows where and how to do it.
- To create a VM, a system administrator would log into Cloudomation Engine and create a server object. She would see the object, its attributes, its status, and the visualisation and logs of processes involved in creating and updating it. This makes it easy for her to understand how to create a new server, what this means (i.e. which steps are actually involved in creating this server), and to know which servers already exist. As a result, it will be easy for her to troubleshoot issues and to make changes to existing automation associated with the object.
While the overall complexity of the process stays the same, using object oriented automation makes it easier to understand and use, and ensures that there is up-to-date information about the results of the automated process. It also creates a strong incentive both to use the automated processes (because they are easy to use and understand) as well as to automate additions to the process, such as changes to the VM, so they can be done via the same interface, and their results can be again captured in the object.
What is great about object-oriented automation
Compared to other automation approaches, object-oriented automation has several huge advantages:
- It’s a lot easier to understand and keep track of than a pile of scripts. The objects provide mental anchor points for your automation that make it very tangible what happens when and where, what the results of the automation are, and what its current status is. Take a look at the objects and you will immediately understand what an automated process is about – much faster, easier and clearer then when reading a script.
- Objects are “self-documenting”. Changing the value of an attribute in an object is “functional documentation”: It doesn’t just update the information, it triggers a process that ensures that this information is applied. Whatever information is available on the object is always “true”, always in sync with the real world, because changing an attribute triggers a process that ensures that the real world is also changed. In this way, both the object’s current state, but also the changes are documented – including, for example, who made a change.
- Objects provide an intuitive place to collect information about “things”, entities which exist already as mental representations of things like a customer or a server in our heads. Thinking about objects is very intuitive and close to how we already think. When we think about customer data management, we already think of a customer as an entity that has a lot of information associated with it. The object “customer” already exists in our heads. But in many cases, such mental entities don’t have an equivalent in our digital infrastructure. The data we have about a customer is distributed across a number of databases and software systems. Modelling these objects provides a place where this information can be integrated.
- Side note: Thinking about object-oriented automation in this way provides an even larger perspective: One of object-oriented data management and object-oriented digital infrastructure. There could be a master data management system in each company where the digital entities are modelled which are relevant to this company. Data and automated processes could then be connected with these objects.
Cloudomatin Engine comes with a master data management system which allows users to do this for automated processes within Cloudomation Engine. It also has broad system integration capabilities which allows users to associate information and processes in other systems with objects modelled in Cloudomation Engine. But Cloudomation Engine is not a database. Its master data management system is intended to keep metadata about objects, and can contain references to data in other systems (following also the idea that data should be copied as little as possible to avoid drift.) However it is (currently) not built to allow many people in an organization to discover and work with objects. Its scope is to make the creation and maintenance of automated processes easier for system administrators, DevOps engineers, platform engineers, software developers and other technical professionals.
ERP systems go some way in this direction by aiming to provide a unified view of some of the central entities relevant to most companies: customers, suppliers, products, employees etc. However they often approach this in a somewhat piecemeal fashion, come with a fixed data model that can only be customised to a limited extent, and no or very limited automation capabililites (which means: no lifecycle hooks), which limits them to predominantly serve as data stores which require heavy manual maintenance to avoid their inevitable accumulation of “data garbage”.
- Side note: Thinking about object-oriented automation in this way provides an even larger perspective: One of object-oriented data management and object-oriented digital infrastructure. There could be a master data management system in each company where the digital entities are modelled which are relevant to this company. Data and automated processes could then be connected with these objects.
Summary
- Automating complex processes involving many steps, different systems, many conditions, variations and lots of business logic is difficult. There is no magic that can make it simple. But there are approaches that make this complexity easier to handle.
- By aligning with how people already think about the world, object-oriented automation makes it easier to get a grip on complex automated processes. It is centred around the modelling of objects with attributes and lifecycles. The objects are representations of the mental categories that we already have in our heads: customers, servers, ads, whatever else is part of our digital business processes.
- Creating, changing and deleting these digital objects triggers automated processes that create, change and delete their “real-world equivalents” – e.g. by creating a virtual machine in a cloud environment when creating a “server” object, or by updating a customer’s address in a CRM system when changing a “customer” object.
- Thereby, these objects make it simple to understand and interact with objects that currently often exist only in our heads.
