Our Process
Software Architecture
What is Software Architecture?
According to a common definition, Software Architecture is a way to organize a system. In particular, this regards its components, work environment and rules defining the way it is built and developed.
Software Architecture is a means to ensure system reliability, flexibility, security and scalability, and a way to meet technical and business expectations towards it.
Software Architecture also determines the relationships and interactions between system components. Therefore, it refers to its structure.
It sets the tasks for developers. It is a kind of diagram defining individual components.
The primary goal of Software Architecture is to create a system operating and acting in accordance with varying expectations.
So, it is also a method of their harmonization and orchestration.
Why is it worth to create Software Architecture?
The main purpose of Software Architecture is to identify the requirements directly influencing the software structure and functioning.
It also enables you to define use cases and use scenarios.
It makes it possible to reconcile functional and non-functional requirements, mainly quality-related.
Software Architecture is a tool enabling you to:
- Enhance communication within a developer team, and more generally it is useful for all stakeholders
- Reasonably analyze and adapt the system being developed to the technical, business and operational requirements
- Speed up the development work
- More precisely plan the work, and specify individual phases
- Evaluate work progress more accurately
- Manage the project better
- Reduce the error rate and lower the costs of fixes
- Give the project a timeframe and organizational framework, define the scope of roles, competences and activities.
Generally, it is more and more useful to create Software Architecture as the project complexity grows.
For large projects, the lack of Software Architecture significantly increases the risk of creating bug-ridden software non-compliant with various requirements.
To create Software Architecture is not an easy task.
The difficulty of Software Architecture is primarily due to:
- Complexity of the system being developed
- Diversity of expectations, objectives and means used to achieve them
- Multitude of stakeholders representing differing expectations (e.g. business managers, owners, users).
To fulfill its function, Software Architecture should be created by an experienced software architect having expertise and able to create a high-level system design, and manage its development.
The result of his/her work should be a document (Software Architecture Description) including business and technological requirements.
The document itself is created on the basis of the requirements gathered from individual stakeholders, in particular including:
- Functional requirements
- Non-functional requirements
Software Architecture should also contain the information about any constraints which the designed application can be subject to in the future.
The most common constraints include:
- Lack of analytical methods to clearly determine that a system meets the expectations
- Communication problems between stakeholders
- Lack of a dedicated software architect.
Also, keep in mind that mobile applications and web applications can be built by means of different methods.
The choice of the most adequate, efficient and useful method is subject to:
- Software architect experience and expertise
- Developer team competences
- Project cost and project budget
- Time available for its execution
- Time necessary for the implementation of specific solutions
- Business environment is which a company operates.
The literature on the subject features a number of:
- Software Architecture description concepts
- IT system development methodology
- Software Architecture description languages.
Also, the choice of the best and most helpful formula is a matter of experience, expertise and the features of the software itself as well as the business objectives to achieve.
None of the concepts, methodologies or languages is flawless. For this reason, experience is very important as it enables you to use these tools with greater awareness of risks, consequences and constraints.
The following play an important role in the Software Architecture design process:
● Architectural analysis
● Architectural synthesis
● Architecture evaluation
● Architecture evolution.
Architectural analysis aims at defining the environment in which a system will operate, and at defining the requirements for it.
The analysis provides the answer to the question about how the system will satisfy functional requirements, and how it will cope with non-functional requirements.
Architectural synthesis focuses on the requirements set out as a result of the analysis and links them to the current project status and the evaluation of the project development method.
Architecture evaluation serves similar purposes, but usually it is carried out after the completion of a given phase of system development.
Architecture evolution, in turn, is a process of maintaining the existing architecture and adapting it to the changes in the environment.
Typically, architecture evolution consists in function expansion and maintaining existing functionality. And their adaptation to each other.
What are the main types of Software Architecture?
With the growth of programming technologies and evolving standards, the approach to the Software Architecture design has also been changing.
Currently, the most popular methods of Software Architecture creation are:
- Monolithic Architecture
- Service-Oriented Architecture (SOA)
- Microservice Architecture
Monolithic architecture is characterized by the connectivity and interdependence of all of its components.
The monoliths operate on a single file basis. This means that all application functions are deployed as a single unit.
The main advantages of monolithic architecture include higher efficiency, lack of modularity, simplicity of deployment as well as greater ease of testing and error detection.
However, this solution has also drawbacks.
Each code change affects the performance of the entire system. This means the need to check the entire application code after each update.
Monolithic architectures are also more problematic is terms of scalability. The entire application is subject to scaling. It is not possible to scale its individual items. This is not always desirable.
As the name suggests, services are at the core of Service-Oriented Architecture, i.e. independent software components with a separate interface.
To put it slightly different, services are the functions enabling the users to perform tasks and achieve goals.
SOA allows you to realize multiple business objectives by means of components which are integrated and yet independent.
The key advantage of the architecture of this type is the ability to quickly and relatively seamlessly integrate a system with new additional components.
Also, Service-Oriented Architecture provides the possibility to employ various technologies shared via an independent communication protocol.
Simply put, Microservice Architecture consists in creating applications using multiple loosely connected or unconnected services.
It is recommended for organizations which are dynamically developing their digital products, depending on business scalability.
The independence of individual services allows you to develop them without the risk that the implemented changes will affect the entire system.
Even more importantly, individual services can be created using different technologies and by different providers.
Microservice Architecture also provides more system security, efficiency and stability. A fault in a given service does not affect or interfere with the others.
The downside to the architecture of this type is its technological complexity, involving the need to have broad competences and technological experience.
Also related to the software integration with external services. This type of architecture can also cause problems during testing.
Best practices for Software Architecture
Software Architecture design has been discussed many times and abounds in patterns of best practices enabling you to:
- Minimize errors
- Make Software Architecture documents more communicative
- Improve the work and knowledge flows
- Manage projects
- Optimize the processes of analysis, synthesis, evaluation and evolution
- Make decisions more effectively.
Good patterns most often apply to:
- Knowledge management
- Management of the communication within a team and the communication between all stakeholders
- Methods of making design decisions
- Preparation of project documentation.
The quality of Software Architecture and the usability of the document in which it is included largely depends on the software architect ability to put together all requirements in an accurate and comprehensive manner.
Knowledge flow is critical for this process. If the knowledge is incomplete, it can result in an incorrect or incomplete Software Architecture design.
Design patterns, prototypes and analyses of similar digital products are significant elements for the streamlining of this process, and should be documented and provided to all stakeholders.
Making design decisions is an issue resulting in a number of problems and risks.
Keep in mind that making decisions is a multifaceted activity with different effects, and takes place at different levels of generality / specificity.
Awareness of various consequences enables you to reach a compromise between varying expectations and circumstances faster and more efficiently.
Documenting all information, activities and auxiliary materials is of key importance.
A document containing Software Architecture should include static (code structures) and dynamic (system operation) views, descriptions, notations and specifications.