Every organisation has its commonly used phrases and, since starting in Defra in October, I keep hearing people use the term ‘we aren’t trying to boil the ocean’. It’s an evocative term, but we could use it to describe Data Architecture.
In Data Architecture, you can’t boil the ocean without understanding the impact on every organism and item that exists within that ocean: every shipwreck, every lost item, every reef, and every living thing. From the tiniest plankton to the largest whale, recording every item, where it can be found, and how it impacts on everything else in the ocean, is often the sort of challenge you feel like you’re taking on when designing an organisation’s data architecture. You may think, then, that this sounds like an impossible task!
So why do we need Data Architecture?
It’s all about integration. How pieces of the data jigsaw sit together. It’s about defining business data requirements, how they integrate across services, control of assets, and standardisation. It links business and technology architecture and helps organisations manage change and improve effectiveness, because it is about knowing what information is needed to run the business. Done well, it’s both an influencer and an enabler.
Without Data Architecture we will build and buy isolated information systems, build tactical approaches and end up with a complex – and expensive – set of systems which need supporting. And if one changes, who is going to assess how that impacts all the others?
The Rural Payments Agency did this for their new systems, to better understand how data is integrated, and to ensure that their iterative developments were impact assessed across their technology landscape. Doing this at Defra presents a whole new challenge for the Data Transformation Programme, because change is happening everywhere. It’s important because, to be truly data-driven, Defra needs to understand the full data lifecycle within its systems and how we can improve data, so that it becomes the sort of critical information we all need to provide a service to our colleagues and customers. The starting point is understanding what data we have, where it’s stored, how we use it now, and how we want to use it in the future.
We’re starting this effort by categorising DEFRA’s data into “subject areas”. This enables us to partition the data and information landscape of an Enterprise into areas with a manageable scope.
The priority for me is ‘Customer’, because everything we do involves our customers and we need to look and how we improve and simplify the customer user experience, data sharing and data governance. My colleagues in the Data Transformation Programme are all working hard on these areas, but we’ve also been talking to those working on the Customer Strategy, implementing cross-cutting IT Solutions and Digital Transformation.
We all store customer data in many different systems and I know how frustrating it must be for our customers to register multiple times to use different services. This is very timely because we are starting to implement Customer Relationship Management systems, so big questions need answering:
- Should we register customers once, for multiple services?
- Should our customers manage all their transactions through self-service?
- Do we need different customer-facing systems for different services?
- Should our Customer Relationship Management hold all customer data, and distribute it to other systems?
Answering these questions helps us to design the appropriate data architecture for our services, but we can’t do it in isolation. We are working closely with the Technical Architects and colleagues across the business to ensure we build the right solutions that deliver services without compromising the data.
Each of Defra’s agencies has its own identity and ways of doing things, but as we all join together we have to consider how we maximise our usage of data and ensure it supports and improves our transformation targets.
It’s an exciting time to be in Defra, and therefore an exciting time to work in Data Architecture.
