Software Architecture and Design

Software architecture consists of word software and architecture. First, we must understand the definition of these two words, software and architecture. So, we will have a better understanding about the definition of software architecture.

Software is collection of computer instruction or collection of data that tells the computer how to work and execute tasks or actions. Software is opposite of hardware, which describes a physical aspect of a computer. Software can be interpreted as generic terms used to refer to application, script, and program that run on a device or machine.

In computer science or software engineering, computer software is all information processed by computer systems, programs, and data. Computer software includes computer programs, libraries, and related non-executable data, such as online documentation or digital media. Computer hardware and software require each other and neither can be realistically used on its own.

Architecture is a process, product of planning, or designing from construction of structures. Of course in the computer world the architecture will relate to process software development  not to create buildings.

Discussion regarding the definition of software architecture and design has actually been discussed and debated for a long time by experts who work on software development (solution architect). Some experts say or define software architecture as the most fundamental or fundamental part of the software organisation being developed. There are also some experts who define software architecture as a way of how high-level components interact one with each other.

In the explanation above, we underline the words fundamental and high level components. Why do we emphasize this? It turns out that until now there is no most objective way to determine how fundamental and how high the level of the component is. Each software architecture that is made can be defined with different levels of high-level components. In the real world, a better understanding of architecture is a shared understanding of software developers or rather solution architects who are experts in designing software.

There are also those who explain software architecture in terms of its function. Software Architecture in terms of its function is interpreted as a design decision that we must create at the beginning of the project. This is done with the aim that before making the software we already have a strong and solid foundation for making the software that we will be working on.

The definition above is one of my favourite definitions about software architecture as defined by Ralph Johnson, who is the author of a book called Design Patterns: Elements of Reusable Object-Oriented Software:

“Software Architecture is the decisions you wish you could get right early in a project”

Ralph Johnson

Software Architecture is also known as a blueprint for a system. It provides abstraction for managing system complexity, establishing communication, and coordination mechanisms between components. Thus, the team will receive clear and correct guidance during the application development process according to the objectives to be achieved. 

The following are matters related to the function of software architecture as a blueprint that we must understand.

• The blueprint will define a structured solution so that it can meet all technical and operational requirements. In addition, the blueprint must be able to optimize general attributes such as performance and security.
• This blueprint will involve a series of critical decisions about the organization regarding the software development process and each of these decisions can have a major impact on the quality, maintenance, performance and overall success of the final product.

The choice of architecture will determine how we handle the performance, fault tolerance, scalability, and reliability of the software we build.

Software architecture as Blueprint

From Figure 1.1 and Figure 1.2 we also can see that the level of high level components are different. Software architecture in the second illustration is more detailed than the first one. So every software architecture will have its own deep level and will be different from other software architecture.

Have you ever wondered how systems or software at large companies were designed? Generally, in large companies such as google or facebook, before the main module development begins, a software design and software architecture has been decided to be used. This architectural and design of software will offer the attributes of practicality and quality desired. Therefore, we must always understand a variety of different architectures, before selecting and implementing them in our applications. So, if we are a solution architect, we must have deep knowledge of various types of architectural software. Better understanding of these will provide us with a fixed decision when designing a system or software.

From all the explanations above, we can conclude that architectural software has important things that a solution architect must think about. Thus, the solution architect must be able to determine which parts of our software system are important that will have a serious impact on our application in the future. From these important things that we start to move and explain how these important things will provide solutions.

Practical Relevance for Business Team and Users

Now we are clear about what software architecture is and know the risks if we do not have it or having it but not good. I think we all agree that software architecture is important. Its existence will determine the success of the application that we will make. But what’s the benefit for you as a software user or paying customer?

From the user point of view, most users don’t care whether the architectural software exists or not. What users care and worry about is the functionality of the software, its performance, and its reliability. All three of that have a significant impact on the user experience and can quickly lead to frustration if one is bad. A good architecture helps ensure that solutions are reliable, work well, and meet all functional requirements.

Meanwhile, from the business side or those who buy our application, it can be explained as follows. When companies decide to buy, build, or license software solutions, they also pay attention to its functionality, performance, and reliability. However, there was much more that they wanted. They also usually consider the new solution should meet:

1. Compatibility and interoperability with existing IT systems.
2. Data security and protection.
3. Maintenance and suitability to be adapted to new requirements or changed (future proof).
4. Cost or the prices of new solutions.

The above points are very important to pay attention, especially when it comes to business-critical solutions. They can jeopardise the whole business and mistakes can make them bankrupt.

Stakeholders in Software Architecture

Who are the stakeholders of software architecture? To answer this, we must first understand the meaning of stakeholders. Stakeholders are people or organizations that have rights, shares, claims, or have an interest in the system or property that meets their needs and expectations.

These stakeholder interests have an influence on the software project that is being worked on. So, their opinion must always be considered. If we don’t do this and ignore one of the key stakeholders, we can ruin the whole project, and that would be a lot more expensive than just letting bug production happen. Stakeholders provide opportunities and boundaries for the system and are a source of requirements.

The interesting situation often happens, stakeholders are not identified before the decision-making stage. But once a decision is designed, announced, or implemented, everyone affected by this decision will have a say. To save the project from potential harm, we are advised to answer the why and to whom, then answer how or how.

Stakeholder Type

Who are projects usually made for? The satisfactory answer is – for end users. The end user is also a stakeholder in the project. However, they may not be the most important. Therefore, in software development, it is a good idea to focus not on the end user, but entirely on the stakeholders.

It is not possible to create a comprehensive list of stakeholder types because, for different systems, they can differ significantly. Let us highlight the following stakeholders as the most common stakeholders. Also, let’s look at each category in terms of the consequences of ignoring their interests.

