In this article, we explore the importance of solution architecture in small applications, and why having an architect involved can make a significant difference. The author shares their experience in creating a solution architecture document, and how they decided to keep all notes and documents in the form of text files in MD format, providing insights on how to create attractive README.md files with a use of badges from shields, providing document structure and required chapters. The article also covers topics such as defining requirements, managing development tools and libraries, and creating effective documentation for small applications. " " you might ask. " " Are you kidding? Do such small applications require an architect to be involved? " " I would answer. Yes, yes, and yes! Generally, architects create a huge document known as a that includes everything. Initially, I followed the same approach, but it turned out to be quite difficult to track changes due to the high frequency of modifications. So, I decided to keep every note and document in the form of text files in , like this one. I also learned how to create attractive files with the use of from shields, providing document structure and required chapters. Solution Architecture Document MD format README.md badges Requirements I began my journey as an architect with selection. By selecting the right , an architect can ensure that the software is designed to meet specific goals and objectives, as well as technical and operational requirements. This helps ensure that the software is scalable, maintainable and meets the needs of both the and the . It's worth noting that my approach to selecting differed from that of a because I needed more technical requirements. I divided architect requirements into four parts: requirements requirements business end-users stakeholders requirements product manager ; Constraints ; Assumptions ; Quality Attributes and . Hardware requirements Constraints are factors that limit the architect's ability to design and implement a software solution. These factors may include technical, business, or organizational constraints that impact the development process. Constraints I have listed them on the following in the form of a table with the following columns: page - to describe the constraint itself; Constraint - to provide more details about the constraint; Description - to indicate the business value of the constraint (High, Medium, or Low); Business value - to indicate the resources required to implement the constraint (High, Medium, or Low). Architecture viewpoint Assumptions are made by the architect about the environment, conditions, or factors that are expected to be true for the software solution to function as intended. These statements are made based on available information, but they necessarily proven to be true. Assumptions statements are not are important to consider during requirements selection because they can impact the design and implementation of the software solution. By identifying assumptions early in the development process, the architect can take steps to verify the assumptions and adjust the design as needed to ensure that the solution will function as intended. Assumptions Quality Attributes , also known as non-functional requirements, are the characteristics of a software solution that describe how well it performs in terms of its operation, maintenance, and evolution. are not directly related to the functionality of the software, but rather to how well it meets certain standards or requirements. Quality Attributes Quality attributes are important to consider during requirements selection because they can impact the user experience, the cost of ownership, and the long-term success of the software solution. Quality attributes The are provided in the form of a with the following columns: quality attributes table : to describe the quality attribute Name : to provide additional details about the quality attribute Description : to explain the rationale for selecting the quality attribute Motivation : to indicate the metrics used to measure whether the quality attribute has been achieved or not Measurable Metrics : to indicate the business priorities for the quality attribute Business Priorities : to indicate the architecture priorities for the quality attribute Architecture Priorities Hardware requirements Last but not least were . hardware requirements refer to the physical components, such as servers, storage devices, and networking equipment, that are necessary to support the software solution. These requirements are based on the needs of the software and the expected workload or usage patterns. Hardware requirements It is important to consider hardware requirements during the architecture design phase to ensure that the solution is designed to work within the limitations and capabilities of the hardware that will be used to support it. Software Architecture Views are representations of different aspects of the software system that are designed to communicate specific information to different stakeholders. They provide a structured way to organize and present information about the architecture of the software system. By using , architects can ensure that all stakeholders have a clear understanding of the system and its architecture, which can help to avoid misunderstandings and ensure that the system is designed to meet the needs of all stakeholders. Software architecture views software architecture views I created three : Software architecture views Context view, Functional view, and Deployment view. I used as it is supported now by GitHub. Mermaid.js Context view A is a type of software architecture view that provides a high-level overview of the software system and its external environment. Context view It shows the relationships between the software system and its users, other systems, and external entities. The view is useful for stakeholders who need a high-level understanding of the software system and its contexts, such as business analysts, project managers, or system owners. Context Functional view A is a type of software architecture view that focuses on the functional or behavioral aspects of the software system. It describes the functional elements or components of the system and how they interact with each other to perform the desired tasks or functions. Functional view The is useful for software architects, developers, and testers who need to understand the functional requirements of the system and how they are implemented. Functional view Deployment view A is a type of software architecture view that describes how the software system is deployed or installed in the computing environment. It shows the physical elements of the system, such as servers, networks, and storage devices, and how they are connected and configured to support the software system. Deployment view The is useful for system administrators, operations teams, and infrastructure specialists who need to understand how the software system is deployed and managed in the computing environment. Deployment view Since the FVA Tool Set can be deployed using only one node and a few processes, I provided a simple text for the . description Deployment view Tools, libraries and languages At some point, I realized that I needed a better way to manage the various IDEs, UI and command line tools, libraries, and languages that I use. Tools and libraries I compiled a list of all the tools and libraries that I used for development and presented them in a table on the project's GitHub . The table includes the following columns: page the name of the tool/library, Name : its intended purpose, Purpose : the version I used, Version : the license it is distributed under, License : the platform on which it can be run, Environment and : any additional information I wanted to provide. Comment Initially, the list was much longer, but as some of the tools/libraries became outdated, I moved them to a separate table using the same format. You can find the old dependencies list . here Languages I just used plain text to describe the the FVA Software uses. programming languages Licenses Undeniably, we should remember about licenses. As FVA Software uses third-party tools and libraries, their respective should be included in the code. In addition, I had to create the FVA License and gained an understanding of what a license is and how to create one. licenses Also published . here

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

The writer was physically present in relevant location(s) to this story. The location is also a prevalent aspect of this story be it news or otherwise.

Everything I Learned as an Application Architect While Creating my Product

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Detecting Architectural Gaps with Automation - Business Context

HueHive Diagram Generator: Easy Diagram Creation and Visualization with ChatGPT

I Choose Mermaid for Graph Creation and You Should Too 🚀

Here's Why You Shouldn't Use Graphviz for DAGs: What You Should Use Instead

Detecting Architectural Gaps with Automation - Proposed Solution

Detecting Architectural Gaps with Automation - Business Context

HueHive Diagram Generator: Easy Diagram Creation and Visualization with ChatGPT

I Choose Mermaid for Graph Creation and You Should Too 🚀

Here's Why You Shouldn't Use Graphviz for DAGs: What You Should Use Instead

Detecting Architectural Gaps with Automation - Proposed Solution

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps