What is Software architecture?

Definition of components, and it's relationship that meets functional and non-functional requirements:

1. Functional: What needs to make business happen

2. Non-Functional: The quality attributes of the architecture that make one architecture better than others:

• Scalability 

• Maintainability

• Performance 

• Reliability & Availability 

• Security 

• Maintainability & Modularity 

• Cost & Resource Efficiency 

• Operationalization

What is MDA?

MDA means model driven architecture, a new approach of formulating software requirements and technical specifications in graphical representation, which leads to higher understanding and les confusion about product to be built.

It consists of the following models types, each type is a prerequisite to the next on:

CIM, PIM, PSM, then the code is the realization for all previous models.

1. CIM: Computation Independent Models, focus on the business/analysis models

2. PIM:  Platform independent Models, focus on the design models in an abstracted approach

3. PSM: Platform-specific Model, focus on detailed specification of design models according to the target platform

Practice

Reference Standard

Benefit

Software Architecture is the fundamental organization of a system into components and relations between them and the working environment, considering the quality attributes (Performance, availability, usability, security, and adaptability), and enhance developing pattern solutions-repetitive solution development tasks.

We have the following elements:

• Solution components (building blocks)

• Components relationship

• Deployment model of the components

• Relationship between nodes

• How to consider quality attributes in architecture

Component can be:

• Business Component, according to business decomposition 

• Technical: According to infrastructure reusable components that is result from scanning different operations (Security, Caching, Reporting, DAL)

Node can be:

• Client machine

• Server machine

• Smart device (Mobile and TV)

So, Why We need component diagram?

1. Design clarity

2. Standardization 

3. Planning clarity

4. Drilling down the composition

5. Reveal hidden facts

6. Clear sizing approach

Component implementation approach?

You have two approaches to creating reusable components:

1. Business component: Create reusable components with the same source code nature(OOP) in case you have 

2. Cross-cutting Technical Component: like logging, security, and caching, Use Aspect-Oriented architecture development approach, 

Software architecture is the process of determining the solution buding blocks, relationship between them, and its relationship with the environment

The challenges:

1.How can we detect/find (reusable components) the solution building blocks?

2.Which technology/tool to build it with?

3.And what are the objectives of reusable components?

Regarding the first challenge, no more time to waste in building #SRS and more documents

Immediately shift your mindset to #MDA( model driven architecture), which you should represent your solution in models, in all #sdlc and solution elements

Then you should have 2 types of #components:

1. Business components ( include the implementation of business requirements ), which the current #ddd (domaim driven design) is focused on

Ex:

PayrollMdl: payroll component

AccPayable: account payable component

2.Technical components (include component or more for each operation type within the system)

Operation types: like 

1. CRUD Operation component, like DAL (Data access layer)

2. Reporting Component 

3. Logging Component

4. Database administration component

5. Security operations

You will need one or more for each

#UML is the best fit for building the models, that support architecture modeling and take decisions before implementation.

Why We need reusable components?

Reusable components is totally independent that detecting normal solution building blocks, where your are looking for the following perspectives:

1.  How to decrease solution cost, by buildig components once, and reuse it every where

2. By keeping high maintainability, since you maintain at one place, and solution cascaded everywhere

We can create components on the following cases:

1. When reusability probability found, make it component.

2. When it’s hard to do, do it.

3. When you want to classify and organize your outputs

Otherwise, You are over-engineering your product.

Decompositions approach:

Good decomposition should provide the following:

1. Single responsibility

2. Cohesion

3. Completeness

4. Reusability

Over Engineering

You should take care from the over engineering that leads you to extreme expected reusability rather than rational one, so derive your reusability levels from your engineering strategy.

One of the core values for using the MDA, is the accuracy of estimations, as you will have the visibility for the following:

1. All objects

2. Missing Objects

3. Missing operations

4. Required/Missing integrations

5. Effort per each layer to achieve the business scenario over technical tasks

6. Detect expected response

7. Detect missed operations

8. SRP according to the communication

9. Integration layers

10. Reusable components

11. Composite structure

12. The execution time to do the sequence i. Rectangle, which indicate severity and application of defensive programming and logging

Expected Activities for Assessing the effort from architecture perspective

1. New micro-services

2. New classes

3. New APIs

4. New schemas

5. New tables

6. New database objects

7. New integration

8. POC

9. New MDA models

10. Code quality activities

11. FE page

We can mention here in this subject the Top 10 Wrong practices while applying MDA using UML:

1. Partial implementation of the models Analysis/design/infrastructure

2. Absence of models landscape that simplify the presentation of solution models

3. Absence of transformation approach between model (Architecture context, analysis, design), which means that teams are working in silos, no tracability and relationship between the models

4. Incomplete Models: Insufficient and incomplete models make team move to the final source code, and then the objective of having models come none

5. Absence of relationships with applied patterns

6. Absence of relationships with applied non-functional requirements

7. Absence of relationships with applied digital transformation drivers

8. Absence of reporting for the tracability matrix that support the governance and assuring the completeness and consistency of the models

