My Goal

As a company, Xogeny's goal is to find a way to bridge the gap between the technology sector and engineering. The technology sector is a veritable fountain of innovation and progress. On the engineering side, we don't really leverage all of these advancements. As engineers, we live in a world that is like a time capsule containing technology from 20 years ago (or more).

So I've tried to dedicate myself to finding ways to channel innovations I see in the software and IT world into engineering so that engineers can benefit from all the same kinds of advances that we see fueling the growth and innovation in the tech sector.

Easier Said Than Done

Of course, I didn't expect all this to be a piece of cake (otherwise we would see more of it). But I initially assumed the hard part would be identifying the engineering problem and pairing it up with the software/technology solution. What I was expecting (and is still mainly true) is that people coming from an engineering background really don't recognize that the solutions coming from the software/technology space actually solve some of the engineering problems they have. For example, many of the advancements that Modelica brings to the world of physical modeling are actually derived from graph theoretical algorithms from the computer science world. But this topic is hardly limited to modeling and simulation, I see it across engineering. As I've pointed out previously with topics like version control, things that are "solved problems" in the software world continue to plague us in the engineering world either because we don't recognize how to apply the technology or we frame the problem is such a way that we make it difficult for ourselves to leverage the solution (or both).

I have been pleasantly surprised so far that most of the people I've talked to on the engineering side have been quite enthusiastic about my ideas around web-based engineering analysis applications and cloud based engineering workflows that combine engineering problems together with software solutions.

But The Real Problem Is...

But even when I get engineers enthusiastic about how we can modernize engineering software, what has really stymied me is the IT organizations. Now I should say in advance that I recognize many of the challenges faced by modern IT organizations. I was the Global Director of IT for Emmeskay. So I know there are lots of operational details that need to be covered. Obviously, these organizations are constantly working to make sure all the hardware is functioning, that email is working, that viruses aren't spreading and that networks are up. Not to mention, for example, the various regulatory concerns regarding financial controls in publicly traded companies.

But in my discussions with a bunch of people in engineering organizations from different industries, the one thing we all seem to agree on is that there is an organizational issue between the engineering and IT functions. When I speak with engineers, it is almost universally the case that they see IT as an organization that largely rebuffs their requests. In a nutshell, it is (at least from their perspective) an organization whose job is to say "No".

This is not meant as a generalization about all IT organizations. I've seen several very forward looking organizations where IT and engineering work very closely to great effect. But in my experience, those are the exception, not the rule.

This is fascinating when you consider that I'm talking about engineering companies. Their entire value proposition rests on doing engineering work. And yet, that value proposition is in many ways diminished by their inability to leverage innovative ideas.

The bottom line is that you end up with engineering organizations being subservient to IT organizations when, in my opinion, it should really be the other way around. This is actually partly an organizational issue. The organizational part is that IT should have its deliverables set according to the engineering agenda. Of course, part of those deliverables will be functioning infrastructure. Part of them will be related to other essential functions like HR and finance. But some of them should be related to innovation targets set by (forward looking) engineering organizations.

But this is not entirely an organizational issue. There is a deeper issue. And here is where I turn the tables a bit. There are lots of good reasons for IT organizations to say "No". Engineers, left to their own devices, will likely tend to formulate quick and dirty (non-robust) approaches or seek out short-term (short sighted) solutions. Furthermore, they are not necessarily conversant enough in the technologies and approaches to really come up with concrete plans (or hire a consultant like me to help them). So part of the problem is that some fraction of the engineering side need to actually learn about the technologies that are available and the opportunities they afford and be conversant enough to really negotiate with the IT organizations in a knowledgeable way. In a sense, the result of this compartmentalization of engineering and IT is that it creates a communication breakdown where the requirements from the engineering side cannot be properly articulated and any objections from the IT side cannot be credibly challenged.

"Engineering IT" Manifesto

So my point here is not to point fingers. IT is a complex topic and implementation is hard. It is understandable that requests that further complicate the task are frequently met with a "No". On the other hand, we need to modernize the way we view the role of IT in engineering companies.

As such, I propose the following Engineering IT Manifesto as a way to think about how we move forward from this point. The essential points are:

#1: IT is an essential component of Engineering

We cannot deny this fact. The only consequence of denying this is dysfunction. The fundamental thread that runs through all of these points is the counter-productive compartmentalization of IT and Engineering. The first step in addressing that is dismissing the notion that they should be compartmentalized in the first place.

#2: Engineers must value IT

An engineers fluency in IT must go beyond email and spreadsheets. Fortunately, my experience is that the next generation of engineers seem to be more informed and interested in learning about how IT can add value to engineering. But we need to make sure that they are given the chance to explore this and that this exploration is valued by their management. My sense is that most young engineers I know are held back by generations of engineers who want to continue using legacy approaches. This is a lost opportunity of epic proportions, in my opinion.

#3: IT deliverables must be tied to engineering success

It seems clear that the power structure in engineering companies needs to reinforce the idea that the engineering groups need to take a more active role in defining the deliverables for the IT organization. This means not just that they have the authority to define deliverables, but that they have the knowledge (as per #1) to do so.

#4: Stop looking to vendors to solve your problems

What I often see is engineering organizations who don't want to be "distracted" by IT related issues. They see these issues as somebody else's problem (or at least want them to be). This not only reinforces the compartmentalized approach to IT, it puts them in a frame of mind to "outsource" their IT related issues. Sadly, this often means being coaxed into buying large, monolithic software solutions that do lots of things they don't need and only a few things they do need (poorly, in some cases).

One thing we, as engineers, can learn from the software world is to look for light, modular approaches. We don't want to have to create our own solutions from scratch nor do we want to embrace these monolithic solutions. The "sweet spot" is in composing solutions from "building blocks" that solve specific problems and then putting them together in a way that makes sense for our engineering processes. But this, of course, requires an understanding of how to put the building blocks together (see #1).

#5: IT and Engineering need to formulate a joint strategic plan

The final piece in this puzzle is to make sure that somebody is pushing a vision of the future that capitalizes on emerging technologies to benefit the organization. This vision needs to bring both IT and engineering stakeholders to the table to map these things out. Too often, engineers are content when they have processes that yield the correct mathematical or physical result and overlook the business need for competitiveness. For an engineering organization it is necessary that somebody be aggressively looking out for how to improve the overall efficiency of the organization and capturing value from innovations in the software/IT world.

Summary

We need to see this compartmentalization of engineering and IT as a bad thing and take steps to break down these barriers. IT people need to see their role as facilitating engineering innovation and engineers need to be better educated in these topics to help formulate solutions and independently evaluate the merits of different processes or strategies. I think there are many people on both sides who would love to work toward this kind of vision.

Of course, I'm biased. I spend a lot of time thinking about this nexus between engineering and IT. I see so much potential here and yet so little interest in exploiting it. So there is always the chance that much of this is just wishful thinking on my part. But based on conversations with lots of people, I still see this as an issue that could bear a lot of fruit for engineering organizations.

I would love to get feedback on this. Whether I'm right or wrong, I'd love to hear from you (or better yet, help you and your company address these issues). So feel free to contact me or share you comments below.