Book Image

Solutions Architect's Handbook

By : Saurabh Shrivastava, Neelanjali Srivastav
Book Image

Solutions Architect's Handbook

By: Saurabh Shrivastava, Neelanjali Srivastav

Overview of this book

Becoming a solutions architect gives you the flexibility to work with cutting-edge technologies and define product strategies. This handbook takes you through the essential concepts, design principles and patterns, architectural considerations, and all the latest technology that you need to know to become a successful solutions architect. This book starts with a quick introduction to the fundamentals of solution architecture design principles and attributes that will assist you in understanding how solution architecture benefits software projects across enterprises. You'll learn what a cloud migration and application modernization framework looks like, and will use microservices, event-driven, cache-based, and serverless patterns to design robust architectures. You'll then explore the main pillars of architecture design, including performance, scalability, cost optimization, security, operational excellence, and DevOps. Additionally, you'll also learn advanced concepts relating to big data, machine learning, and the Internet of Things (IoT). Finally, you'll get to grips with the documentation of architecture design and the soft skills that are necessary to become a better solutions architect. By the end of this book, you'll have learned techniques to create an efficient architecture design that meets your business requirements.
Table of Contents (18 chapters)

Engaging and working with stakeholders

Stakeholders could be anyone who has a direct or indirect interest in the project. As well as the customer and user, it may also be the development team, sales, marketing, infrastructure, network, support team, or the project funding group.

Stakeholders could 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 government.

Often, stakeholders have a different understanding of the same business problem as per their context; for example, a developer may look at a business requirement from a coding perspective, while an auditor may look at it from a compliance and security perspective. A solution architect needs to work with all technical and non-technical stakeholders.

They possess excellent communication skills and negotiation techniques, which help them to find out the optimal path for a solution while keeping everyone on board. A solution 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 solution 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.