Have you architected your product? Who is architecting it?
Some would say, “Yes, our tech team is doing it”. Some would say, “No, we are a start-up. We need to build fast, fail fast. So, no time for thinking architecture”.
To create a solution which is built to succeed and grow, one needs to architect it right by considering various aspects of user experience, technical scalability, business model and long term vision.
However, the word architecture is so strongly connected with technology in people’s minds that there is a confusion on who owns it, what all does it include and what is the right sequence to go about things. While actually, architecture has a much broader scope and encompasses different dimensions.
To disambiguate it, I present four key high level aspects of a product architecture that are required to be cracked in beginning before one goes to development.
I am taking a sample case to illustrate the meaning of each aspect. Sample case being “Building an application to let people manage their personal finances”.
Solution Architecture (or Solution Outline)
Having solution architecture assures you have a logically complete solution in principle. i.e. There is no logical fallacy or incompleteness. It would work. It would also have kept business and user objectives in mind.
E.g. Solution architecture in a personal finance application could be
- Objective of application is to let users manage and track their personal finances easily.
- Money would be made via freemium model.
- The kind of asset classes application would support e.g. Fixed Deposits, Mutual Funds, Equities etc.
- Form of application: On desktop as well as mobile app
- Will enable users to manage finances via portfolios.
- Users would be able to manage multiple portfolios
-
In each portfolio, ability to add their different asset classes
-
Ability to connect bank accounts to import transaction details
- Ability to manually add records of transactions
- Transactions
- Auto categorisation of the expenses
- Ability to manually add their personal expenses in their custom categories
- Analytics
- Ability to track progress of their portfolio
- Recommendations on portfolio actions
- Data sourcing
- APIs of Stock Exchanges.
- List of all the Mutual Fund Houses to be manually updated
What I have presented here is just a subset of what would be there. A complete document would talk about what context, purpose and approach for all the dimensions of business, technology and user experience. It would cover the data source, data output; kinds of technology components required; external applications support required; application components and other resources needed for product to function well.
This should be prepared by Business and Product Heads together after thorough analysis of market and users. Having tech head present during preparation of this helps in clarifying high level feasibility of some asks.
Technical Architecture
Technical Architecture assures that solution is built in such modules that product is scalable and efficient. It gives a clear picture to the tech team on
- What all entities are there
- How are they connected and interact
- What are their hierarchies
- What all databases would be required
- How will information flow and get stored within the application.
- What all modules need to be built
- High level decision on the technology that would be used
A very important point to keep in mind here is that entity relationships need to be in line with mental models of users.
In our case for example, we would have
- Entities required:
- Portfolio,
- Asset Classes,
- Transactions
- …
etc. with their respective characteristics
- <Relationships of various entities>: via an ERD or some such equivalent. e.g. Portfolio has different asset classes. Each asset classes further has different accounts and then each account has its transactions in it.
- <Fields of all entities>: Characteristics should be such that key constraints are met. E.g. Need to make sure that multiple portfolios, custom categories, different asset classes etc. are possible
- <A diagram depicting different modules and information flows>
This should be prepared by Product Head and Technical Head together. Having Product owner in this exercise is important because they bring the perspective of future scopes, what can be compromised and what not, and also to assure that entity architecture is in line with the mental model of the users.
This is really important part. A mistake in this part cripples product for long run, as then product later becomes unscalable, confusing and difficult to change. One can tweak business models or flows relatively easily, but not the underlying tech architecture. That is simply very expensive.
User Experience Architecture
Making solution good and easy for user is part of user experience. Building Information architecture is part of this exercise. User experience Architecture will answer following:
- What would be the mental model of users with respect to various entities (e.g. Portfolio has different asset classes. Each asset classes further has different accounts and then each account has its transactions in it)
- What would be landing screen and CTAs or outflows on it.
- What would be the navigation structure and hierarchy
- What user interaction model will be followed, e.g.
- Do we use card type view or table type view.
- Do we have tree type structure of information or flat.
- Do we build interface for users to input, or do we have file upload with pre decided format
- …
User Experience Design and Product Flow Design
Once these high level aspects are worked out, we go to the detailed flows and functionalities. e.g.
- Information hierarchy of each screen
- What would be the first time users’ experience
- What would be the flow of adding transactions/accounts
- What would be the flow of checking current portfolio break-up
- What level of information would be shown on what action
- What functionalities do we provide to users
- ….
Product owner and UX head are a must in building it. It helps to have these regularly reviewed by tech and business people too, to make sure you are not going way off track from business objectives or planning something that’s not technically feasible.
This last point is not actually the part of architecture, and more like a building block, but I have included it here, as it is part of “defining the product” and is important before development commences.
———————–
All these points are important to be taken care of for a solid product development, and contrary to intuitive feeling, these don’t increase development time, but reduce it. Planning well makes developers happier, reduces rework and prevent discarding of features.
Do not skip this hard work of thinking and planning the product well in the beginning due to bias for action (That feeling, “Why sit and keep thinking, while we can build something!”). That bias for action turns out to be very costly down the line. Plan well early, so that you can run fast with small cycles.
Also, even if you don’t do all these things explicitly, someone anyway ends up doing them, as without these you can’t build the product. Unfortunately, when product folks don’t own these steps, a developer ends up doing it at the time of writing the code, and needless to say, they would make mistakes as nobody has told them what is the long term plan of the product and how will it be used!
Happy developing!