(continued from part 1)

In order to better perform our jobs as system engineers, we need to understand the territory of systems engineering, guide ourselves from point A to point B in that territory, and be able to communicate our results to our stakeholders.  We understand our jobs by building and following a metaphorical map of the system engineering territory.  We make decisions about how to get from one point to another. We communicate to our customers by providing them another simplified map of the results that they can understand and relate to.  (Yes, the PowerPoint graphics so commonly used are a method of describing maps.)

You’re probably wondering why I discuss metaphorical maps and not the specific details of the system engineering process.  The reason is simple. Often we’re stuck in a very specific way of thinking.  An intellectual rut, if you will.  We’re locked into specific interpretations of our jobs and processes.  By thinking metaphorically, sometimes we can see relationships and open up to ideas we wouldn’t see without the metaphorical view.  If you’re willing, let’s explore this metaphor together.  Let’s back up, and ask ourselves, what is a map in general?

What is a Map?

For once, the dictionary fails us by not providing a good definition of map, so instead we turn to Wikipedia, where we learn that a map is:

In a typical road map, as you might see on Google Maps, Bing, Apple Maps, or Waze (or many others) we see geographic regions and their relationships.  Some of the information includes relationships between cities via roads and relative locations.  We also see municipal boundaries and geopolitical extents.  We can see the relationships between cities and geographic entities such as rivers, lakes, mountains and shorelines.  Using more detailed views, we can delve down to the relationships between individual addresses and the corresponding cities and roads.

Of course, there are many different kinds of maps.  Maps have a specific scope and purpose, a specific theme.  Geographical, or topographical, maps are the most commonly used, but there are also many others.  Aeronautical maps that show airspace restrictions, radio frequencies and general aviation information.  Topological maps show relationships and connections, but no extraneous information (such as scale or distance) depending on the application.  Network maps show interconnectivity among communications nodes.  There are too many types of maps to mention here, but the interested reader can look into the subject of cartography on Wikipedia.

Given all the information on the maps, what do maps do for you?

1. Provide information to find where you are, whether it be a city address or a network node (navigation)
2. Describe the lay of the land
   • Show terrain, entities, and relative placement of the entities whether city addresses or network nodes
   • Show important llandmarks
   • Show entities of interest for the subject area
3. Enable guidance
   • Provide information needed to decide how to get from one node to another
   • Allow you to find the best routes

There are things that maps do not do.  For example, a map can enable guidance on your available travel options, but the map cannot tell you how to get from point A to point B.  Should you travel by car, or by airplane?  The map cannot answer that.  Should you detour to visit an attraction, or drive straight through?  The map cannot make decisions for you.  The map, by itself, cannot tell you the process of getting from A to B, nor the decisions along the way.   It only provides the information necessary to enable the decisions.  Without the information, you can’t make the decisions necessary to follow your process.

To cross terrain, we need both a map and a process for making travel decisions.  The common GPS system in your car or on your phone is a combination of a map, and an application to handle decision making.  In this case, the decision making is restricted to particular assumptions, such as travel by automobile, and that the goal is either the shortest distance or quickest route.

If you think about it, a map comes pretty close to fulfilling my definition of a model:

Maps and Processes

System engineering is generally considered a set of processes with goals.  The main goal is to move from customer concept to design specification that can be handed off to other disciplines, like moving from one map point to another.  Where’s the information necessary to decide how to move? We describe our processes in System Engineering Management Plans (SEMPs) and measure our compliance to our processes, but we very poorly formalize the necessary information.  I believe the missing ingredient is the map of the SE landscape that provides the information for the necessary decision-making.

In my opinion, system engineers have spent decades developing processes, but far too little time developing and formalizing the map of the SE territory.  In order to make decisions, we need a complete model of the system engineering territory, including a model of the SE discipline itself and a model of the customer needs.

When building models and maps of decision-making processes, we start to venture into the realm of Enterprise Architecture, or EA.  For the purposes of this article, I’ll avoid any Enterprise Architecture specific terms.  My views on EA will be discussed in another article.

The system engineering territory does not need to be explored like a poorly known Louisiana Purchase by the Lewis and Clark Expedition. (A part of early United States expansion in 1804-1806.)  We’ve already covered the SE territory, but we haven’t documented it very well.  There have been maps of SE, like the image bellow of the schema from an old SE tool in the 1990’s, so the knowledge is there.  We just haven’t made that knowledge persistent.

