Fast-Slow or Slow-Fast? Two different approaches to digital transformation

Osirium staff go to a lot of conferences, and often we take a quiet moment to listen to end users talk about current projects. We’re always intrigued by the wide range of descriptions of ‘digital transformation’. Many conference lunches later, we’ve observed two broadly different approaches; the slow to fast approach, and the fast to slow approach. The first is driven by the business units, the second by the IT teams – specifically DevOps.

This blog takes a look at what the different approaches are, their merits and weaknesses, and how best to secure privileged credentials and accounts, no matter which you use…

Background

If your company delivers to the Web, digital transformation is obvious – it is about the customer web experience. However, for companies that build products, it’s not so clear-cut. Take tractors for example; for the most part they are all unique, though the underlying engines and chassis might be the same. The end uses of tractors are diverse, as are the attachments, control systems and mounting points, all of which are driven by the customer.

Digital Transformation in a tractor factory will, therefore, have many dimensions. The most obvious would be the flow through the assembly line with various tooling to make the right tractor for the right customer. We can see that Enterprise Resource Planning (ERP) would need to be in the mix here so that the right materials and subsystems are available at the right time.

Of course, there is a dealer and customer in the chain, and they both need to know where their tractors are. Given this, is digital transformation about a customer web site so that they can track their own tractors through the build process, or is it a dealer portal so that they can maintain their customer relationship? It’s clear that a Customer Relationship Management (CRM) system has to be part of the digital transformation also.

Now we have two dissimilar applications – ERP and CRM – that need to be integrated to optimise the business workflow and customer communications. From listening to end users discuss their current projects, we have found two distinct approaches to challenges such as this example: one driven by the business units and one by the IT teams – specifically DevOps.

Fast-Slow – the business-driven approach

Picture the scene…Within business teams, Excel is the tool of choice. An Excel super-user in the business figures out how to import data from an ERP/CRM/Business Intelligence system. They process the data according to their perceived needs and export the new data to another part of the ERP/CRM/ Business Intelligence chain. Because they are part of the business team, they create reports along the way, and these, in turn, become part of the business metrics. This is the fast part of this approach.

The overriding rationale here is ‘we need this now to operate the business, IT will take too long and they don’t understand what we need’. However, business consultants tend to move around or even out of the business quickly. This means that their spreadsheets are no longer maintained. People know that this sheet needs to be run, but over time, what it does and how it does it becomes clouded. If it gets updated, it’s not under source control. Of course, the original author never considered edge cases or underlying systems not being available (or more likely a simple change in data format, for example from XML to JSON). What we discover is that the data collection side of these spreadsheets is riddled with privileged credentials that access sensitive parts of the ERP/CRM/Database systems. Furthermore, separate CSVs with all sorts of GDPR actionable data are created along the way.

With an interconnected chain of spreadsheets, failures can be silent. This means that figures can be missed lower in the chain that will affect the report that the board sees. In turn, this could lead to wrong business decisions. It gets uncovered when different departments argue about what should be the same figures. This triggers the process of working out the provenance of data.

Here’s the balance, these ad-hoc spreadsheet enabled integrations were created in the most agile way, delivering business benefit immediately. However, they are fragile to edge cases and a CISO’s nightmare. When they break, the original author is either long gone or deep into something else. So these integrations arrive on the desks of the DevOps teams to be reworked into robust, traceable and secure integrations that are under source control.

Agile is happening here as well, if it broke and didn’t get to DevOps it wasn’t that important. Or was it? What often happens is that the next business type along can’t fix the Excel code, and so recreates it from scratch. They fall into the same cycle of embedding credentials and working around edge cases as they hit them. Hence, this is the slow part of the business-driven approach.

Slow-Fast – the IT/DevOps-driven approach

The alternate approach, whilst CISO friendly, is also not nirvana. Given that the business knows what it needs to do and where it is going, the first approach would be to curate all the data sources, reducing them to the absolute minimum. That way the organisation knows where all the data is, and what security policies exist for access to that data. The Data Provenance issue never becomes a problem. This is the slow part of this approach.

From this position, they can start to build all the robust integrations needed. This is fast, since most ERP/CRM applications have well maintained APIs along with Role-based Privileges. APIs tend to be long-lived, documented and versioned. Of key importance here is that this approach is secure.

The issue here is that the speed to value is lost. It takes time to curate data, and proper application development is generally not core to the business. It is very expensive to reverse a decision in this path. The business can rarely tell DevOps what it actually wants because they’ve not reached that stage yet. For the very reason that the business can never fully tell DevOps what they need, DevOps will compensate with wider solutions so that they do not penalise their future selves.

What’s the Solution?

We’ve demonstrated that both approaches get to the same place in the end, both have slow and fast phases, and that the DevOps process is predicated on security and data provenance, but the speed to value is low.

Both Business Teams and DevOps are behaving just as their roles define. What the organisation needs is the best blend of both approaches.

It seems to us that some boundaries would help a hybrid approach, so here are our suggestions:

Business Types:

1. Never put credentials into a spreadsheet, and if you find you have to, call DevOps.
2. Know that edge cases are tough and put a limit on the effort you put into solving them.
3. Recognise when a solution becomes critical to the business, then get it into the DevOps domain.

DevOps Types:

1. Always be curating your data sets; good data makes for easier integrations.
2. Use a Privileged Access Management solution for managing privileged credentials.
3. Use a Privileged Task Automation solution for surfacing data to the Business Types. Delegate the task, not the privilege, avoiding the need for privileged accounts in the first place; it gives short-term gains that are easier to migrate in the future.

Instead of there being two routes to the goal, a hybrid route will be quicker and safer. Privileged Access Management and Robotic Task Automation can be built in along the way. In no time we’ll have our Tractor Factory delivering multi-coloured multi-functional Tractors to happier customers in a quicker timeframe and with less stock inventory. It’ll all be down to the right people, doing the right tasks, in the most agile way, with all the data and credentials safely secured.

Find out more about Osirium’s Privileged Access Management solution, the PxM Platform, and our Privileged Task Automation module.

‍