Strategies to Capture Greater Value from

Systems Engineering
Executive Summary
Achieving sustainable growth and profitability in an environment of constant change and
increasing complexity motivates companies to find better ways to develop and produce
innovative products. Systems engineering (Figure 1)1 helps address these needs through its
capacity to improve a companys design, manufacture and support of complex, highly
integrated products.
While systems engineering is widely discussed and
implemented in some form at many companies, the
actual practice tends to fall short of the ideal. Most
companies that develop complex products have
systems methodologies in use. However, the
development and engineering practices relating to
these, and the abstract whole systems models that are
at the heart of the systems definition process, are not as
well integrated into the product development lifecycle
as they could be.

Systems engineering is an
interdisciplinary process that
ensures that the customer's needs
are satisfied throughout a system's
entire life cycle..to produce
systems that satisfy the customers'
needs, increase the probability of
system success, reduce risk and
reduce total-life-cycle cost.
Source: A consensus of senior systems

engineers facilitated by Sandia National

This fundamental disconnect means companies cannot
Laboratories and University of Arizona
fully achieve the product capabilities and
developmental performance improvements they
Figure 1: What is Systems
envision from systems engineering. Most large
Engineering?
companies have product lifecycle management (PLM)
systems that deliver good automation and collaboration
in their mechanical and physical design areas. Separately, software configuration
management (SCM) or application lifecycle management (ALM) for embedded software
development delivers strong workflows for software-related activities. Unfortunately, in most
instances these two domains do not communicate well, and each struggles to effectively
leverage the abstract whole system model at every stage.

For a more integrated vision of systems engineering to be practical, change is needed. As a

key element of this, software suppliers must deliver appropriate capabilities above and
beyond those currently available in PLM, SCM and ALM environments. To deliver more value,
development strategies must take a broader view of systems engineering. These software
systems (PLM, SCM and ALM) currently provide somewhat discrete domain-driven workflows.
What is needed is an overarching and pervasive management system to mitigate
complexity in both product and process. Fortunately, new developments in standards and
software are allowing these changes to occur.

http://www.sie.arizona.edu/sysengr/whatis/whatis.html

Page 1 of 8

In turn, companies systems engineering approaches must mature to leverage this new layer
of software as it emerges. As a foundation, executives must create clear visions for holistic
systems approaches within their operations. They should actively engage in programs that
ensure improved knowledge sharing across many development and operational disciplines.
Importantly, their support for changes needed in company working cultures and habits will
be critical to the success of these programs.

Focus on the business

In a business environment characterized by increasing competition, shorter times to market,
increased regulatory pressure, globalization and an increasingly complex stakeholder
network, companies are driven to focus on those business initiatives that deliver timely, high
value returns.
Systems engineering is an enabler for business initiatives that focus on revenue generation,
profitability, quality and operational performance. Examples of these include:
-

Improving product innovation and development processes

Improving the management, reuse and synchronization of knowledge, intellectual

property (IP) and resources

Improving product quality

Improving production efficiency

Improving lifecycle profitability

It aims to achieve these by delivering a more structured, integrated and collaborative

development strategyone that delivers value across mechanical, electronics and software
domains, and leverages reusability across the lifecycle.

A less than perfect environment

In many companies, however, systems engineering exists more as an additional discipline or
engineering team practice rather than a pervasive and integrated methodology across all
domains. One commonly observed practice is that sub-systems are often designed in relative
isolation. This environment is one where requirements persist with significantly local context
but without the highest level systems requirements linked in an automated way throughout
the development lifecycle with any consistency. This undermines the intent to better
understand the sub-systems behavior in the context of the system as a whole.

Page 2 of 8

A relatively recent military example highlights problems exacerbated though poor systems
development. The Phoenix2 drone was ordered by the British military and delivered in the late
1990s. To quote one press source Its troubled 1990s development history is now used as a
how-not-to-do-it example in university systems engineering coursesThe Phoenix was
especially renowned for its Rube Goldberg/Heath Robinson recovery method, in which it
descended to land hanging upside down beneath a parachute. This was in order to
safeguard sensitive sensor gear in a belly pod. Unfortunately, the upside-down landings were
found to wreck the fuselage, so exasperated engineers finally added a dorsal airbag to
cushion the shock Attempts to remedy this and other faults in the Phoenix resulted in
significant added costs and ultimately a re-assessment of the militarys choice of drone.
Historical investments in domain-specific applications, workflows and data sets have resulted
in islands of domain competence. Even use of multi-faceted systems such as PLM for
electronics and mechanical design, and SCM or ALM for software can result in disconnects.
Although these are fundamental to the successful operation of the complex system, their
somewhat isolated use can create challenges, particularly around successful integration of
sub-systems to deliver the final product. Thats not to say, of course, that these domain
technologies, knowledge or workflows exist in isolation, far from it. However, historically there
has been a heavy reliance on manual or proprietary interfaces.

Reconsideration of current strategies

While initiatives with regards to systems engineering may be company specific, a few key
issues may serve as catalysts for re-considering current developmental strategies. Some
examples of these include:

Focus on the right question

