Understanding a solutions architect’s responsibilities

Now that we have broken down the various roles of a solutions architect, we will next take a look at the details of the responsibilities of a solutions architect. A solutions architect is a technical leader in a customer-facing role, which comes with many responsibilities. The primary responsibility of a solutions architect is to convert an organization’s business visions into a technical solution and work as a liaison between businesses and technical stakeholders. A solutions architect uses broad technological expertise and business experience to ensure the success of the solution’s delivery.

A solutions architect’s responsibilities may differ slightly based on the nature of the organization. Often, in a consulting organization, a solutions architect may be dedicated to a particular project and customer, while in a product-based organization, a solutions architect may be working with multiple customers to educate them on a product and review their solution design.

A solutions architect carries various responsibilities at different stages of the application development cycle, even before the project is kicked off. During the project incubation phase, the solutions architect works with business stakeholders to prepare and evaluate the request for response (RFR) document.

Once a project is kicked off, the solutions architect analyzes the requirements to decide on the feasibility of technical implementation, while defining NFRs such as scalability, high availability, performance, and security. A solutions architect understands various project constraints and makes the technology selection by developing a POC.

Once development starts, the solutions architect mentors the development team and adjusts both technical and business needs.

After the application has launched, the solutions architect makes sure that the application performs as per the defined NFRs, and identifies the next iteration based on user feedback.

You will learn more about the solutions architect role at various stages of the product development life cycle in this section. Overall, a solutions architect holds the following primary responsibilities, detailed in Figure 1.3.

Figure 1.3: A solutions architect’s responsibilities model

As shown, there are various significant responsibilities for a solutions architect. In the following sections, you will learn about the various aspects of the solutions architect’s responsibilities.

Analyze functional requirements (FRs)

At the onset of any project, defining business requirements is fundamental to solution design. These requirements, initially presented in basic form, necessitate the involvement of a varied group from the start, including those with technical expertise, to accurately identify and understand these requirements. Business stakeholders initially set these requirements, but as the project technologically evolves, frequent adjustments are often required. This is where the role of a solutions architect becomes pivotal, not just in designing the application but also in shaping the overall business outcome.

Solutions architects go beyond technical expertise, integrating deep business insights to align technology with business goals. They work closely with product managers and stakeholders, bridging FRs with technical solutions and becoming trusted advisors. Their role is crucial in visualizing the end product and its implementation, guiding projects to not only meet technical specifications but also fulfill strategic business objectives and meet user expectations.

In essence, the role of a solutions architect transcends traditional boundaries of technical expertise. They are pivotal in bridging the gap between technical possibilities and business realities, ensuring that the final solution not only adheres to technical specifications but also delivers real business value. Their ability to work with a diverse set of stakeholders, understand the nuances of business needs, and foresee potential challenges makes them indispensable in the journey from conceptualization to the realization of a project. The success of a project often hinges on their capacity to translate complex requirements into a coherent, functional, and efficient solution architecture.

FRs specify what a system should do, detailing the behaviors, functions, and features the application must support. They are directly related to the user interactions and tasks the application will perform. NFRs, on the other hand, define how a system performs certain functions, outlining the system’s quality attributes, such as performance, usability, reliability, and security. These requirements describe the system’s operation conditions and constraints that affect the user experience but not the specific behaviors. Let’s learn more about NFRs and how solution architects help to uncover them.

Define NFRs

NFRs may not be visible to users and customers directly, but their absence may impact the overall user experience in a negative way, and hamper the business. NFRs include critical aspects of the system, such as performance, latency, scalability, high availability, and disaster recovery. The most common NFRs are shown in Figure 1.4:

Figure 1.4: NFRs in a solution design

In relation to NFRs, solutions architects ask themselves the following questions:

• Performance:
  • What will the application load time be for users?
  • How can we handle network latency?
• Security and compliance:
  • How can we secure an application from unauthorized access?
  • How can we protect an application from malicious attacks?
  • How do we adhere to local laws and audit requirements?
• Recoverability:
  • How can we recover an application from an outage?
  • How can we minimize recovery time in the event of an outage?
  • How can we recover lost data?
• Maintainability:
  • How can we ensure application monitoring and alerts?
  • How can we ensure application support?
• Reliability:
  • How can we make sure the application performs consistently?
  • How do we inspect and correct glitches?
• Availability:
  • How can we ensure the high availability of an application?
  • How can we make an application fault-tolerant?
• Scalability:
  • How can we meet the increasing demand for resources?
  • How can we accommodate scaling for a sudden spike in utilization?
