What are your responsibilities as a system architect?

Analysis of the context and scope of the system is a critical phase for the system architect and involves several steps: The system architect begins by analyzing the requirements of the end user and stakeholders involved in the project. This includes understanding the functional and non-functional needs of the system. The system architect must evaluate the technological context in which the system will be implemented. This includes analyzing available hardware platforms and relevant software technologies. Based on context and scope analysis, the system architect defines the boundaries of the system, i.e. which components and functionalities will be included in the system and which will be excluded.

Let me give you a real world example where I have seen Chaos Engineering work. Chaos Engg helps improve system resilience and reliability in cloud context. A large financial institution, has embraced Chaos Engineering as part of its resilience engineering practices. The company employs a tool called "Chaos Gorilla" to simulate the failure of an entire Amazon Web Services (AWS) availability zone. This helps evaluate and strengthen its systems' resilience in the face of significant infrastructure failures. This concept can be applied across various industries, including finance, to enhance the reliability and resilience of critical systems.

Validating system architecture is a crucial step to ensure that a design meets the desired requirements and performs effectively. Mistakes in this process can lead to suboptimal system performance, increased costs, and potential issues in the long run. Some costly mistakes include: Insufficient Performance Testing Neglecting Security Validation Ignoring Fault Tolerance and Redundancy Overlooking Real-world User Experience Lack of Continuous Validation

Coordination and collaborations are the must have skills for a system architect. System architect need to have complete understanding of the system how it looks like, and to gain that it is required to engage with different stakeholders to gather more knowledge and understanding about the system requirements, constraints, technologies, etc. With their clear vision for the system, the system architects engages in all phases of development of the system lifecycle.

Some people believe that the system architect should define the architecture until it's "done" and the product can be build, and off he can go...leaving the details to the rest of the team. It couldn't be farther away from the truth. As a system architect, you should follow your product through the lifecycle (although effort will decrease with time). This also helps you to understand how to avoid problems in all life stages by good architecture - in your next projects.

One example of system architecture gone wrong in cloud computing occurred with the 2017 AWS S3 outage. AWS experienced a disruption that lasted several hours, affecting a multitude of websites and services globally. The architectural flaw lay in the lack of adequate safeguards and the over-dependence on a single region for critical infrastructure. The outage underscored the importance of comprehensive redundancy, fault tolerance, and the need for well-defined recovery mechanisms in cloud architectures to mitigate the impact of unforeseen events. It served as a wake-up call for organizations relying on cloud services, emphasizing the necessity of resilient system design to minimize the risk of widespread disruptions.

Excellent general description here. I'll just add one item that has been on my plate a great deal over the last year +. Safety-critical systems should be (and many cases are) required to consider, plan for, mitigate, and prevent extraordinary levels of risk, including systemic, catastrophic, organizational, regional/community, worker, and individual/consumer. In most cases safety-critical systems have significant regulatory and compliance procedures that must be followed. We don't have such requirements yet in my industry (AI systems), which is a glaring omission for high-risk methods, but in most industries, following robust safety-critical engineering principles is required to work in the industry.