There was a time when most (somewhat organized) salespeople managed their contacts with a Rolodex, hand writing names and phone numbers on flip cards.
Then — after observing this relatively standard process — some smart people figured out they could automate it by writing software. The CRM enterprise application category was born.
Of course, this is not an isolated story. Obviously, smart people across industries have been creating software to augment and replace manual workflows for decades.
In my Amazon bestselling book The Next CIO, I argue that a similar movement is needed to help IT leadership automate common processes that deliver a host of foundational services to the business.
Figure 1: Three options to automate the offboarding process
Take the process of employee offboarding. If a CIO wants to automate this process, then there are essentially three options available, as shown in Figure 1.
Develop custom, in-house solutions from scratch
In the first option, IT writes the software from scratch, developing a custom, in-house solution. This approach can make sense when the process is of strategic value and creates a core differentiation for the business. However, although employee offboarding is certainly important, it is not usually a strong enough strategic differentiator for a company to justify building the process from scratch.
Run a 1–3 year IT projects to build a custom, in-house solutions
The second option — and the one most IT organizations take today — is to fund an IT project that will likely result in writing custom code and stitching together custom integrations leveraging a third-party platform and various tools. In the case of employee offboarding, this is likely done with an ITSM platform connected to a CMDB.
Large IT projects like employee offboarding likely take one to three years to complete and consume IT resources that are already in short supply. This approach also adds additional costs down the road, as a custom, in-house solution also needs ongoing support and maintenance.
Buy functionally pre-packaged applications
The third option is to buy a functionally pre-packaged enterprise application that automates common IT processes like employee offboarding, similar to how most companies have replaced Rolodexes with CRM deployments. A pre-packaged application should be able to deliver value to the organization in about 90 days, not requiring the one to three years that would likely be required to run an IT project building a custom in-house solution.
Sounds good, right? Well, surprisingly, today there is no category of application that offers functionally pre-packaged enterprise applications that automate the common IT processes that touch a company’s broad, complex, and dynamic technology landscape.
The CIO of the future — the Next CIO — needs this application. Enter the proposed new category: Enterprise Technology Management (ETM) applications.
As described in The Next CIO, the creation of ETM applications would enable ETM vendors to deliver functionally pre-package solutions that address common IT processes, such as employee offboarding.
I say “functionally” because although an IT process may be common across organizations, it will need to be tailored to meet the specific workflows and technology management tools and assets deployed by each organization. This adds unique requirements to the architecture of the ETM applications, as addressed in The Next CIO.
One last point here: There’s likely resistance within IT to invest in yet another application, as many IT shops are being instructed to reduce their application count. To this objection, I suggest investing in an ETM application should be thought of as replacing a much larger investment in running an IT project.
REST APIs enable the promise of autonomous IT
We all know vendors have been promising IT process automation for over 20 years. The story almost always involves marrying data from multiple systems to achieve a level of abstraction that allows IT to focus on more strategic objectives.
Unfortunately, history has taught us that these promises rarely manifest in reality:
- Integration across tools and departments is difficult
- Different departments feel a need to protect their systems, not wanting IT to play around in their “sandboxes”
- There are limitations on what can talk to what
- There are significant data hygiene issues, making it difficult for IT to trust that it knows the true state and performance of its deployed assets
- The interfaces are often more suitable for systems engineers than anyone at an executive level
That said, what has changed somewhat recently is REST APIs providing a (relatively) standardized interface to virtually every platform and tool used in the enterprise. REST APIs allow ETM vendors to build connectors into the management tools already used by the enterprise. These management tools already have deployed agents used to collect data on various assets, enabling ETM applications to be agentless and operate on top of these platforms and tools exchanging asset data.
When the CIO chooses the “run an IT project” approach to automate a common IT process, then considerable time and resources will be spent coordinating and participating in meetings with the various siloed organizations like operations, finance, and security. Not to mention the time spent developing the glue that binds these organizations’ technology platforms together. A lead topic for many of these meetings will likely be how IT will make the necessary custom integrations with these groups’ tools.
This topic can be met with resistance from the various groups, as it’s likely they will not want to allow IT into their systems. For instance, HR might be concerned that doing so will create the risk that personally identifiable information (PII) will be exposed, not knowing how to provide an employee’s separation date without also exposing salary data, for example.
By building connectors using REST APIs, ETM vendors bypass this obstacle, only gaining access to the data fields for which they have the credentials. Likewise, ETM vendor connectors should be easily audited as you should be able to look at the connector integration and see exactly which fields are mapped from the ETM application to the technology management tool.
Getting improved data hygiene as a nice byproduct
In addition to improving IT agility by replacing the running of IT projects with deploying applications, ETM applications must also deliver better data hygiene. Without accurate data on the state and performance of a company’s assets, then automation will be flawed. As Guillermo Diaz, former CIO of Cisco, puts it, “Automating with garbage data just makes the garbage go faster.” Therefore, an ETM application must also seamlessly integrate technology asset management functionality.
Automating common IT processes … and more
Finally, although ETM applications might find initial success automating common IT processes like employee offboarding, the motivation, architecture, and maturity framework discussed in The Next CIO apply across all technology-centric workflows important to the business. It is with this broader lens that The Next CIO is written.
Interested in learning more? Check out The Next CIO available on Amazon.
