❓ What is the role of a Solution Architect 👉 Session follow-up discussion

Hello all!
We are opening this thread to follow-up on our UiPath Community Paris session today: What is a Solution Architect?
The chat discussion was extremely engaging and the time did not allow us to continue taking questions and delivering answers. As promised, we open up this conversation space so that all of you can dive deeper on the subject, while exploring and getting the answers that will bring added value and clarity.

:pray: Remember that Forum is a space for giving and receiving, so please do engage in the discussion and provide answers to any questions you can address. Together, we get more answers and find the best solutions.

UiPath Community Paris Meetup: What is a Solution Architect?
What is a Solution Architect: session saved chat discussion: chat.txt (2.5 KB)
RPA Developer Blog: Role of a Solution Architect in RPA
UiPath Academy: RPA Solution Architecture Fundamentals
UiPath Academy: RPA Solution Architect Advanced


I have watched and love it. Thank you so much.

I want to know how do you guys manage documentation PDD/SDD/DSD when process needs to be divide in subprocess (e.g. Read System Source, insert data into queue to other automation do the job - performer). currently we are using Automation Hub to centralize ideas and calculation ROI based in individual automation.

So, for automation that we need to divide into n RPA, we divide in N individual ideas and measure individual metrics for each RPA. But it takes a lot of work create documentation (PDD, SSD etc for each automation)

1 Like

Great :slight_smile: this is going to be helpful at anytime

Very insightful diccussion

Hello @rikulsilva

Very good question.

There can be different approaches to this. What I do usually is the following.
Whether we use the Automation hub or not, we kind of have all sub-processes documented as one. Let’s say for example, a particular business use case has three sub-processes. The PDD mostly contains the as-is and the to-be process in high-level with minimal technical content. The reason for that is, it is a business-focused document.

Regarding the SDD/DSD, we include all sub-processes in the same document. We showcase how the overall process looks like, and then have diagrams of how each sub-process is designed.

It takes a while to create these detail, but this is what our clients expect as well. Some of the clients even expect this level of detail way before starting the development.


Hi @Lahiru.Fernando

That sounds good.

I’m currently studying a way to take in consideration automation good practices and automation circle, but for us its a little difficult. In my company, CoE team is under IT Department. So we need follow IT Governance (e.g it’s necessary get rpa approval in IT committee) and Business needs and to make matters worse, we have External Sox Audit yearly. For Sox Compliance understanding, RPA influences company revenue.
This way, docs need achieve IT, Sox Compliance and business needs.

And for ROI calculation, having one rpa for process it’s easy to calculate. But if we divide it, I wondering how to make the delivered FTE calculation easy without need divide FTE by subprocess too (we mapped rpas logs with automation idea in AH)

In my approach, the way of how we document depend on the size of the process, its ownership, clarity of happy path, goals, products and automation workload - which often turns out crucially as we want to deliver results fast. So we shouldn’t limit ourselves to the current definition in a given organization, but rather make a division according to chances for quick wins.

Because, after all, according to Porter Value Chain, a process is both a macro-process and its minor component at the sub-process level. And yet we can also robotize activity sets separately. So a process definition itself is very elastic.

We usually call something around 2-3 BPM the “process”. Of course, it depends on how the client defines the process and we include in the analysis all aspects mentioned in the first paragraph, but as I wrote above - this limit is only in our head. Automation is the excellent moment to reenginering and optimization.

In practice, we are trying to divide “processes” above 60 MD into subprocesses from the point of view of work planning and faster delivery of first RPA benefits.

From the documentaion point of view, we are trying to document sub-processes (similar in nature of activities of the path of the same process, with one goal, leading to similar work products under one process owner) together and if we extend the process contained in one document with subsequent paths, we do it as part of the Change Request procedure.
On the other hand, we document separately processes, which clearly differs in the nature of activities, purpose, products or has different owners.

In the case of sub-processes documented together, we are talking de facto about different paths of the same process, so we make a business case for the whole process, and then we divide it into happy path, other main paths (if they have a significant share in the task volume) and remaining paths we count collectively as the Other.
Then the Pareto principle applies and we focus on the automation of subsequent paths, according to their importance, leaving sparse paths clearly as a collective issue - what is left after the total estimates and subtracting the happy path + 1-2 significant paths. So it is easy to prepare a business case per path for what is important.

Then, within one document, we make a detailed description (business values, risks, map and flow) for what is planned for implementation, with only a general indication of the rest.
For example, process flow, is accurate for paths which are subject to automation, with an indication of the places where the branch takes place. We treat it as the end of automation and variants that are not subject to it, apart from their briefly marked existence and the collective counting of the business values on a residual basis, are not marked in the RPA documentation.

For the purposes of compliance/audit, etc., we assume that they remain in manual implementation, and therefore the responsibility for them and theri documentation is on the side of the business owner, as before.
From the existing documentation (process cards, procedures, instructions, control tools, etc. before automation) we extract only what changes and document it in the RPA documentation.


In addition with what Lahiru detailed. We suggest to follow swim lane diagrams (Even Task capture now support this) for high level and low level details. Refer this diagram in PDD and SDD for easy navigations. Slowly this diagram become bible when it cover L4 steps.


1 Like

@rikulsilva, Interesting! have you checked the ROI dashboard from Insights (Business ROI)?. Also, it provides some flexibility on calculation (ROI Dataset).


@balaraman.ramiya, not yet. We’re reorganizing the CoE structure, separating into 3 fronts, Discover, Architeture, Development.

I took notice to discute it with team.

Thanks for sharing

@jdomanski, thanks for sharing

I totally agree with you

We’re continue working to change Organisation mindset about RPA solutions. We already got some flexibility and the next action we’re planning is change our documentation.

But is a century-old company and CoE is a little baby with 2 years. We will get there with patience and feet on the ground


ok, I would suggest to review this course for Governance. (If you have not done already) Introduction to the Automation Operating Model.
This will help to set and align industry practice.