Although systems engineering is most accurately about technical integrity, it is often said, “the product of systems engineering is baselines.” One of us had a senior systems engineer tell him that systems engineering is only responsible for the technical documents about the system. They indeed are, but the purpose of documented baselines is to achieve technical integrity, and it follows that appropriately identifying, documenting, communicating and managing change is an important aspect of enterprise architecting.
This is perhaps most important during concurrent development, and has frequently arisen in various space enterprises. Consider a new constellation of satellites that must be integrated with existing legacy satellites, with the satellite control network, with mission control, and with ongoing developments across various organizations concerned with ground segments of the enterprise architecture (Figure 2). Enterprise change management becomes extremely challenging in this complex enterprise environment.
A change management control board should be invested with executive authority, and should be chaired by a member of the acquisition organization ─ the element of the enterprise that is paying the bills and worrying about
the schedule. The system supplier often serves as the secretariat of the board. All deliberative bodies that evaluate proposed changes, such as the requirements working group, provide support, advice, and recommendations to the control board, but only the executive authority invested in the control board can decide when a change can be allowed and when it cannot.