The architecture of an IT solution is its technological base, which takes into account the risks of the project, the budget, requirements and constraints, and scaling needs.
In addition to designing the IT-architecture, at the start you need to roughly estimate the scope and cost of the project. To do this, in our practice we use one of the proven methodologies of creating software architecture – Attribute-Driven Design (ADD). At the same time we rely on the quality attributes of a particular IT-product. Based on them, we create an architectural concept of the system at the evaluation stage (presale).
Consider the stages of working with the architectural concept, the possible difficulties and solutions, based on the experience of our Architectural Committee. We hope that this article will be useful for architects and developers who want to master the ADD methodology, and can be interesting to allied professionals.
It is the IT architect who decides what the information system will ultimately look like, in general and in detail. He needs to find a balance between competing requirements and constraints.
If you have a detailed architectural solution, it allows you to most accurately estimate the timing and cost of the product implementation. In addition, it is possible to determine the characteristics of the system which will meet the business requirements already at the start. Among the criteria of IT-architecture quality are flexibility for scaling, risk minimization, speed and independent choice of contractors.
Requirements and constraints
Our goal is to design the software architecture (software) in a systematic, predictable and cost-effective way. To do this, we need to define the requirements for the product.
As a rule, product development terms of reference (TOR) contain requirements, but they are not always specified sufficiently. For this reason, among the key tasks of an IT architect are requirements gathering and analysis, creation of architecture design and solution description, its verification, as well as control and supervision during software development.
Let’s take a look at what is included in the requirements list:
1. Design Purpose.
The goal determines what we need at the start: a detailed architecture or a rough idea of the system design, which will allow us to estimate the amount and cost of work.
2. Quality attributes, non-functional requirements
These attributes define the properties of the system that it must demonstrate – requirements for performance, availability, security, usability.
Example: the system should work 24×7, allowing no more than 30 minutes of downtime per month.
3. Functional requirements
You can define what your system can do.
Example: the ability to unload data from a file and send reports by email.
4. System requirements
These arise gradually in the process of detailing and are implemented iteratively.
Example: authorization, action logging, caching.
5. Constraints
Do not relate directly to the system behavior and are not subject to our influence. For example, the client wishes to develop a microservice rather than a monolithic architecture. This also includes legal requirements, e.g. in the area of personal data storage.
As a rule, the product owner does not have a complete list of requirements for the system in advance, so the architect directly organizes the process of collecting and fixing them. Of all the requirements for the system, the specialist must identify architecturally significant requirements that have a profound impact on the final solution.
According to the ADD methodology, requirements gathering is the first step of the job. Its purpose is to:
- help estimate the cost and schedule of the work;
- develop key technologies;
- ensure that the business goals are achieved during the development process.
Next, let’s look at the rest of the design steps.
Overview of the methodology
1. Gathering requirements
The source can be the results of stakeholder surveys, an analysis of the project’s business goals and usage stories. In doing so, it is important to be specific about what the client has in mind. For example, not just “no site downtime,” but “an acceptable downtime period of 30 minutes per month.”
Next, we evaluate the importance of the requirements according to two criteria:
- Value to the business;
- Degree of influence on the architecture.
Levels of the importance we estimate on a scale of HML (high, medium, low). Thus, each requirement will have a two-letter combination. Architecturally significant items are labeled HH, HM, HL, MH, and MM. It is worth noting that a large number of HH requirements means high risks on a project.
2. We design the architecture
We design the software architecture based on the most significant quality attributes.
This is a recursive process in which the system is decomposed into smaller subsystems.
ADD is the first method that focuses on quality attributes and how to achieve them. An important contribution of ADD was the recognition that analysis and documentation are an integral part of the design process. The method has been used successfully for more than 15 years.
The current version of ADD is now 3.0, which is iterative. According to it, design is done in stages throughout the system’s development time, in each sprint. It provides a step-by-step guide to the tasks that need to be accomplished in each iteration.
The seven ADD steps are.
Step 1: Checking the input data.
Make sure that all necessary data and requirements are available, prioritized, correct, and executable, and that the purpose of the work is clear.
Step 2: Define the list of requirements for the subsystem
Rank the requirements by importance to the business and the degree of impact on the architecture, group them according to the HML assessment, choose 5-6 priorities. Set a goal for each iteration.
Step 3: Choose a part of the system to design
We proceed from risk and complexity of implementation, business value, critical path and accuracy of requirements elaboration. Build on achieving requirements that align with iteration goals.
Step 4: Determine the best possible option
The most difficult point. Analyze all the options, find advantages and disadvantages.
Step 5: Concretize the components of the chosen concept, define the responsibilities and interfaces
Usually at the beginning of the work the concept is formulated in general terms. At this stage we define all the elements of the subsystem and the responsibilities of each, choose the interface through which components interact with each other.
Step 6: Sketch a solution and a brief description
We write it in a visual document, for example, as a UML diagram or SFML. You should also write down all the decisions, describe the trade-offs you made and the alternatives you considered. This will help to further evaluate the arguments in favor of a particular architecture and create documentation.
Step 7: Verification of requirements fulfillment
At this step, the methodology recommends getting a “second opinion” of other experienced fellow architects, in order to approach the process more objectively. The participation of several experts with their experience and point of view on the architecture will help to quickly identify deficiencies if any.
We clarify and specify the requirements, prioritize and then repeat steps 2 to 7 in each iteration. In this way, you need to work through all the high-priority requirements, respecting all the constraints. But you don’t have to iterate sequentially. Rather, you will alternate between system design and implementation phases.
3. Track progress
To complete the above steps in time, the architect needs to monitor the team’s progress and respond promptly to changes. The authors of the methodology advise tracking the implementation of steps with the help of an architectural backlog in the form of a kanban board. In its columns we place architecturally significant requirements, constraints and system tasks. They may have the following statuses:
- Not Yet Addressed
- Partially Addressed
- Completely Addressed
- Discarded
When you need an IT architect?
As a product develops, new requirements often arise and old solutions are no longer sufficient.
It also happens that a small in-house team works within the same technology stack, but to solve business problems, it is necessary to integrate or develop new functionality while selecting the optimal implementation technologies. Developers may need help to do this, since technologies are changing every six months, and it’s hard to keep up with everything and have expertise in all languages and directions at the same time.
In such situations, they usually turn to an experienced team of architects who are “burning” with their work, have accumulated diverse experience and continue to develop competencies in different technologies.
As a rule, business orders architecture development from an IT company in the following cases:
- Need to develop software to meet legal requirements.
- Need to develop software from scratch, while reducing the risk of errors, missing deadlines, and increasing implementation costs.
- Need to increase system flexibility.
- The system does not meet scalability, load, or security requirements.
- No resources to develop IT architecture.
Thank you for your attention! We hope this article was helpful to you.