This particular map is of “Design Guide C” from the tool RDD-100 by Ascent Logic, Inc.  Oddly enough, the design guide (1 of 4 maps) was only documented in an alphabetically organized reference guide; this visual diagram was never provided by the vendor.  The picture only exists because I spent several days back in the 90’s exploring the reference guide to divine these visual relationships.

I believe that understanding the basic system engineering entities and their relationships is the key to improving the entire process of system engineering, and the solutions we generate.  In the next article, I’ll look at a simplified “map” of system engineering and what needs to be done to make it useful.

Part 3 is available here

The Role of Information in System Engineering

As system engineers, we like to think that our jobs are to engineer at a system level, that is, we “enable the realization of successful systems” as INCOSE would say.  In order to do this, we address customer needs, operations, performance, cost and schedule, training and support, and to a lesser degree, test, manufacturing and disposal.  These are all very important areas to address if the system is to be successful.  If the system is to meet user needs, a discipline that coordinates and integrates these other disciplines is essential, hence system engineering.

System engineering is not a discipline of design.  We don’t design integrated circuits or printed circuit boards.  We don’t solder components to PCBs.  We don’t write production C++ or Java code.  We don’t install blade servers into racks and connect them with a specific network topology.  We don’t design mechanical parts to be machined on a Computerized Numerical Control (CNC) milling machine.  We don’t really do the “fun” stuff in engineering.

Instead system engineers have their own tasks.  We gather the user needs and wants, formalize them into requirements and create a requirements database.  When in doubt about a user need, we perform trade studies to determine the best implementable option, and document that in a trade study report.  We define the concepts of operation, system functions and logical architecture. We record all that in a set of specs and architecture documents, or better yet, in an MBSE database.  We create mappings between all the entities we defined and try to document those linkages.

Show Me the Data

Lately some educational institutions have issued degrees in system engineering, but in general we’re usually electrical or software engineers who transition into the field.  Sometimes we are specialized analysts who can synthesize new technical information.   Sadly, very few system engineers are skilled in information management.  For example, how many system engineers know what a relational database is, or what fourth normal form is?  Raise your hands!

I know many requirements engineers who cannot even use an important tool of their trade, DOORS, relying on others to perform input and export reports to Excel.  Engineers can use tools like Excel, yet must rely on others to help them get a DOORS export.  Heaven’s forbid they use Access or mySQL to manage information. Even fewer probably know how to use Microsoft Query to extract and cross reference information.

I believe MBSE is an industry attempt to do more information management for system engineering.  MBSE attempts to capture system engineering information in a single model and database.  Unfortunately MBSE stops well short of fulfilling its promise.  In general MBSE models will address architectural, behavioral and structure information, but fail to address other aspects of system engineering information.   Most MBSE tools, especially those based on SysML, cover a limited territory of information concepts.  Often these tools address the end product itself, and not the full field of information concepts that system engineers deal with.  Other tools are used to address other information, such as requirements, planning, testing, trade studies, simulations and visualization.  Although these tools have their own models, seldom are the models well integrated.

The Map and the Territory

It should be obvious that there is a very large territory of information that system engineering covers.  When communicating, we do so in the context of the map we’ve created for that information territory.  This can be an issue if somebody in a different context doesn’t understand the map we use.  If the map omits critical information for the other party, then the communication fails.  If the map presents information in an unusable format, communication fails.  If the terminology and concepts are incompatible, communication fails.  MBSE might provide a limited map that uses common symbols, but much of the remainder of the map only exists in our heads, making it difficult to share.

How do you determine what information other people need?  How do you anticipate their queries?  How do you store and present information in a flexible manner?  These are some of the issues that should be addressed to fulfill the information management needs of system engineering.

Do You Have an Information Management Problem?

Many organizations will dismiss this idea out of hand.  “We’re doing just fine information-wise, thank you.”  Perhaps your organization hasn’t fully examined the issue.  How do you know you have an information management problem in your system engineering department?  With a tip of the hat to Jeff Foxworthy, here are some real world clues you might have an information management problem.

If your engineers manipulate requirements in Excel and you have separate administrators who handle the DOORS database, you might have an information management problem.

If a requirement in DOORS has an attribute called “Proposed Change”, you might have an information management problem.

If your information is linked to your MBSE database solely via a text attribute called “Allocated CSCI”, you might have an information management problem.

If you don’t understand the difference between a configuration item and a component, you might have an information management problem.

And my personal favorite:  If a requirement in DOORS has over 100 attributes, you definitely have an information management problem.

Part 2 is available here.