Model-Based System Architecture, 2nd Edition

13Roles

13.1 Roles

On systems engineering conferences, we have met people who provide their employers with requirements specifications, architecture descriptions, verification strategies, and many more value-adding deliverables. When we looked at their business cards, then some were “Digital Signal Processing Engineer,” some may have been something like “Head of Mechanical Design Unit F,” and others were “System Architect.”

No matter what is written on these peoples' business card, if we meet them on a Systems Engineering conference then it is probably because they are applying thoughts, methods, or processes that are attached to Systems Engineering. If we meet them in a session about system architecture, then they are probably even mentally involved in systems architecting.

In the development of a system, we may ask who currently performs a systems architecting activity. The answer should be independent of this person's position in the organization, but it should be based on the kind of activity that different individuals are currently carrying out. When talking about the activities in systems architecting and the skills and competences needed to carry them out, then it is possible to describe them independent from the shape of the organization, which makes the description of systems architecting reusable across different organizations and robust against organizational changes.

To avoid the need to consider different kinds of organization, the notion of a role is being used ...