Contents
Before we start development of a complex software we need to define what to build and why. We also need to know the guidelines that shape the answer of the question "How to build?". To answer the What, Why and How we need a defined architecture that helps us answer the questions. But what is the definition of the architecture itself? What is the guideline which needs to be followed to come up with the right architecture? Here I will talk about how we can define our architecture.
An exact definition does not exist. But we remember the well known problem space and solution space. We can start with this. The problem space helps us understand the problem and think about it carefully so that we can derive action items from there to solve the problem. In solution spaces we provide the most viable solution of the problem.
How do the problem and solution spaces connect with each other? The Process. In the Agile world of software development, we should not wait to gather all the information we need in the problem space so that we can start with a solution space. We should start with our solution space when we get the minimum information from the problem space required to start with the solution space. So there should be a Process which allows us to iterate over our problem space so that we can consume the new information in the problem space and incorporate it into our solution space. As time progresses our problem space becomes more concrete, we start understanding what exactly we want to solve. The process allows us to refine our solution space according to the changes in the problem space.
Problem Space - process - Solution Space
For example, we have an idea that we need to build a software that helps mitigate the carbon footprint of our day to day life activities. Now honestly this requirement is vague and scope is huge. It has been observed in part that a generic solution does not solve any problem well. First we need to narrow down the scope so that we can provide a specific solution. And we decided we will focus on the retail section of the market. Then we need to understand how exactly the carbon footprint in retail products is generated, who(product producer, seller , byer) generates the most? ,means defining our personas and stakeholders. Then we need to find how we can reduce the footprint. Then we need to think how we could earn money by selling our solution to the retail sector. As you can see here our problem space starts shaping from vague to concrete.
What is a problem space for software architecture ?
The problem space for an architect comprises the stakeholder, the business goal(s), the requirements (Functional and quality) and boundary conditions. From these sections architects extracts "Architecture Drivers" that drives the decision taken to provide a solution in the solution space. You not only need to model your solution space with architecture diagrams but you need to model your problem space also from the input sources.
Who are the Stakeholders?
Stakeholders can be external or internal.
External Stakeholders
When developing an Architecture first you need to listen to the existing or would-be customers, You need empathy for your customers for who you want to solve the problem. You need to understand their pain point, needs, requirements and wishes. So the customers for whom you build the software are the primary stakeholders.
Sometimes the software will be mainly used by the end users of your customer. Here your customer is an organization like a bank and end users are customers of the bank. So end users are also stakeholders.
Internal Stakeholders
Pre-sales and sales department
Your pre-sales and sales department is also your stakeholder because they deal with customers day to day and provide you insights on the drawback of the current software in use or problems customers face. Sometimes we use a presales team to do the final level of acceptance testing.
Management executives
Management executives are stakeholders because they are the people who make business decisions and define goals of the company or a large chunk of your organization. You need to convince them that the solution you are providing will address the problem and the architecture you provide will be futuristic and implementable and it will not have any major drawbacks during or after implementation.
Third party companies or partners
If you work within an echo system of third party companies who sell your product to build or partners who want to build on top of your product then they also become your stakeholders.
User Assistance group
Your User Assistance group who writes down the user documentation needs to be informed as early as possible. They need to understand the solution first. If you see they are asking a lot of questions then maybe the solution is very complex and the users will not be able to use it.
Support Teams
Support Teams who do customer support need to be involved because they need to understand the uptime/availability of the product (how much percent of the whole life cycle the product will be live? Or how much percent of a year?) and maintenance process and maintenance window. You need to think during failure how easily the failure can be detected and corrected. You need inputs from the customer support team because they will drive these scenarios and will be on the line of fire with customers.
Others
There could be Data protection aspects, Legal aspects, Cost(TCO - Total cost of ownership) aspects you need to involve all of them to avoid any breach.
If there are other applications who want to use your product as a reusable service also need to be consulted.
The infrastructure team who ensures the hardware and infrastructure and takes care of actual deployment of the software to the hardware also has an opinion on your product.
Last but not the least the developers, you need to make sure the developers understand and follow the architecture and can develop accordingly. The developers are deep into technology and implementation so they can provide you with some technical challenges you might face in the current architecture and you may need to modify your design accordingly.
After you have listened to all your stakeholders you need to keep in mind what is your business goal. How do you want to earn money from your product? or how will you want to keep your existing customers happy? Could be that you develop a product that provides additional functionality which is not the main product you sell to your customer but as an addition so that your customers are happy. For example when you sell financial products you can offer a free tax calculation self-service software.
In part 2 of the article we will know more about the Business Goals, the Business Requirements, the Boundary Conditions, the Solution Space and the Process.
Comentários