The Definition of the Disciplines of Systems Engineering

I posit that the Systems Engineering discipline has three sub-disciplines:

1.       Systems Engineering – the role of the systems engineer is to work with the customer to identify the customer’s “system” and “programmatic” requirements and to ensure that the customer’s system requirements are met (the system has been validated.)

2.       System Architecture – the role of the system architect to:

a.       decompose the customer’s requirements and to derive the functions needed to meet those customer requirements,

b.      then structure and order the functions into a functional design or system architecture (what M. Griffin calls an elegant design), and

c.       finally to allocate the requirements to components using tradeoff studies to determine the actual components. The design is then handed off to the SMEs for detailed design and component verification

d.      The system architect the verifies the functions and works with the configuration manager to ensure that the system that is verified is the system that is migrated to the validation procedures

3.       Enterprise Architect – the role of the enterprise architect is to support the organization’s investment process to ensure that the funded projects and programs optimize the systems and tooling for the organization to meet its mission using its strategies.  Additionally, the enterprise architect supports the Governance and Policy Management process to ensure that the policies and standards minimize the intra-/inter-organizational process friction.

There is a good deal of detail I left out, like the fact the risk management ties the requirements to the design in multiple ways.

Most IT ignores most of System Architecture process completely, and goes directly from poorly identified customer requirements to components, creating systems with many redundant components, with many unnecessary components, with missing functions, and with gaps at interfaces among the components.  These the teams consider “design defects” which is probably right because the team did not take the time to perform system architecture to create the functional design.

Systems Engineer must identify the mission, strategies, and model the organization’s process, if they want to use SOA…otherwise, the SOA implementation will be a flat failure…I suspect this is true of most Cloud Computing, as well.  This steps beyond of the boundary of traditional IT into business process analysis…per Dr. Michael Hammer, and into the world of the virtual extended enterprise and the next generation manufacturing efforts, that I worked on in the early and middle 1990s under DoD and NSF grants.

My definition of the role of the Enterprise Architect is unique, as far as I can tell, even though it is based directly on concepts in the FEA/DoDAF 2.0.  This is well beyond traditional IT and into organizational management and decision-making.