Cover image for Building An Architectural Character for Modern Software Architect [Part 3]

Building An Architectural Character for Modern Software Architect [Part 3]

edisonnpebojot profile image Edison Pebojot(πŸ‘¨β€πŸ’») ・Updated on ・12 min read

Part Name Description
01 Software Architectural Thinking for Developers From the perspective of a developer, architects see it differently. There's more to design philosophy than simply thinking about architecture. From an architectural mind, this is seeing things.
02 Architecting Modules for Software Modularity Software architecture modularity has proved slippery to describe. For architects, recognizing modularity in the architecture platform of choice is important.
03 Building An Architectural Character for Modern Software Architect A company aims to address a specific problem, then a list of requirements is collected. For the exercise of requirements gathering, a broad range of techniques exists.
04 Identifying An Architectural Character for Modern Software Architect Up Next: November 29-30, 2020

Building An Architectural Character for Modern Software Architect (πŸ“πŸ’€πŸ”§βš‘)

Alt Text

The exercise of requirements collection is a broad range of approaches usually specified by the software development process used by the team. However, as seen in Figure 4-1 (Below), the architect must consider several other variables:

Alt Text

Figure 4-1. Domain requirements and architectural characteristics

Architects have a role in defining the characteristics of the system. Architectural characteristics are defined by many companies in a number of ways, including non-functional requirements. Architects developed the concept to separate Architecture characteristics from functional requirements. We like Architecture characteristics because it describes the architecture, and thus the system as a whole, without discounting its value. Let's see an example of criteria for building the characteristics of software. Three requirements meet with an architectural characteristic:

Alt Text

Figure 4-2. Criteria for building characteristics of architecture
  • Specifies a non-domain design consideration: This criteria define non-domain consideration for success when designing an application, concerning how to implement the characteristics (and why these choices have been made).

Note (πŸ“): When we say Non-domain consideration in Software Architecture, we mean consideration that is not included in the domain requirment.

This criteria adds characteristics to designing an application with the suggestions from the architects, but often doesn't appear in a required documents. For example, architects suggest to add performance for the application but it does not appear in a required documents.

  • Influences some structural aspect of the design: For example, an architect might asks this question, does this characteristic of architecture need special structural requirements to succeed?

Note (πŸ“): When we say structural requirements, we mean code structure (or code characteristics) requirements.

In every project, for example, security is a concern, and during design and coding, all systems must take precautions. However, consider two example payment system (Below):

  1. Third-party payment system example: If an integration point handles payment data, then special structural requirements may not be needed for the design. Standard security, such as encryption and hashing, should be implemented into the design, but it requires no special structure.

  2. In-application payment system example: If payment system needs to be done by the application under construction, the architect can structure a specific module, component, or service to separate security concerns for that purpose. The architecture characteristics now has an impact on design.

Remember (πŸ’‘): Of course, third-party integration often leaves large vulnerabilities that can be exploited by hackers or malicious programs and special structural requirements might be involved during this decision. It highlights some of the choices that architects need to make when choosing how to design.

  • Critical or important to application success: This criteria is mostly focus on choosing characteristics of software architecture (with limited number). Applications could accept a large number of architecture characteristics, but they should not. Accepting a large number of architecture characteristics adds complexity to the design. Therefore, the choice of the least amount architectural characteristics is an important requirement for architects.

We further divides characteristics of architecture into characteristics of implicit versus explicit architecture. Implicit architecture characteristics rarely appear in required documents, they are not proposed (or suggested) by architects but they're still included (But rare) in the required documents (Because they’re still necessary for project success). Explicit architecture characteristics does not appear in required documents, they are proposed(or suggested) by architects but not included in the required documents. Let's see an example:

  1. Implicit architecture is, for example, Google Inc. may have to specify low latency (minimal delay) in every system, yet the architects in that problem domain (or problem space) don't want to know how important it is. And the architects don't need to suggest low latency, but Google Inc. included it to their domain requirements (But rare).

  2. Explicit architecture is, for example, Google Inc. may not have to specify low latency (minimal delay) in every system, yet the architects in that problem domain (or problem space) know how important it is. And the architects suggested low latency, but Google Inc. didn't include it to their domain requirements.

