When it comes to system architecture, one of the first considerations teams will face are the system requirements. They can be split into two categories. Functional requirements are those surrounding customer needs — for example, what areas of the system does this user group need access to? Then non-functional requirements are focused on the system. These in turn can be divided into two areas covering many factors each. First are those known as ‘business quality attributes — for example time to market, cost or ROI. Then there are ‘system quality attributes’, like availability, security, scalability etc. This first step is so important because missing an initial requirement can lead to huge impact on the system’s overall performance down the line.
I experienced this years ago in a previous role. Requirements were set out by managers at the beginning. With faith that they were accurate the team built the system under the assumption that usage volume of our system would be so high that a high load would be necessary. Unfortunately, in practice this was not the case — volume was low and as a result the system was hugely expensive to run. Once this was realised, I joined a team which would be responsible for re-architecting the system and optimising the architecture. In the end, after analysing metrics like volume and profiling the whole system, we decided to rebuild the system from scratch, ultimately saving the business around $10,000 a month.
The root of this problem was that the initial requirements were incorrect — they were defined by people without the experience in system architecture necessary to make such requirements. If that business could do it all again, the best approach would be ensuring the right people are in place to gather system requirements — this takes a set of skills that extend beyond just product, development or architecture. There are three main knowledge areas which are relevant here:
System architecture knowledge
Understanding the fundamentals of how systems are built is the foundation to leading teams through to successful development. It is a complex area of knowledge because systems are not specific to software development, but learning the concepts and then studying the context of software architecture is necessary for expertise. Books like «Software System Architecture» by Nick Rozanski & Eoin Woods, and «Software Architecture in Practice» by Len Bass, Paul Clements, & Rick Kazman are a great way to learn.
Product mindset
As an architect it is important to have the mindset of a product owner or product manager. Key elements of this are a fundamental understanding of the vision, scope and roadmap of the system that is to be built. When it comes to true product mindset no stakeholder can be forgotten. Requirements must be gathered from every role involved in the development and use of the system — users, managers, investors, developers, designers etc. An architect is responsible for solving business needs using technology: without understanding the business needs, the solution delivered will not be valuable.
Soft skills
To apply product thinking to system architecture, an architect must be able to work well with each stakeholder to gather the relevant information. This means being able to speak multiple languages — not easy. For example, it is not optimal to talk about things like code refactoring or microservices with a marketer — they want to know how fast the product is for their customers. Vice-versa: speaking about customer profiles with a developer isn’t the way to understanding that developer’s requirements. It’s not possible for one person to be an expert in every team role, so working with managers and team members across each function will ensure each stakeholder is represented in the system’s requirements.
Good system architecture comes down to good teamwork, and on an individual level that requires a broad range of both technical and soft skills which must be learned with education and experience. By balancing the functional and nonfunctional requirements, taking all stakeholder needs into account and prioritising appropriately in collaboration with the development team, an architect will drive better decisions and ensure their system is built correctly from the outset.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.