In this day and age of self-serve data platforms, microservices, and artificial intelligence, why do our Business units rely on Excel for running business-critical workflows? Because of functionally stupid governance—our sociotechnical systems are not cross-functionally aligned with the sociotechnical practices and needs of business operations. In plain English:
- Stop trying to build enterprise architecture, systems, and platforms
- The enterprise isn’t doing business—it’s a wholly abstract entity
- Operational units do business
- Start building products for them
Advice to the reader. This short article tries to help you discover a problem—the first step of a design process (specifically, of the Double Diamond design process model)
Shadow Data Work: Actual Best Practice In Business Operations
Doing business in today’s fast-paced environement is challenging. It’s a testament to the resilience and resourcefulness of the people that are doing data management and data work in our biz units that we are able to even stay in business. Our opportunity landscapes are fast becoming unmanageably volatile, uncertain, complex, and ambiguous (VUCA).
Our biz units fundamentally operate on urgency—adapting to new circumstances and getting things done at speed. They have to make do with the resources available to them within the agency bounded by their budgets, competences, mandates, and remits. They cannot wait for central functions to come out of their silos to resolve bottlenecks and blockers with robust and sustainable sociotechnical systems and practices. Biz units have to cope—play the cards dealt to them and work around structural problems to deal with their situation. This is suboptimal, for sure, but shadow data work done by citizen data managers and data workers is currently best practice—because that’s as good as it gets, given the circumstances.
Shadow IT is a problem—and that problem is that IT isn’t doing what it should
Central functions complain about Shadow IT and business operations being “too busy to improve”. This indicates that the central functions have a pretty sizeable blind spot. Biz units do shadow work precisely because the central functions are not doing their jobs. On second thought, let’s nuance this a bit. There’s a more productive and actionable way to frame this.
Central functions are, in fact, doing their jobs. The problem is that the jobs they do try to serve a ‘customer’ that only exists in the abstract: the enterprise. The enterprise is just a faceless collective that obscures the various units trying to do their jobs—to the best of their existing abilities. To be of real service to the best interests of the enterprise as a collective, central functions must see the operational units as their customers—and build products for them.
Build products—not point solution spaghetti
Now, we mustn’t jump straight into what Double Diamond calls solution space. If we do, and we start replacing enterprise systems with more or less tailor-made services for biz units, we risk rushing head-long into a monolithic mess of point solutions—the organisational version of what programmers call spaghetti code: a ‘spaghetti’ of projects and processes, if you will.
Designing, developing, and deploying data-driven products that are useful to our ‘customers’ and adoptable into their sociotechnical practices is no trivial thing. This goes double for useful and adoptable products that scale gracefully with the business as it grows. Well-designed products require well-organised productisation efforts.
- On the strategic level, you need to source productisation capabilities if you do not have them already
- On the operational level, you need actual cross-functional biz-data-tech teams that actually co-create self-services with and for the actual ‘customers’ that increases their productivity
- On the tactical level, you must organise, govern, and manage your productisation efforts
Delving deeper into making data work products
If this article makes sense to you, we can recommend a beefier article on designing, developing, and deploying products for data workers. It takes central data management as its starting point, rather than business units doing shadow data work—but it delves deeper into the fundamentals of making data work products.
Double Diamond is a productisation tool
Productisation capabilities are strategically important. Productisation transcends traditional product development, embedding itself as a core organisational strategy. If we expand slightly on that, it involves tools that help you productise. We argue that Double Diamond, a design process model, not only simplifies the complexity of innovation but also institutionalizes a dynamic framework for continuous improvement and market adaptation.
The first ‘diamond’ discovers (divergent phase) and then defines (convergent phase) the problem space in the form of some use-case we can productise. This article speaks mainly to problem discovery. The embedded article puts its focus on problem definition, the fundamentals of productisation. Additionally, it takes a few steps into the solution space, the second ‘diamond’. The first step explores paths to ‘solutions’ by developing design patterns. The second, then, defines and deliver composable products.
Many people perceive the model as a linear process, where you discover-define-develop-deliver in that order. At Dairdux, we tend to see it as a map of different regions where the design ‘process’ can trace its erraticif not random journey.
Double Diamond works in reverse, as well. You can also work the Double Diamond backwards. Doing point solutions is fine, as long as you dedicate some effort to capitalising on them. By iteratively wresting something that is more generalisable from them, you develop patterns from delivered solutions, pointy or not. Eventually, you can define a set of use-cases, and, finally, discover the problem. This can help combat the very human tendency to jump from the surface of the problem to conclusions about a solution at the first sign of an opportunity for one.
Our interpretation of Double Diamond can be found in another article that tackles productisation in the abstract.