The Manager’s Survival Guide for Architecture-Driven Engineering

Architecture-driven engineering, a relatively new engineering approach where an optimized and validated architecture is developed before detailed design, shows quite a bit of promise in the manufacturing industry.  As a result, many organizations are exploring whether this method is a good fit and whether it’s the right place to start their digital engineering initiatives.

Architecture-Driven Side of Digital Engineering

Architecture-driven engineering is a technical-led approach. Engineers start by developing the structure of an E/E system, partitioning it into different domain-specific work, and simulating its performance. By building the model of the architecture at the beginning of the process, they can use it to explore various design alternatives and even perform trade studies. The model encapsulates details including what software functions are associated with which electronic endpoints, which signals run on different pieces of the network, and much, much more.

Given the rising complexity of today’s E/E systems, taking an architecture-driven engineering approach can yield significant value for organizations. But that doesn’t necessarily mean it’s the right first step in your overarching digital engineering strategy. This post will consider the people, process, and technology factors outlined in the first installment of this series, The Manager’s Survival Guide to Digital Engineering, and contrast them with the architecture-driven engineering model.

The Cultural Fit

It is all too easy to look solely at the technical benefits of a digital approach when considering adopting it. But that would be a mistake; one of the most challenging aspects of any improvement is the associated cultural changes involved.

Architecture-driven engineering can sometimes represent a problematic leap for engineers. It requires abstraction, where blocks and symbols represent different aspects of the E/E system. These abstract elements can change drastically from one candidate architecture to another.

If your organization consists primarily of electrical or electronics engineers, this may not be much of a challenge. These abstractions frequently surface in the schematic and diagramming phase of design prior to layout. As a result, an architecture-driven engineering effort may be a good, strong fit.

By contrast, mechanical engineers regularly solve problems abstractly by coming up with complex concepts for designs in their head. Generally, the first time they do any digital work is when it’s time to document the physical implementation in a 3D model. If your organization is heavy on mechanical engineers, you may find that an architecture-driven engineering approach requires a bigger leap.

On the other hand, software engineers may be too well-versed in abstraction. As you undertake an architecture-driven engineering approach, you may find they have trouble understanding that an abstract concept links directly to a physical piece of hardware with mechanical, electrical, electronics, and software components.

The make-up of your engineering department is a critical factor when considering an architecture-driven engineering approach. Unless you have systems engineers, who can take on leadership roles, you will have to rely on some mix of electrical, electronic, mechanical, and software engineers to develop, iterate upon, and simulate these architectures. It’s important to keep that in mind.

The Change Plan for Architecture-Driven Engineering

The second challenge is managing the transition from your current processes to one where architecture-driven engineering plays a primary role. Having a change management strategy to guide you is paramount.

To start, it’s important to identify where and when architecture-driven engineering will come into play in your development process. Will concept development work precede it, or is architecture engineering the first step? How will you manage the hand-off from architecture engineering to detailed design work?

To successfully adopt this approach, an organization needs solid answers to such questions to carefully assess how the change plan will look. Defining an overarching process—and locating architecture-driven engineering within it—is critical to this effort. Once you do this, the other components of your effort will fall into place. You can then figure out what resources you need to solve potential problems during the change. You can also document and disseminate the sequence of process steps that people must follow, developing a steady cadence of supporting communication to reinforce the process as you move forward.

Pursuing an architecture-driven engineering pilot program is an excellent first step for many organizations. While any new effort will need tweaks and changes, this kind of pilot program allows the ability to iterate the process in multiple stages to support a smoother transition to this new, architecture-driven way of doing things.

The Technological Change of Architecture-Driven Engineering

As you pursue an architecture-driven engineering approach, using old-fashioned spreadsheets and other documents in the product development process can put you at a serious disadvantage. These tools just aren’t up to the task of tracking the complex changes occurring across the development of architectures for today’s E/E systems.

Organizations will see significant gains if they adopt a systems engineering tool to support a model-based systems engineering (MBSE) approach instead of relying on outdated manual processes. A tool tuned specifically to the E/E systems process allows them to better manage and address follow-on technological change issues. As you consider what technology solutions can best support your move to an architecture-driven engineering approach, ask yourself the following questions:

• Are there any data sources, models, or other critical information that should be part of these MBSE tools? What is the volume of these digital artifacts? The answers to these two questions can assist you as you determine what approach to use to migrate legacy data, models, and other information to your new tools.
• What digital artifact will support each step in the development process, especially during the architecture-driven engineering phases? Answering this question provides a clear map of how engineers can transition from one phase of development to the next.

Survival of the Fittest

In order to manage the ever-increasing complexity of today’s modern products, manufacturing organizations are looking toward different digital engineering approaches to make improvements. Architecture-driven engineering is a relatively new concept, yet it holds great promise to help engineering teams better manage the complexity of E/E systems. To realize that promise, organizations must consider how such an approach might fit with their engineering culture, how they can support the necessary changes to the design and development processes, and how they can make the right investments in technological tools to support their efforts. Referring to this survival guide can help you determine whether an architecture-driven engineering approach is the right fit for your organization.

—–

For more information about digital engineering, architecture-driven engineering, and model-based engineering, visit our website or download our Digital Engineering eBook.