Are you interested in what the role of a System Architect is? Most people that think of an Architect, think of someone who plans and designs a building. During construction he/she keeps a close eye on details. A System Architect is doing something similar, except it is not a building but a (high-tech) system. This blog post will try to give answers to the questions what is the position of the System Architect and what drives the System Architect, seen from high-tech industry perspective. Feel free to comment on this blog post to share your view or experience.
What is the position of the System Architect?
The System Architect has a key role in a project to communicate with several stakeholder of the project/product. Among the stakeholders are the paying customer, the user of the system, marketing department, project manager, product manager, production/quality manager, designers, developers and testers. In this web of stakeholders the Architect is responsible for the technological part of the system, needs to communicate opportunities, identify risks and understand the domain / business case of the customer. During the project the Architect needs to think critically in order to mitigate risks. The general expectation from the Architect is to guide the project to all major technology/design decisions, to gain more certainty. This is also referred to as the “Quest for certainty” by Gerrit Muller in System Architecting.
The System Architect will translate the Voice Of the Customer also abbreviated as VOC into high-level (technical) requirements. Only by truly knowing what the customer wants and just as important why the customer wants it, he can start drawing up the skeleton / framework of the system. He needs to weigh the costs and benefits of different features of the system and decide with the stakeholders, the must haves, should haves, could haves, and would like but will not get. So it boils down to decision making and having vision!
Most of the time a System Architect works in multi disciplinary setting. Which means, challenges can be solved in different domains (Mechanical, Electronics, Mechatronics, Software etc). Of course a good Architect will have a broad knowledge, but also needs to have feeling with technology in general. This “gut” feeling often guides him to ask the right questions, to the right person. Translating a challenge in a high-level concept can help to cross the borders of different domains. This ability partly comes with experience.
The Architect is also the person to assist in defining the Acceptance Test of the product, preferrable in cooperation with the customer. Here we also see the strength of a good Architect to make quantifiable requirements, which can be verified later on. The better the requirements the easier the definition of the acceptance test. The Architect should take pride in writing down requirements that are understandable in one way, have clear rationale and are measurable.
What drives the System Architect?
The Architect should like to switch perspectives, in other words, looking from the different viewpoints of stakeholders. He should have knowledge on abilities like designability, testability, usability, securability, traceability, verifiability etcetera. Besides that the Architect also needs to have a feeling with the product / system, plainly said being passionate about it. Should love to zoom in, eye for detail and zoom out, helicopter view. Talent for these abilities is one thing but there are also models / frameworks to support an Architect, e.g. CAFCR and 4+1 View, many of them are based on perspective taking.
Since an Architect should be proud of his work, one good take away is to expose the Architecture of the system to everybody that needs to see it. Think of having a poster with a model of the Architecture near the coffee machine. See how much input and discussion you will get, this will help you to come more quickly and effectively to your desired output. Make it a living poster / wall and update regularly. This makes the Architecture attractive and interactive and not just a document, spreadsheet or a bundle of diagrams.
Moreover the Architect gets energy from enthusing / inspiring / explaining people and needs to like to communicate about the product / project on different levels. This communication needs to be tailored towards the audience, technical / non-technical, abstract or in detail.
So far my perspective and explanation on the role of a System Architect. Please share your thoughts and experience below.
— Bob Peters (Embedded System Engineer), Embedded Systems Enthusiast