1 Foreword 🔗

I would like to welcome you to Lean Engineering Research. I’m glad you’ve found this website and I will do my best to provide you with the answers you seek!

Maybe you are an engineer or a scientist. Maybe you work at a university, at some other research institution or in a company’s research department. Maybe you are a student, a regular employee or a manager. Regardless of your role in engineering research, if you feel that there is too little valuable progress despite constant struggle, if the urge to make a meaningful difference in the world drives you, and if you can not get rid of the feeling that there should be a better way of doing things - then this is the right place for you.

Lean Engineering Research is my attempt at applying Lean Thinking [1] to the practice of engineering research. It is a complete, integrated model that can serve as the theoretical foundation for your lean operating system [2]. This lean operating system will enable ever faster progress of your team or organization at a sustainable pace despite limited resources. It will align everyone towards the same higher level goals to contribute to society in a positive way. And it will replace constant overburden and frustration with motivation and fulfillment.

Lean Engineering Research is an OER (open educational resources) book. Please read the Terms of Use for the specific conditions. I provide the material openly because - in the spirit of Lean - I want to provide as much value as possible with minimum effort for the “customer”, i.e. you. That is also the reason why Lean Engineering Research comes in the form of a website: it makes it as easy as possible to access the information at any time.

Lean Engineering Research is work in progress. This means that the OER book on this website is incomplete and will stay incomplete for quite some time. I will make frequent changes, like new content, restructuring and even rewrites of sections. Lean Engineering Research can appear fragmented, because I may work on sections not in the order of the outline. This may seem strange, but the rationale behind this is once more rooted in Lean philosophy: instead of spending years writing a text and then providing it as a whole, I want to provide value as soon as possible. Maybe some section is already useful for you, even though the whole book is incomplete. This also allows me to collect feedback early and incorporate it into the text, thereby increasing its value for you. In any case, just like any organization practicing Lean, Lean Engineering Research will never be really complete in the sense that there is nothing to improve. There is always a way to make things better.

To keep the overview of changes, I follow strict semantic versioning of the material. You can see the current version in the right corner of the top bar on this website. The format is v<major>.<minor>-<patch>.

• major: Indicates 1st, 2nd … edition of the book. 0 indicates that the content of the first edition is still incomplete.
• minor: An increase in this number indicates substantial additions like new sections or chapters, substantial rewrites or restructuring.
• patch: An increase in this number refers to smaller additions, rewrites or restructuring. It may also increase when typos, grammar or illustrations are fixed. There may also be changes to the html layout or even internal changes that are not directly evident.

I would be very thankful for any suggestions, corrections and general feedback. You can help to improve Lean Engineering Research. Contact me by E-Mail are via LinkedIn. I’m looking forward to hearing from you!

2 Introduction 🔗

Under construction.

3 The Nature of Engineering Research 🔗

3.1 What is Engineering?

To get a useful definition of engineering research, we need a common understanding of what engineering actually is.

3.1.1 A Definition

According to the Collins Dictionary “Engineering is the work involved in designing and constructing engines and machinery, or structures such as roads and bridges.”[3] Merriam Webster defines engineering as: “(1) the activities or function of an engineer (2a) the application of science and mathematics by which the properties of matter and the sources of energy in nature are made useful to people (2b) the design and manufacture of complex products (3) calculated manipulation or direction”. [4] The Encyclopedia Britannica has the following to say about engineering: “Engineering, the application of science to the optimum conversion of the resources of nature to the uses of humankind. […] The term engineering is sometimes more loosely defined, especially in Great Britain, as the manufacture or assembly of engines, machine tools, and machine parts. […] Of great importance is the process of creative synthesis or design, putting ideas together to create a new and optimum solution.” [5]

Lopez-Cruz provides a definition that is broader in scope and also somewhat more precise:

[Engineering is] the human activity that deals with creative design, construction or manufacturing, deployment, maintenance, development, improvement, operation, and control of (engineered) systems. The aim of engineered systems is to transform (in a conscious manner) an existent situation/environment into a desired situation/environment. [6]

He makes use of the term engineered system as the key subject of engineering:

[An] engineered system is a system (which in turn is a technological artifact) involved in an economic process, this is to say that the product (either an item or service) conforms to quality, performance, and features to meet constraints for its usage. […] Engineered systems may exhibit physical materiality or not. Those exhibiting physical materiality are, for instance, building structures, machines, devices, energy plants, chemical plants, bridges, and dams. Those lacking materiality may be organizational processes and procedures, industrial processes, and computer software. [6]