Those Involved in the Project and Working on It

The first group of software architecture stakeholders is a group of people or organizations that are directly involved. This first group can be grouped into four major groups.

1. Project Team, they are a group of people who should be considered first when creating software architecture. Let us not make application solutions using the. Net language if it is available in companies is  only java programmer and none of them know .Net. From here it is necessary to pay attention to the availability of existing programmers, not to determine the technology used because it is trending. Unless the company gives time to learn or provide training in the programming language that will be used and at least the company must hire at least one senior who can direct and teach the existing programmer team.
2. Management Team, they are a group of people that we have to talk to and pay attention to before we decide to make architectural software. Because this management team is a group of people who will protect us so that everything we design can be carried out until it reaches the final goal.
3. Third party, it is possible that there will be several problems related to the integration process with third parties because of the level of complexity and it is even possible that we have limitations that we cannot use their solutions. Therefore, third parties are also stakeholders that we need to talk to before creating architectural software.
4. Supporting Team, an organization or person who supports the system at one or more stages of SDLC. Generally the support team will be involved after this application is used live. Suppose an architect forgets to create a support system. This raises questions such as “Is designing this system just a hobby, and how do we support it?”.

Those Affected and Software Users

The second group of software architecture stakeholders are those who are not directly involved but directly affected by the architect’s solution. This second group is grouped into at least three categories.

1. Customer, this group of stakeholder is the important stakeholder that must be considered all of they want because they are who pay the money for software development. If you are a solution architect who creates software architecture, you must always ask them and communicate with them. For example, some time a fantastic technical solution for real-time data processing and synchronization was created. This solution was one of the most advanced techniques on the market, taking into account the latest technological trends. Furthermore, it was competently designed, correctly tested, and shown to the customer. And then it turned out that the customer wanted something different. More precisely, a completely different solution. And they did not need super synchronization at all.
2. End Users, this group is the user of our application. Yes they will be affected by our software architecture but in real life for the end user in company or not a public user their influence was not strong. On the other hand, if the user is a user public their influence is so strong and you must understand this user also  is a customer of our public application.
3. Head of Employee (Department Head), They are rarely encountered in practice, but they are one of the most demanding stakeholders. If you forgot them, then prepare yourself for them by putting sand in your wheels. 

Those not Involved in the Project but Their Position can Influence It

1. Top Manager, The company’s profit, success, and position, as well as the success of projects, are essential for them. We should try to take this into account.
2. Company Owner, They get very upset hearing the words “project” and “risks” in one statement. Try to minimize them when designing your project.
3. Shareholder, The company’s profit is significant for these stakeholders. Moreover, they want to get it as soon as possible and be stable. Designing a solution that will be done in five years, although you can divide it into iterations and start earning tomorrow is a mistake that can cost you your career.
4. Regulatory, You designed a system that does not correspond to some standards and guides, and then your solution is banned from the AppStore? It is anything but the right solution.

Software Design

Software design is different with software architecture. Sometimes most software developers are confused and often consider them is the same. Software design is responsible for code level design, what each model is doing, the classes scope, and the functions, purposes, etc. When used strategically, they can make a programmer more efficient, giving them methods that have already been refined by others, so they don’t have to keep reinventing the wheel.

When communicating or discussing a code with others or when we manage and review code, software design can provide useful common language to conceptualise repeated problems and solutions.

In the real programming world there are a lot of designs commonly used and we call them software design patterns. Design patterns are used to represent some of the best practices adopted by the experienced object-oriented software developers. A design pattern systematically named, motivates, and explains the general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to implement the solution, and the consequences. It also provides guidance and examples of implementation. 

As per the design pattern reference book Design Patterns – Elements of Reusable Object-Oriented Software , there are 23 design patterns which can be classified in three categories: Creational, Structural and Behavioral patterns.

Here are two examples of the most important software design patterns that we can use in our software development process.

Singleton

Singleton is one of the simplest and most used patterns. This pattern prevents a creation of class (struct in golang language) only one object or instance. In every layer, every step, every place in the system that only one instance. For example when creating database connections we use this pattern. A single DB connection shared by multiple objects as creating a separate DB connection for every object may be costly.

How to ensure than only one object created, because it’s trivial to create an object of a class. The answer is to make a private or protected constructor like in the Java programming language or create a new function like in golang.

employee.go

package employee
import (  
    "fmt"
)
type employee struct {  
    firstName   string
    lastName    string
    totalLeaves int
    leavesTaken int
}
func New(firstName string, lastName string, totalLeave int, leavesTaken int) employee {  
    e := employee {firstName, lastName, totalLeave, leavesTaken}
    return e
}

main.go

package main  
import "employee"

func main() {  
    e := employee.New("Same", "One", 30, 20)
}

Factory Method

In real life a factory produces goods, in software development a factory is a product object. Factory method is related to object creation. In Factory pattern, we create objects without exposing the creation logic to the client and the client uses the same common interface to create new types of objects. The idea is to use a static member-function (static factory method) which creates & returns instances, hiding the details of class modules from the user.

Usually objects are created in java like below.

SomeClass someClassObject = new SomeClass();

The problem in the above approach is using default  constructor and with this become very dependent with concrete implementation of SomeClass. There’s nothing wrong with using new to create objects but it comes with the baggage of tightly coupling our code to the concrete implementation class, which can occasionally be problematic

Here is an example of a simple factory method in golang.

func NewPerson(name string, age int) Person {
  return person{
     name: name,
     age: age,
  }
}

We can return a pointer to instance person instead like below.

func NewPersonPointer(name string, age int) *Person {
  return &Person{
     Name: name,
     Age: age,
  }
}

Ikuti Blog Saya

Dapatkan konten baru yang dikirim langsung ke kotak masuk Anda.