How to define the Architecture of a Software? (part 2)

---

Contents

• Business Goals

• Capturing market segment

• Win industries or user groups

• Sustainability

• Retain customers

• Increase customer productivity

• Reduce Total Cost of Ownership and Total Cost of Deployment

• Brand Promotion

• Competitive advantage over rival companies

• What will be the Requirements?

• Requirement from Customer

• Customer Acceptance test

• Interview of your Customer/User

• Product Specification

• Change in Law

• Change in software security

• Customer created support issues

• Service Level Agreement

• Industry standard

• Technical guidelines, Experts, partners, User groups, Consultants

• What are non-functional requirements?

• The Problem and the Context( The Boundary Conditions)

• Architecture Drivers

• What is a solution space for software architecture ?

• What is a process for software architecture ?

---

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 w