Engineering 2.0

The Dawn of Time

I worked my way through engineering school as a programmer and system administrator. So I was actually there when the whole internet/web thing started. I worked for the University of Minnesota in a computing lab in the medical school. We downloaded Mosaic when it first came out and it seemed "neat", but it wasn't immediately apparent that this was a technology that would (and this is an understatement) change the world.

Of course, it wasn't until the mid-1990s that things really started to change. By change I mean started affecting people in their personal lives. People who worked in computer labs knew about the internet and the WWW before it really hit the consumer market. I often use the pre-internet as an example of where the modeling world is today, i.e. lots of walled gardens. I then point out how we could scale things up much more if we followed the WWW model of openness and using solid vendor-neutral standards as a foundation (e.g. Modelica, FMI).

But what I really want to talk about is "Web 2.0". The Web 2.0 revolution started around 1999 and it represented not just having information on the web, but really adding iteractivity. It represented the start of a trend to move desktop applications to the web.

Don't Start the Revolution Without Me

But here's the problem. I'm sure anybody reading this (on the web) has seen their personal life impacted (if not completely changed) by the "Web 2.0" revolution. But as an engineer, I find that there has been only minimal impact.

Why is it we haven't see a corresponding "Engineering 2.0" movement come out of all these great advances in technology?

Some would argue we have. Some would argue that many tool vendors are now providing you with cloud based solutions for engineering tools. Frankly, I haven't been too impressed. What I see mainly is the equivalent of porting a COBOL application to the web. By this I mean that a lot of what I see is companies trying to repackage large, monolithic, legacy capabilities originally designed for desktop purposes into "webby", "cloudy" kinds of things. Most (not all) of the companies that I think are really rethinking and reimplementing things don't seem to be inventing "Engineering 2.0" so much as "Compuserve1 for Engineers". By that I mean they support networking but lack the openness, API and use of standards necessary to really scale.

Here's a test. The next time you see a company pushing what is billed as an "Engineering 2.0" kind of solution, look at who they are. Did they have an "Engineering 1.0" product before? Does their current offer look like the old one but just with a different UI? Do they already have a market capitalization of over 100 million dollars? If you answer yes to most of those questions, then they are not the disruptors, they are the disrupted. If you want competitiveness, quality customer support and innovation, my money is always on "the startup". Look for that guy in the room.

Brain Drain

I was speaking to an audience of college students the other day ranting on this subject. I was expressing my frustration about how there seem to be lots of talented developers out there but none of them are putting their talents behind developing really cool innovative applications for engineering. In fact, I jokingly said that "somewhere, there is a guy pitching a venture capitalist on a new iOS app specifically designed to help people manage the milk in their fridge because 'Hey, everybody has milk...charge people 0.99 and multiply by 300 million people'...we'll be rich!". It turns out, not only do such apps exist, I even found a web site with a 'featured dairy app' section.

Mon Dieu!


So why haven't we seen an "Engineering 2.0" revolution? I think there are two main factors. First, I think engineering is, necessarily, a conservative discipline. It is (rightfully) very important that we don't get the wrong answer. So tried and tested solutions are given precedence over "new fangled" approaches. These are the right priories, but I think they are taken too far.

Afterall, I'm really talking to engineering businesses here. For them, engineering isn't just about getting the right answer like it was when we were doing our homework in college. It's also about building great products that are safe and profitable (yes, in that order). And it's the "profitable" part we can't forget about. Getting the right answer is a "necessary, but not sufficient" condition for safe products. But a big differentiator for businesses is (or at least should be) efficiency of the process. A lot of industrial companies would like to improve process to improve their bottom line, but they have a hard time figuring out if they will be sacrificing correctness in the process.

The other factor I see is that I don't see a lot of strategic emphasis from companies on these topics. So even if someone on the inside is bold enough to try and reshape their internal processes to improve efficiency while preserving correctness, they don't have the will or the bandwidth to drive the market as a whole. As a result, they really can't push existing vendors or seed new vendors unless they make strategic decisions (potentially partnering with other industrial companies) to drive the market where they want it to go2. As somebody who is trying to develop tools developed for an "Engineering 2.0" market, I'd love to see this happen.


So there you have it, a lot of potentially incorrect or misdirected raving about the state of engineering. Hopefully, I'm wrong and there is more going on than I know about. I know a few businesses trying to push "Engineering 2.0" approaches, but I just wish this issue had greater visibility with customers.

  1. Don't know what CompuServe was? Ask your mom and dad. 

  2. At a recent seminar, I had somebody in the audience from a large automotive OEM try to convince me they were helpless to change anything because they were at the mercy of a supplier who was ~1/1000th their size (in terms of market capitalization). That is what a failure of corporate/industry strategy looks like. 

Share your thoughts

comments powered by Disqus