• Usability:
  • How can we simplify an application’s use?
  • How can we achieve a seamless user experience?
  • How can we make the application accessible to a diverse set of users?

Depending on the nature of the project, however, there may be certain NFRs that are suitable only for that particular project (for example, voice clarity for a call center solution).

You will learn more about these attributes in Chapter 2, Principles of Solution Architecture Design.

The solutions architect becomes engaged in a project from a very early stage, which means they need to design a solution by gauging requirements across the stakeholders within an organization. The solutions architect needs to ensure consistency in solution design across system components and requirements. They are responsible for defining NFRs across these different components and across different groups since they make sure that the desired usability of a solution is achieved across the board.

NFRs are an integral and essential aspect of solution design that tends to slip when teams are too focused on business requirements, which can impact the user experience. A good solutions architect has the primary responsibility of conveying the importance of NFRs and ensuring that they are implemented as part of solution delivery.

Understand and engage stakeholders

A stakeholder is anyone who has an interest in the project, whether directly or indirectly. As well as the customer and user, stakeholders may also be the development, sales, marketing, infrastructure, network, or support team, or the project funding group. Stakeholders can also be internal or external to the project. Internal stakeholders include the project team, sponsors, employees, and senior management; external stakeholders include customers, suppliers, vendors, partners, shareholders, auditors, and the acting government of a country.

Stakeholders often have a different understanding of the same business problem as per the context they find themselves in; for example, a developer may look at a business requirement from a coding perspective, while an auditor may look at it from one of compliance and security.

A solutions architect’s role involves working with both technical and non-technical stakeholders to ensure the success of a project. They need to understand the project requirements from various perspectives, which necessitates engaging with a diverse group of stakeholders. This includes translating complex technical concepts for non-technical stakeholders and ensuring the technical team understands the business objectives. By collaborating with all involved parties, the solutions architect ensures that the technical solution aligns with the broader business goals. This broad collaboration is essential for developing a comprehensive and effective solution that meets everyone’s needs.

Solutions architects possess excellent communication skills and negotiation techniques, which help them to ascertain the optimal path for a solution while keeping everyone on board. A solutions architect works as a liaison between technical and non-technical resources and fills the communication gap. Often, those communication gaps between a businessperson and the technical team become a reason for failure. The businessperson tries to look at things from more of a feature and functionality perspective, while the development team strives to build a more technically compatible solution, which may sometimes lean toward the non-functional side of the project.

The solutions architect needs to make sure both teams are on the same page, and that the suggested features are also technically compatible. They mentor and guide the technical team as required and put their perspective into simple language that everyone can understand.

Understand architecture constraints

Architecture constraints are one of the most challenging attributes of solution design. Architecture constraints significantly challenge solution design because they limit flexibility and innovation. Ensuring new solutions are technically compatible with existing systems within these constraints requires considerable effort and resources. Additionally, constraints related to budget, resources, and timelines can impact the quality and scope of the solution. Complying with industry standards and regulatory requirements while meeting functional needs is a delicate balance to maintain.

A solutions architect needs to manage architectural constraints carefully and be able to negotiate between them to find an optimal solution. Often, these constraints depend on each other, and emphasizing one limitation can inflate others. The most common constraints are presented in Figure 1.5.

Figure 1.5: Architectural constraints in a solution design

The solution design should consider the following constraints:

• Cost:
  • How much funding is available for solution implementation?
  • What is the expected ROI?
• Quality:
  • How closely should outcomes match FRs and NFRs?
  • How can we ensure and track the quality of the solution?
• Time:
  • When should the output be delivered?
  • Is there any flexibility regarding delivery time?
• Scope:
  • What are the exact expectations from business and customer requirements?
  • How does the requirement gap need to be handled and accommodated?
• Technology:
  • What technology can be utilized?
  • What flexibility does using legacy versus new technologies provide?
  • Should we build in-house or source from a vendor?
• Risk:
  • What can go wrong and how can we mitigate it?
  • What is the risk tolerance of stakeholders?
• Resource:
  • What is required to complete solution delivery?
  • Who will work on the solution’s implementation?
• Compliance:
  • What are the local legal requirements that might impact the solution?
  • What are the audit and certification requirements?

A solutions architect needs to balance constraints and analyze the trade-off of each; for example, saving costs by reducing resources may impact the delivery timeline.

Achieving a schedule with limited resources may affect quality, which in turn increases costs due to unwanted bug fixes. So, finding the balance between cost, quality, time, and scope is significant. Scope creep is one of the most challenging situations that a solutions architect may be faced with, as it can negatively impact all other constraints and increase the risks to solution delivery.

