Software Architecture

Architecture Governance And Validation

3 Day(s)

🎯 LEARNING OBJECTIVES

Understand the purpose of architecture governance and quality assurance.
Apply architectural principles, standards, and review practices.
Evaluate architecture compliance against business requirements, technical standards, and quality attributes.
Identify architectural risks, document decisions, and manage deviations through corrective actions.

🧠 PREREQUISITES

Basic knowledge of software architecture, design principles, and quality attributes.
Familiarity with software development processes, requirements, and technical documentation.

📖 Topics / Lesson

1.MDA governance approach

2.Architecture validation process

3.Architecture Scale

4.Key source code metrics

Video Sessions

Research References

Architecture Governance

1.MDA governance approach

One of the key feature to be used in software engineering, and can't be achieved without using the MDA tools, is the relationship matrix, which used to validate the models.

In Enterprise architect tools, one of the key features, is the relationship matrix, which you can select the source object (use case as example), and target object, and the relation type and direction between them.

Using the relationship matrix can provide the following capabilities for engineering team:

1. Relationships between objects over all models

2. Inconsistency between models

3. Irrelevant objects.

So, you can determine as example the following:

1. The missing implementation, like which digital transformation drivers (represented in requirements) are still not implemented within the components/micro-services.

2. The missing implementation, like which digital transformation drivers are still not implemented within the components/micro-services.

3. Relationships between actors(Business users)

4. Actors Vs Actors relationships, which show you the different levels of actors and their authorities for performing actions more than normal employees

5. Devices Vs Nodes, Which show you which devices connect to your solutions nodes, which will be used for service providing and integration purposes, and find missed scope

2.Architecture validation process

#softwarearchitecture validation process

previously, We have focused on the architectutre process, from start to end.

But, We have a set of challenge that face the architecture:

1. How shall we guaranttee the completenes of architecture models

2. How shall we guaranttee the #softwarequality of the models(next episode)

Regarding the completeness of the models

1. Solution journey should be represented using activity diagram, and reviewed with top and mid management level

2.All #usecases should be inherited from main solution scenarios, and reflecting #userstories

3. All #usecases should include pre-conditions, post-conditions, and all #usecases alternative scenarios

4. Process of collecting static models from mentioned names in the use case models, with consolidation and abstraction for correlated objects

5. Then packaging them in suitable correlated components according to #SRP approach, including also the communication responsibility to other parties(internal/external components for integration)

5. Clear definition of the components, #deployment for each component should be configured clearly, and documented

3.Architecture Scale

Software Architecture scale can be differed according to the following factors:

Platform (Desktop/web/mobile)
Connectivity (online/offline)
Integrations (Aggregation/EDA/Database level)
Business model (SaaS/provisioning module/B2B/B2C/social media integration)
Availability (cloud/dedicated/on prime)
Security (hybrid cloud/WAF/SSL/Encryption/OWASP)
Realtime operations (Realtime database/notification)
Communication (SMS/MAIL/PN/Geo-fencing)
Data volume (distributed DB/big data)
Data structure (Relational/ non-relational)
Scale (Micro-services/docker containers/kubernetes)
Response time (CDN/Caching/load balancing/Deployment nodes)
Feature based(data marts/data warehouse/MLAAS)
Sensitivity: backup plans/disaster recovery
Customer experience: social media accounts integration, e-payment gateways

We will discuss them in depth in the following sections.

4.Key source code metrics

Maintainability Index - Calculates an index value between 0 and 100 that represents the relative ease of maintaining the code. A high value means better maintainability. Color coded ratings can be used to quickly identify trouble spots in your code. A green rating is between 20 and 100 and indicates that the code has good maintainability. A yellow rating is between 10 and 19 and indicates that the code is moderately maintainable. A red rating is a rating between 0 and 9 and indicates low maintainability. For more information, see Maintainability index range and meaning.
Cyclomatic Complexity - Measures the structural complexity of the code. It is created by calculating the number of different code paths in the flow of the program. A program that has complex control flow requires more tests to achieve good code coverage and is less maintainable. For more information, see the Wikipedia entry for cyclomatic complexity.
Depth of Inheritance - Indicates the number of different classes that inherit from one another, all the way back to the base class. Depth of Inheritance is similar to class coupling in that a change in a base class can affect any of its inherited classes. The higher this number, the deeper the inheritance and the higher the potential for base class modifications to result in a breaking change. For Depth of Inheritance, a low value is good and a high value is bad.
Class Coupling - Measures the coupling to unique classes through parameters, local variables, return types, method calls, generic or template instantiations, base classes, interface implementations, fields defined on external types, and attribute decoration. Good software design dictates that types and methods should have high cohesion and low coupling. High coupling indicates a design that is difficult to reuse and maintain because of its many interdependencies on other types. For more information, see Class coupling.

Lines of Source code - Indicates the exact number of source code lines that are present in your source file, including blank lines. This metric is available starting in Visual Studio 2019 version 16.4 and Microsoft.CodeAnalysis.Metrics (2.9.5).
Code coverage.
Response time.
MTBF: The average time it takes alive between each failure.
MTTR: Mean time to repair, how much it takes to resolve the issues
SaaS provisioning time : how much it takes to create new instance
Fault- tolerance: to which level there is an isolation and modularity, that prevent the spread of negative impacts on the overall system when part of it fail, so if a module failed, the others are still working.