Asking this question to a variety of professionals may lead to ten different answers for the definition of solution architecture. In fact, they may all be correct, within the context of a given organization's structure. Each organization may see solution architecture from a different perspective, based on their business needs, organizational hierarchy, and solution complexity.

In a nutshell, solution architecture can be described as defining and foreseeing multiple aspects of a business solution, from both strategic and transactional perspectives. "Strategic" means that a solution architect defines a long-term vision for a software application to ensure it stays relevant, regardless of future changes, with possible extensions to address increasing user workload and additional feature demand. "Transactional" means an application should handle the current customer workload and address daily business challenges without any issues.

Solution architecture is not just about providing a software solution. It covers all aspects of a system, which includes, but is not limited to, system infrastructure, networking, security, compliance requirement, system operation, cost, and reliability. As can be seen in Figure 1.1, there are many aspects that a solution architect may need to address.

Figure 1.1: Circle of solution architecture

A good solution architect addresses the most common aspects of the software solution in an organization:

• Globally distributed teams: In this age of globalization, almost every product has users distributed across the globe, and stakeholder groups to take care of customer needs. Often, the software development team has an onshore-offshore model, where a team works across different time zones to increase productivity and optimize project costs. Solution design needs to consider a globally distributed team structure. This means solution development and operation should not be people-dependent but utilize tools to scale and collaborate regardless of team members' work locations and time zones.
• Global compliance requirement: When you are deploying your solution globally, each country and region has its laws and compliance regulations, which your solution must adhere to. Some examples are as follows:
  • The Federal Risk and Authorization Management Program (FedRAMP) and Department of Defense Cloud Computing Security Requirements Guide (DoDSRG) for the USA
  • The General Data Protection Regulation (GDPR) for Europe
  • The Information Security Registered Assessors Program (IRAP) for Australia
  • The Center for Financial Industry Information Systems (FISC) for Japan
  • The Multi-Tier Cloud Security (MTCS) standard for Singapore
  • The G-Cloud for the UK
  • The IT-Grundschutz for Germany
  • The Multi-Level Protection Scheme (MLPS) Level 3 for China
• Compliance requirements are different between industries; for example, the International Organization for Standardization (ISO) 9001 (which is primarily for healthcare, life sciences, medical devices, and the automotive and aerospace industries), the Payment Card Industry Data Security Standard (PCI DSS) for finance, and the Health Insurance Portability and Accountability Act (HIPAA) for healthcare. Solution architecture needs to consider any compliance adherence in the design phase. You will learn more about compliance in Chapter 8, Security Considerations.
• Cost and budget: Solution architecture gives a good estimation of the overall cost of the project, which helps to define a budget. This includes capital expenditure (CapEx), which is the upfront cost, and operational expenditure (OpEx), an ongoing cost. It helps management to create an overall budget for human resources, infrastructure resources, and other licensing-related costs.
• Solution implementation component: Solution architecture provides a high-level overview of different implementation components of the product beforehand, which helps to plan execution.
• Business requirements: Solution architecture considers all business requirements, both functional and non-functional. A functional requirement addresses the application features that an end user will directly interact with. Non-functional requirements are not directly related to customer-facing feature enhancement, but impact the overall application in terms of critical factors, including performance, scalability, and availability. It ensures that business requirements are compatible, allowing them to be converted into the technical implementation stage, and strikes a balance between stakeholders.
• IT infrastructure requirements: Solution architecture determines what kind of IT infrastructure is required to execute the project; this includes computing, storage, network, and considerations, and helps to plan the IT resources more effectively.
• Technology selection: During solution design, a solution architect creates a prototype, which considers the corporate requirements, and then recommends the right technology and tools for implementation. Solution architecture aims to build in-house rather than third-party tool sourcing while defining software standards across the organization.
• End user requirements: Solution architecture pays special attention to the requirements of the end user who will be the actual consumer of the product. It helps to discover the hidden requirements that a product owner may not be able to capture. During implementation and launch, the solution architect provides a standard document and standard language structure in order to make sure that all of the requirements have been met to satisfy the user's needs.
• Solution maintenance: Solution architecture is not just about solution design and implementation, but also takes care of post-launch activities, such as solution scalability, disaster recovery, and operational excellence.
• Project timeline: Solution architecture designs the layout details of each component with their complexity, which further helps to define the project milestones and timeline by providing resource estimation and associated risks.

An industry-standard and well-defined solution architecture addresses all business requirements within a technical solution and makes sure to deliver the desired result in order to satisfy the stakeholders, as per their expectations in terms of the quality, availability, maintainability, and scalability of the solution.

The initial design of a solution architecture may be conceived at a very early stage during the pre-sales cycle, such as the request for proposal (RFP) or the request for information (RFI), and is followed by the creation of a prototype or proof of concept, in order to discover any solution risk. The solution architect also identifies whether to build a solution or to source it. It helps to identify the appropriate technology, while also keeping an organization's critical security and compliance requirements in mind.

There are two primary situations for creating a solution architecture:

• First, enhancing technology for an existing application, which may include hardware refresh or software re-architecting.
• Second, creating a new solution from the ground up, where you get more flexibility to choose the best fit of technology to address a business requirement.

However, while re-architecting an existing solution, you need to consider the minimal impact on the current environment. Solution architects may decide to completely rebuild if re-architecting the existing solution is not worth it, and a better solution can be provided through a full rebuild approach.

Put simply, solution architecture is about looking at all the aspects of the system in order to generate a technical vision, which provides steps to implement the business requirements. Solution architecture can define an implementation for a project, or a group of projects in a complex environment, by putting together all of the different pieces that are related to data, infrastructure, networking, and software applications. A good solution architecture not only satisfies the functional and non-functional requirements but also addresses system scalabilities and maintenance in the long run.

We have now briefly covered the role of solution architecture and its different aspects. In the next section, we will look at the evolution of solution architecture.