The idea of an engineered system is not exclusive to [6]. For example, the International Council on Systems Engineering (INCOSE) writes about engineered systems on its website:

An engineered system is a composite of people, products, services, information, and processes (and possibly natural components) that provides a capability that satisfies a state customer need or objective. […] The people component can be individuals, roles, organizations, organizational units, governance structures, etc. The products component can be hardware, software, firmware, data, facilities, etc. The services component can be business services, information services, application services, infrastructure services, etc. The information component can be individual information items, information categories, information structures, documentation, knowledge elements, etc. The processes component can be procedures, methods, techniques, work instructions, policies, directives, etc. Capability is an ability to do something in the anticipated operational environment. [7]

All of those statements about engineering contain valuable ideas and views. No single one, however, appears to me to be complete and broad enough to be useful for this text. Borrowing from these ideas, particularly from [6] and [7], I would like to suggest another definition of the term engineering. There are many views that are equally correct. I aim for one that serves the succeeding discussions in this book the best.

Engineering is the human activity that deals with creative design, construction/manufacturing, deployment, maintenance, improvement and operation of engineered systems. The aim of engineered systems is to deliberately transform an existent situation/environment into a desired situation/environment. This transformation’s purpose is to address the needs of individuals, society and even humankind, while protecting and preserving our natural environment. An engineered system may be a purely technological or a socio-technical system. The former can be physical (any form of hardware: buildings, machines, computers…), or non-physical (algorithms, software, data), or a composite of both. In socio-technical systems, people interact with technological systems and knowledge-bases by following organizational processes.

3.1.2 Engineered Systems

Engineered systems are the key subjects of engineering. An engineered system is the instrument used by engineering to realize the desired change in a given situation/environment.

An engineered system can be either purely technological or socio-technical.

Technological systems include an enormous range of different items. Most of them combine physical as well as non-physical parts. Consider for example all those technological systems that we encounter in our everyday lives. We use all kinds of computer devices, like notebooks, smartphones, tablets, smart watches, as well as all the software that is running on those devices, e.g. office suites, cloud services, smartphone apps, sophisticated AI algorithms that we don’t notice anymore because we have learned to take them for granted (face recognition on smartphones). For these devices and much more, we use electricity (which naturally comes from the socket): power plants, wind farms or solar parks. Think about the massive machinery we use to build other machines like lathes, casting machines, even complete assembly lines. Think about medical devices, e.g. MRI machines, CT scanners, pacemakers and artificial joints, on which our lifes may depend directly. Be aware of the numerous types of vehicles that are used everyday to transport people or goods from A to B: cars, ships, trains, airplanes, rockets. Finally, let’s not forget the large-scale infrastructure that we use everyday, from simple houses to whole dams.

Technological systems span a large number of dimensions.

• Maturity: Engineered systems can be finished end-consumer products, or they can be early prototypes of this product - or something in-between.
• Purpose: Engineered systems can be end-consumer products or they can be the machines (in the widest sense of the word) that are used to produce these end-consumer products. In a different context, however, these machines can themselves be considered end-consumer products.
• Supply chain tier: Engineered systems can be complete end-consumer products, or they can be components of these, e.g. a car versus high-end steel alloys for the car’s body, a smartphone versus a USB-C socket, a vacuum cleaner vs the electric motor that powers it, a streaming app versus a networking software framework.
• Size: Technological systems can be very small or very big. Compare integrated circuits with billions of elements on a Die the size of a fingernail with the Golden Gate Bridge.
• Complexity: Technological systems can be very simple or very complex, like a smartphone app next to the kernel of the Linux operating system, or a model plane compared to the International Space Station.
• Cost: They can be very cheap or very expensive: a child’s bicycle vs a professional racer bike with carbon fiber frame.
• Quantity: Engineered systems can come as single, unique pieces or as mass products, like formula 1 cars compared to mainstream cars with millions of pieces sold.
• Age: We don’t even have to cling to our modern civilization. Engineered systems have been there for a very long time: an abacus, ancient surgical instruments or the pyramids of Giza.

