A recent article on TechCrunch suggested that the path to digital transformation for large organisations starts with small pockets of innovation.
It talks about the ‘bi-modal’ approach to doing IT (popularised by Gartner):
- Mode 1 is traditional, waterfall, risk-averse approach
- Mode 2 is new, agile, digital, innovative with a higher appetite for risk
In principle, I agree that IT has to be bi-modal, but the rationale and execution as explained in this article is, I believe, flawed or incomplete.
Mode 1 and Mode 2 are not about different ways of building and managing software as such, but about the scope and interest of the users, with which there are strong parallels. Mode 1 inherently supports many stakeholders using a least-common-denominator approach. Mode 2 supports a narrow set of stakeholders very, very well.
Historically, Mode 1 has mainly been comprised of systems focused on ERP for financial planning and management, accounting systems, HR systems, critical payments infrastructure, etc. Almost everything else is Mode 2 by default – i.e., where the benefit to the local users usually outweigh any need/benefit to the wider firm or business line.
The problem is, as organisations mature, Mode 2 systems inevitably become more Mode 1 in nature, as the data they capture, process and control gets dispersed to other systems and processes, and as they in turn depend on more data and processes from other systems.
And this is when complexity becomes an issue. The Mode 2 way of working becomes subject to Mode 1 constraints because of the sheer complexity of dependency management, and as a consequence, projects take longer, cost more and clients get increasingly dissatisfied with their IT service.
So part of the challenge re digital transformation is how to get (legacy) Mode 2 applications that have become Mode 1 back to Mode 2 again.
Perhaps part of the answer is to recognise that parts of the legacy Mode 2 applications are actually Mode 1 (enterprise), and to carve out the remaining parts of the legacy Mode 2 applications that are truly unique to specific users or localised use cases.
The key characteristic of Mode 1 applications must be ‘planning’ – they by definition will take time to get right, and while agile practices and architecture can certainly be applied, the sheer number of stakeholders involved will limit its agility. In the future, firms will compete on how agile their ‘Mode 1’ applications are, but today this is less of an issue as almost all firms in a given industry/sector face the same legacy challenges.
Innovation today is driven by Mode 2 applications; these indirectly generate requirements into the Mode 1 solutions. For example, as soon as another application requires data from a Mode 2 application, this implies that data is Mode 1, and should be a hint that the Mode 1 ‘service’ should now accommodate that data.
The basic premise is to keep Mode 2 applications as simple (in enterprise terms) as possible, to continually drive enterprise-relevant functionality into the Mode 1 enterprise-wide eco-system, and to continually prune such functionality from the Mode 2 application implementation.
The Mode 1 applications then become enterprise services, and can adapt agile practices appropriate for their domain. Mode 2 applications remain highly agile, with a high degree of risk and a high degree of innovation.
But how can we identify these candidate ‘Mode 1’ services from legacy ‘Mode 2’ applications, and how can these evolve into enterprise solutions in their own right?
That is the subject of another post…