Hi Reader,

Visualizing a compelling, well-thought solution architecture in an hour is a great way to build architecture muscle and authority with your customer and in your organization.

It might also feel like an incredibly daunting task.

And that’s why I’ve spent some time in creating a tear down of the process that helps to create authority in a program, project or with a customer - literally overnight.

Today, I’m sharing this tear-down in 6 steps so that it is accessible for you.

Let’s get in.

Please feel free to write to me if you have any views w.r.t. any points below or about any specific topic that you want me to write upon in the coming weeks!

Outcomes of Solution

Figure out the outcome of the solution architecture as precisely as possible.

This is an area which most people ignore completely to start with. They set a vague goal to “create solution architecture”

Instead, you should define:

1. What the customer is trying to achieve
2. If revenue growth is the agenda - scalability is a major architecture concern
3. If partnership is in the charter, interoperability is a consideration.
4. Regulatory compliance drives security.
5. Progressive growth over a period of time = modular, service oriented, plug-and-play solution components will be needed.

Sometimes, there are multiple concerns but we need to define them first. This in turn will drive the focus of our solution architecture & design activities.

Solution Domains

Think about the business domain of the solution.

Here’s an example:

Bad way to think about a solution:

→ “It’s a auto-lending solution.”

Good way to think about it:

→ “It’s a auto-lending solution for individual finance, business lease, OEM partnership that covers sales, service, insurance, disposal services.”

Clearly defined business units, product/service life-cycle.

Starting point of Domain, Sub-domains will be established.

Architecture Patterns

Enter: Architecture Patterns

We don’t need to boil the ocean by getting into the implementation patterns at this stage. We should think about the overall solution construct through patterns.

To find your Architecture Patterns, ask yourself these questions:

1. How are the overall solution tiers arranged (layered architecture)
2. How is the data life-cycle managed (Lambda Architecture, Kappa Architecture)
3. How many types of integrations are involved (Hybrid integration architecture)
4. Is the deployment across private cloud (data center) and public cloud or across different commercial public cloud platforms
5. Is Cloud migration or re-platforming a significant part of the solution

Architecture pattern is not just about thinking of solution design or implementation. Architecture pattern thinking is also to be aware of the salient architecture concerns where we can consult experts to strengthen the solution architecture.

Consumption Channels

The primary goal of transforming the channels is to align a company’s digital capabilities with customer expectations and preferences, while also staying ahead of the competition in the digital age.

5 areas to think about-

1. What customer pain points we are resolving and opportunities to enhance the digital experience?
2. Do we need omni-channel integration - back-end services to orchestrate customer journey & maintain state?
3. Personalization as a service - how are we going to capture customer preferences and behavior in real-time?
4. Do we need integration of chatbots and AI technologies to streamline customer interactions?
5. How can we leverage insights from customer txn and behavioral data to inform decision-making and improvements in real-time?
6. What are the current volumetrics of customer journeys and upside projections?

Customer channels are drivers of many initiatives because they are the revenue generating components. Channels are the tips of the iceberg, the solutions are manifested to customer through channel but are implemented deep down in other layers.

Services

Event Storming takes time to identify all the services of a domain/subdomain for the first level of thinking. Instead when you read customer brief or RFP document, think about -

1. what domain components are already there - as existing solutions
2. which legacy solutions we have to live with
3. which legacy solutions must be re-engineered
4. which solutions don’t exist.
5. The state of legacy drives the service transformation. So it should be the starting point of our thinking.

Then ask yourself, if we are to bring in new solution components:

• what should be built?
• what can be bought?

You can go one level deeper to think (optional)-

• Which components can be modeled as microservices
• where should we use serverless

It is not mandatory to think about the implementation mechanism at the first pass but a thought would help in the approaches you will find later on.

Minimum Viable Foundation

As I said earlier, we should avoid being lost in details of implementation but think about the ways to kick-start the implementation. What are the building blocks of the solution that needs to be implemented in first few months/weeks - think about this as minimum viable foundation, consider the following

1. Hosting is one important aspect - do we need a new hosting platform because of re-platforming need?
2. Do we need-
   • cloud hosting
   • containerization platform
   • minimum viable hosting/platform setup right upfront?
3. Similar to this we need to think about the minimum viable components for-
   • data platform
   • integration platform
   • devops solution
   • observability (logging, monitoring, tracing)
   • security controls
   • automation.

Sometimes, minimum viable foundation platforms are an extension of existing setup - adding new capabilities to make the devops, observability (logging, monitoring), security of new stack (containerized services).

In Summary

Thinking through the first draft of a solution architecture might seem like a daunting task. But breaking it down into manageable steps makes it not just possible, but actually efficient and enjoyable.

And the best part about this is that it looks at different aspects of a solution without going too deep.

Remember: you are already doing amazing work as an architect.

There will be situations when you will be pulled in for damage control, to fill in for someone or turn around something within 24-48 hours. This process is your guide on that day.

That’s it for today.

Till next week.

Please feel free to write to me if you have any views w.r.t. any points above or about any specific topic that you want me to write upon in the coming weeks!