Architecture focuses on building the right system and model-driven use-case based architectural decomposition lays the foundation for building the system right. Why is architecture singled out? Because it provides the foundation on which the system is ultimately constructed. The choices made in selecting the system's architecture become a lasting legacy - either good or bad.

Here's a transportation example: The basic architecture used for centuries in building roads or other transportation elements (like rail tracks) was basically point-to-point (the shortest distance between two points can be considered optimal since it minimizes the road length and one would assume maximizes time to travel efficiency). Simple enough, but there was always at least a physical constraint: the terrain, which forced the path to avoid obstacles. There were also other potential constraints such as "hostile" territory or political boundaries.

In any case, roads were built and paths crossed somewhat haphazardly. Move forward to the 20th century. Population growth generated additional constraints - namely street lights or traffic signs to optimize the flow of traffic through intersections. These are somewhat problematic on roads architected in the point-to-point avoid obstacle approach, especially where more than two roads intersect. A clearly "better" architecture has proven to be laying out roads in rectangular grids. This architecture and the many implementations are much easier to control from a signaling and traffic flow perspective.

So build the right system and build it right - making it robust (scalable, extendible, easy to maintain, easy to use, and so on).

The systems development framework focuses on defining the right things to do throughout the product lifecycle to optimize business value and return on investment and best practices, processes/supporting tools and governance (requirements, quality, change, configuration, and program/project management) focus on ensuring things are done right.

"Doing" and "building" are action verbs; they require resources to perform the "doing" and the "building". The most significant enterprise resource is people, followed by supporting infrastructure. Acquiring, motivating, and retaining skilled personnel applies the right resources, and aligning the organization appropriately to optimize communication, collaboration, and effort applies the resources optimally. A sound enterprise infrastructure (including IT equipment and software) is one key aspect in ensuring the resources are applied optimally, once again maximizing business value and return on investment

The six principles of systems engineering address all three aspects described above. The three technical principles (noted below) focus on architecture and the derivation of system models, while the remaining principles provide the complementary infrastructures and workflows needed to optimize the technical development environment.

The six systems engineering development principles are:

1. Decompose systems, not requirements (technical).
2. Enable both separation and integration of "key systems development" concerns (technical).
3. Specifications flow up and down the architecture (technical).
4. Systems and components collaborate; so should development teams.
5. Development organizations should reflect product architectures.
6. Base the "development" lifecycle on removing risk and adding value.

Decompose systems, not requirements
Since systems and software engineering principles and methods have been written about, discussed, and applied in countless cases, one might think that development teams have a common understanding of such terms as "system" and "systems engineering." Unfortunately, this is not the case; neither across enterprises within a specific industry nor across the product and functional domains within an engineering development community in a single enterprise.

According to INCOSE (the International Council on Systems Engineering), systems engineering is²:
An interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem:

• Operations
• Performance
• Test
• Manufacturing
• Cost and Schedule
• Training and Support
• Disposal