- Diagrams can help communicate some important aspects of application architecture.
- However, they themselves do not capture or define the actual architecture of a software development project.
- The application architecture can be best expressed as the shared understanding of system design by expert developers who are most familiar with the system.
- To understand the de facto architecture of a system, you have to understand the code, not simply as an abstraction, but how it functions and how the pieces work together.
- As a software architect, you need to know how to write code, and you need to communicate with lead developers as a coder among coders.
- In order to provide technical leadership, you will need to gain their cooperation and respect.
- At the risk of sounding trite, you need to show them that you know what you’re talking about so that you can engage in technical discussions that produce sound technical decisions.
- Part of the process should be regular code reviews, whether in-person or via pull requests.
- If possible, you can augment this with periodic pair programming sessions, which will help to promote geek bonding.
- For this reason, it’s important to keep your coding skills up-to-date.
- This can be challenging if you’re a full-time software architect, so you might want to consider contributing to some open-source projects.
The Purpose of Software Architecture
- Architecture is about the important stuff, whatever that is.
- There are different ways of defining what is important to a project.
- It could be related to technical decisions, such as programming languages and frameworks, which once implemented are difficult to change without incurring substantial cost.
- Given this characterization, one might speculate concerning the process by which important technical decisions are made.
- It’s the job of the architect to ensure that consequential decisions are made in a strategic manner.
- In other words, the architect is perhaps the person who sees the larger technological landscape, who discerns emerging trends, and who can discriminate between enduring paradigm shifts and passing fads.
- Choice of software frameworks is but just one crucial decision in which software architecture can play a role.
- It’s important for architects to train and mentor dev teams in the transition from outdated practices to modern approaches that will result in greater longevity as well as yield increased levels of reliability, scalability, and cost-effectiveness.
The Right Level of Abstraction
- The goal as software architects is to design systems that have fewer aspects that are difficult to change.
- Adhering to SOLID principles will more likely result in a more modular design of loosely coupled components.
- In addition, it is important to establish how microservices interact with one another, abstracting away direct service dependencies in favor of indirect communication based on models such as publish-subscribe or event sourcing with a unified log.
- The purpose of applying these patterns and enforcing separation of concerns is to reduce parts of the system design that are difficult to change, thereby increasing flexibility and avoid premature refactoring.
Architect Roles
- There's a big difference between contributing to the architecture of a software system and being responsible for defining it yourself; with a continuum of skills, knowledge, and experience needed across the different areas that make up the software architecture role.
- The software architect is a role, not a rank which is an evolutionary process where you'll gradually gain the experience and confidence that you need to undertake the role.
- Since the role of a software architect is varied, you need to look deeper to understand the level of involvement, influence, leadership, and responsibility that has been demonstrated across a number of different areas.
- The software architecture on most projects can be broken down into two phases: the definition and delivery.
Management of Non-functional Requirements
- Software projects often get caught up on asking users what features they want, but rarely ask them what non-functional requirements (or system qualities) they need.