Perspectives of a System Architect

Tangram Flex is excited to continue the multi-part series about bridging the treacherous gap in engineering.

Scott LaChance, Principal Systems Architect at Tangram Flex, shares his perspectives on the treacherous gaps in engineering in this edition of our CSIP blog series. Scott is an experienced technical leader who shares his valuable knowledge and skills in systems and software engineering, architecture, and logistics with the Tangram Flex team.

Why is it so hard to build a system as designed? What keeps the conceptual design from being realized while satisfying the customer expectations? When did “code and fix” become a best practice?

Even in modern Agile and DevOps environments, the need to elicit requirements, have an architecture, perform design activities, implement the design through code, test the system (beyond unit testing), and deploy securely still exist. Much of this is automated with current tools — and reuse is getting easier — but the traditional engineering discipline is still relevant and necessary.

Not All Roads Lead to Rome

The perspective of which core issues keep programs from delivering systems as designed depends on the role of the person describing the problem. In a typical DoD contractor organization, program management, systems engineering, and software development are separated. With little overlap between the units, each has its own viewpoint:

• A program manager looks at it as a schedule and cost problem
• A system engineer sees it as a requirements problem
• A software developer considers it a software tool problem

Each role uses different tools and processes to fix their issue.

With the idea that modifying program schedule and cost will improve the end product, program management has the tendency to cut back on discipline in engineering. Although this may make sense on paper, this practice often results in less capability delivered, unhappy customers, and an unstable system — in fact, increasing engineering discipline makes it more likely that critical milestones will be achieved.

Systems engineers try to write more detailed requirements, intending to increase the likelihood that the system will be designed as intended. This sucks up a great deal of the available schedule, leaving little time for development. This leads to software developers looking for a library that does not require any coding to save time, matching requirements to the library instead of building software to meet the system requirements. These practices lead to workarounds and inherited risk from software libraries and less testing because of schedule challenges, resulting again in less capability, unhappy customers, and an unstable system.

Mind the Gap

The tools and processes system engineers use to define systems to meet customer requirements provide a rich set of artifacts and traceability that satisfy many early customer milestones. Transitioning from these high-level designs to implementation, however, is a challenge. The system design needs to define how the system should behave before it is handed off to software developers. Typically though, the design does not have enough detail to enable the development team to fully realize it.

Tools used by the system engineers, such as Model Based System Engineering (MBSE), are not available to or understood by the development team, and designs are often exported into a non-traceable format like a static document or a simplified illustration. This creates a huge disconnect between those who write the requirements that define the system, those who implement the system requirements, and the expectation of the customer who receives the final product.

In practice I have called the disconnect between the what and the how as the fatal, or treacherous, gap. This gap is created as a result of the system engineers failing to fully define the necessary behavior (or the how) before handing off to the software development team. Simply defining requirements at a systems level is insufficient to clearly define the system for development. A domain object model, behavioral models, and a data model are also necessary at the level of systems design to enable successful software implementation.

The typical system engineer and software developer overlap on over 80% of the skill set required for developing a system. Requirements elicitation, modeling (MBSE), problem solving, systems thinking, configuration management, and detailed design are typical skills of both disciplines. The difference comes in the form of specialization. Some system engineering folks specialize in requirements, performance, testing, and other domains. Some software development folks are generalists, while others specialize in embedded software, low level drivers, algorithms, or web-based development. With this diversity in mind, it is critical for system engineers to design the system with sufficient behavior, including core domain objects, interfaces, data models, behavior models and constraints, to achieve the proper definition for the development team. The system architecture and design is a necessity, not merely a suggestion.

In practice, software developers, specifically junior engineers, are handed high-level requirements with no detailed specification as to how the system should behave and then told, “go implement”. There is no system design beyond a block diagram, no behavior models of how the system should behave, no performance requirements allocated, and no internal interfaces are defined. The detailed implementation design is left to the casual observer. In this type of engineering culture, software development activity is valued over productivity– developers are measured by lines of code, not by the output and quality of working software. This results in an unstable system that does not meet the customer needs and requires extensive rework.

