Go to main page
A journey into the programming realm
The point of no return
Leaping into the unknown
Business goals are what a company hopes to accomplish or where it hopes to be at a specific future date.
A stakeholder refers to anyone involved in the project, or who is impacted by the outcome of the project, such as the user, the developer, the tester, the project manager, the architect, and so on.
Customer Requirement Specifications are specifications that are sent by the end-customer of the application, and they define what the application should do (and usually NOT how to do it). The architectural decisions should be taken with the specifications in mind.
Functional requirements specify what the system should be able to do. They usually specify a behavior, such as:
Non-functional requirements specify the system’s quality characteristics (quality attributes), rather than specific behavior. They cover all the remaining requirements which are not covered by the functional requirements. Examples of non-functional requirements include:
The client should receive a response after a login attempt within 2 seconds.
A change request is a document that contains changes to the requirement specifications and implicitly, adjustments in the software. The document will only refer to what needs to be changed, not how the change should be implemented.
Accessibility is the capability of the system to be used by people with disabilities. In the end, considering the needs of others may also improve the design for all of our users.
Availability and Resilience are the capabilities of the system to be fully or partly operational, and to effectively handle failures that could affect the availability of the system.
Internalization is the capability to be independent from a particular language or country. Having this in mind, it assures that some details are not getting lost in translation.
Interoperability is the capability to facilitate integration with third-party systems. To improve it, you should use well-designed external interfaces, standardization systems, etc.
Maintainability is the capability of the system to support changes, such as business requirements or correcting old errors. This my also affect the time needed to restore the system after a failure.
Performance is the capability of the system to execute actions within a certain period of time.
Performance can be measured in two ways:
Key performance indicators include:
Performance usually affects the entire system and can affect many parts of the architectural solution. Performance issues can affect everything, from the server’s capacity to the database queries or the capacity of communication channels.
Reliability is the capability of the system to continue to operate under predefined conditions. Usually, the system fails due to the inaccessibility of external elements such as databases, systems, and network connections.
Scalability is the capability of the sytem to handle load increases without decreasing performance, or the posibility to rapidly increase the load.
There are two ways to improve scalability:
Key scalability indicators include:
Security is the capability of the system to reduce the possibility for malicious or accidental actions or possibility of theft / loss of information. In order to protect the systems, we can use a number of measures such as authentication or encryption.
Examples of security in the system are:
Usability is the capability of the system that allows people who interact with the system to work effectively. It is one of the most important attributes, because users can see directly how well this attribute is working. One of key problems of usability is too much interaction or too many actions necessary to complete a task.
Key usability indicators include:
4+1 is a view model designed by Philippe Kruchten for describing the architecture of a software, based on the use of multiple views. The views are used from the viewpoint of multiple stakeholders (users, developers, project managers), describing the system through the use of UML diagrams.
Development view illustrates a system from the perspective of a programmer, and it often includes package diagram.
Logical view is concerned with the functionality provided by the system to end users, and it uses class and state diagrams.
Physical view describes the system from an engineer point of view through deployment diagrams.
Process view explains the system processes and how they communicate, and it focuses on the runtime behavior of the system. This view addresses concurrency, distribution, integrators, performance, scalability etc. through activity diagrams
The fifth view is using a small set of use cases or scenarios, which describes sequences of interactions between objects and / or processes. They are used to identify architectural elements and to illustrate and validate the architecture design. This is also known as the use case view.
When we think of software architecture, we think about all the technical parts, like defining the architecture, the interfaces, the responsibility, applying some patterns, or optimizing performance.
Other than that, we also think about the non-functional requirements, such as the quality attributes.
But architecture itself, and being an architect is more than that.
First of all, architecture is all about trade-offs, because you can never have it all.
You cannot design an architecture that has high availability, security, performance, and so on, at the same time.
As a non-technical analogy, we have the story of the Vasa ship.
In 1620, the King of Sweden at that time wanted to quickly end the war between Sweden and Poland, so he requested an architect to build a ship called the Vasa.
The ship had some requirements that were not found on any other ship of that time - It was supposed to have over 200 feet (60 meters), to carry 64 guns on two gun decks, and to be able to transport 300 troops.
As it usually happens, the deadline was short, and the budget was tight. In the end, the ship was built according to specifications, and during the launch day, the ship sailed for a bit, and then sank to the bottom of the ocean.
The problem was that the ship was built to be both a fighting ship and a transport ship at the same time, and the architect created an unstable ship, in order to fulfill all of the king’s wishes.
The moral of the story is that trying to fulfill each and every requirement will create an unstable architecture - A jack of all trades, and master of none.
When there are two options, people think that the architect is supposed to make a choice between them.
Taking such decision it means that we’re stuck with it, in most cases, so each decision is very important to make.
An effective architecture is one that will reduce the importance of such design decisions.
When we have to choose between two choices, we should strive to ask ourselves how should we design the software so that the choice between the two of them is less important.
Architects should always defer the decision as much as possible, since at a later time they will have more information about the system and about the impact their decision will have.
The architect should always be looking for decisions that have to be made soon.
As a developer, your focus will be on classes, interfaces, tests, and so on, and making sure that they all fit together.
Rarely, there are cases that you have to sit back and look how the whole system fits together.
As an architect, that’s all you do - and you should make sure that those pieces work well together.
During the development phase, developers have IDEs and debuggers, and they can easily debug until the bug is found.
It is also important to be noted that, in most cases, the project is passed to another team, with different skill sets.
Other than that, there are also many disadvantages that happen in maintenance / production environment:
The architect should be aware of the limitations that comes from maintenance phase and plan for them, especially taking care of the verbosity of the logs and making sure that it is working properly, that documentation is updated, that the role of the components and classes is clear, and that the system is easily testable.
Software Architects must take responsibility for their decisions, as they influence the software the most.
In order to be responsible, the architect should put everything in writing (to make it official), and comunicate the decision to the people that will develop it and / or are affected by that decision.
After a decision was taken, the architect should make sure that it is implemented correctly.
In the end, the architect should also delegate some decision making to the experts in specific problems, because there’s no such thing as a know-it-all expert.
Even if the software is great, if it’s hidden behind a horrible interface, no one would want to use it.
That’s the only thing your users are seeing, so the architect should make sure that the user experience is as good as possible, and that the most common interactions are simple and intuitive.
Package diagram is a view displaying the coupled classes and their encapsulation into a group (similar to namespace).
Activity diagram is a view representing the flow from one activity to another, describing an operation within a system.
Reserve is a function that pre-allocates a specific memory size, to accommodate new data.
The act of exploiting a bug in order to get administrator access.
Composition refer to two classes (composite and component) in which one of them (composite) contain an instance of the other one (component), creating a ‘has a’ relationship. The composite object has ownership over the component, meaning that the lifetime of the component object starts and ends at the same time as the composite class. In simple terms: A class contains an instance of another class.