Current attempts by government to rein in corporate exploitation of workers and evasion of tax are nothing new. The Introduction to my latest book Supercommunities tells how battles between state and private interests over workforce and taxation have been bringing down societies since the Bronze Age. But now it's the Digital Age. Does global society finally have the opportunity to do things differently? And would this allow us to address inequality and climate crises?
The theory of Supercommunities offers a way for governments and corporations to work together, to empower hyper-local, hyper-connected, hyper-aware communities, where people work together at grass roots to create economies that are not only sustainable but also caring. The secret sauce is the underpinning technology enabler, the Internet of Communities - an open source platform that lets communities own their own data, and thus their own future. Communities can adopt this platform to become digitally enabled, in a holistic way that focuses on local wellness.
Control over local data allows community organisations to publish up-to-date wellness services to community members aiming to become self-activated, integrate services across sectors to enable wraparound care for people facing life challenges, and evaluate their effectiveness / gaps / overlaps to support continuous improvement. Along with these good things, however, communities also inherit some of the digital challenges already faced by public and private sector organisations.
Very few government or corporate bodies would claim that they are 100% satisfied with the way in which they provide digital support to their stakeholders. To the contrary, most openly acknowledge that budget and timescale have forced them to take shortcuts in building IT services. The future impact of taking these shortcuts, in terms of the additional costs of maintenance and improvement compared to having taken an idealised approach, is generally known as "architectural technical debt". This is rather unwieldy, so I will simply call it "digital debt". Digital debt captures the effects of building, in places, on sand rather than on rock.
Just like government and corporate bodies, communities need to understand their digital debt, and have a plan for managing it. What is more, communities have a particularly interesting challenge, since they are not a single organisation - rather, they include multiple organisations that work in partnership to deliver services. This is not uncommon. In the public sector, healthcare and defence form similar "systems of systems" to communities. In the private sector, banks, supermarkets, and other companies that deliver complex services are dependent on large, networked supply chains.
So, what is digital debt? Standard definitions break it down into deeply technical issues such as dependency violations, non-uniformity of patterns and policies, code issues, inter-dependent resources, and lack of mechanisms for addressing non-functional requirements. These arcane terms describe the extra things you need to worry about when maintaining and improving a structure that is partly built on sand. But here's the thing - they come from an earlier age of IT, when it was the norm to make grand plans, implement them over a period of years, and build to last. This is no longer how IT works.
In the last twenty years, development methods have changed. Agile approaches assume systems always to be in flux, architectural patterns allow systems to be broken into chunks and upgraded piecemeal, and open source frameworks evolve so rapidly that it is the norm to rip-and-replace them regularly. The underlying philosophy is that debt is an inevitability - we have always mortgaged the future by taking tactical decisions, so we should assume debt to be the norm, and adjust our techniques and tools accordingly. As a result, there is not a lot to be gained from analysing all the reasons why your current systems are imperfectly designed. Rather, one should focus on what you want them to do better. In this modern IT world, communities and others who seek to understand their digital challenges should focus on the real-world impacts of past time and cost constraints, rather than on the details of how IT applications and infrastructure are delivered.
So, here is a simpler way to think about digital debt, by considering it under 3 headings:
Capability Debt - what do stakeholders want to do online but cannot do at all?
Service Debt - what do stakeholders try to do online but find to be unusable or unreliable?
Data Debt - what data do stakeholders use that is incomplete, duplicated, inconsistent, untimely, invalid, inaccurate, or in violation of privacy?
A particular reason to think about digital debt in this way is that effective solutions to these challenges are rarely just about IT. For example, there may be manual workarounds that deal with Capability Debt quickly and effectively. Providing Frequently Asked Questions information and short explanatory videos may help address Service Debt at low cost. Dealing with Data Debt is often as much about improving how people enter data into a system as about changing the way in which it is processed.
To find holistic solutions for these issues, I like to use a visual technique called Wardley Mapping, in which you build and gradually refine a chart showing capabilities and the underpinning services as they evolve over time. I discuss in Supercommunities how a community can apply Wardley Mapping to all forms of planning. It is particularly useful for taking a non-technical, real-world approach to paying down your digital debt.