Detecting Architectural Gaps with Automation - Proposed Solution
Tags: tutorial, architecture, programming
Published: 2024-05-31 11:37:56

# Introduction
In the ever-evolving realm of software development, the quest for a robust and seamlessly integrated solution stands as a paramount pursuit.
This article embarks on a comprehensive journey into the depths of a proposed software solution, meticulously scrutinizing its architecture, integration strategies, and deployment modalities.
Through this exploration, we illuminate the symbiotic dance between users and technology, offering a roadmap for architects, developers, and IT aficionados alike to navigate the labyrinth of a forward-thinking software solution.

# The Context View for Standalone Application
A **context diagram (view)** defines the solution's boundaries and connections with third parties, such as external systems, users, and data.

As shown in the context diagram above, there is an interaction between **Users** and the **Proposed Solution**.
These interactions will be implemented using a **UI web interface**.

For obtaining input, the solution interacts with **Online** and **Offline UML** tools using their **API** to retrieve the initial **Software Architecture** and to save the extracted **Software Architecture**.

To access code, configuration, and the database, interactions with **Version Control Systems** and the database are utilized.

Finally, Report Storage is employed to save the outputs extracted from the **Architecture** under analysis.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0fark3d7frj6ok89ocsg.png)

# The Context View for a Separate Step in CI/CD
The sole distinction between the previous view and the **Context View** for a **Separate Step** in **CI/CD** is the integration of the proposed solution with the existing **CI/CD** pipeline.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/o922a83ffwagbonaggmc.png)

# Functional View
The functional diagram below illustrates the high-level functional decomposition of the proposed solution.
An agenda is provided below to explain the color coding used in the functional decomposition diagram.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5fdxbsw5srq7vqghnc66.png)

## Integration Layer
The function of the integration layer is to abstract and segregate the system from external components, enhancing system extensibility and modifiability.

The following components are involved:

- Online UML Tools Integration Point: This component integrates Online UML tools with the Processor.
- Offline UML Tools Integration Point: This component integrates Offline UML tools with the Processor.
- Version Control Systems (VSC) Integration Point: This component integrates Version Control Systems with the Processor.
- Databases Integration Point: This component integrates database configurations with the Processor.
- CI/CD Integration Point: This component integrates CI/CD tools (such as Jenkins, Bamboo) with the Processor.
- Reports Plugins: An engine designed to generate reports in a flexible manner and store them in an external report storage.

## User Interface
The user interface function interacts with users in two modes: **architects** and **administrator** mode. 
It utilizes a web interface that is compatible with desktop browsers.

## Data Layer
The data layer function maintains the following types of data:

- Architecture Baselines: This feature records the history of architecture changes, allowing users to track and view past changes. It is accessible for viewing from the architects' panel.
- System Configuration: This aspect encompasses a set of check configurations for processing. It also keeps track of configurations for report plugins. Changes to these configurations can be made from the architects' panel.
- User Configuration: This includes user profiles and access rights, which can be modified from the administrator panel.

## Processing Layer
The processing layer serves as a fundamental function within systems, tasked with processing input data to identify architecture problems.
Configuration of this layer takes place through the architect panel, where checks against the input are initiated.
Additionally, it collaborates with the reports plugins engine for report storage. 
Furthermore, the extracted architecture is preserved in **Architecture** baselines, enabling architects to review it at a later time.
It is worth noting that **Machine Learning (ML)** might be employed during processing to enhance the quality of reports.

# Deployment View
The deployment view illustrates how a solution is intended to be deployed, encompassing its flows and the supporting components.

## Deployment View - On-Premises


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8ztbayx2fyiojyf643fx.png)

On-premise deployment assumes the use of a single computing node for installation.
The **Database** component should be deployed first, as other components depend on it.
Subsequently, the **Processor** and **ML components** are deployed once the Database component is in place.
The **User Interface** component, report plugins, and integration points are deployed in the final stage.

The **Database** component is deployed as a single DB instance with multiple schemas inside.
The **User Interface** component is presented as a web service, while the **Processor** and **ML components** are native processes built for the target platform.
Reports plugins and integration points are designed as dynamic libraries that can be easily added, removed, and configured at runtime.

## Deployment View - Cloud

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d4itx97pcr9e20kdad7j.png)

