We live in an era where people seem to give titles and labels to everything, not just IT, but IT is a jungle! Systems designer, Systems analyst, Application support analyst, IT manager, IT coordinator, Solutions Architect, Web designer, Web development project manager, User interface (UI) designer, Webmaster, UX/UI specialist, SEO manager, Front-end developer, Back-end developer, Full-stack developer, Technology manager, Technology assistant, Business systems analyst, Information security engineer, Computer forensic investigator and so many more! And then we have that fancy one like Chief Digital Officer (CDO), Digital Transformation Specialist, Technology Evangelist, Chief Innovation Officer (CIO), Cybersecurity Ninja, Data Scientist, DevOps Guru, and the list is endless. Personally, I don’t like titles, and I consider myself an Enterprise Integration Consultant, which means that depending on the client’s needs, I can have different responsibilities. I can perform simple developer tasks or more responsible tasks like architecture and guidance.
By reading this book, the first impression I got was that the author was defending and/or selling the Solution Architect title almost as the mastermind behind everything, bordering on arrogance by using sentences like:
- “That is when an SA has to switch to their guardian angel hat and come to the rescue.”
- “That being said, SAs are not called guardian angels just for defending the developers but also are of great help if the team is short of hands…”
- “As the name itself suggests, SAs have ownership of their solution, It’s creation. They designed it and they will be the ones who will have the final say.”
- “As the SA, you won’t think about why you should do this, but you know that you are the only one who has to do it”
- “… you have to be involved in the day-to-day operations of development, testing, user acceptance testing (UAT), and deployment phases.”
- “…you will face some situations where developers are frustrated to know you design a solution the way you did, …”
And many more. The reality is that some of these behaviors and sentences do not correspond to reality or the best way to approach and bring a solution to a successful conclusion. And to be honest, if I have to sell my “title” like this, probably the client won’t need me…
However, abstracting from this somewhat arrogant behavior, in my opinion of the author about the highly inflated profile of an SA, the book touches on some very interesting points in the life cycle of a solution and to each intends to become a solutions architect or a project manager. And although in certain parts the author particularizes the text for RPA solution, as well as the name of the book mentions, in my opinion, most of the book is written generically. An Enterprise Integration solution architect or a BI solution architect has to have the same concepts, responsibilities, and skills as an RPA solution architect.
Even so, for those who want to be responsible for the management and architecture of solutions, it is a pleasant book to read. However, be more humble, try to integrate all those involved in the decisions on solutions, and make them part of the project. If people have a sense of belonging, they give 100%.
RPA Solution Architect’s Handbook Book Description
RPA solution architects play an important role in the automation journey and initiatives within the organization. However, the implementation process is quite complex and daunting at times. RPA Solution Architect’s Handbook is a playbook for solution architects looking to build well-designed and scalable RPA solutions.
You’ll begin by understanding the different roles, responsibilities, and interactions between cross-functional teams. Then, you’ll learn about the pillars of a good design: stability, maintainability, scalability, and resilience, helping you develop a process design document, solution design document, SIT/UAT scripts, and wireframes. You’ll also learn how to design reusable components for faster, cheaper, and better RPA implementation, and design and develop best practices for module decoupling, handling garbage collection, and exception handling. At the end of the book, you’ll explore the concepts of privacy, security, reporting automated processes, analytics, and taking preventive action to keep the bots healthy.
By the end of this book, you’ll be well equipped to undertake a complete RPA process from design to implementation efficiently.
What you will learn
- Understand the architectural considerations for stability, maintainability, and resilience for effective RPA solution design.
- Interact with cross-functional teams for seamless RPA implementation.
- Write effective RPA documentation, non-functional requirements, and effective UAT scripts.
- Demo RPA solutions, receive feedback, and triage additional requirements based on complexity, time, and cost.
- Design considerations for intelligent automation and learn about RPA as a service.
- Explore best practices for decoupling, handling garbage collection, and exception handling.
Who is this book for
This book is for RPA developers, RPA Sr. developers, or RPA analysts looking to become RPA solution architects. If you are an RPA solution architect, this book can help you advance your understanding and become more efficient. Familiarity with RPA documentation like SDD, and PDD, along with hands-on experience with either one or more RPA tools, will be helpful but is not mandatory.
