Contents
In part 1 of this article I discussed why it is important to define the architecture of a software product. What is a problem space and who are the internal and external stakeholders. In this part I will explain the Business Goals, the Business Requirements, the Boundary Conditions, the Solution Space and the Process.
What Could be the Business Goals?
Capturing market segment
Your company may want to capture the operations done by a market segment for example the Big companies in Retail and want to automate their operations by providing a cloud based software. By doing that your company can earn money.
Win industries or user groups
Your company has a product, similar to products from other companies. And your company wants to win the exciting industry and users who use the products from competitor companies. Your company wants to come up with a new product or upgrade your product that addresses the gap of the existing products. By doing that users can switch using the product your company has launched or planning to launch.
Sustainability
Sometimes you need to upgrade your existing product with new technology and capabilities so that your product does not get outdated in the fast moving world.
Retain customers
Your company wants to retain the existing customers and wants to keep them happy by providing new features in existing products or provide free service to an additional product/software/service.
Increase customer productivity
You and your team found out some pain points of your customer and want to enable your customer to run their business more efficiently and productively than before.
Reduce Total Cost of Ownership and Total Cost of Deployment
You want to reduce the TCO of the existing product and also want to reduce the TCD for your customer.
Brand Promotion
The aim of the new product that you are developing the architecture for might be just to provide a new free solution to the customer so that the brand of your company gets attention from customers.
Competitive advantage over rival companies
You are in fear that if you do not do enough innovation in your product your rival will do it and take away your customer and market share.
All these business goals can impact your architecture decision you make in your solution space. For example, if the goal is for brand promotion by providing free software you might not consider that your software scales when thousands of users use the product at the same time, so you deprioritize the scalability aspects. But you put high effort on the performance aspects of the product because even if it's a free product, if it's not fast and responsive enough your company's brand name will be belittled. You might have medium priority on quality topics because quality of the product is important for reputation but implementing quality in the product also increases development cost and TCO.
What will be the Requirements?
Requirement from Customer
requirements often come from the stakeholders but not necessarily. Many times the users and customers are not sure what exactly they want or how their problem could be solved. Then as a software company you need to think about what you want to build to solve the problem and what functionalities you will need.
Customer Acceptance test
You developed a feature or a whole new software product and in the later stage of software development you asked your Customer to do a user acceptance test and provide feedback. From the feedback you identify that you need to incorporate capabilities or functionalities in your software.
Interview of your Customer/User
before we come up with a solution we need to verify what are the problems we want to solve or whether our assumptions are correct. Interviewing your customer or end user is the best thing for that.
Product Specification
Your company may have some specification and guidelines. You need to conform with those specifications, for example all cloud products should have 98% availability. This becomes a quality topic for the cloud software and for the architecture of the software.
Change in Law
A change in IT law in your country of operation also triggers some requirements for example Global Data Protection Regulation(GDPR) . A law change by the government also can generate a software requirement, for example if you are selling an insurance product and govt. Says that the insurance premium of your Household insurance can be reduced or increased based on how much carbon footprint your house produces and as an insurance provided you need to have this provision. As this is a new aspect in household insurance now you need to think how to add this new feature in your insurance calculation and how to fetch the carbon footprint for an individual that is calculated and published by a non-profit organization or by the government. Organization itself. Certainly you are going to automate it and some of your services need to communicate with a third party product or web site to extract the carbon footprint when your software calculates the insurance premium. As an architect you need to think about how to make communication and automation happen.
Change in software security
An example could be, your company decided to apply multi factor authentication to the login workflow of your cloud application to provide more security which creates requirements in your product and architecture.
Customer created support issues
From the customer reported incident you realize that you need to make a fundamental change in the architecture so correctly address the issue.
Service Level Agreement
Upgraded SLA for downtime and maintenance window for greater availability.
Industry standard
Your company adopted the new version of industry standard which needs to be reflected in all the products of the company.
Technical guidelines, Experts, partners, User groups, Consultants
Sometimes as an architect or business specialist or a subject matter expert or a technical expert you can think a bit ahead of time and know where the future is. From your foresight you could derive some requirements for example the software should have ML capabilities. Or, you know you need to integrate your software with other source products to bring in more capabilities, which means you need an standardized API and extendable architecture.
Everyone speaks about functional requirements but it's your job as an architect to remind people about non-functional requirements and the quality attributes.
What are non-functional requirements?
Scalability | Maintainability | Accessibility | Usability |
Extensibility | Longevity | Availability | Reliability
|
Robustness | Simplicity | Performance | Portability |
Stability | Functionality | Operability | Portability |
Uniformity | Security | Compatibility /interoperability | Completeness of features |
Cost effectiveness
| Deploy ability
| Understandability- Readability of code | Resilience |
The Problem and the Context( The Boundary Conditions)
Without a context you can't pen down a problem specific enough to be taken action upon. You need to know the context of your problem. Because a problem can be very generic, that way your domain of problem and solution will be vast and will generate many requirements and many people to satisfy. It will be hard to implement a solution. It's a good idea to define the context so that you can define what is in-scope and what is out of scope.
When you make these decisions and define the context the below boundary condition influences you.
Time. Within how many months you want the first version of the product to be in the market. This is needed because you can't develop a software for too long without getting any revenue from it. Maybe you need to cut down some requirements to release it to the market fast. When technology is evolving rapidly and requirements are changing faster it's more important than ever that you launch the product with a new idea faster.
Budget. How much you are willing to spend to develop and maintain the product is one of the most important elements that decides the boundary conditions.
The Resources and Skills of developers available to your organization and technical and non-technical knowledge of the people with whom you are going to build the solution is also an aspect you need to consider.
The Technology and Infrastructure available in your company that can be used or can be quickly acquired is also sometimes a constraint.
Whether there will be any legal obligations like Data Protection and Privacy in general and specific to the industry in which you are building the product. Many times there are specific asks from the customer they would like to adhere to.
Release plan. When you need to release the product in the market could be crucial. Due to market pressure or to gain competitive advantage you might need to release the product fast. There could be phase wise enhancement plans that have to be in place using which you want to reach out to different market segments or personas phase by phase. On the other hand you might want to see how well the product is received by the target audience before investing a lot into the product. The architecture should also be developed keeping the release and phase wise plan into mind.
When you have dependencies to other development organizations within or outside of your company then you need to think about how those dependencies can be incorporated to your design technically and also how the communication aspect of the project can be handled. You also need to design to handle the faulty behavior of the dependencies as you will have little influence over how they are architect and how they behave in various corner cases.
You also need to think who are the people going to use the product. That means you need to know your target audience and personas well. This can affect the architecture very much. For example, if the target audience is tech savvy you can introduce few functionality that the users will appreciate, but otherwise a regular user might think it is of little use for them.
Architecture Drivers
All of the above that we discussed so far could be an input for your architecture, meaning your architecture driver.
You need to prioritize them and make a decision which among them you want to make the main drivers and why. As this is a major decision point you also should document your decision and the reason behind. This will answer the questions of the people who search for this question in years to come.
What is a solution space for software architecture ?
The solution space is where you think how you would like to address the problem(s) identified in the problem space.
You need to build a cheap prototype so that you can test your assumption and get early feedback from stakeholders.
You need to model your architecture using UML and provide the design and consult stakeholders regarding the architectural designs you have made. You need to divide the architecture into small work packages so that they can be developed relatively independently by an individual developer or a team.
At the end you take the architecture decision about what the software should look like.
You need to make tradeoffs between different quality attributes, as many of them are always opposing each other. Often there are multiple solutions possible, you should write down all of them. You should write down the tradeoffs between them. You need to think and write down what are the risks that might come in future because of the tradeoffs and the solution option you have chosen. You also need to find out what will be the consequences of when the risks occur. Your boundary condition may also force you to agree to some tradeoffs. For example, you know a very good library is available in python to address certain ML algorithms but you don't have all JAVA developers, you have to use the not so superior Java library. A particular Cloud Infrastructure provider has certain capabilities but it's too costly or your company can't provide the infrastructure because your company doesn't have any business relationship with the provider at the moment.
You need to evaluate and assess the decision that you have taken. If you find any early problems or road blocks you might need to work on your architecture and refine it. You also need to do a lot of Proof Of Concept implementations to find any major roadblocks. The main idea of prototyping and proof of concept is you put the solution within the context (that you have identified) and verify whether the solution works within the context.
What is a process for software architecture ?
A process keeps the information flowing from problem space to solution space and vice versa, When you find your solution does not work in the context then you can build a new solution but you might want to revisit the context you set because sometimes your solution is correct but the context you defined has discrepancies or the insight you have drawn by studying the problem is not correct. A process also makes it possible that you take some actionable items both in your problem and solution space. Without a process you might not be able to manage everything efficiently but remember a cumbersome process can destroy the work itself.