data architecture approach blog post

When building data architecture, focus on impact

The majority of projects to build data architecture fail. There are a myriad of reasons why, but from Conjura’s point of view, the overriding issue with all data architecture projects is that no thought was given to how data would actually be used; used by the analytics team; use by the marketing team; used by the finance team and used by the organisation as a whole.

In this article, we outline a better way to approach these projects, an approach that focuses on impact; on designing data architecture to meet a small number of specific and business-critical use cases. At Conjura, we believe this is the most effective and efficient way to design your data architecture, and it’s the one we follow with all our clients.

The common approach to data architecture: data for data’s sake

Most organisations, big and small, now recognise that data is a hugely valuable asset and using it effectively can generate an important competitive advantage. That means that most organisations also recognise that they need several tools to collect and process data to make it available to users i.e. they need data architecture. 

What is often missing in these organisations is a view on why they need data and what they will do with it once they have it. Therefore, most organisations will embark on a complex and often expensive project to implement architecture, without any clear use cases in mind. Data is included for data’s sake, not because it adds any value to the outcome. 

This is an issue that Conjura has come across in businesses of all shapes and sizes, and it can have dire consequences for the success of the project. Without clearly defined use cases, the architecture will try to be everything to everyone, but it often ends up being nothing to no one. Without clear outcomes, there will be scope creep, delays and cost overruns. Ultimately, projects like this have a high probability of failing. 

Conjura has seen 3 month projects turn into 18 month sagas; has seen 5 figure implementation costs turn into 6 figure disasters. What’s worse, after the projects are finally complete, Conjura has seen the outputs quickly shelved due to lack of use and a lack of confidence in the numbers from the end users.  

At Conjura, we believe there is a better way.

Conjura’s approach to designing data architecture: focus on impact

When approaching data architecture design, Conjura recommends focusing on the impact of data for the organisation. Conjura recommends first taking the time to understand how the data will be used, how it will support the key business objectives and who will be using the data. 

It sounds simple, but it isn’t. 

One of the most difficult decisions within a business that wants to develop sophisticated data architecture is to decide on what use case is most important and impactful. Data can support any business objective, so this decision requires being very clear on strategy for the business. 

Should the business focus on lowering the cost of customer acquisition (CAC), monetising existing customers, increasing customer lifetime value (cLTV) or decreasing customer churn for example? The answer is, of course, different for every business and will depend on multiple factors. 

What’s most important is that once a set of use cases has been prioritised, they should drive all subsequent data architecture decisions. This requires a deep understanding of data architecture design and of how data can support business processes and decisions. Without the necessary experience, the link between your data architecture and your use cases will be missing, putting the project at risk. 

Designing your data architecture for impact

Conjura has the necessary expertise to design data architecture and the knowledge on how data can be used to drive the business. What it doesn’t have is a deep understanding of the businesses we work with.

That’s why Conjura spends at least a week understanding our client’s business, how it operates, what data it has available, who will be using data and where there is the biggest uplift potential. We’ll use this information to work with the business on deciding what use cases to prioritise and how to design the data architecture. For example, for a B2C subscription business, we may focus on the marginal cost of acquiring a customer and the scalability of marketing channels. We’ll identify whether lowering the cost of customer acquisition or increasing the number of leads generated will have the greatest impact. We’ll then design and build the data architecture to support this goal.

The point is that there must be a collaborative approach, among several stakeholders, when designing data architecture. The design process must include information from your data engineers, your data analysts, the non-technical end users of data as well as the senior management team. Without this, your project will be missing some key information, and will have a higher probability of becoming an expensive failure. 

Flexibility in the approach

Businesses and strategies change. Therefore, key use cases will also change. It is important to take this into account when designing data architecture. When you build architecture aimed at supporting a defined set of use cases, it does not mean that the architecture cannot be used for any other purposes. Instead, Conjura recommends taking a modular approach to design that will allow the architecture to be modified and adjusted over time as the business changes. 

While this does mean that the architecture requires iteration over time, this is true of any approach to data architecture. The key difference with Conjura’s approach is that the initial effort and cost of designing and building the architecture is much less (because the scope is clearer and more defined) than trying to build a huge, all-singing-all-dancing solution that the business ultimately has no use for in the first instance.

Other factors to consider

Of course, there are multiple factors that should be considered when designing data architecture. These include cost, implementation timelines, feasibility and the ease of maintenance. We don’t go into these factors in this article, but check Conjura’s blog in the next few weeks when we’ll cover these in more detail. 

If you’d like to speak to Conjura about your data analytics architecture, please get in touch via foresight@conjura.com.