System architects play an integrating role between many specialized engineers and other stakeholders during the creation of new systems. The role of system architect requires a broad set of skills. How do you cope with conflicting needs, opinions, and interests? How do you lead the design team effectively? How do you balance innovation and risk mitigation, installed base and new systems, short term and long term? How do you share vision and make pragmatic choices at the same time?
Let's look at some real life scenarios:
Scenario: The stovepipe organization. The R&D organization is decomposed in functional disciplines. System architects are perceived as free agents without responsibilities, doing the fun work. They meddle with ongoing engineering work and limit the autonomy of the discipline. The challenge for system architects in such organization is to transform from being a threat into becoming someone who brings value.
Scenario: Crisis during system integration. After several years of work the project stumbles from crisis into crisis, causing delays and budget overruns. The interconnected parts of the system don’t function properly, performance is poor and the overall system is unstable. This situation typically happens when little to no systems architecting took place earlier in the project. The system architect has to start as troubleshooter and do damage containment. After this stressful period the architect and the team hopefully have learned enough to do more proper architecting for the next system. They may even have been able to identify refactoring opportunities to bolster the system.
Scenario: Broad product portfolio where synergy should be harvested. This is a very common situation. The development organization is active with multiple product lines on the market. The history of individual product lines has resulted in divergence, where from the broader perspective synergy is expected. How do you migrate to a situation where synergy between systems can be harvested? How do you juggle variation to harvest synergy? What are the threats and pitfalls of increased synergy?
Scenario: The brilliant but invisible architect. Designers and architects tend to be introverted people who dislike socio-political situations. Quite naturally they hide themselves in the safe world of design. Communication with management is quite limited. This poor relationship degrades the decision making process. Architects need to train their communication and presentation skills, especially towards the less technical managers. How does a system architect communicate complex topics to managers who may fail to grasp the nuances?
(sub)System engineers, designers, and architects with real world product creation experience. This course looks mostly at the non-technical aspects of systems architecting.
Prerequisites: at least bachelor in engineering or science and some practical experience in design and engineering. More experienced designers and architects tend to appreciate this course more.
Objective of the course is to teach system engineers and architects methods and techniques function effectively in multi-disciplinary design environments with lots of stakeholders.
After this course students will:
understand how the architecting process fits in the much broader set of company processes
understand the priorities of company processes and their mutual relationships
know their deliverables and responsibilities
have insight in the multitude of activities and the need to balance them by time management
elicit requirements from different perspectives
understand the tension between formal requirements management and the actual use of requirements
have seen a collection of system architecting methods and techniques, such as CAFCR and story telling
be able to analyze create and asses stories
be able to structure a roadmap and facilitate a roadmapping process
understand synergy approaches, such as platforms, product families, common components, or re-use, with their advantages and disadvantages
be able to manage expectation level of different stakeholders
understand the role of software in systems
be able to structure documentation modular, maintainable, and manageable
be able to present architectural issues to less technical management teams
have insight in the many psychological, social, political and cultural aspects that have impact on systems architecting
teach system engineers and system architects how to interact with many stakeholders and how to fit their work in the company processes
teach them to understand the complexity of this task in relation with the broader context of customers, life cycle, and organization
provide them with an mental framework for the role and task
provide them with an overview of methods, knowledge, techniques, and methods to be applied in their daily job
The course takes 5 full days. Participants taking the course for credits have to do a 10 week project afterwards. During the course participants work on real-life cases, preferably from their own domain. About half of the exercises are being done in randomly mixed teams on prescribed cases. Theory and exercises alternate continuously. Theory is ample illustrated with examples from practice.
The exercises provide even more value when multiple participants from the same company participate. We recommend to send a small team to the course, if possible.
During the course we address the following questions:
How does systems architecting fit in the organization and its processes?
What are deliverables, responsibilities and activities of the system architect?
How to elicit requirements?
What methods, tools and techniques are available for the architect?
How to anticipate on future needs, trends, and changes?
How to harvest synergy?
What is the role of software in complex systems?
How to structure and manage documentation?
How to present to less technical management teams?
What human factors impact systems architecting?
How to apply this material in the own organization, short term and long term.
This course focuses at the less technical aspects of systems architecting. The program is based on one of the basic working methods of an architect: viewpoint hopping. The course addresses systems architecting from ten different viewpoints with time boxes of about half day.Course material
The course fee for a course week including all course materials, lunches and coffee breaks can be found at Systems Engineering of Buskerud and Vestfold University College site
To register please send an e-mail to: email@example.com with the following information:
Name and mail address for each participant
Name of company
The number of participants is limited.
Courses are taught at Buskerud and Vestfold University College in Kongsberg. Courses can be customized or taught at location, contact us to discuss needs and opportunities.
For more information you can send an email to