Remember (πŸ’‘): Each components supports the others in Figure 4-2 (Above), which in turn support the overall design of the system. The pivot point (or fulcrum) created by the triangle illustrates interaction between these components, leading to the use of trade-off analysis (See on Wikipedia).

List of Architectural Characteristics (Partially Listed) (πŸ“–βœοΈ)

Alt Text

The characteristics of the architecture ranges from low-level (Development) code areas, such as modularity, to high-level (Business Operation) operation areas such as scalability. There's no absolute universal standard. Each company develops its own standard of architecture characteristics. However, architects divide architectural characteristics into categories:

Operational Architecture Characteristics (In Business Operation) (πŸ‘”πŸ’ΌπŸ“ˆ)

Table 4-1. Operational architecture characteristics (In Business Operation)

Term Definition
Availability How long would it take for the system to be available? If it is 24/7, steps must be taken to enable the system to operate 24 hours a day.
Continuity Disaster recovery capability
Performance Stress testing, peak analysis, analysis of the number of functions used, energy supplied, and response times are included. Acceptance of performance also takes months to complete.
Recoverability Requirements for long lasting business operation. For example, how quickly will the system be up again in the event of a disaster? You might use backup plan and duplicated hardware for your long lasting business operation requirements.
Safety Evaluate whether the system needs to be fail-safe, or damages lives. If it fails, will it cost the organization a massive amount of money?
Robustness Abilities to cope with failures and restrict conditions while running if the internet connection goes down or if there is a power outage or hardware failure
Scalability Ability to operate the system as the number of users grows

Structural Architecture Characteristics (In Development) (πŸ”’βž‘οΈπŸ“¦)

Table 4-2. Structural architecture characteristics (In Development)

Term Definition
Configurability The ability of end users to easily change the configuration details of the software through usable interfaces.
Extensibility How necessary it is to add in new parts of functionality
Installability Ease of installation of systems on all required platforms
Reuse The ability to reuse components across multiple products
Localization Support for multiple languages and units of measurement or currencies
Maintainability How simple is it to implement modifications and enhance the system?
Portability Will it take more than one platform to operate the system?
Supportability What is the level of technical support that the application needs? Whose Infrastructure are needed to debug errors in the system?
Upgradeability Ability to easily update from a older version to a newest version of this application

Cross-Cutting Architecture Characteristics (In Development and Business Operation) (πŸ“ˆβ†”οΈπŸ”’)

Table 4-3. Cross-cutting architecture characteristics (In Development and Business Operation)

Term Definition
Accessibility Access to all of the customers, including those with disabilities such as hearing loss or color blindness
Archivability Will it be necessary to archive or delete the data? For example, you have the option to delete or achive you seaches from Google search engine. When you archived it, you can see your search history
Authentication security requirements to verify users are who they think they are.
Authorization Security requirements to verify that users can access only certain functions within the application through subsystem, webpage etc.
Legal What are the limitations under which the system operates? What rights does the company require? Any regulations on the way in which the application is to be developed?
Privacy Ability to hide transactions (or encrypte transactions) from company employees that even network architects cannot see them.
Security Is there a need to encrypt the data in the database? Is there a need to encrypt data between internal systems from network communication? What kind of security does remote user control need to be in place?
Supportability What is the level of technical support that the application needs? Whose Infrastructure are needed to debug errors in the system?
Achievability The training required for users to achieve their tasks within the application

Based on specific factors, software can invent architectural characteristics. Many of the preceding terms are vague. It can sound similar to interoperability and compatibility, but they vary because interoperability mean ease of integration with other systems. In comparison, compatibility is more concerned with business and domain requirements.

