(Carl Fredrickesen, Tinder, Witches and Wizards, Keeping it Real , Deep Doo Doo)
I hadn’t realised this until now, but just saying the term “Systems Engineering”, stirs in me a number of strange yet oddly intoxicating emotions; I did warn you in the first blog I may occasionally go a little off track and I’m not sure yet where this is headed.
Those emotions I suspect, stem from the fact that the term “Systems Engineering”, seems to mean either nothing, or something completely different, to every bugger that I have discussed the subject with over the years, and which in turn is why so many companies still don’t have a systems engineer process, or don’t understand or use the one they do have, and probably why I’m losing my hair far earlier than I would have hoped for.
As horribly cliché as this is going to sound, when I was a lad, back in my aerospace days, senior engineers were old guys with hair as white as their beautifully ironed shirts, and they all wore glasses like the main character Carl Fredricksen in the movie UP, and systems engineers were guys that drove flash cars, knew how a soldering iron worked, had taught themselves software to make the stuff they’d soldered together work and were now designing the stuff that my software team and I were frantically coding up and the hardware guys were building, whilst ordering parts from TI, getting high on solder fumes and drawing rude symbols on the copper boards before dropping them in the acid bath.
Oh how times have changed. I’m pretty sure that back then, engineering managers never had to say things like, “Why does your CV say you’re a systems engineer, you only graduated last week?” or, “No you can’t be a senior engineer, you only came out of uni last year!” or, “What do you mean this isn’t graduate work and you want a pay rise?” That last one is of course completely off topic, I just got carried away in the moment, and just to clear the air, I must say I have nothing against graduates and young engineers, you are the future and my target audience after all, even if your expectations are a little high; I blame the universities and Tinder.
So why did the systems engineers drive flash cars, and why did we all want to be one? It’s because, back then, to be a systems engineer, apart from being paid more, (hence the flash car), those guys had cut their teeth as a hardware engineer, had subsequently learned software engineering to a demonstrably competent level, and thus as a result of their background, knew how to describe precisely what they wanted software engineers to code, without telling them how to do it, and what they wanted engineers to achieve without picking the hardware components for them. Anybody that really wanted to be an engineer, at some point aspired to be a systems engineer.
Hopefully I don’t need to explain the reason for precision, but what’s the big deal about telling a software engineer what you want them to write without telling them what buttons to push, or telling a hardware engineer what you want the hardware to do, without telling them what bits to buy? Surely any muppet can do that? The big deal is that it’s much harder than you might think.
You see a good systems engineer already knows, or at the very least is pretty sure, that when they cascade their requirements, that what they are asking for is feasible. They also know that their requirements, although accurate, will not ‘constrain‘ the downstream stakeholder in regards to how they meet the requirements. Statements from the hardware guys along the lines of, “I can’t use that sensor, it doesn’t have the range!”, or from the software guys, “Don’t tell me how to write code!” should never be voiced, provided the system level requirements don’t leak into the ‘functional domain‘. Understanding and implementing this self-constraint knowingly, is an art in itself. The antithesis of this of course being the engineer who writes their requirements, in arrogance or in most cases ignorance, resulting in delayed milestones due to the inevitable ‘conversations’, strained relationships and in many cases a half arsed final deliverable. In other words, if the downstream team want to use witchcraft and wizardry to meet your system requirements, and they can without contradicting what you’ve prescribed, and the integration manager has a funny shaped scar on his forehead, then let them, as long as the customer doesn’t find out; they might want a discount.
As an aside, if all of your downstream are suppliers, external bodies who are all vying for your affections, and if you dont know you’re asking for the impossible, which seems to be common practice these days, you are likely to receive some beautifully crafted quotes offering you everything you asked for, with some even more beautifully crafted small print. As a system engineer its your job to prevent this happening because nobody else will. It’s your system, so do your research.
Keeping it real, if you want the official definition of ‘Systems Engineering‘, I would suggest you check out the Wikipedia entry. Here’s a link. I generally consider what’s in Wikipedia to be as close to official as it gets, given it’s a public forum and if anybody disagrees with what’s on there passionately enough, they can always change it, and given how engineers are prone to criticising reviewing passionately others’ work, its relatively safe to say that what’s on there now has, in one way or another, been accepted if not openly approved. However, personally I don’t appear to have the stamina or the attention span to read the Wiki entry all the way through, so good luck if you try. It does however, I seem to remember, have an “interesting” list of what the top dogs think systems engineering is, which might be worth you checking out, if only from a purely academic sense.
OK then Dirk, so what do you think it means? I’m so glad you asked. In a nut shell:
‘Systems Engineering‘ is the process by which an engineer, or team of engineers, pulls together all of the information that they need, in order to achieve their objectives, and subsequently presents all of that information to those that need to know it, AKA the stake holders, in order to achieve their objectives. A good systems engineering team with a good systems engineering process, is one that can achieve the above effectively and robustly, on any size engineering project, and make their customers very happy.
And where do these elite engineers start? Let’s head back to your writing pad.
Like I said, Systems Engineering, in the initial phases at least, is concerned simply with the collation of all relevant data and sources of data, so that’s where you start. Make a list of all of the things that you can think of that will ultimately influence your system, everything from the customer and what they want, the driver and what they might want, don’t forget the Government, and as think I mentioned in an earlier blog, consider you and your wants, because let’s face it, you need to be confident that when your progeny leaves home, it isn’t going to go on a rampage, get itself up on YouTube and land you in some deep doo doo.
Scooting off on a tangent again for a second, although we as a society seem to think that we need to keep pushing the envelope in an endless spiral of reinvention, (which I’ve often thought takes us more sideways than forwards, especially when it comes to engineering process, which is at times forced into evolution because the engineers who engineered the last process, which did the job well, have all quit or retired, and the ones that are left don’t have the time or the patience to work out how to use it, so casting their dispersions upon the former glory days, they coerce management into giving them the go-ahead to engender yet another branch to the process family tree, which wouldn’t be so damaging if not for the fact that engineers these days don’t stick around long enough to learn anybody’s process properly, let alone their own; well why would you when there are so many startups offering silly money to anyone that can, even loosely, tell them how to develop the thing they’ve just set up the company to develop, and thus to create for them some new processes thus ensuring the continuation of the dilution of the process gene pool? It’s quite sad really) there are a lot of interesting tools and concepts out there to help you pull all of the above information together in a way that allows you to present your work well, so take your time and start simple.
Looking at the pad above, cobbled together without even a cursory surf of the interweb, you can clearly see that there is a tool for everything, everybody and for all budgets, and I’m only scratching the surface. There are any number of ways of pulling information together and more tools than I can waggle a CAN cable at, that are designed to help you do it, but ultimately what tool set you use, and what fundamental guiding principles you adopt, are entirely up to you, In the here and now however, I’m going to keep it simple because for most people, jumping immediately to what is considered to be the state of the art, is not always the most efficient route forward.
So once you’ve pulled together a list of people who want something from you, along with a rough idea of what they want, and you’re in possession of at least a laptop with a word processor on it, it’s time to start collating. This is where it gets interesting.
