How data-modelling acts as a focal point for success
In a typical enterprise-change context, data-modelling often gets relegated to later phases of the project.
It can be seen perhaps as a bit of a governance overhead - one of those red-tape things to get ticked-off later.
"A data-model's just a weird diagram, right? Only the techy folks care about those, we can get them to write something up, after they finish building the product. Otherwise, it'll just slow us down."
This all-too common, and as we'll see, ultimately damaging attitude comes from a fundamental misunderstanding of what data modelling is, and what it's there to do. Perhaps a good place to start is to clarify what we really mean when we talk about Data Modelling.
Data Modelling is an exercise that captures an understanding of a domain of discourse, in a form that can be communicated to the people and systems who need to share it.
The output of such an exercise should generate artefacts at different levels of abstraction - there to meet the needs of people working at different levels of detail - models don't exist in isolation, they should provide mappings between perspectives.
Perhaps even more critically, we need to make our understanding accessible to machines too. An LLM can't know how your business works. To get any kind of benefit from AI adoption, it's necessary to capture and encode the meanings embedded in your domains of activity in forms that can be accessed, read and understood by the context-challenged capabilities of an LLM - or any other system.
Unless you do that formally, your AIs will do what they do best in the absence of context and make stuff up.
Understanding is hard. Arriving at or negotiating a commonly agreed understanding that remains coherent across contexts can be even harder; and being able to share that understanding accurately and with fidelity is no walk-in-the-park.
When building a team to perform enterprise change, you need to assemble people from multiple fields of expertise to focus on the same thing. They will naturally all have different views, different perspectives, different ideas about, well, everything.
A good piece of modelling-work should result in a navigable map of the concepts around which different stakeholders (both human and machine) can orient themselves. When working across perspectives - everyone (and everything!) must be able to access a shared model of meaning in order to help process nuanced terms, language and understanding.
It needs to cater for people who want a broad, helicopter view of things (perhaps a Project-Manager who wants to align tasks to 'chunks' of knowledge), while also capturing enough detail to support interpreting some technical content authored by an expert in the language of their own field or system.
It can be tempting to file these kinds of undertakings in the "too hard" folder, "Why don't we just get on with delivery? Leave all this boring 'understanding' stuff to someone else?" That's always an option, but it is a costly one - both in terms of risking project success now, but more dangerously, in actively harming the enterprise longer-term.
In already-complex undertakings, the additional friction generated by contextual misalignment tends to generate the following repeatable set of issues:
For example, in one engagement, a business had kick-started an ambitious project to replace a suite of legacy systems but had failed to take the time to understand and properly model the data in the domain. Instead, they engaged a vendor to get on with delivery. Based on the size of the team alone, the project burn rate was c. £30,000-per-day, and for months on end, multiple teams struggled to wrestle with conflicting interpretations of the same thing. It was chaos, the deliveries from the vendor were untestable, and a number of knowledgeable resources decided to quit rather than continue under the strain. It took a good 18-months to catch-up and develop/align a working data-model before things started to get back on track.
If you've worked on one of these big, complex projects, you'll recognise most, if not all of these tell-tale symptoms of conceptual misalignment. Working in a project that suffers from these issues sucks, and people will naturally consider doing something less painful with their time, taking their knowledge and expertise with them.
Worse though, say such a project does manage to get itself over the line, and embeds its incoherency deep into the organisation. Repeat this pattern enough times, and this adversely affects an organisation's ability to conduct future change. Why? Because when understanding isn't captured, every change becomes bespoke. Then, when change is required in the future, the cost of everything being expensively reverse-engineered has to be factored in.
Another example was a client whose core business ran on a venerable mainframe. Over c. 40 years, different teams had expressed their own interpretations of the same set of business processes in various creative and ad-hoc ways, each shoe-horning their takes into the same set of core database tables, overloading the established database fields with implementation-specific content. A few key individuals knew where and how things worked, but this knowledge had started to dissipate as individuals retired and there was no consistent documentation. When it came time to look into replacing or upgrading their aging hardware, it just wasn't possible without a complete and prohibitively expensive reverse-engineering of their whole business. A number of key business aspirations had to be dropped because the practicality of change was simply too expensive.
The results of not taking data modelling seriously can cost businesses dearly in terms of wasted money, time and resources, and as well as lost opportunities.
So, what can we do?
First, we have to change perceptions. Modelling isn't a dry, technical exercise, it's a foundational requirement for building the kinds of cross-disciplinary communities you need when attempting to undertake complex change.
It's a way to preserve your organisation's proprietary knowledge and protect it from eroding over time as people come-and-go, or as the business changes.
It maintains clarity and coherence in how an organisation constructs its core business - avoiding costly spaghetti implementations, reducing entropy and enabling agility.
Done well, and keeping these benefits in mind, modelling provides a simple and practical recipe for success in an enterprise environment.
At Icon, we feel it's important to keep these benefits front and centre across all our data engagements, and with a wealth of industry experience to help develop, mature and unlock your knowledge-assets, we're well placed to promote success in all your enterprise-change endeavours.