Engineered systems can combine technological systems, knowledge-bases, organizational processes, and people into socio-technical systems. Some examples: an MRI machine is part hospital’s radiology department, without the doctors and nurses the machine would be useless. One of the most complex engineered systems - a photo-lithography machine used in the production of integrated circuits - is always part of a semiconductor factory of some sort. People have to work in these factories, and they have to follow - without doubt - organizational processes to achieve a certain output with a certain quality. And to show that not even the sky is the limit: the ISS as a technological system can only do its job with an enormous amount of people being involved everyday, working in a coordinated fashion according to innumerable procedures - on ground and in space.

When I say that people are a part of socio-technical systems, I mean literally everybody that contributes: from top managers, engineers and scientists, to administrative assistants, facility managers and cleaners. People are the most important part of any socio-technical system, and - in a way - people are the reason for socio-technical systems in the first place.

Knowledge-bases include for example documentation, manuals, work instructions, CAD drawings as well as internal and external standards. They can have different scopes: every employee may assemble a private repository of lessons learned; teams may collect and share important information that helps them to interact internally and work efficiently together with their environments; an organization may have standard procedures and policies; and ultimately there are standards that many organizations share, potentially world-wide (e.g. ISO). One could say that a knowledge-base with the widest scope (and questionable quality sometimes) is the Internet - a global repository of knowledge that we all use every day.

Organizational processes determine how the people working in a socio-technical system interact with one another, with technological systems as well as with the socio-technical system’s environment. Organizational processes can be official or unofficial. They may have been designed deliberately or grown organically. They may involve willful actions or automatic habits. And they may cover individuals, teams or the whole system. Whenever I talk about organizational processes I mean processes as they actually happen in reality, not as they are supposed to be or as they are written down (if they even are).

The purpose of any engineered system is to change in a deliberate manner our situation or environment. This does not necessarily mean that the engineered system changes the natural environment, like building a dam to raise water levels, although this can be the case. In the general sense it means that the engineered systems changes our immediate situation or environment. A house keeps us from being exposed to the outside environment. It keeps us warm and protects us from storms. This is a changed environment for us. The phone has changed our situation significantly: before the phone, we had to write letters; a conversation in real-time over some distance was impossible. Now it is. A transformation of our situation so profound, we can not imagine how it must have been before.

3.1.3 Engineering is a Human Activity

When we think about engineering we typically think first about some kind of vehicle or technological gadget. In a way, engineering appears to be technology-centric. It feels obvious. The process from idea to a working engineered systems can feel opaque. Some genius engineer has a great idea and the rest just happens. We have to let go of this view. Engineering is first and foremost a human activity. It is something humans do. Engineering is about a sequence of actions that humans take to transform ideas into finished engineered systems. And - closing the circle - the engineered system’s purpose is to serve humans.

Engineering is human-centric, rather than technology-centric.

It is no surprise that this insight doesn’t come to us naturally. We are all engineers, after all, because we love technology. That’s what we focus on. That’s what we have learned. We think in equations, dynamic models, materials and software systems. Our goal is to make the engineered system work. There is not much room for anything else. In the course of our studies, we focus on mathematics, mechanics, electronics, control theory, fluid dynamics etc. We typically have little affinity towards the social sciences - those fields that deal with people, how they behave and how they interact. Yet we should, because engineering is rarely about individual engineers, but mostly about groups of interacting people, e.g. teams, organizations, often crossing functional and even geographical boundaries.

3.1.4 Engineering Spectrum

Not only the design of an engineered system is part of engineering. There is a lot more to it. As the definition states, construction/manufacturing, deployment maintenance, improvement and operation of engineered systems are equally important. These are not phases or stages. Please think of these tasks as different aspects of engineering, that are closely intertwined. This will be become clearer later in this chapter.

3.1.4.1 Creative Design

Creative design is probably what most people will intuitively associate with engineering (through there is much more to it). To keep it simple, let’s say that creative design is about coming up with a description of the system to be engineered. This description may take the form of mechanical drawings, circuit diagrams, models of software architecture, and any other form using domain specific languages describing relevant views of the engineered system. Important: this design needs yet to be tested.

Why is it not just design but creative design? Coming up with the description of the system is not like the execution of a mathematical function that takes a customer’s need as input and returns a complete description. It is indeed a creative act that requires experience, engineering knowledge, craft, and creative ideas - often out-of-the-box. Many of those ideas won’t work, but some do, and that’s the whole point.

3.1.4.2 Construction/Manufacturing

Above, I mentioned that creative design seems to be the core aspect of engineering. Construction and manufacturing is then nothing more but implementing the design. It’s about building the thing, by following steps in a procedure. But this is far from the truth. Construction and manufacturing are essential aspects of engineering.