Many companies use more of a bottom-up approach to design and manufacture,
which often exacerbates domain bias in systems specification. The result is a focus on
answering what can we do most efficiently with this technology? A more holistic
lifecycle systems approach focuses on answering the overarching question what is
the most valuable thing to do?
The importance of this is clear in recent US Department of Defenses Defense
Advanced Research Projects Agency (DARPA) programs such as META3. Critical of
specialist build programs for complex multi-domain systems, these DARPA programs
treat concept through manufacture phases of complex defense systems and
vehicles in a more cohesive manner and increase focus on headline systems

http://www.theregister.co.uk/2008/03/26/phoenix_says_goodbye/
http://current.com/community/89197208_mod-scraps-227m-phoenix-spy-drone-that-hated-heat-and-landedupside-down.htm
http://openlearn.open.ac.uk/mod/oucontent/view.php?id=397849&section=1.2
http://3mr.me/1-2-the-phoenix-project/
3

http://www.darpa.mil/Our_Work/TTO/Programs/AVM/AVM_Design_Tools_(META).aspx

Page 3 of 8

requirements from the earliest stages of the development process. They provide a
better means for all stakeholders in their various disciplines to remain mindful of
primary business and product objectives and overarching product requirements.

Understanding systems in context

In the real world, systems exist not just as an independent product in an empty or
static space, but in the context of how they are actually used. The relationship
between product requirements and the products, software and sub-systems that fulfill
them is a complex one.
For example, the anti-lock braking system (ABS) in a car has the synergies between
the mechanical, hydraulic, software and electrical control elements that are
fundamental to the systems successful operation. In addition, in-use operation is, to a
very large extent, dictated by external factors - how heavy is the car, where is its
center of gravity, at what speed and in what orientation is it travelling when braking is
applied? What is the makeup and adhesion level of the tires and what are the road
conditions on which its travelling? All of these (and more) play a part in the overall
performance under which the ABS operates and performs to its specification.
Historically, assemblies such as the ABS were often defined and optimized during the
development process without heed to the many inter-domain and external factors
cited above. This disconnect ultimately makes the task of meeting systems
requirements all the more difficult, with many issues apparent at latter stages of
development, or worse yet, in production or final test.

Efficient knowledge and data sharing

In any business, knowledge and data are critical assets. However, many companies
find that managing and sharing these is increasingly difficult. This is particularly true in
the context of a complex systems environment. Exacerbated by the busy schedules
of domain experts and a multitude of distributed, often domain specific repositories,
efforts focused on sharing, extending visibility and reuse often do not fully succeed.
As a result, these assets are significantly under-utilized. Companies are also often
burdened by disjointed manual approaches to capture, manage and disseminate
information. This creates ad-hoc workflows that result in excess effort, and pointless
re-work.
With regards to data and importantly the tools that create and use it, in a large
company there will be hundreds if not thousands of applications which need to
interface. Proprietary data formats and the lack of software vendors openness make
it difficult to truly capitalize on this wealth of valuable data artifacts. Highlighting the
challenges to integrating complex IT infrastructures, one senior engineer from the
automotive industry says that as a result of legacy independent investments made in
software applications and IT infrastructure, we wouldnt want to start from where we
are now. Whilst the efforts of standards organizations do provide some degree of
data transparency and portability, many vendors resist them, hoping to reduce
competitive erosion in their established positions. Going forward though, the
increasing influence of vendor openness in the software ecosystem will undoubtedly
provide a barrier for those vendors still harboring proprietary ambitions.

Page 4 of 8

Quality
There have been many high profile and costly quality failures in the press of recent
years. Quality is a testament, in part, to the competence of a company's product
development lifecycle programs which includes, of course, systems strategies. Any
disconnect in the development process from issues such as common data reuse and
domain interface act as inhibitors to improving overall product quality. Eminently
highlighted by the Phoenix drone example above, the complex relationship between
systems, sub-systems and their constituents can obviously be fractious on large
projects. This makes it all the more important that quality and testability be intimately
integrated throughout the overall development process from the kick-off.

Developing a vision
Systems methodology should, by its nature, form the basis for improvements that span the
entire development lifecycle, encompassing areas such as requirements definition, design,
optimization, variation, quality and test. Any re-definition or re-focus of systems engineering
approaches will obviously require careful consideration of opportunities balanced against
cost and risk.
To move forward, companies need a more integrated vision of systems engineering. This
vision is one that defines a holistic systems approach that delivers a better understanding of
how and why decisions were made, and what influence these have on the products and
processes.
If this vision is deeper than the one you work to today, youre in the majority. For most
development organizations, change in both working practice and technology solutions will
be essential to fully deliver on the goal of more integrated development structures. As with
other broad reaching initiatives, change is most successful when driven by a vision from
upper levels of management. Executive support and participation to provide guidance and
encourage collaboration is essential to making the organization much more capable than
the sum of its parts.
It almost goes without saying that due diligence in establishing the vision is important in any
change program. Yet it is often skipped over or rushed through on internal change projects
without the support and advice of trusted advisors. Software suppliers, consulting and service
providers are amongst the many organizations that have a wealth of knowledge and
practical domain experience to help define practical routes forward. These organizations
can help companies understand the opportunities and risks of potential investments and
provide insights into best practices and technologies that may better address development
needs.