9. Over-engineering Modeling: complex models that are difficult to understand, maintain, and implement. The goal of MDA is simplicity and abstraction, not unnecessary complexity

10. Using non-standard models and shapes within UML models

The bonus one 👌👌👌 is the most important practices, which is:

Absence of using composite models, which enable you to architect, simplify and slice models

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

Architecture levels (Enterprise, solution, technical) and technology selection

We have mentioned a set of practices on how to model your architecture.

In this episode, We will go deeper on fifferent architecture levels.

We have three levels of architecture:

1. Enterprise level : Regarding the organization vidion and strategy, for example , our vision is to build #SaaS model, this vision will be cascaded to platform selection, technology selection, and even solution implementation approach.

2. Solution level: inherited from the enterprise architecture, with level of flexibility on the solution level, and its modules

3. Technical level, depth focus on the detailed of modules building ro class levels.

We can say: the existance of these levels will accelerate your strategy towards achieving organizational objectives, while the absence will lead to a solution, the son of development team, but not the son of the organization vision, and here is the crise. 

Pattern vs anti-pattern approaches

The pattern is a solution for a specific problwm within a context.

We have a lot of patterns/standards/approaches regarding:

1.Layered architecture: to for the connectivity between solution building blocks, like tiers, how many tiers should we have, and why.

2.Components types: like com objects, portable components, SOA, Micro services architecture

3. Communication between components ( queueing, callbacks or event driven)

4.Solution design patterns to resolve specific problems

5. Database design, relational and non relational

With all of the above mentioned patterns, supported by researches, and scientific reviews, we have anti-patterns approach that stick to find the solution his way.

This is a great debate, but we should respect considering the following conditions:

1. You should be aware of what you are againest

2. Understand/appreciate That patterns is the contribution of researchers to support the community

3. Proof your new provided solution to yourself and then to the market.

4. It's not enough to make things work, you should go deeper after details in order to meet/exceed pattern oriented approach.

in order to make reverse engineering using MDA approach, you should do follow one of the following strategies:

1. Horizontal

Focusing on finalizing business journey, from all models, static and dynamic models, Analysis and architecture models, So there is a collaboration between the team members within the agile SQUAD to deliver mature models.

Benefits:

• Mature models will be delivered

• Rework effort reduced

2. Vertical

Focusing on finalizing business journey, from all models, static and dynamic models, Analysis and architecture models, So there is a collaboration between the team members within the agile SQUAD to deliver mature models.

Benefits:

• Immature models according to learning curve

• Rework effort increased

• Faster model

As a process you should do the following:

1. Database informal design rules

-Semantic(Naming convention)

Use suitable naming convention for both attributes and relations, also it should be cascaded to all database objects, like indexes, functiins and triggers.

-Data redundancy and anomalies problems: 

Do not merge relations in one relation as it will leads to insert/update/delete anomalies

-Null values Tuples

-Spurious tuples(fake joins) 

2. Database formal design (Normalization forms)

Functional Dependency is a relationship between two attributes. This represents the relationship between the primary key and non-primary key attributes. An arrow denotes a functional dependency. 

1NF : atomic, multi valued columns, repeated griups, no composite keys

2NF: Remove data depends on partial key

3NF :Remove data depends on non-key attribute 

BCNF : keys depend on non-key column

4NF=MVD split tables with multi value dependency like (customer vendor item)

5NF=Assure non data loss 

3. Query simplification techniques

 like Views, CTE, stored procedures, stored functions

4. When to create index

What is Event?

Significant change in state, for example: Car is marked for Sold, if we sold it the status will be Sold and not available.

How EDA works?

Component interact with others throw invoking events.

Other system components can register to the component as interest of receiving events, that what we call "implicitly".

It provides reuse components, since it decreases the coupling between components.

EDA Elements?

•You have the following elements in the model:

•Publisher

•Event bus

•Event

•Subscriber

•Event response

What is C4?

The C4 Model is a hierarchical architecture modeling approach for visualizing software systems, developed by Simon Brown.

C4 Levels

1. Context: Big-picture view: system and users

2. Container: Applications/services inside the system

3. Component: Internal structure of a container

4. Code: (Optional) Class/module-level view

Reasons for moving from UML to C4

• Clarity: Simple, focused diagrams

• Audience: all stakeholders (tech + business)

• Flexibility: Lightweight and pragmatic

• Abstraction Levels: Explicit 4 abstraction layers

• Tool Support: Lightweight (e.g., PlantUML, Structurizr)

How to model:

• 🧍 Person

End user who uses the systems.

Examples: Customer, admin user or employee.

• 🏢 System

The highest level of abstraction that delivers value to end users, whether they are human or not. Systems are often owned by a development team.

Examples: SendGrid is an external system.

• 📦 Container (App/Store)

Applications and data stores that make up a system. These are independently deployable and runnable. (Not to be confused with Docker containers)

Example: API service, front-end application or mobile app.

• 🧩 Component

Building blocks and modules that make up each container.

Example: Authentication module or payment card validator.

• Level 4 - Code diagram

Usually in the form of UML class diagrams that are ideally autogenerated from the actual code. This level is rarely used as it goes into too much technical detail for most teams.