Give and take: The 9 stakeholders of the system architect

An important task of the system architect is communication. In order to develop a complex system, cooperation with many stakeholders is required.

But why should the stakeholders cooperate with the system architect? After all, it takes time and effort. Therefore, to be successful, we need to understand what we can offer these stakeholders. We also need to formulate precisely what we expect from the stakeholders so that we don't waste their time or ours.

In short: it's a give and take. Read on to find out exactly what this is all about and who these stakeholders actually are.

Incidentally, this list comes from the excellent book Model-Based System Architecture (Review). What each role gives and receives from the system architect is listed below.

Requirements Engineering

Dealing with requirements has a high priority in systems engineering.

• GivesAn explanation/explanation of the requirements
• GetsThe promise that the requirements will be further processed and taken into account;
• Gets: An explanation of the architecture that helps to derive further requirements

Verification

It is often underestimated how valuable early collaboration with the V&V team is: the early formulation of tests alone can sharpen the system description and reduce many risks that would only emerge at a later stage.

• GivesTrust in the architect's experience with the system to be developed
• GivesExpertise regarding the planned approaches for the verification of the system
• Gets: A system that already takes verification into account during design
• GetsInformation about the planned solution that can be included in the verification activities.
• GetsA basis for regression tests, based on solid change management

Configuration management

Early consultation during configuration can also mitigate many risks that would only emerge later.

• GivesExplanation of the configuration management strategy
• GivesOverview of the planned system configurations
• GetsVersioned description of the system architecture
• GetsAn overview of the system's configuration elements and their compatibility

Engineering disciplines

The adjoining Engineering disciplines are usually addressed via department heads, subsystem architects or directly by the developers. Solid communication is very important here.

• GivesExpertise of the domain
• GivesAdmitting to changing the design of a subsystem in order to improve the overall system
• GivesTrust that the architect respects the competence of the relevant team
• Gets: The respect of a stakeholder, especially with regard to interfaces
• Gets: The consideration of their interests
• GetsThe concession of being respected as a competent domain expert

Project and product management

The architect's tasks are often assigned to project/product management. However, it makes perfect sense to separate the roles. If this is the case, the following dynamic arises:

• Gives: The resources for an effective dialog between engineering and architecture
• GivesConfidence that a good architecture will generate a positive return on investment (ROI)
• GetsOverview and clarity about the results and deliveries of the project
• GetsPredictability In terms of costs and performance
• Gets: Early warning of risks
• Gets: Better products

Planning the roadmap

When work is being done on the current product, the next generations are often already being planned in the form of a roadmap.

• GivesTransparency regarding the roadmap and its changes
• GivesWillingness to take knowledge of the architecture into account in roadmap planning
• Gets: More realistic roadmaps

Suppliers

More and more work is being outsourced to suppliers. It should be obvious that collaboration is extremely effective here. And the advantages are symmetrical:

• GivesTechnical knowledge of the supplier that helps the manufacturer to create good interface definitions
• GetsTechnical knowledge of the manufacturer that helps the supplier to create good interface definitions

Marketing

This is primarily about product marketing, which is often differentiated from other marketing activities.

• GivesWillingness to engage in a technical dialog
• GetsA system architecture that provides strategic support instead of being just another product on the roadmap

Management

And finally, of course, we have to convince management that our activities contribute to the success of the business.

• GivesConfidence that the investment in a good architecture will generate a positive return on investment (RoI)
• Gets: Predictable projects
• Gets: Better products
• GetsBetter communication between the engineering domains

Stakeholders of the system architect

Actually, what is said here is nothing new. Nevertheless, it is amazing how long this list is. It's easy to forget an important stakeholder.

Systems engineering is largely about communication. This list helps to ensure that we communicate with all stakeholders.

Photo by Cytonn Photography on Unsplash