This festive season, I’ll probably find myself pressed into the company of people who don’t know what I do, and who will make the mistake of asking. I’ll tell them I’m a Systems Engineer, and few, not even other engineers, will know what that means. Some will abruptly excuse themselves to find another drink to go with the perfectly good one they’re already holding; others may smile and nod and suddenly recognise an old friend that they must catch up with right now on the other side of the room; most will simply feign imminent illness. A few, however, will experience that critical lapse of verbal control familiar to all social drinkers, and will unthinkingly ask for an explanation, which I’ll be happy to launch into even as their words catch, falter and die in their regretful throats. At the start of the evening, this will be relatively straightforward, but those asking in the whimsical after-hours will be on the receiving end of something more like what follows.
The Intractable Nellie
Way back in the day, when men were real men, analogies were tortured and metaphors were mixed like drinks, a bunch of blindfold engineers got together to eat an elephant.
And because they were seasoned professionals, not some bunch of blindfold academics or west-coast wannabe-billionaire teenage beanbag-dwellers, they appointed a project manager and so became a team. And the project manager did the stuff project managers are supposed to do, worrying at the money, tracking timescales, dividing the task into smaller and smaller chunks and directing each eager resource at an appropriately-sized portion of the problem, according to long experience of similar jobs over an extensive career of circus animal consumption.
And so the job began. Each engineer groped his or her way to the assigned body part, took out the appropriate tools of his or her peculiar discipline and began his or her appointed task with admirable vigour. And everything went well for a while, the sound of productive knives, forks, spoons, nail clippers, hair trimmers, gardening tools and teeth and so on drowning out the regular milestone screams of payment being extracted from the budget-holder in arrears.
Then, abruptly, the sounds changed. The scrape of stainless steel on bone, the tearing of wrinkly grey flesh gave way to the sounds of clashing cutlery, professionally-acceptable but still expressive swearing and the laceration of many fingers. The engineers had reached the interfaces of their component limbs, beginning to meet in an unplanned and undocumented fashion. Human, rather than pachyderm, blood was beginning to flow and work slowed to a crawl. Also, the left ear eater had been doing some exploratory scoping, and had begun to form the suspicion that the ear was somewhat larger than originally predicted. The self-appointed manager of the right-rear-leg-and-buttock team was reporting similar issues, and the less said about the emerging scale of the firmware, the better.
Faced with a looming elevation in workload, the project manager went by the book, issuing an early warning to the customer that the task was more mammoth than understood, and that something may have to give. The customer expressed bewilderment, accepting that estimation is tough but wondering how it was that, with the elephant supposedly three-quarters-eaten already, the team had only just discovered such an error in scale. The project manager explained, quite reasonably, that blindfold elephant-eating is a tricky business, and these things, more often than not, just happen. And experience told that this was hardly the worst underestimation of a problem ever seen – after all, there was that time when the elephant had turned out, on initial prodding, still to be alive! That had been character-building.
The customer was unimpressed. Contracts were contracts, he said, and, he said, he had accepted the risk of time and materials with his eyes open. But, he said, he had rather assumed that the team would take steps to manage the scale of the job from the outset, not just from eight months in. So what was the problem?
And the project manager asked (tentatively, because it was too late, but you should always ask even if it is too late) for confirmation that the animal being eaten really was an elephant. An Indian elephant, yes? And the customer said no, Indian elephants are old hat. And we are aggressively pursuing the African elephant space these days. And is that going to pose a problem?
And the project manager wished they’d had a Systems Engineer on the team in the first place.
Enter the Systems Engineer
The Systems Engineer’s jobs are many, you see, but the central function to which it all amounts is the management of information flow between those with no business understanding each other’s work – between the customer and the engineering team, and between engineers concentrating on different parts of the solution or working in different disciplines.
And it is this function that can save a project from horrendous, costly, painful and embarrassing collapse at that point where it appears to be at its most productive. It’s said that the faster you go, the bigger the mess, and it’s generally at the point that development is in fullest swing that interactions between team members require only the very tiniest trip to cause a magnificent pile-up. The Systems Engineer works as far as possible to ensure such trips can’t occur, and, if they do occur, that the project is sufficiently and promptly slowed, caught and righted before it gets a mouthful of tarmac. And the best way to prevent the trip and / or to be in the best position to catch it is to understand everything about the project at a level just sufficiently ignorant of the detail that one person (or a small, structured team) can take it all in and monitor it competently. This is the foundation of Systems Engineering.
Requirements and Architecture
To maintain constant understanding of a development project, the Systems Engineer keeps an eye on both the goal and the solution. They build understanding of the customer’s problem and formalise it in the shape of the project requirements, and they supervise the architecture which is developed to solve that problem.
By structured translation of the requirements between the customer’s field of expertise and the engineer’s, followed by formal or informal elaboration of the requirements to describe partitioned portions of the solution to be worked on by engineers in different fields (as set out in the architecture), the Systems Engineer provides a clear interface from the customer’s field of expertise down to the individual detailed designers working on the solution. And by feeding reported problems from the detailed designers back up to the architectural level for impact analysis, and then relating unavoidable consequences back to the customer’s domain in the context of the original requirements, the Systems Engineer provides feedback on how the job is going, and enables rapid and clear decision-making by the customer if things do go wrong: Do we fix it, what would be the consequences of not fixing it, and if we do fix it, how much is it going to cost?
An Engineer You Can (and Should) Hug
As a customer of an engineering team, you’d hope to have a good relationship and frequent contact with the Systems Engineer, especially when working to a tight deadline. And the ideal relationship is often not the most straightforward – if your Systems Lead swallows your suggested requirements whole and never challenges any of them, you should suspect a failure of communication. Experience suggests that only after some friendly argument over the detail is a problem ever fully understood by both sides, so you should hope for some deep conversations rather than blind acceptance. But in the end, remember: The Systems Engineer is the customer’s best friend on the development team. Assuming you are faced with a separate Systems Lead and project manager, the Systems Lead is usually responsible for representing your needs to the team (including to the PM), and will never present you with a bill. He or she is wholly and constantly concerned with ensuring you get what you need, and with reducing risk to its delivery.
The Silent Masters of Churn
And that’s it. The Systems Engineer worries constantly at the requirements, architecture and various other bits and bobs such as driving the integration process, system testing (which is extraordinarily important, but not the sort of thing you talk about in polite company), risk management (both to project delivery and to end users stepping into the line of fire of the product), and any associated design documentation required by the relevant regulatory bodies troubling themselves with your product. Lots of conversations, lots of checking of understanding, no obvious hard output much of the time. Like a sort of prayer wheel, the Systems Engineer is often invisible, whirling away in the background, with no apparent impact on the project – they don’t appear to produce much of the final design (a good architecture rapidly becoming invisible in the face of debugging the fiddly minutiae) and most of their output is in the form of paperwork nobody ever reads after the project is completed. In fact, some might argue nobody reads it during the project either, but the fun thing about it is that this generally doesn’t make it any less worthwhile – it’s the iterative process of creating it that counts. But the day that prayer wheel is stopped (usually on budgetary grounds), the vengeful and needy God of Project Delivery begins to take an interest, and his hairy familiar, Unexpected Change, will not be far behind. It’s probably waiting for you just round the next corner right now. It craves cash to fill its cavernous belly and carries a big stick.
The Leftovers
And what of the blindfold engineers and their unexpectedly-African elephant? Well, the project manager called in a Systems Engineer, a classical hero, bulging of biceps and clear of vision, who briefly took the project right back to the requirements stage. He removed his blindfold and thus formalised the customer’s needs through rapid but careful discussion: African elephant, male, middle-aged, normal limb-count, medium-rare. Then he formalised the architectural partitioning and interfaces and a performed brief gap analysis, leading to instructions to the rear leg people that the thighs were henceforth to be assigned to the buttock teams, with an emergency doubling of ear specialists and partial outsourcing of the software to a 3rd party (at considerable expense). The budget-holder grumbled, but accepted a significantly increased bill in order to hit the original deadline, and everyone except the elephant survived to repeat the same mistakes many, many more times before retiring to tell the tale.
And how is eating an elephant, the total deconstruction of a working thing into nothing, at all relevant to the construction of an aeroplane / car / satellite / baggage handling system / medical device? Well, it’s a poor analogy. An after-midnight analogy. But it models in reverse a utopian vision of development that will rarely be achieved. The ideal in building a thing is not, as often happens, to set out with nothing but a vague idea of some imagined outcome and keep adding and fettling bits until it looks finished. It is more efficient and elegant to start out knowing precisely what the end result should be, and to assemble it from a known number of precisely planned parts that all just fit together. No extraneous work, no missteps or blind alleys, no parts left over, nothing missing. In other words, to dismantle it backwards. Nobody ever cut up an elephant and found a random bit of extra Bakelite or fifty lines of unreachable code in there. I could have gone with blindfold cannibalistic engineers for my analogy, but humans have an appendix so that would have been absurd.
Anyway, the take-away from all this is that the Systems Engineering discipline operates with appropriate freedom from the detail so as to be able to keep an eye on the prize throughout, and concentrates on the final closing of the gap between product and dream, keeping development close to the ideal, waste-free path. It is the client and the engineering team’s best friend. And it is a must-have on any complex product development.
Or maybe I just dislike elephants. At this time of night, it’s hard to tell.