Software tools as enablers

To turn vision into reality, software providers need to enable a new level of integration
between the abstract systems models and the lifecycle systems that manage development

Page 5 of 8

artifacts. This should be one that ultimately maintains the abstract whole systems model as a
constant integrated reference, and one that delivers effective and integrated sub-system
developmentin short, one that achieves the promise of a true systems approach.
In practice, more effective developmental strategies supported by appropriate technology
investments will help to drive positive change in your business. With this in mind, some of the
activities that you may wish to consider on the road to improvement include:

Link the whole system to sub-systems for re-use

The companys systems engineering and reusability strategies need to facilitate a
top-down and agile development infrastructure. Accomplishing this amongst the
disciplines requires a good understanding and definition of the system as a whole as
well as greater flexibility in subsystems decomposition and reuse. Look for more than a
product-centric view of discrete reusable elementsone that supports reuse from the
highest level of system definition through sub-systems, product development and
manufacturing processes.

Improve your understanding of systems in context

The ability to evaluate systems in the context of the whole allows companies to take
best advantage of earliest stage optimization, which includes evaluating cost and
opportunity of trade-offs before committing to expensive detailed sub-system design
and analysis. As system modelling methodologies and supporting languages evolve,
this continues to be an area of significant investment by both software suppliers and
standards organizations. Look to take advantage of these evolving technologies and
standards at the earliest opportunity and through the entire development lifecycle. It
goes without saying that these software tools should not act in isolation; they should
of course collaborate with the design, simulation and test solutions used in the
extended product process.

Improve your leverage of existing data and workflows

The historic cost of integration and customization complexity in addressing
development across domains has, to date, proved a daunting challenge for most
businesses. This is in part because of the proprietary nature of many of the software
solutions in use. Look to develop your systems engineering strategies to better
leverage existing data and workflows. PLM, SCM and ALM are key components that
drive workflow in most large development environments. The recent evolution of a
number of these systems from predominantly single discipline coverage to broader
cross-domain remits makes them more open to third party integration. Continually
push your software providers to open up new possibilities for these core domainspecific systems to share data more effectively.

Design in quality and testability

Integrated, systems oriented approaches for quality and test can result in better
calibration of initial requirements to product deliverable. Using the ABS system
mentioned earlier as an example, one can imagine integrated quality and test
strategies that encompass the complete development processfrom whole car to

Page 6 of 8

sub-system and ultimately component level. While quality by design is a decadesold concept, systems engineering can bring it to a next level of effective deployment.
Seek to apply integrated quality and test processes that leverage the benefits of the
top-down strategic systems model to deliver a more auditable and ultimately
valuable strategy for quality processes.

Take advantage of standards

Given the multi-vendor environment that exists in all large companies, companies
must find a way to enable synergies between their various applications. Standards
such as the Automotive Open System Architecture, (AutoSAR 4) and Open Services for
Lifecycle Collaboration (OSLC5) are amongst the many organizations that aim to
support such a vision. As software vendors continue to develop applications that take
advantage of these standards, companies gain a new opportunity to use software to
provide an inclusive view of their development environment and its performance. This
new approach has a view inclusive of systems and sub-systems. Encourage your
software providers to adopt open standards; it provides both you and them a more
integrated development environment that reaches far beyond their own product
suite.

Conclusions
With a background of economic unrest, uncertainty in product demands and an
increasingly savvy customer base, there is pressure on businesses to deliver better, more
profitable products. Delivering these in the context of increasing development complexity
continues to focus discussions on technologies in use and strategies employed to deliver
product to market. Companies must move to better utilize all aspects of their knowledge and
asset base.
Evolution from accepted development paradigms is rarely straightforward. Faced with the
task of moving from well-established, often discrete domain-driven workflows, to a top-down
approach that is at once transparent and collaborative, businesses will inevitably require
change in both corporate and individual cultures. Nonetheless, the vision of a truly
integrated multidisciplinary development lifecycle arguably may only be achieved through
a more strategic view of both product definition and its development from the offset,
leveraging the values of the business as a whole to generate value beyond the mere sum of
its parts.
Of course this wont be easy, but there are actions that all large producers of complex
products can take now. A pragmatic re-assessment of existing systems engineering strategies
as a starting point would undoubtedly help companies better appreciate any disconnects
between their overall corporate goals and their in-use technologies. Within this task,
companies have the opportunity to assess the relationship between departments, workflows,
and data to help define and influence future activities.

4
5

http://www.autosar.org
http://open-services.net/

Page 7 of 8

In line with the holistic systems engineering approach advocated by this paper, any
technology investments must act to support corporate objectives - not define them.
Customers, especially larger ones, have a valuable part to play by inciting software vendors
to deliver more valuable, open and collaborative working environments. Having said this,
software innovation is ongoing and there are some interesting developments coming from a
number of software vendors. Indeed the realization of systems engineering as an overarching
and integrated practice throughout the development lifecycle, along with upcoming
solutions to support it, may well be closer than one thinks.

Page 8 of 8
RAL14060-USEN-00