As we will see later, the practice of engineering happens in iterations. This means that the faster you can build prototypes of the designs you make, the faster you can test these prototypes, learn and proceed to the next (better) prototype. That’s why software development is so fast: design and manufacturing go hand-in-hand.

A very interesting case is software. In software development, the distinction between creative design and manufacturing is blurred. Code is either generated from some other (graphical modelling) language or it is written directly. And it is this code that may be considered to describe the design of the software. At the same time, it is the software, i.e. it has already been manufactured. This emphasizes once more, that creative design is an aspect of engineering that is closely intertwined with the other aspects.

The creative design of an engineered system must always include considerations of manufacturability. There is no use of a beautiful design that will never make it’s way from paper into reality because it can not be build or it is way to expensive to build.

The factory - regardless of the type - is also an engineered system. Look at the assembly lines. These can be way more complex than the product to be manufactured itself. These assembly lines need to be engineered. What’s more, this factory needs to be maintained and improved (see below). This is also engineering. And it has to happen while manufacturing products to get representative feedback. Solving problems in the running manufacturing process also is engineering.

Finally, creative design of the engineered system goes hand-in-hand with the creative design of the factory that manufactures it. Both are connected.

3.1.4.3 Deployment

According to Wikipedia “[t]he deployment of a mechanical device, electrical system, computer program, etc., is its assembly or transformation from a packaged form to an operational working state.” [8]

Deployment is as diverse as engineered systems. Some examples:

Remember when you bought your last smartphone. You could not use it right away. There was some steps to be followed. Either you bought it from a store, or it was shipped to you. You had to unpack it, insert your SIM card and maybe also a memory card. You may even had to charge your smartphone if the initial charge was too low. Then you had to power on the device and follow the initial instructions on the screen: you had to choose the WLAN and enter the associated password, you had to choose your language, configure cloud backup etc. This can all be considered part of the deployment and typically takes a couple of minutes to half an hour.

Let’s say you put this text aside and watch your favorite show via a streaming web service. Nowadays, these websites are frontends to a vast backend of innumerable micro services - self-sufficient software applications running in the cloud and interacting with one another - that ultimately provide all the functionality necessary for selecting and watching a show on your smartphone or smart TV. These web services are updated frequently and deployed without you ever noticing. There is a whole machinery at work that automatically builds, tests and packages the micro services, before stopping the old one already running, installing the new one and starting it. The machinery ensures by always having multiple identical services running that there is no interruption in service and the customer actually doesn’t realize that an update has just happened in the background. Depending on the complexity of the specific micro service, this may take seconds to hours.[9]

More on the hardware-side: Imagine an assembly line for manufacturing cars. There are a lot of industrial robots involved. Such a robot also needs to be deployed. It arrives packaged in a specific configuration for transportation. So it must be unpacked, placed on its foundation which may require a crane of some sort. Then it needs to be mounted securely to that foundation, and connected to power and data network. The robot controller may need to boot for the first time, and the robot may also need to get calibrated in place. Finally, personnel has to “teach” the robot the movement and test - first slowly, then with full speed - that everything works as expected. The overall process may take hours.

Let’s go bigger: off-shore wind turbines. Manufacturing and deployment are blurred, because the final assembly has to be done at the final location of the wind turbine. The foundations may even have to be constructed in place. The different parts like rotor blades, sections of the structure, are shipped - literally - as separate components. The floating foundation has to be constructed, the structure needs to be set up, the turbine housing needs to be mounted, as well as the rotor blades, and finally, it needs to be tested and commissioned. This may take weeks.

As a spaceflight engineer I can not resist to provide as a final example the deployment of the International Space Station (ISS). The ISS orbits the Earth at an average height of 410 km above ground. It has about 1000 cubic meters of volume. It’s mass is 410 tonnes. It’s solar generators provide 100 kW of power. And it is roughly 100 by 74 meters wide. 16 pressurized modules, diverse components of the central truss, solar arrays and various other components that were constructed on ground had to be launched to orbit and assembled on location, often by astronauts during numerous space walks. It took more then 40 rocket launches. The whole deployment of the ISS took over a decade. [10]

