Page 1 of 8

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.

This fundamental disconnect means companies cannot

fully achieve the product capabilities and

developmental performance improvements they

envision from systems engineering. Most large

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.

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

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

Laboratories and University of Arizona

Figure 1: What is Systems

Engineering?

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

Page 2 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 3 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

2 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-landed-upside-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

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-landed-upside-down.htmhttp://current.com/community/89197208_mod-scraps-227m-phoenix-spy-drone-that-hated-heat-and-landed-upside-down.htmhttp://openlearn.open.ac.uk/mod/oucontent/view.php?id=397849&section=1.2http://3mr.me/1-2-the-phoenix-project/http://www.darpa.mil/Our_Work/TTO/Programs/AVM/AVM_Design_Tools_(META).aspx

Page 4 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 5 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 6 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 domain-

specific 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 7 of 8

sub-system and ultimately component level. While quality by design is a decades-

old 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, (AutoSAR4) 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 http://www.autosar.org 5 http://open-services.net/

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

Page 8 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.

mackmaTypewritten TextRAL14060-USEN-00

mackmaTypewritten Text