Detecting Architectural Gaps with Automation - Proposed Solution

Introduction In 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. 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. 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. 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 architectural 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 and is 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 plugin 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 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 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 that a dedicated machine be allocated 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 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 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 to launch the Java class dependency analyzer. For systems built on the .NET framework, Net Dependency Walker serves as a suitable choice for ascertaining 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. 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, are implemented in 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. Introduction In 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. context diagram (view) 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 . Users Proposed Solution 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 . Online Offline UML API Software Architecture Software Architecture To access code, configuration, and the database, interactions with Version Control Systems and the database are utilized. Version Control Systems Finally, Report Storage is employed to save the outputs extracted from the Architecture under analysis. Architecture 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. Context View Separate Step CI/CD CI/CD 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. 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. 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. architects administrator Data Layer The data layer function maintains the following types of data: Architecture Baselines: This feature records the history of architectural 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. Architecture Baselines: This feature records the history of architectural 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 and is 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 plugin 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. Architecture Machine Learning (ML) 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 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. Database Processor ML components User Interface 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. Database User Interface Processor ML components Deployment View - Cloud 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 that a dedicated machine be allocated for this purpose within the cloud pipeline. Cloud deployment CPU usage Integration with UML Design Tools: As previously mentioned, the proposed solution should seamlessly integrate with offline UML design tools, including: UML design Microsoft Visio OmniGraffle Microsoft Visio OmniGraffle Furthermore, the proposed solution should also integrate effectively with online UML design tools, which encompass: UML design Enterprise Architecture LucidChart Draw.IO PlantUML Gliffy.com Enterprise Architecture LucidChart Draw.IO PlantUML Gliffy.com 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. APIs Microsoft Visio Processor System Configuration DB 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. Online UML APIs APIs APIs Processor 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. UML HTTP REST APIs UML design HTTP REST API LucidChart HTTP GET POST Enterprise Architect REST API JSON 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 overall computing needs. AWS Azure GCP Machine Learning ML ML Cloud Environment ML 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 : 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 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. Azure GCP 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 to launch the Java class dependency analyzer. For systems built on the .NET framework , Net Dependency Walker serves as a suitable choice for ascertaining dependencies. JDeps proposed solution JDeps Java .NET framework Net Dependency Walker 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. CI/CD CI/CD CI/CD The diagram provided illustrates a standard CI/CD pipeline, depicted as the first pipeline. This pipeline encompasses multiple sequential stages, which include: CI/CD Plan Code Build Test Release Deploy Operate Plan Code Build Test Release Deploy Operate At present, two prominent products, Jenkins and Bamboo , are implemented in 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. Jenkins and Bamboo CI/CD 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.