It may seem obvious by now: deployment is engineering. An engineered system needs to be designed in a way that allows efficient deployment. The process of deployment itself needs to be engineered. There may be custom tools required (e.g. rockets) that also need to be engineered. In many cases, the engineered system may need to be tested on location as part of the deployment. In those cases, deployment may deliver valuable feedback for engineering when unforeseen problems are encountered in the operational environment during first testing. These problems may need to be fixed as part of the deployment process. The two latter aspects may not be so relevant for a smartphone (hopefully), but for a 200 meter tall wind turbine off-shore, it may be an important part of deployment.

3.1.4.4 Maintenance

“Maintenance, otherwise known as technical maintenance, refers to a set of processes and practices which aim to ensure the continuous and efficient operation of machinery, equipment, and other types of assets typically used in business.” [11] This holds - of course - for engineered systems in general. Some engineered systems, however, may not require maintenance at all. I hope that your furniture doesn’t require any noteworthy maintenance. And also your smartphone should be maintenance-free, at least from your perspective. Then again, there are engineered systems that can not operate without extensive, and highly regulated maintenance. Believe me, you want to fly only with airplanes that are properly maintained.

The goal of maintenance is to minimize repairs that come with a downtime of the engineered system. In practice, the need for repairs can often not be avoided completely. If a repair is desired in favor of a complete replacement, engineering of the engineered system must ensure that it can be repaired with little effort, or even at all.

3.1.4.5 Improvement

Improving an existing engineered system instead of engineering a new one is the rule, rather than the exception. Think about successive generations of car models, software suites, computer processors, smartphone models or even orbital class rockets.

An engineered system consists of components (which are also engineered systems). To improve this engineered system in a certain way, typically, only a fraction of the components need to be added, removed, replaced, extended or modified. All the other components - of which there are many standard parts that rarely change at all - stay the same. Sometimes engineered systems that appear to be new developments still use quite a lot of proven components. One could argue that these systems are also improvements of existing ones.

Please note that in the case of physical systems, I don’t mean with the term improvement that the actual physical instance of the engineered system is improved. This is possible, of course, but will happen only in edge cases. Rather, improvement means that the design of an engineered system is improved, or in other words, the development doesn’t start from scratch but on a relatively high level - on a level of an existing engineered system that has already proven to work. I will not make this distinction in this book and talk simply about improvement.

Software is - again - an interesting case: in modern software development continuous integration is practiced, where each and every tiny change is tested, validated and released automatically to those micro services that form the building block of web services. Each of those tiny changes leads to a new software version, i.e. a new engineered system that is an improvement of the previous one. This can happen multiple times per day. And the process can span many years, even decades. A version of a particular software application may appear to have nothing to do with the ten year old version, yet it was created with a long sequence of small improvements. [12]

Why is it so common to improve existing engineered systems instead of starting (more or less) from scratch? From an economic perspective, the goal is to create an engineered system with minimum effort. (There may be other aspects, like for example political factors, that can lead to a deviation from this principle.) If there already exists an engineered system that is close to what is needed, it can be considerably cheaper to modify an existing system rather than creating a new one from scratch. This approach minimizes economical risk, since the old engineered system has already proven that it does its job. The probability that an improvement also will work is high. The most important reason in the context of engineering research is that improvement of an existing engineered system is an essential part of the practice of engineering research. A prototype is tested, which leads to the next prototype, which again is tested, and so on.

Sometimes, improvement is indeed not enough. For achieving considerable performance improvements, or for creating completely novel engineered systems, there are more new components needed than existing ones can be reused. Improvement has its limits. In any case, the economic rationale of minimizing effort in engineering research must not become a dogma. It favors more conservative solutions, solutions that are close to what already exists. In competition, this can lead to economic catastrophe.

3.1.4.6 Operation

I sincerely hope that you don’t need engineering skills to operate your smartphone. If you do, I recommend you consider a different brand. Engineering, though, is required to make a smartphone that easy to use. Operation of engineered systems is a vital and often overlooked aspect of engineering. It has to be included in an engineered system’s design right from the start.

There are cases, however, where the operation of an engineered system is so complex, that it in fact requires engineering and associated know-how. Imagine complex manufacturing machines. Those are not plug-and-play. Or think about an interplanetary probe that travels to other planets. If operating such a spacecraft is not engineering, I don’t know what is. It requires detailed procedures, checklists and trainings. All of these need to be engineered as well.

3.2 What is Engineering Research?

Under construction.

4 Value and Waste 🔗

Under construction.

5 The Technology Forge 🔗

Under construction.

Bibliography 🔗