Making the case for sustainability data products
I believe the year was somewhere between Gangnam Style taking over the internet and Germany winning the FIFA World Cup Trophy. Server racks hummed in corporate broom closets and my hair follicles had just been introduced to the concept of planned obsolescence.
Things were not going well in our project. A perfect storm of internal miscommunication, sub-par documentation and unforeseen personnel changes was about to run aground our 1,5-year implantation voyage of a critical customer system. As the skipper of the project, it was my responsibility to share our analysis of the situation with our client. After a concise presentation, laced with a fair dose of humility and anxiety, I finally managed to stop talking and asked our client their take on the situation. The client took a sip of coffee, leaned back in their chair, and stated the obvious. “Your complexity should not be my concern.”
It was kind of a douche thing to say, and I often relive this discussion as I’m chopping a particularly gnarly piece of wood at our summerhouse. But that phrase also carries a powerful clarity of thought and direction, and that is why I’m writing about it today.
For the sake of clarity, I’ll quickly tick a few boxes on commonly understood truths
Leaning on the cynefin framework, working with data in an enterprise environment can be anything from complex to chaotic, but it seldom is clear. The intricacies of governance, observability, automation, autonomy etc. are most likely already familiar themes to you so let’s just agree that this stuff is difficult.
Secondly, developing a product is not for the faint of heart. It’s a never-ending, ulcer-inducing balancing act of desirability, feasibility and viability that lands beautiful products in your UI of choice.
And finally, the state of sustainability data in your organisation is terrible. Some of it lies mangled in the deep bowels of a three-letter ERP, some has been splashed around various excels, and a surprisingly larger part of it doesn’t exist at all: It is conjured up once a year to soothe the regulators that be.
As all of this is undeniably true, what is the ecologically sourced silver bullet I’m about to serve you to fix the sustainability data problems your organisation has? And how does this relate to the verbal spanking my client gave me? Well, if you bear with me for a couple of minutes, I’ll cross-pollinate sustainability and data product thinking, ramble a little bit about thermodynamics and hopefully, I’ll find a neat way to loop back into the lesson I learned as a young professional.
Let’s start with products
I mentioned earlier a common framework of feasibility, viability, and desirability that all product teams should strive for. In short, a product should be technically achievable to develop, and fulfilling the customer needs should convert into a business case that justifies the existence of the product. So, what’s the problem?
With data products, it’s complex. Some of it is real and true, but a lot of it is just self-cultivated inertia in siloed enterprise environments. What does this mean exactly?
For the sake of argument, let’s imagine you’ve identified a customer need relating to data that resides on servers in your production facilities somewhere overseas. To fulfil the customer need, you need a small portion of this production data. You’ll also need to pull some additional data from a couple of DWs you don’t have access to, and possibly deviate from some common naming standards along the way. This is as common as it gets and there is a 90% chance, you’ll never ship a line of code because things are internally perceived as complicated or complex.
To add insult to injury, you’re reminded that your organisation has 50,000 customers and all of them have varying needs regarding your idea. If you want to walk down this path, you’d better serve all of them or else some manager in a suit will get cross with you. You close the Teams call with an Area Business Director and find your idea on a long-term development backlog, also known as the boneyard, where promising ideas are planted on the graves of conflicting interests.
So, how do data products help with any of this? Let’s start with desirability. No product must serve the whole market. If you try to address all the customer needs out there, your idea will be either diluted to such a low common denominator that there is absolutely no value left, or vice versa it will be swamped with contradictory demands that make it unfeasible to execute. What does good desirability look like? A product team’s main mission is to justify its existence with a clear solution-problem-fit that they are making an impact on. For desirability, if a data product team has identified a customer need that is big enough to warrant a solution, they should have the freedom to commit themselves to solving it. Big enough can mean a meaningful portion of the total addressable market or even just a singular problem big enough to warrant a solution.
What is meaningful or big enough? That brings us to the viability of the solution. As I wrote earlier, viability refers to the product having a business case to lean on. Data product teams do not usually reside under profit & loss and as they often serve internal customers, defining viability can be a messy ordeal. So, how can we define viability from the depths of a matrix organisation structure? Simplicity is a blunt instrument, but it is just what the doctor ordered. If you’ve identified the customer’s need, it is your job to secure a budget to solve it. Don’t aim for a 12-month runway financed by business, but make sure they have enough skin in the game to be interested in what you’re up to.
So, you’ve managed to cajole the powers that be to fund you half the way for your first release, where’s the rest of your budget? That brings us to feasibility. Corporate environments are rife with good IT-owned assets for you to use, such as infrastructure, platform services, data warehouses, APIs etc. As you will be utilising these assets in a way that helps you get the job done, whilst possibly experimenting with novel methodologies, it is customary that IT foots part of your development costs in the form of resources. It is good to note that feasibility is the slickest of all these three slopes. In product-based thinking, “good enough architecture” will get you somewhere, but you will run into the issue of scale and industrialisation eventually. Simultaneously, you should not technically overinvest in an idea that has yet to meet the customer.
Reflect on sustainability data
Alrighty, now that we’ve sorted out the product stuff, let’s pause for a moment to reflect on sustainability data. And by sustainability data, I don’t mean a corporate responsibility report, but the actual data of the environmental footprint and handprint of any organisation.
Since we’ve spent a fair amount of time lamenting over complexity, we might as well examine the second law of thermodynamics for a moment. It states that in a closed system, randomness and disorder – entropy – left unchecked, can only increase. Antientropic thinking has also been applied to software development and refers to the inevitable degradation of any software product with a lot of dirty code. Now folks, sustainability data, if any, is entropic by nature. Historically it has been undefined, unnurtured and to be frank, unwanted. This is about to change.
We’ve been helping our clients with sustainability data-related practices for a fair amount of time, and we believe the time is right to start applying some antientropic thinking into the equation. Yes, I’m referring to sustainability data products. The example I gave earlier of a hypothetical data product need is present in the form of sustainability data in every European organisation. Sustainability data is now needed – desired – as part of product-related data that flows through a value chain. Regulation not only requires you to report your own environmental impacts, but also to collect this data from your own supply chain and pass it on to your own customers. Viability – the business need – will most likely manifest first as a hygiene factor to get you through the door of a customer’s business. The largest and most forward-leaning customers are setting their beyond-regulation requirements for a product carbon footprint and life cycle assessments. With desirability and viability addressed, we’re left with the issue of how to get this done in a feasible manner. Once again, a product-based approach carries a lot of merit, but as you will be starting from scratch in a complex environment, we advise you to keep three principles in mind.
The heading of this text is “Sustainability data, should you give a f?”. You should, and actually three to be precise. I’ve written earlier about the three Fs of sustainability data – fidelity, friction and frequency and stand by those words. In designing your first sustainability data product,
- set a realistically ambitious target for data (fidelity) that is sufficient to your customer,
- make sure your sustainability data product reduces manual work (friction),
- and that the product contributes to making up-to-date data accessible to its users (frequency).
A decade ago, I was reminded that my organisation’s self-inflicted complexity is primarily my organisation’s problem and shouldn’t be passed on to the client. Those are wise words in any business you’re in.
For sustainability data, we’re all sitting around the same round table. And by this, I’m not only referring to circular value chains but to the fact we all inhabit this small planet of ours. For us to start doing things right, we need to establish what we are doing in the first place. Our complexity is our joint concern and making future-proof decisions in our day-to-day business practices starts one sustainability data product at a time. As Solita, we’re here to help you on this journey.
If you wish to hear more about our sustainability data product thinking and architecture offering you can contact us!
