Hey, here I write about basic concepts that you need to know to prepare to CPSA Certificate. Of course, I am not so smart yet because I want to describe my process, so I prepared this blog based on the book Software Architecture Foundation and based on my assumptions and experience. Sometimes I tried to shorten the topic as this post will just be notes for me on the last exam preparation phase.
Introduction
“Software architecture: the fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution”
Foremost, there are many valid software architecture definitions.
How I understand the above definition is that software architecture is formal, detailed documentation containing all aspects of the system. The documentation should be comprehensible to all persons concerned. The design should describe all components of the systems, including contexts, subsystems, modules, important classes, and functions. Documentation should present relations between components, their role and the way how they communicate to each other. Explanation of the importance of external systems is in my understanding one of the key points. Description can contain principles allowing to keep the system on track to provide good quality.
Architecture is designed to be flexible and accommodate changes in business logic, scaling needs or technology stacks.
One thing worth to mention is that the relational database schema is not typically considered a direct part of software architecture because architecture focuses on high-level structural concerns and decisions about the system as a whole, while database schema design is more of a detailed implementation concern. Software Architecture has an abstract nature. It means that an architect should focus on system boundaries, responsibilities, communication between components, and architectural styles. A relational database schema, on the other hand, is a low-level implementation detail specific to the data storage level.
Goals and benefits
Among many benefits, CPSA preparation book mentions the following:
- Support the design, implementation, maintenance, and operation of systems,
- Achieve functional requirements or ensure that they can be met,
- Achieve requirements such as reliability, maintainability, changeability, security, energy efficiency, etc.
- Ensure that the system’s structures and concepts are understood by all relevant stakeholders
- Systematically reduce complexity
- Specify architecturally relevant guidelines for implementation and operation
Additionally, it’s worth mentioning, that overengineering and overarchitecting is not welcomed. Architects should focus on important elements of the system, instead of paying attention to every little detail of every component or technical concept.
Conceptual integrity is also a really important thing. It means that the design should follow a consistent set of rules or decisions. The author of the book gives the following examples: in UNIX mostly everything is a file, or in LISP everything is a list.
Software lifecycle and role of architecture
Software Lifecycle (SLC) is something else than Software Development Lifecycle (SDLC). This is an important thing to remember when talking about lifecycle. SLC is much broader in scope. The responsibilities of software architects cover almost the entire lifecycle of IT systems.
The software lifecycle describes all phases of a software product. We can identify the following phases: planning, development, using and funeral (retirement). The process is mostly not straightforward. In the meantime, we have a lot of sub-iterations in which the system evolves to meet the business requirements.
Usually, somewhere in the middle of this process, the system architecture loses its integrity and coherence as changes to the system accumulate. It’s because all architectural decisions have been made based on initial requirements and have been taken into account during planning and the first iterations of the development. That’s why all should have a funeral in mind. All these changes led us to the new version of the IT system.
Once a system enters the servicing stage, there is no turning back and the system becomes legacy. In this phase, the system maintenance is difficult and gets expensive. One of the architect’s roles is to make sure to not stay forever in the maintenance phase and initiate the migration of mission-critical systems to the new version. Managers often don’t understand or recognize the right moment to do it.
Funeral or retirement of the system means that we migrate relevant data to the new system, and we can turn it off, but we shouldn’t remove documentation and the source code. It still might need to be considered to understand old requirements and decisions made.
Tasks and responsibilities
Software architects are responsible for preparing the architecture design for a solution, meeting business requirements. The responsibility has to be aligned with organizational processes and with the overall responsibilities of project management and other roles.
The book depicts the following tasks and responsibilities:
- Clarify and scrutinize requirements and constraints, and refine them if necessary, including required features and required constraints,
- Decide how to decompose the system into building blocks and define connections between the building blocks,
- Determine and decide on cross-cutting concepts
- Communicate and document the software architecture based on prepared diagrams, views, concepts, etc.,
- Accompany the realization and implementation of the architecture
- Analyze and evaluate software architecture, especially with respect to risk that involves meeting the requirements,
- Identify, highlight, and justify the consequences of architectural decisions to other stakeholders
An important thing worth mentioning here is that the architect should cooperate continuously with the development team to identify potential risks, exceptions, etc.
Worth remembering are the details of six important architect’s tasks, also mentioned above:
- Clarify requirements,
- Clarify functional requirements,
- Design structures and concepts,
- Communicate architecture
- Shepherd implementation
- Evaluate architecture
Cooperation with other stakeholders in the ecosystem
Stakeholders or in other words, people that you have to work with to reach the goal are divided into the following categories:
- Business/domain/product focus – these are the people who understand the business. Architects usually communicate with them on requirements. Communication with this group should be technical jargon-free.
- Management – with this group of people, an architect speaks about organizational constraints, resources, or schedules.
- Technology team – developers, operations, and other architects. Communication is mostly about specific technical aspects.
- QA
Development approaches
Here I only want to mention about Plan-Do-Check-Adjust approach:
- Plan: Make architectural decisions to meet known requirements.
- Do: Execute. Implement decisions.
- Check: Get feedback and evaluate the result from the previous step.
- Adjust: Improve or refine decisions
It’s nothing revelatory, it looks like the process that every software developer should know.
Goals
Project goals are short-term. Architecture goals are long-term.
Architectural goals are derived from the quality requirements of the system.
An architect and all stakeholders should be aware of their all goals, as they all play in the same team. It’s not like there are single warriors on the battlefield, everyone having their own goals.
Prefer explicit statements over implicit assumptions
When working with people, there are a lot of potential areas of misunderstanding. Therefore, it’s recommended to express openly everything. Every decision that seems obvious to some people might not be obvious to others. That’s why explicit statements are better than implicit assumptions. The implicit assumption is a risk to the project, and it’s an architect’s role to mitigate this risk.
When creating the documentation, there should be no place where someone will have to think why this decision has been made. As support for this process come quality scenarios, domain models, glossary, ADRs (Architecture Decision Records), and last but not least feedback from others.
How software architect differs from other architects
Every software architect should be aware of other architectural areas. In organizations, we can distinguish many “architectures” but it’s not about software architecture itself. Here we mean high-level processes, budgeting, capability management, etc. which we call enterprise architecture. Business architecture is about organizational aspects, strategies, and governance. There are hardware architects who make decisions about hardware structure. System architects who take care of everything in the top IT area. This knowledge is important but according to the preparation book not relevant for the CPSA exam.
Types of IT systems
Software architects have to be aware of the classification of IT systems. This classification has many dimensions. We should take into account many aspects like the size of the system, hardware dependencies, platform on which the system runs, volume of the data, specialization, and user interaction aspects. Taking into account all aspects, software architects can make the right decisions and sometimes agree on some trade-offs.
Distributed systems
Everyone who works on a project with microservices should be aware of the common issues with distributed systems. I would even say, that this knowledge is crucial for software architects to plan the architecture thoroughly, taking into account the possible issues. In such a constellation many problems can happen between independently running instances, that execute their code on different machines, providing data with different latency, writing and reading information from different data sources. All these aspects should be taken into account.
Summary
I see this chapter as a simple introduction, to be able to understand what the software architecture is and what is outside of the scope. I learned from it where are the borders of architects’ responsibilities. An important thing in this role is being a communicative person as we will have to talk with many different stakeholders, but also being able to communicate respectively to the stakeholders, avoiding misunderstandings. This chapter teaches about the broader picture of where software architecture is located and which role it plays in organizations.
Thanks for reading. Ciao!