System of Systems Engineering: Part I – Challenges

This post is based on a paper titled System of Systems Engineering I’ve written about four years ago. It provides a clearer understanding of the development challenges. The content of the paper was based on several other IBM intellectual capital (IC). Excerpts from the ICs are included as-is. The paper proposes the IBM Rational Collaborative Lifecycle Management (CLM) solution best suited for reducing risk and improving outcomes for the complex System of Systems (SOS) engineering programs. While the recommended tooling addresses the full scope of the software delivery lifecycle from inception to production, it is not necessary that you should view the solution as an “all or nothing” proposition. The intent is to highlight the problem areas and make you aware of how the IBM Rational solution addresses them.

I will be publishing several posts based on this paper. This post covers the System-of-System engineering Challenges.

System of Systems Engineering Challenges

SOS programs are inherently difficult. Typically the High Level Architecture (HLA) and capability requirements are specified by an outside entities (e.g. from a Request for Proposal AKA RFP). These capabilities are translated into functional capabilities, which translates into operational requirements. In turn, the operational requirements are realized through hardware, software, or a combination of both, which are contracted out to various suppliers. In between is often a Systems Integrator (SI) responsible for initially decomposing the HLA into the components, and later assuring that the delivered components integrate into an operationally capable system that meets stakeholder needs. The lifecycle of the program is often governed by a formal process, with well defined phases, milestones and quality gates.

System of Systems Engineering - High level requirements are decomposed in delivery quality software.

Click image to zoom in

Experience has taught us that this model is risky and programs executed this way in the past have had dubious success rates. The outcome is beset by cost overruns, schedule slips, quality issues, and an inability to deliver software reflecting the specified SOS program requirements with adequate speed of software development.

Delivering quality software that meets functional and business requirements of SOS programs has become even more challenging for many reasons. The scope and capabilities of SOS programs have increased significantly in recent years requiring the integration of many software components which magnifies the development complexity. In addition, SOS applications today require a high degree of integration with other software (off the shelf and custom packages).

In addition to software complexity, the advent of distributed teams of SOS programs across SIs and contractors exacerbates the problems of managing the software development process. This broad geographical team distribution can introduce a multitude of errors in communication, which can result in problems managing data and synchronizing work. To the broader team, these issues can lead to decreased productivity, misunderstood processes, gaps in project plans, increased rework, lack of agility, higher coordination costs, mistakes in transferring work, poor project visibility and control, and challenges in measuring project success.

Moreover, the number of stakeholders in SOS programs goes well beyond just programmers and managers. Development teams for these programs now include business analysts, software developers, testers, project managers, lawyers, auditors, and other non-traditional participants.

The collaboration that is required to work within an extended development team can cause additional problems. Each team member is overwhelmed with excessive data from e-mails, Web sites, text messages, and other forms of contemporary communication. As SIs and contractors attempt to make critical business decisions, the volume of data challenges team members, who must struggle with time pressures while determining what data is relevant and where it is located.


In conjunction with the large number of stakeholders involved in software delivery, tools play an essential role in the development process, enabling unprecedented automation, removing manual tasks and associated errors, codifying best practices, and helping businesses to adopt systematic approaches to standards and governance.

Different stakeholders use tools for different purposes; requirements tools are used by business analysts and developers to manage, organize and communicate system requirements and architectures, while project managers use planning tools to schedule work activities and manage resources. Within the heart of the development process, software engineers use integrated development environments (IDEs) to edit, compile, and debug their code, while testers exploit a test management system to create test scripts, perform test automation, and record results. All members of the team track their work activities in a change management system, and then coordinate changes to system artifacts using a configuration management system.

Unfortunately, most tools have not kept up with the pace of changes in complex software systems. Many tools, including open source and vendor supplied, are silos that lack integration capabilities through standard interfaces. This lack of integration impacts the ability of the software delivery team to collaborate, automate, and report among the teams effectively. Project teams are often forced to work in a number of different tools, manually gathering information from a multitude of sources.

For SOS programs, managing this information efficiently and presenting the right metrics to the right stakeholders is critical to maintaining an optimal development process. Inaccurate or missed information can stall development efforts and ultimately compromise the programs missions and cause schedule delays.

Optimal software development for SOS programs requires a process that works effectively with distributed teams, addresses the integration challenges of software, and encourages stakeholder feedback early in the delivery cycle. Frequent delivery of an application encourages stakeholder participation, providing validation that the true requirements have been captured accurately and implemented correctly before the product goes into production.

In my next post, I will discuss a potential solution to overcome these challenges with the IBM Jazz platform.

About the Author

Sami's picure on cafesami.comSami Joueidi holds a Masters degree in Electrical Engineering and an Enterprise Architecture certification from Carnegie Mellon. He has over 20 years of experience as a technical leader of complex IT projects for Fortune 500 firms, in diverse roles such as Systems Integrator, DevOps, Cloud Architecture, Enterprise Architecture and Software Development & Release Management. He guides customers on how to leverage the latest technology trends to their advantage and helps them with their Cloud adoption strategies.

© Sami Joueidi and, 2015. Excerpts and links may be used, provided that full and clear credit is given to Sami Joueidi and with appropriate and specific direction to the original content.

Do you like to comment?

Loading Facebook Comments ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.

error: Content is protected !!