In his role as Tanium CISO, Christopher Hodson frequently meets with CIOs, CTOs and CISOs who are tasked with supporting enterprise-scale technology refactoring initiatives, often without the prerequisites necessary to ensure that information protection and business resilience are retained. This blog is 1 of 3 in a series examining digital transformation in the age of aggressive regulatory compliance, starting with how to think about the much-used, much-misunderstood term itself.
“Digital transformation” generally refers to the combining of process and technology to improve business operations, in part through the introduction of computing capability that replaces or augments manual operations. It’s an increasingly common executive mandate, especially from the board level: digital transformation can drive automation, which helps reduce complexity, preserve healthy bottom lines for the business, and maintain happy customers. What’s not to like, right?
The danger in this is that in the rush to achieve “digital transformation,” organizations are often putting the cart before the horse, especially when it comes to security and IT operations. More products that automate IT processes won’t make the business more efficient if they’re also creating visibility gaps among what’s being connected to the network. And automation won’t make organizations more secure, or more resilient to other forms of disruption, if they don’t have a handle on their basic IT hygiene.
Here are three key considerations fundamental to digital transformation.
1. “Transformation” requires knowing what we have
No, really, do we have a handle on everything?
To materially improve business operations and the overall customer experience, organizations must take inventory of current solutions and processes. service offerings and processes across the enterprise, legacy ways of working must be understood and documented. Transformation only occurs at the intersection of technology and process. Technology in isolation cannot solve any business problem. In my experience, the ‘digital’ in digital transformation is prioritized over the need to profoundly alter operational procedures, which causes major issues down the road.
To overcome issues pertaining to process opacity, many companies I engage with are seeing huge value from business process modeling (BPM). BPM allows a company to create a business case for transformation, identifying inefficiencies, manual effort and pain points in across existing business tasks. BPM often creates the business case for digital transformation and allows for semi-qualitative return on investment (RoI) calculations.
BPM or not, however, it is imperative that any company embarking on a digital transformation journey understands the breadth of its ‘as-is’ estate and realize that isn’t simply an incomplete catalogue of applications, but an architecturally-led assessment of:
- Organizational structures
- Critical business processes
- Data classifications
- Endpoint assets
- Data flows and processes
I have worked with several CIOs who are using digital transformation as a catalyst for a more robust regulatory compliance posture, complexity reduction and improved time-to-market of solutions. Security and technology leaders are working in concert with business analysts to translate business services from a functional level, through to the applications that serve them and the data housed therein. Such a model is hugely valuable in qualifying regulatory positions and highlighting critical business applications.
2. We need to define what, exactly, we’re doing and who owns it.
Too often, organizations think about service delivery in terms of time to deploy a set of applications, or to migrate a workload from ‘on-prem’ to the cloud. More often than not, value drivers are not satisfied to issues that manifest post ‘go-live’.
I have used the term ‘service industrialization’ for many years to describe the on-boarding of applications or infrastructure into an environment. The metrics for success across this process shouldn’t be based on ‘time to deploy’ or opaque project costs but focused more around organizational fit. I see too many instances where a fresh application is brought into a company without an understanding of:
- Who owns the service?
- How do stakeholders consume the service?
- How many people do I need to run the service?
Not being able to answer those fundamental questions will slow your roll, as they say, no matter how robust the application or service is on its own.
3. In the rush to ‘transform,’ let’s not just create more digital data sprawl
IoT, ephemeral cloud workloads, Docker containers, micro-services and Big Data – you might say that each of these technologies underpins digital transformation. Well, each also adds to a company’s digital exhaust, and when improperly managed or accounted for in the whole of a technology architecture, contributes to the challenges associated with both number 1 and number 2 above.
“Digital transformation” is a loaded term: often, a euphemism, and sometimes, a distraction. I have heard CIOs talk about cloud migration, for example, when really we’re taking a poorly performing, monolithic application stack and conducting a ‘lift and shift’ to another datacenter (invariably owned by a cloud service provider). Digital transformation isn’t just dramatically changing business services and isn’t just a good, budget-friendly opportunity to add more “stuff.” It provides an opportunity to step back and rethink the application architecture altogether.
In part 2 of this blog series, I’ll discuss why rethinking application architecture not only helps achieve the business productivity promises of digital transformation, but also keeps you ahead of the game in this age of GDPR, CCPA and other privacy regulations that have changed IT and challenged the teams that support it.