Architecture and Design are widely used terms in software engineering. Every software has some architecture. But what is Software Architecture and why is it given so much importance? Or is it really important? The goal of this write-up is to gain a better understanding with help of some examples. Let's start with the basics. What is Software Architecture? There are many definitions of Software Architecture. says Wikipedia "Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems" has defined architecture as and Martin Fowler "the decisions you wish you could get right early in a project Architecture is about the important stuff. Whatever that is." There will be many more definitions. They all are true, but I have found the description in by easier to start understanding the concept. Here is my explanation based on that: Clean Architecture Uncle Bob There are two aspects (or "value" as Uncle Bob says) of software: : the reason for the software to exist like an email client to send and receive emails, a calculator to perform calculations, etc. Behavior : it is the foundation on which features (that provide behavior) are built. Shape / Structure Behaviors will change with time as the software needs to adapt to the growing and changing user needs. . A good architecture will provide a shape/structure that makes the evolution of behaviors easier, faster, and less expensive Architecture's goals are to make it easy to understand (for a developer), develop, maintain (change), deploy and operate the software. A lot has been said in a few lines! It will become clear as we go further. What is Design? The difference between Software Architecture and Design is confusing because they both are mixed and sometimes there is no clear differentiation. But still, let's try to understand what is called Design. Architecture is about shape/structure which is fundamental and difficult to change once done. Design is things that are built on the foundation and things that can be changed with relatively less difficulty. Let's try to understand with an example: An application has default system settings and user settings. User settings override default system settings. Default system settings are configurable via database and environment variables. Environment variables take priority over database config. To implement this requires deciding many things like: Configuration Parameter naming standardization Database schema to store configuration APIs / Interfaces used by other parts of the system to fetch and update configuration Classes and their relationships implementing the behavior required for configurations #1, #2, and #3 are things that are more expensive to change once implemented and deployed. So they are . #4 can be changed relatively easily even after implementation so it can be considered a . Architectural Decisions Design Decision Process of Architecting is . Architecture a set of decisions taken in a given scenario Most of the time, something can be done in multiple ways, but the selects one option from that. That is the . E.g., Architecture choice of one option Architectural Decision There are multiple protocols to build an API: REST, GraphQL, and SOAP. The decision to use GraphQL is the Architectural Decision. So the next question should be how are these decisions made? Inputs to Architectural Decision Making: Requirements Architectural Characteristics (AC) (or Non-Functional Requirements) are derived based on requirements and business domain. E.g., For a stock trading platform, Performance and Reliability are important ACs. For a news aggregation portal, Responsiveness is important - meaning it immediately loads the first 5 stories and loads the remaining stories asynchronously, so the user doesn't have to wait longer to start consuming the content. Implicit ACs: things that nobody will ask for but always expect like Security, Maintainability, etc. Available resources: budget (cost), skills, and time. Example: It is identified that writing a serverless function (AWS Lambda) is a good choice to perform some background tasks. NodeJS may be the right choice to write a serverless function but do we have the skills in the team to build it within the time we have to release the feature? We don't have NodeJS developers but we have Java developers, so is it possible to use Java to write a serverless function? Most Architectural Decisions are trade-offs. They have some bad outcomes, but still, it may be the for the given circumstances. If we can live with it, it is easier otherwise we have to try to mitigate its effects. E.g., right decision Writing a serverless function (AWS Lambda) in Java has the problem of because JVM takes at least a few hundred milliseconds to start up. Cold Start So we have the following options. Each has its negative impact but we have to select the one : right for current circumstances Since the functions will be used in background processing so we decide to live with a few milliseconds of a performance hit for now and revisit this later if it becomes a serious issue. In case we cannot afford a performance hit, we have to provision at least 1 (or more depending on load) Lambda instance to be active all the time. But this will add to the Cost. Train a developer on NodeJS and then write functions in NodeJS. But this will impact the timeline. Find an alternate to the serverless function. The output of Architecting: Documentation with reasoning and decisions. It can be diagrams, write-ups, specs, etc. Common artefacts: Components and relationships between them Shared libraries and interfaces Deployment view Security scheme - authentication, authorization, secrets management API Schema DB Schema Guidelines like naming conventions, exception handling practices, logging conventions, etc. Case Study Let's walk through the journey of an application to understand these concepts with an example. and discuss requirements. The product Manager (PM) Engineering Team (ET) Stage: Building MVP : We need to build a mobile app that will allow users to send SMS in bulk and check the status of the delivery. Users can manage a list of recipients by uploading a CSV or managing via the App. PM : Do we need to send an SMS for each request immediately upon receiving the request? ET : No, we don't have to do that now. We put the request in the queue and we process requests one by one. The expectation is that we will process it at least within an hour of the user submitting the request. This is MVP so we will keep it simple. PM : How will the user onboard and sign-in? ET : They will use their mobile number. We will send an OTP and verify the number. PM comes up with an architecture for MVP and produces artifacts. ET Components Deployment The architecting process would produce other artefacts like Database Schema, Security Scheme, etc., but we are only including things relevant to the discussion. 1 month after the MVP release : We have got an enterprise customer who is interested in using our services. PM : That's great! ET : They right now use another provider. They generate a CSV file with requests at a scheduled frequency. This file is uploaded to a shared location and the service provider processes the file to send messages. They are interested in trying out our service if they do not have to make any changes to their implementation. Can we make it work? PM : It should be possible. Let us think about it. ET comes up with a solution that can be implemented quickly. ET Components A new component is added that will read files and create requests from them. This was possible because core domain logic to manage requests, recipients, etc. was implemented in so it can be re-used easily from any part of the system. FileRequestService BulkSenderDomainLib Deployment What went well? Breaking down the system into modules allowed a new requirement to be accommodated very easily and quickly. This kind of requirement was not expected during MVP, but the Architecture was able to handle it. 6 months after the MVP : There is a lot of interest in our service. Customers want to use it but we are getting a lot of complaints that the messages are delivered after hours. PM : Because we are getting a lot of requests... ET : But we need to fix this. We also want to introduce a quick delivery paid plan. We think we will get customers ready to pay for an immediate delivery commitment. PM : That's going to require a lot of work. ET : Why..?? PM : We kept it for the MVP. We did not provision for scaling for the such load. ET simple : We better do it right now! PM What went wrong? . That is now causing a problem when the solution needs to scale quickly. This lapse can be costly because it can either force a half-baked solution in hurry or delay business plans. did not identify Scalability as AC\NFR in request processing in the original MVP architecture ET Should always design for scale even when they don't know what is going to be the scale? ET Its a : trade-off a. Building for scalability will add complexity to the solution meaning more time to release. b. On the other hand, there may be kind of problem we just went to through. . If MVP doesn't work, doing a quick release saved effort, so (b) would be the right thing. There is no right or wrong approach That's where the is required to find a balance between and working with all stakeholders. Architectural Decision Making Long Term Goals Short-term Needs In the end.. There is no universally accepted definition or scope of Software Architecture. It also evolves continuously with change in technology e.g., Cloud has added a lot of new possibilities that widen the scope of Architecture. We have tried to understand . And now if you go back and read all definitions of Software Architecture, you may understand them better. what can be considered Software Architecture Instead of exactly defining what is Software Architecture, it is important to get a good understanding of the and the . Process of Architecting Importance of making good architectural and design decisions This is a vast topic with various perspectives. A lot of the insights come with experience. I have presented my understanding. Please comment if there is anything you would like to add (or remove too :)). Thanks for reading! Journey from a Developer to an Architect Role is discussed in next part Software Architecture Basics: From Developer to Software Architect References by Robert C. Martin Clean Architecture by Mark Richards, Neal Ford Fundamentals of Software Architecture: An Engineering Approach by Simon Brown - Component Diagram uses C4 template C4 Model Also Published here