Get Back on Track

In my experience, programs in which the domain model and the behavior of the system were specified and defined explicitly were much more successful. This level of specification traced requirements to defined behavior and allowed the development team to faithfully implement the system. This satisfied the customer, delivered the product on time, and the system was stable.

In case you were wondering, the team did not agonize over the model, requirements, or behavior– rather, we provide enough definition to get implementation started. These are the guide rails for the team, and we accept feedback and update them in real time. When challenges occur, applying the engineering discipline ruthlessly and efficiently allows us to resolve or mitigate risks, leaving no hard questions unanswered for the system. Sometimes we place unresolved questions behind an abstraction to address in parallel while development moves forward on the known parts. This collaboration between systems engineering and software development is both a key agile tenet and an example of increased engineering discipline. In my experience, operating without this collaboration has always led to rework, missed deadlines, and great cost.

Bridging the Gap with a Component Software Integration Platform (CSIP)

A key to bridging the treacherous gap is transitioning the high-level model (which includes requirements, domain model, behavior) to the tools used by the developers. This is where component-based engineering (CBE) can be applied. As a subset of MBSE, CBE works at the component interface level. These components, whether existing and available for reuse or simply defined at the interface level, provide building blocks that software developers understand and use to rapidly implement the capability specified by the design. There is traceability back to any system model, enabling the software development team to focus on the efficient implementation of the corresponding component.

Obviously, this level of system-to implementation-integration can be done manually with a great deal of discipline and commitment to process…. however, experience has shown that the first thing to go in a project is manual process discipline. This is where a CSIP comes into play.

A CSIP helps to promote engineering discipline by reducing rework and rekeying, maintaining traceability to the high-level design, and allowing software development teams to leverage reuse of existing components.

A good CSIP will have several automated integration points with system design tools, a component library that provides ready access to existing, verified components that can be reused by software designers, and will integrate with an organization’s existing build or CI/CD processes. This bridges the treacherous gap in several key ways:

• System engineers and software developers have assurance that the components being selected and integrated have an appropriate level of provenance and pedigree.
• New component definitions are automatically imported from the high-level design to quickly provision component interfaces for the software designers. This enables reuse at a component level.
• Requirements traceability from the high-level system is automatically available to the CSIP and software team. This tight integration provides a clear starting point for development, alignment with the system design (requirements, model, constraints) and can also provide the acceptance criteria in the form of acceptance test definitions.

As the software designer refines the details, there will be derived requirements that are mapped to the high-level requirement being implemented. Component model derivations are associated with the high-level model. This allows for automated requirements traceability that can be flowed back to the higher-level design tools. This greatly reduces the manual touch time for artifact generation and provides clear direction to the implementation team. There is greater visibility at the systems level into the implementation for the systems engineers, architects, and program management.

The capabilities of a CSIP are necessary to bridge the treacherous gap in engineering, and an automated CSIP supports rapid development and deployment goals of an organization. Our CSIP, Tangram Pro™, integrates with upstream MBSE and existing CI/CD pipelines or legacy build processes seamlessly and provides repeatable release configurations by providing variation management. This functionality not only bridges the treacherous, but spans across the bottom of the System V to integrate the full system implementation lifecycle. Adopting this approach unifies the goals of the program management, system engineering, and software development teams and leads to more capability delivered, happier customers, and stable systems.

Tangram Flex simplifies software integration for mission-critical defense systems. Every system is unique, but the mission is clear: the people on the ground need dependable, adaptable equipment to get the job done. At Tangram Flex, we understand the challenges of security, speed, and safety. Our team combines engineering expertise with our Component Software Integration Platform (CSIP), Tangram Pro™, to arm engineers with customized toolkits for meeting mission needs.

Tangram Flex is headquartered in Dayton, Ohio. Our staff has experience from DoD, Fortune 500 companies, and innovative software startups. We are dedicated to walking alongside our customers to keep pace with changes in technology. Get in touch: hello@tangramflex.com.