**Cloud deployment** involves the utilization of two computing nodes for installation.
Due to the potentially high **CPU usage** of the Machine Learning process, it is recommended to allocate a dedicated machine for this purpose within the cloud pipeline.

# Integration with UML Design Tools:
As previously mentioned, the proposed solution should seamlessly integrate with offline **UML design** tools, including:

- Microsoft Visio
- OmniGraffle

Furthermore, the proposed solution should also integrate effectively with online **UML design** tools, which encompass:

- Enterprise Architecture
- LucidChart
- Draw.IO
- PlantUML
- Gliffy.com


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/94pnu49xy6y2m6d812w4.png)

## Integration with Offline UML Design Tools

Due to the absence of **APIs** in offline tools, collaboration with them is established through import mechanisms.
Consequently, architectural documents saved in **Microsoft Visio** format will be exported by a plugin (integration point) and subsequently analyzed by the **Processor**.
The path for scanning input documents will be stored in the **System Configuration DB**.
To support this form of integration, the ability to parse various input formats must be implemented.

## Integration with Online UML Design Tools

**Online UML** design tools typically offer **APIs** for integration purposes.
The collaboration with such tools will make use of their respective **APIs**.
However, it's important to note that some UML design tools might lack **APIs** for integration.
In such scenarios, the import of architecture documents to a designated folder will be undertaken.
The subsequent parsing of these documents will be implemented to import data into the **Processor**, following a similar approach as outlined earlier for offline tools.

For online **UML** design tools, **HTTP** or **REST APIs** are commonly available.
Accordingly, the integration point will access data within the **UML design** tool using the provided **HTTP** or **REST API**.
Each integration with a specific tool will require a distinct integration point.
For instance, integration with **LucidChart** will be realized using the **HTTP** protocol with **GET** and **POST** verbs.
On the other hand, integration with **Enterprise Architect** will involve the use of a **REST API** with **JSON** as the data format.

# Integration with AWS, Azure, or GCP

This section outlines how the proposed solution can seamlessly integrate with **AWS**, **Azure**, or **GCP**.
Given the potential enhancements **Machine Learning** can offer in terms of result quality, it is advisable to allocate a dedicated compute node for **ML** tasks. 
However, in scenarios where the on-premise environment lacks the capability to support **ML** calculations, a viable solution is to leverage a **Cloud Environment** for both **ML** computation and the overall computing needs.

Drawing from the deployment flows previously described, each component should be matched with the appropriate cloud provider service.
For instance, in the context of **AWS**:

- Processor - Leveraging AWS Lambda functions
- Database - Utilizing RDS and MySQL services
- Machine Learning - Employing AWS Machine Learning services
- And so forth for other components

Similar mapping strategies can be applied for **Azure** and **GCP**, ensuring that each component seamlessly integrates with the suitable services provided by the respective cloud platforms.

# Dependency Analysis Tool
Dependency identification plays a crucial role in architecture analysis.
It dissects the entire codebase into components and elucidates their interactions.
Given that similar functions are already available in tools like **JDeps**, leveraging their output would logically bolster the implementation of the **proposed solution**.
**JDeps**, for instance, is a command-line tool utilized for launching the **Java** class dependency analyzer.
For systems built on the **.NET framework**, **Net Dependency Walker** serves as a suitable choice to ascertain dependencies.

# Integration with Jenkins or Bamboo

As mentioned previously, one facet of the application involves integration within a **CI/CD** pipeline.
**CI/CD** represents a multifaceted and composite process, encompassing numerous stages.
Within a single **CI/CD** pipeline, a plethora of functionalities converge to facilitate a comprehensive workflow.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xdwmt3gx4odnp9pd4bs7.png)

The diagram provided illustrates a standard **CI/CD** pipeline, depicted as the first pipeline.
This pipeline encompasses multiple sequential stages, which include:

- Plan
- Code
- Build
- Test
- Release
- Deploy
- Operate

At present, two prominent products, **Jenkins and Bamboo**, serve as implementations of the **CI/CD** pipeline concept.
In real-world project scenarios, both Jenkins and Bamboo are utilized to create pipelines tailored to specific project requirements.
Typically, upon each code commit, at least one pipeline is triggered, orchestrating various processes.

In the context of integrating the proposed solution, the existing pipeline structure can be extended.
This extension entails invoking the proposed solution for architecture analysis.
Consequently, the augmented pipeline would resemble the second pipeline depicted in the provided diagram.