No complete list of standards exists. The International Organization for Standards (ISO) publishes a list of definitions:

  • Performance efficiency: Performance measurements according to the quantity of resources used. This includes the following:
  1. Time behavior: measure of response, processing times, and rates
  2. Resource utilization: amounts and types of resources used
  3. Capacity: The degree to which the maximum limits are defined
  • Compatibility: The degree to which a product, system, or component can share information and perform its required functions with other products, systems, or components while sharing the same hardware or software environment. It includes:
  1. Coexistence: can perform its required functions while sharing environment and resources with other products
  2. Interoperability: The degree to which two or more systems are able to share and use information
  • Usability: The degree to which the system can be used safely and successfully by users. It includes:
  1. Appropriateness recognizability: Users can understand if the software is suitable for their needs.
  2. Learnability: How easy users can learn how to use the software
  3. Accessibility: make the software available to people with the widest range of characteristics
  • Reliability: Degree to which a system functions under specified conditions.This characteristics contains subsets such as:
  1. Maturity: The software meets the requirements for reliability in normal operation.
  2. Availability: software is accessible
  3. Fault tolerance: Despite hardware or software failures, does the software performs as intended?
  4. Recoverability: Can the software recover from failure and restore the desired state of the system?
  • Security: The degree to which information and data are protected by the software such that persons or products or systems have access to data relevant to their types and authorization levels. This group of characteristics includes:
  1. Confidentiality: Data is only available to those who are allowed
  2. Integrity: Unauthorized access to or modification of software or data is prohibited by the software
  3. Nonrepudiation: Can actions or events be proven so that the system is sure that it cannot deny someone? (See on Wikipedia)
  4. Accountability: Are users accountable for the use of the system by their actions? Are systems entrusted user responsibility so that users are accountable for the loss of data? Can the behavior of an user be monitored by a system to prevent the loss of data?
  • Maintainability: The degree to which developers can adjust the software to improve, correct or adapt it to environmental changes or requirements. This characteristic includes:
  1. Modularity: The degree to which the software is composed of separate components
  2. Reusability: The degree to which developers can use component in more than one system or in building other component
  3. Analyzability: How easily developers can collect software metrics
  4. Modifiability: The degree to which the software can be modified by developers without adding errors or degrading current product quality
  5. Testability: How easily the software can be tested by developers (or others)
  • Portability: The degree to which a system, product or component can be transferred from one hardware, software or other environment to another by developers. This characteristic includes:
  1. Adaptability: Can software be adapted by developers for multiple hardware, software or other environments?
  2. Installability: Can you install or uninstall the software in the required environment?
  3. Replaceability: How easily developers can replace the functionality?

The last item in the ISO list addresses the functional aspects of software (which we do not believe belongs in this list):

  • Functional suitability: This characteristics illustrates the degree to which, when used under defined conditions, a product or system provides functions that meet stated needs. This characteristic is composed of the following subsets:
  1. Functional completeness: The degree to which the functions perform the tasks stated
  2. Functional correctness: The degree to which the correct results are provided by a product or system
  3. Functional rightness: The degree to which the functions allow the completion of the tasks defined. This are not architectural functions, but rather motivational specifications for the program to be designed.

The lack of clear definitions of architecture characteristics, including the software architecture operation itself, is a confusion among architects! This leads businesses to define their own terms, which causes to uncertainty around the industry. We can not force a standard terminology on the field of software development as much as we'd like. However, the advice from domain-driven design to develop and use a language among fellow employees is followed and recommended to help ensure less term-based misunderstandings.

Trade-off for less architecture characteristics (βœ…βŒ)

Alt Text

For a variety of reasons, applications can only accept a few of the architecture characteristics we have mentioned. First, design effort is needed for each of the supported characteristics. Second, the characteristics of architecture also have an influence on other characteristics of architecture. For example, if an architect wishes to refactor the code structure because of weak security characteristics added into the application, it would almost definitely change (or influenced) by introducing structural characteristics.

However, choices are focused on trade-off analysis. Too many characteristics of architecture rarely work because the design becomes unwieldy (or difficult to carry). This indicates that architects should aim to be as iterative (or reusable) as possible to design architecture.

Summary (πŸ“šπŸ“š)

Alt Text

There is something more that needs to be taken into consideration, which is the characteristics of the software architecture, separate from the domain requirement. We have 3 criteria for building characteristics of software that need to be considered. Characteristics such as performance may be suggested by the architect but can not be used in the document requirement. Perhaps, if they do not require you to change the code structure, components or modules, you are no longer involved in software design. The guideline should only have less characteristics, since software design would be lost its balance. There are so many characteristics of architecture in industry, separate characteristics terms that leads to misunderstanding, so if you are a software architect, you would have a hard time. Of course, ISO also facilitates in standardizing characteristics of architecture.

Learn More (πŸ“•πŸ“™)

Up NextπŸ‘‰ Part 04: Identifying An Architectural Character for Modern Software Architect πŸ”₯ πŸ”₯ ( November 29-30, 2020)

Alt Text


Editor guide