Before committing to a major software investment, the question that saves millions isn’t “how” but “why”, and answering it well determines whether the right thing gets built at all. Here’s our approach.
Suppose you’re after a bridge.
Let’s say that we – you and I – might talk about bridges, then. Your people reckon you need a bridge, from “here” to “over there”. Why? Well, that’s the right first question, and I’m glad we asked it. (The wrong first question would be “How?” – we’ll get to that.)
Blueprints for stability: designing with long-term vision
Bridges tend to be quite complicated beasts. Judging by the “here” and “over there” you waved your hands at, a plank between a couple of chairs isn’t even going to begin to cut it, not even as a team-building exercise.
But before we embark on a conversation about bridge-building, let’s just be clear … I’m not really in the business of advising on and building bridges, any more than you (in all probability) are really after one. A bridge, of course, is a metaphor, and a jolly good one too for our purposes.
Because, as I was saying, bridges tend to be quite complicated beasts. For a start, you don’t want your bridge to fall down – not ever! It needs to be safe; it needs to be able to carry the expected load, and more (both in terms of weight and amount). There will be a good deal of regulation to navigate, and quite rightly too (not all of it concerned with safety, either). And speaking of safety, you’ll be wanting your bridge to be perfectly stable – you don’t want to inadvertently build a bridge that resonates with crosswinds or even with foot traffic, do you? (Better not Google the Tacoma Narrows bridge, unless you’ve a penchant for unbounded aeroelastic flutter). And then there’s the road, rail, power, and/or water networks that need integrating on either side, assuming you’re not after building a “bridge to nowhere”.
Widening the span: designing systems that adapt to future needs
And once you’ve got a bridge – is it still safe, this year? Are you keeping up with the maintenance? Are we sure that there isn’t some crucial bolt rusting away, or microscopic but critical cracks opening in the concrete? Is the bridge being used as much, or more, than you expected, and if so does that matter – does your bridge business model still stack up? Do we still need the bridge at all, or is it time to investigate helicopters, or building “over here” rather than “over there”?
Yes, bridges are a complicated undertaking. So when you start asking “Why?”, you are absolutely asking the right question. Why are we proposing a bridge? What’s so important “over there” that we require a bridge to access it? Is there none of it “over here”? Do we need to get “over there” so quickly that the direct route – and all the difficulties involved – is the only option worth considering? Quite possibly, yes, indeed, a bridge is the right answer, perhaps even the only answer. It’s worth asking the “Why?”, though, if only so that you understand the requirement fully – delivering a footbridge when you need to let planes cross a motorway wouldn’t be ideal, and blocking a shipping route with a bridge that’s too low is unlikely to be popular.
What bridge building tells us about software engineering
We’ll retire our metaphor now – it’s done sterling service in conveying my general idea from “here” to “there”, but now let’s talk a different kind of engineering. Software engineering. (You see, that’s what we’re good at, here at Softwire – we are, naturally, very civil engineers, but not of the literal bridge-building kind).
There’s a great deal in common between our metaphorical bridge and real software. Software – especially up to the equivalent kind of scale, say, of an autoroute leaping gracefully across an entire French valley – comes with very similar demands. The need for integration with existing systems; the need for safety, reliability, exceptional performance under normal, adverse, and even adversarial conditions. Deep observability and insightful monitoring, perpetual vigilance, and ease of maintenance over time, with a reasonable cost to do so. All of these are vital considerations, often non-negotiable requirements, and they are core to how we approach our “Future systems engineering” practice.
However, we come back to that question “Why?” which I said was so much more important to ask before the “How?”. Just as with bridges, when a major and complex software investment is on the table, we need to ask why this, why now, what is “over there” that can only be reached via bridge? Are we proposing to build the right kind of software? Have we looked at the alternatives? Have we fully understood the regulatory environment, and how that might affect what might be built? Suppose there’s a bridge there already – rusting a bit, showing its age – does it merely need maintenance? Is a new bridge the right approach, or is a bridge needed at all, given that flying cars are now an option?
Asking the right questions before building the right thing
All of these questions – strategic questions – are vital to ask before committing to a significant future project. Having seen what we’ve seen, and built what we’ve built – not the Milhau viaduct or Humber crossing, true, but certainly the bespoke software equivalent – we’re well placed to advise you on the “Why” before working on the “How”. And as far as we can tell, that’s unusual!
So let’s talk about your future engineering needs. We won’t sell you a bridge – but we’ll answer the right questions and build the right thing – and build it very, very well – with you.
