What is DAM missing?
We never know what we’re missing until someone makes something that goes against all conventional wisdom yet succeeds spectacularly. Rediscovering the history of something recently is making me wonder what DAM might be missing, in software and in practice. Let’s begin with that example.
A de Havilland Mosquito B.XVI courtesy of Wikimedia
Wood is good
de Havilland Aircraft Company Ltd. had a history of building planes out of wood successfully with their founder, Geoffrey de Havilland, taking a different view to the rest of the airplane world. While they were transitioning over to metal, he persisted with wood because it’s light, easy to craft and easy to repair. This principle reached its peak with the DH98 Mosquito.
In 1936 the British Air Ministry issued the specification P.13/36. We can think of a specification as a request for tender (RFT). The core requirements of the specification were:
Twin engined medium bomber
Bomb load of 3,000 pounds
Range of 3,000 miles
Speed of 275 miles per hour
de Haviland proposed the design that would develop into the Mosquito. To simplify the story, the Air Ministry was expecting to receive proposals for bombers made of metal with armour and turrets with guns to defend itself from fighters. de Havilland approached the specification with a completely different mindset.
Make the plane out of wood because it’s light, cheap, has no supply pressures, is easy to repair, and has an untapped labour pool
No armour because it’ll make the plane lighter
No defensive armament because not having turrets, guns, ammunition, and crew to fire the guns will make the plane lighter
Put a couple of powerful Rolls Royce Merlin engines on it
The weight saving will make it fast enough to avoid the fighters
The weight saving will enable higher bomb payloads
de Havilland’s mindset also encompassed the view that the purpose of a bomber was to drop the bombs on the target, not to slog its way through fighters and shoot them down as it went. Instead, the Mosquito would be fast enough to avoid the fight altogether. Naturally, de Havilland was criticised at every turn because his mindset was completely against the grain, so the Mosquito went nowhere. But given time, persistance and the intense pressures of World War II, the design finally broke through. As early as February 1941 a prototype reached 392 mph at 22,000 feet. Even as a prototype it was faster than the Supermarine Spitfire at higher altitude with a greater range and higher payload.
The insane power to weight ratio meant that the Mosquito could be turned to all kinds of uses. Designed to be a medium bomber, it was first used for photo reconnaisance where its speed, range and altitude proved vital. But it was also used as a weather plane, pathfinder, target marker, night fighter, strike fighter, anti-shipping strike fighter, and more. This incredible flexibility was a feature of its design, not an accident. For example, RAF Bomber Command was flying at night to minimise risk from the brutal German air defences. By this stage, radar was fully integrated into air defences, but despite this, Mosquitos had a high survival rate. Someone realised that this was because the Mosquito was made of wood which reduced radar reflections making it stealthy. So when German nuisance raids on Britain with planes equipped with radar to see night fighters began, the RAF sent up Mosquitos with their own radar systems and armed with four 20mm Hispano cannons. These night fighter (NF) Mosquitos couldn’t be seen by the German planes because they were made of wood, could see the German planes because they were made of metal and then shot them down in great numbers with their powerful armament. NF Mosquitos were then sent over to loiter over Luftwaffe airfields. When RAF bombers approached enemy territory, German radar would detect them and night fighers would be scrambled, only for them to be immediately attacked by Mosquitos they couldn’t see.
The Mosquito’s history is littered with such stories, including the time they interrupted the broadcast celebrating the 10th anniversary of the Nazi party by destroying radio transmitters, knocking first Göring and then Goebbels off the air. Small wonder that Göring said: “It makes me furious when I see the Mosquito…I turn green and yellow with envy.” Göring, a fighter ace from World War I, was so envious he tried to build a near clone of the Mosquito also made of wood. The plane, dubbed the Moskito, got killed by political opposition that said that building planes out of wood was stupid.
The incredible flexibility of the Mosquito, borne of its fundamental design philsophy, enabled a spectrum of variants and mission applications that would otherwise have been impossible. de Havilland showed the whole world that they’d gone down a rabbit hole deriving from a lack of appreciation of the impact of weight, speed and manufacturing.
Building Mosquito Aircraft at the De Havilland Factory in Hatfield, Hertfordshire, 1943, courtesy of Imperial War Museums
A DAM rabbit hole
The Mosquito shows that the value of approaching problems with a different mindset is that it can open up a vast landscape of possibilities that were unknown because everyone was thinking inside the box. So what can we learn from the Mosquito? Rediscovering this history has made me ask the following questions:
Are DAM systems too heavy because they’re being loaded up with features that stretch beyond managing assets?
Are such designs expensive and difficult making development and support overly complex?
Is attempting to answer every question by saying “AI” creating more issues than it solves?
Do the above factors increase system costs?
Does the complexity of modern systems create too many unexpected outcomes?
Does the complexity of modern systems make integrations overly difficult?
Does the complexity of modern systems threaten adoption?
Does the scale and complexity of modern systems increase staffing requirements?
Does the capability to customise DAM systems increase vendor lock-in?
Breaking down DAM and related functions into separate, specialised applications could allow for greater modularity. Each application can focus on its core functionality, making it easier to develop, maintain and upgrade. This could also simplify configuration as clients can acquire and configure only the applications they need. This offers potential in scalability as new applications to carry out essential functions could be acquired as needed and in a way that reduces the impact upon existing functions. This modular approach also offers the potential to simply integrations as each application is specialised, reducing the complexity of integrations to help make them cheaper and easier.
Smaller scale applications can iterate and innovate more quickly. As user or client needs change and new technologies emerge, they can respond far quicker than heavy applications, especially if clients have customised them. Smaller applications are typically easier to maintain and support, minimising downtime. Itcould also reduce costs as organisations can acquire the best applications without having to pay for a range of features they’ll never use.
“There are no solutions, only trade-offs” - Thomas Sowell. This is something that anyone who works in a large digital landscape will likely appreciate. So, what are the trade-offs for a modular approach?
With a modular architecture there would be many more systems which would likely present coordination and governance challenges. Data consistency across a larger number of applications could also present challenges. With so many more applications in the stack, ensuring that every new application can be slotted in seamlessly becomes more challenging. A wider number of applications would also create user experience challenges as maintaining consistency is already almost impossible with a handful of applications. More applications could well mean having more vendors, each with their own contracts, support and maintenance agreements.
There’s also a deeper challenge which is that no product manager at a vendor is going to wake up and think, ‘Wow, I can’t wait for the opportunity to rearchitect my entire code base’. Take any of the big vendors who have a big suite of MarTech applications: it’s impossible to imagine any of them trying to slice up the functionality their suite offers into a wider, more specialised, suite of applications. And it becomes harder still to imagine this when we remember that many MarTech suites have been created by acquisition rather than development. DAM systems especially fall into this category. This means that many of the functionalities across MarTech suites have different code bases and designs. Imagine trying to unify all of that.
This suggests that the modular approach would require a new vendor to develop from scratch. This would enable a suite to be built that would have a consistent design and user experience with an API designed to be capable of bringing a wider array of applications together. And who’s going to be able to attract the level of funding needed to do that in MarTech?
A de Havilland Mosquito attacking Gestapo headquarters in Copenhagen, 1944, in the Aarhus Air Raid, courtesy of War and Son
We don’t know what we don’t know
I started out by wondering if DAM has reached the same place that bomber design did in the 1930s and early 1940s. Are we so far down the road of what’s commonly understood to be DAM in terms of technology and practice that we don’t know what we don’t know? Put simply, we don’t know what opportunities are waiting for us if we can but think like Geoffrey de Havilland.
I can’t authoritatively say one way or the other. DAM was already well defined before I entered the field. The tools made available to a practitioner of a discipline shape how we can practice. Run this through enough product lifecycles and perception of what the discipline is will start to become constrained with practitioners regarding certain functionalities as standard. This means that it’s difficult for me to break out of the loop and think about DAM in a fresh way too. And practicing DAM means that I don’t have the opportunity to get my hands on a real spectrum of applications.
I’m also aware that DAM managers have a reputation for complaining about DAM applications as well as a tendency to complain about new vendors entering the marketplace. Perhaps we do this because we don’t want to see more of the same. The risk is that if a Geoffrey de Havilland came along, a lot of us would roll our eyes and go back to complaining. We don’t know what we don’t know and ignoring or dismissing new vendors risks us never knowing it.
Is there a fresh mindset to be found in the practice of DAM that could offer a new way forward or is it all downstream of the technology? Do we need fundamentally new tools to play with to farm new, fertile ground? Where is our Mosquito?
‘We inadvertently create the complexity of tomorrow by trying to solve the problems of today with the mindset (models, theories and methods) of yesterday. Perhaps the easiest way of breaking this “curse” is to begin changing the mindset’ - Erik Hollnagel, Coping with complexity: Past, present and future, 2012