Scope creep refers to the gradual expansion of a project’s objectives and deliverables, often without corresponding increases in resources, time, or budget.

It is essential for a solutions architect to understand all the aspects of every constraint and to be able to identify any resulting risk. They must put risk mitigation plans into place and find a balance between them. Handling any scope creep can help a lot in delivering the project on time.

Make technology selections

Technology selection is the key aspect of a solutions architect’s role and may involve the most complexity. There is a broad range of technologies available, and a solutions architect is required to identify the right ones for the solution.

The solutions architect needs to have breadth and depth in their knowledge of technologies to make the best decision since the chosen technology stack can impact the overall delivery of the product.

Each problem can have multiple solutions and an available range of technologies. To make the right selection, a solutions architect needs to keep FRs and NFRs in mind, and define selection criteria while making a technology decision. The selected technology needs to consider different perspectives, whether the goal is the ability to integrate with other frameworks and APIs or to meet performance requirements and security needs.

A solutions architect should be able to choose the technology that not only satisfies current requirements but also scales for future needs.

Develop a POC and prototype

Creating a prototype is probably the most fun part of being a solutions architect. To choose a proven technology, a solutions architect needs to develop a POC in various technology stacks to analyze their fit for the FRs and NFRs of the solution. The solution design POC is when a solutions architect is trying to figure out the building blocks of the solution.

The idea of developing a POC is to evaluate technology with a subset of critical functional implementations, which can help us decide on a technology stack based on its capabilities. It has a short life cycle and is limited to being reviewed by experts within a team or organization.

After evaluating multiple platforms using a POC, the solutions architect may proceed with prototyping to a technology stack. A prototype is developed for demonstration purposes and given to the customer so that it can be used to secure funding. POCs and prototyping are far from being production ready; solutions architect builds have limited functionality, which can prove to be a challenging aspect of solution development.

Solution design and delivery

Solutions architects work on solution design after understanding different aspects of FRs, NFRs, solution constraints, and technology selection. In an agile environment, this is an iterative approach where the requirements may change over time and need to accommodate the solution design.

The solutions architect needs to design a future-proof solution, which should have strong building blocks and be flexible enough to adjust to changes that can occur due to user demands or technology enhancements. For example, if the user demands increase ten times, then an application should be able to scale and accommodate user demands without significant changes to the architecture. Similarly, if new technology, such as ML or blockchain, gets introduced to solve a problem, your architecture should be able to accommodate them; for example, using AI to build a recommendation system on top of existing data for an e-commerce application.

The solutions architect needs to be careful about drastic changes to the requirements and apply a risk mitigation plan.

For future-proof design, you can take the example of a loosely coupled microservice architecture based on RESTful APIs. These architectures can be extended to new requirements and have the ability to integrate easily. You will learn more about different architecture designs in Chapter 4, Solution Architecture Design Patterns, and Chapter 5, Cloud-Native Architecture Design Patterns.

Ensuring post-launch operability and maintenance

The solutions architect plays an integral role after the solution’s launch with respect to product operability. To handle the increasing user base and product utilization, a solutions architect should know how to scale the product to meet demands and ensure high availability without impacting the user experience.

In unforeseen events such as outages, a solution architecture guides infrastructure, IT support, and software deployment teams to execute a disaster recovery plan for business process continuation. The solutions architect satisfies the organization’s RPOs and RTOs. RPOs define how much data loss an organization can tolerate in terms of the volume of data lost during the outage interval—for example, a loss of 15 minutes of data. RTOs define how much time the system should take to get back up and running. You will learn more about RTOs and RPOs in Chapter 11, DevOps and Solution Architecture Framework.

In the event of performance issues due to an increase in demand, the solutions architect helps scale the system horizontally to mitigate application bottlenecks, or vertically to alleviate database bottlenecks. You will learn more about different scaling mechanisms and self-healing in Chapter 8, Architectural Reliability Considerations.

The solutions architect plans to accommodate any new requirements in an existing product that arise from usage patterns or for any other reason. They can make changes to NFRs based on monitoring user behavior; for example, users may leave a page if it takes more than three seconds to load. The solutions architect works through this and guides the team in handling issues that may occur post release.

Solution scaling and technology evangelism

Being an evangelist is the most exciting part of the solutions architect role. The solutions architect increases product and platform adoption by spreading the word through public forums. They write blogs about solution implementation and conduct workshops to showcase the potential benefits and the use of technology platforms.

They build mass support for technologies and help establish a standard. A solutions architect should be passionate about technology. They should be an excellent public speaker and possess excellent writing skills to perform the technology evangelist role.