Ben Rockwood said something last December about the re-emergence of the Systems Engineer and I agree with him, 100%.
NASA Systems Engineering Handbook, 2007
To add to that, I’d like to quote the excellent NASA Systems Engineering handbook’s introduction. The emphasis is mine:
Systems engineering is a methodical, disciplined approach for the design, realization, technical management, operations, and retirement of a system. A “system” is a construct or collection of different elements that together produce results not obtainable by the elements alone. The elements, or parts, can include people, hardware, software, facilities, policies, and documents; that is, all things required to produce system-level results. The results include system-level qualities, properties, characteristics, functions, behavior, and performance. The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected. It is a way of looking at the “big picture” when making technical decisions. It is a way of achieving stakeholder functional, physical, and operational performance requirements in the intended use environment over the planned life of the systems. In other words, systems engineering is a logical way of thinking.
Systems engineering is the art and science of developing an operable system capable of meeting requirements within often opposed constraints. Systems engineering is a holistic, integrative discipline, wherein the contributions of structural engineers, electrical engineers, mechanism designers, power engineers, human factors engineers, and many more disciplines are evaluated and balanced, one against another, to produce a coherent whole that is not dominated by the perspective of a single discipline.
Systems engineering seeks a safe and balanced design in the face of opposing interests and multiple, sometimes conflicting constraints. The systems engineer must develop the skill and instinct for identifying and focusing efforts on assessments to optimize the overall design and not favor one system/subsystem at the expense of another. The art is in knowing when and where to probe. Personnel with these skills are usually tagged as “systems engineers.” They may have other titles–lead systems engineer, technical manager, chief engineer– but for this document, we will use the term systems engineer.
The exact role and responsibility of the systems engineer may change from project to project depending on the size and complexity of the project and from phase to phase of the life cycle. For large projects, there may be one or more systems engineers. For small projects, sometimes the project manager may perform these practices. But, whoever assumes those responsibilities, the systems engineering functions must be performed. The actual assignment of the roles and responsibilities of the named systems engineer may also therefore vary. The lead systems engineer ensures that the system technically fulfills the defined needs and requirements and that a proper systems engineering approach is being followed. The systems engineer oversees the project’s systems engineering activities as performed by the technical team and directs, communicates, monitors, and coordinates tasks. The systems engineer reviews and evaluates the technical aspects of the project to ensure that the systems/subsystems engineering processes are functioning properly and evolves the system from concept to product. The entire technical team is involved in the systems engineering process.
I would imagine that successful organization understands this concept of systems engineering, but I don’t think I’ve ever seen it put so well.
NASA’s engineers have both common and conflicting goals, just like we do in web operations. They weigh trade-offs in efficiency and thoroughness, and wade into the constraints of better, cheaper, faster, and hopefully: more resilient.
This re-emergence of the systems engineering (or “full-stack” engineering) notion is excellent and exciting to me, and I’m hoping that everyone in our field, when they hear “DevOps” (and/or how Theo says *Ops) what they mean is taking a systems engineering view.
I wish the systems engineering department at my university had been better. All of the other engineering disciplines (electrical, mechanical, computer, compsci, biomedical, etc) were incredibly technical and demanding, but systems engineering was a bunch of frat boys who wouldn’t even meet to work on an assignment on Thursday before 2pm because they were drunk from Wednesday night partying. It soured me on the term. I like DevOps better, when it comes to web-centric software development. I think all the systems engineers from my university are working Dilbert jobs for the government or defense contractors now, wasting my tax dollars.
My problem with system’s engineering groups is eventually all power comes to rest in their hands when the know requirements, but they don’t know the actual system, and always try to control low level details. I’d rather not have that over my head.
Gregory: I understand what you’re saying, but re-read the last sentence of the description:
“the entire technical team is involved”
While it might certainly be your valid experience, a non-holistic and non-collaborative approach isn’t what systems engineering is about. What you describe isn’t actually systems engineering. 🙂
Well put indeed. But after reading I’m asking myself: are NASA engineers role models for those in IT? NASA creates systems of amazing complexity at astonishing cost. Efficiency is clearly not an objective there – which is why entities outside of NASA are taking lead in delivering space technology.
“are NASA engineers role models for those in IT?”
I wasn’t wanting to imply that, but I do absolutely believe the tenets of “systems engineering” as it stands generically. Here’s another one that is more wordy, but still quite apt: http://en.wikipedia.org/wiki/Systems_engineering
🙂
Pingback: Confluence: System Administration Univ
So, having worked as a system engineer for 7 years and being excitedly told about the emerging devops concepts at my latest endeavor, I silently chuckle and go along with the discovery of devops. It would be nice to call a spade, a spade again though.
Pingback: M-A-O-L » Systems Engineering and Automation
Pingback: Class 12 | SMS Engineering & Design
Pingback: ¿ Por qué estudiar IngenierÃa de Sistemas o carreras afines ?
Thanks so much for the detailed explanation