The gist of it is: RPA Patterns is a site that teaches you useful real-world knowledge about different aspects of RPA projects, with a focus on UiPath (more on this later).
Fair warning: This will be a long post. Feel free to skip parts and revisit them later by using the collapse buttons on the left-hand side. Or see the Short Version.
Note that the date for this post is a bit misleading as it reflects when I started working on RPA Patterns. Because I have a pronounced tendency to give up on projects, and nobody needs yet another “blog” with a single post, I decided not to launch it immediately, but work on some meaningful starter content instead. I kept the original date because some of the overview pages are reverse-sorted by date and I want this post to always be the last in the list.
This took longer than expected (I do have a day job and other things to take care of, you know), so I am editing this in January 2021. You may be happy to learn, however, that I have already spent well over 100 hours generating content and the sunk-cost effect is likely to compel me to continue for a while. Imagine you’d have to pay for all that training! If that doesn’t make you happy, I don’t know what will!
Let’s delve into what RPA Patterns is actually about. The four types of content it aims to provide are:
- A Blog about what’s currently going on in the RPA world and with RPA Patterns
- Patterns, i.e. recurring themes that you might see in projects and articles focused on narrow topics
- Guides: how-tos, application deep-dives, and articles focused on broad topics
- Videos, as RPA is a very visual technology, seeing how something is developed can often be more helpful than a thousand words written about it
The target audience for RPA Patterns are people who want to learn more about RPA, especially about implementation topics. If that’s you: welcome! If not, other associated roles like project managers or program directors, might also profit from some of the content, in particular the blog.
In the following, I will go into more depth about the different content types, in order describe what I have in mind for each of them. But before we got to that, I have a disclaimer to make, and I would also like to share with you some of the underpinnings of why and how content will be provided on RPA Patterns.
In the interest of full disclosure: I work for UiPath, which is probably the primary reason for my interest in RPA. So I only intimately know their solution, and as a consequence this site will mostly have “UiPath Patterns”. I also have a financial interest in the company in the form of employee stock compensation But hopefully, many of the lessons will be tool-agnostic and therefore transferable to competitors. And I’d also be quite happy to host patterns for other vendors if somebody were to provide the content: so if you’d like to write some guest posts for RPA Patterns, please contact me.
Let me be very clear about two points, however: First, this site is unaffiliated with UiPath, so anything I say here only reflects my own opinion, and should not in any way be taken to represent an official statement by UiPath. Second, I will not post any information that hasn’t been publicly released, so please don’t try to get insider information out of me.
And, while I will do my best to be neutral and have an open mind, you should stay aware of the subconscious biasing effects of self-interest while perusing the content on RPA Patterns. And keep in mind that we all undercompensate for the strength of the effect, even after disclosure
Because it doesn’t really fit anywhere else,a second disclaimer: I will reserve the option to put some things behind a paywall. While I currently think the content on RPA Patterns should be free, I cannot predict what the future will bring. If my opportunity costs of maintaining this site become too large and the decision is between monetizing it and shutting it down, I might give monetization a go.
Think back to a time when you attended a class in school, or university, or even just a corporate seminar. What sort of scenario entered your mind?
Perhaps you are one of the lucky ones who remembered a great experience with an awesome teacher. But I suspect that, for most of us, we’re picturing ourselves bored out of our minds, with a teacher who does not know how to structure knowledge, or how learning works, and who certainly doesn’t have a clue how to engage with students.
What is my point here? Learning new things is hard - and it’s made harder by having bad teachers who use worse and outdated methods.
Luckily for us, the internet enables many new forms of learning: you can choose between videos of the best lectures, auto-didactic learning through tutorials and example apps, reading open source code to derive inspiration, and a number of other approaches that have the potential to completely transform your learning process.
But don’t expect incumbent learning institutions to pick these up any time soon: as with any large organization, they resist change and are more likely to fight new methods tooth and nail than adopt them. So you’ll have to look for learning in other areas, such as this website.
The primary aim of RPA Patterns is to help you become better at doing all things RPA, with a focus on development. For this to be effective, you most likely also have to learn some things about learning itself, and to unlearn a few things you may be taking for granted. If you don’t think that applies to you, think again.
This is not a blog about learning, however, and I not an expert on the subject, so I can only do my best and sprinkle in, from time to time, a few of the lessons I’ve learned over the years. If you fancy a more nourishing meal, you will unfortunately have to start your own transformative journey. A good starting point is the course Learning How to Learn by Barbara Oakley, and especially her references.
With all these potential wellsprings of learning literally at your fingertips, there is one key question you should always ask:
Is this a good medium for transmitting the skills or knowledge I am trying to learn?
Note the bold part: for learning to be effective, it has to be active. You cannot expect anyone to impart knowledge to you. The best other people can do for you is to offer you information — but you have to ingest, ruminate, and extract nourishment from it yourself.
Ideally, you should always have a plan in mind about what you are trying to get from a medium (be it a book, lecture, video, blog, ritual dance, or whatever). There is a small exception to this: when you have absolutely no idea about a subject, and are just trying to get an overview, it’s ok to be rather passive. But in this case you should expect to forget almost everything you again if you don’t dig deeper
One last point before we get back on topic: Think about a good lecture you attended at some point (e.g. a Ted talk): it likely made you feel great, and you walked away from it energized and with a feeling of having learned much of value.
That is great!
But did you ever stop afterwards to inspect what you actually remember from the lecture? And how you could apply what you remember to your daily life? Chances are that you remember far less than you expect, and can apply next to nothing.
Good lectures are a little like chocolate: they make you feel good for a while, but they provide little nourishment. At best, they can whet your appetite to learn more and provide an agenda of what you should look at. Bad lectures, on the other hand, make you feel bad and stifle curiosity. Avoid at all costs, they are literally worse than not learning anything at all.
This experience goes under various monikers, but I like “The Illusion of Competence,” which sums it up quite nicely in my opinion. Beware the illusion of competence and try to stay away from media that will make you feel like you learned more than you did.
Alas, this is easier said than done, as I know from my own woefully inadequate personal experience. Passive forms of learning (lectures, books, videos) are particularly prone to triggering illusions of competence.Yes, yes, I know that your teacher told you to stay away from anecdotes and testimonials. But remember the old adage: the plural of anecdote is data.
Active forms of learning (exercises, tests, note-taking, asking questions), on the other hand, have the opposite problem: you feel like you understand nothing, but are actually learning far more than you realize.
Only reflection and testing what you learned can help you identify when you are most likely to fall into these traps and, over time, allow you to become better at avoiding them.
Here we are at last. So, why write a blog, then? After all, blogs aren’t good for learning. They are very passive. The reader cannot ask questions. You cannot test your knowledge. Blog posts don’t lend themselves to exercises. Like a good lecture, they can at best provide a starting point on your journey.
All true. A blog on its own is pretty bad. But as part of a larger package, there are three things it does very well:
First, and rather self-explanatory, it is great at updating readers when something new comes up (if you subscribe to the feed or check in regularly, at least).
Second, it will remind you to engage with the subject. Learning things in a single hours-long binge simply doesn’t work. Instead, you should engage with a subject repeatedly and in different environments.This is called spaced repetition
The blog reminds you to think about RPA and how you can use it. And because it uses a story-like narrative style, it is rather digestible. So you can read it anywhere, such as on the way to work (assuming you use public transportation) or even on the toilet (yes, I know you take your smartphone there with you, don’t even try to deny it). Blogs are also great commitment devices for their authors. Blogs remind their authors that they committed to creating new content regularly and make them feel bad if they don’t
Third, it can serve as a jump-off point to different, but related topics. This solves a problem that is unfortunately seemingly ignored in much of the learning literature: how do you even decide what to learn?
I guess most of the time, researchers of the topic assume full-time students as their primary subject, in which case the teacher will tell them what to learn. But for those of us lucky enough to not have an external curriculum handed down by infallible authority, this can be a daunting task. Blogs can be read for “entertainment”, so they provide a natural way to stimulate your curiosity.
But to get the most from it, you have to engage with it actively: follow the links, re-read the hard parts, take notes, don’t fall prey to the illusion of competence.
In contrast to this monster of a first post, I will try to keep the blog posts short and crisp. The aim is for each post to focus on a single topic exclusively and for most people to be able to read it in 5-10 minutes. Discussions about other topics will be relegated to links or separate posts.
In the future, I would like to experiment with some features to help you engage with the blog better, such as a “read later” queue and a spaced repetition reminder function, but the priority for this is pretty low. For the most part, it will stay simply a blog, that is a chronological record of my commentary on what is going on.Why should you care about my commentary? I don’t know… but you’re still here, aren’t you?
The main focus of RPA Patterns! In case you are confused by the term, let me explain: there is a long-standing tradition in software design to talk about “patterns”, which are recurring solutions to similar problems. In a way, you can think of software design patterns as a distillation of developer experience.
As such, patterns are very helpful - in particular for beginners or part-time developers who may not feel comfortable with coming up with solutions on the spot. But please don’t confuse them with so-called “best practices”: the term is an oxymoron, as any solution will be context-dependent. Don’t apply patterns blindly. Switch on your brain.
Most of the time, the term “pattern” seems to be used as an affirmative statement — a good pattern, if you will. The converse — a bad pattern — is often called an “anti-pattern”.
I don’t like that terminology much; patterns are neutral: they are just something you see often, and not inherently good or bad. Sticking to that use of the word also doesn’t allow you to have things like situational patterns that are good in some circumstances and bad in others, which, let’s be honest, are most of them.
While this will evolve over time, here are some thoughts about the direction I want this to go:
- Each pattern resides in a living document, with historical versions for reference added at some point
- I will write a blog post for the first version of each pattern and whenever major changes occur
- I may also create an accompanying video if I think the additional utility of that is great enough
- Patterns are categorized and tagged
- Patterns have a rating in terms of general usefulness and a discussion in which situations they apply (possibly extended by user ratings)
- Patterns offer multiple different solutions if the situation warrants it, including a discussion of which of these are more and which are less appropriate in different circumstances
- Patterns contain a section discussing plausible solution candidates that are not recommended for some reason
- Patterns will contain references to documentation links or whitepapers when applicable
- Ideally, patterns will have a practice area called a Sandbox, exercises, example projects, or links to other sites where you can try them out (to do that active learning we talked about)
- Patterns will reference applicable software versions when necessary (both for the RPA tool and the automation target)
- I would like to add a spaced repetition reminder functionality where you can make sure that you still remember what the solution was
I have so far identified the following types of patterns that are important in the context of RPA/UiPath
- Workflow patterns: how to solve certain problems (which I call situations) and organize your workflows
- Development patterns: how to improve your development experience and skills
- Compositional patterns: how to combine workflows and sub-processes and how to make them reusable
- Application patterns: common (mis-)behaviors of important automation targets
- Design patterns: more high-level observations about business processes, RPA projects and the whole RPA program
How do patterns fit into the plan to teach you something new, then? Given their structure of Situation -> Solution, they most naturally provide a “recipe” for how to solve a situation. This is not active! What can we do about that?
To make patterns more active, I will try to give each pattern a sandbox where you can play around with the pattern and check your understanding, and exercises. I know nobody likes exercises, but that is precisely because they are one of the best ways to both test your knowledge and do active learning (see Illusion of competence).
So if you don’t do the exercises, I will be very cross with you.
Sometimes, just describing a pattern or a short blog post don’t really cut it. In these situations, I want to provide a more in-depth exploration of a topic. Therefore, in addition to patterns and the blog, RPA Patterns will have longer guides to illuminate particular topics.
Guides and patterns can be distinguished by scope and length: where patterns are short and to the point, and focus on a specific situation, guides will provide a more comprehensive view about a topic.
I have not thought about guides as deeply as about the other two parts of the site, but in general, the plans for guides are similar to those for patterns.
- Guides will be living dcocuments
- They will be accompanied by a blog post
- They will be less standardized than patterns
- Guides will also have exercises
- They may provide a common thematic overview for a collection of related patterns (as an example, see Splitting Things Up)
To give a few examples of what you might see:
- Application guides: tell you about all the important things you should watch out for when automating a certain application (such as SAP WinGUI or MS Excel)
- Feature guides: how you can best make use of a certain product feature. To take a recent example, this could focus on UiPath Document Understanding or Automation Anywhere’s IQ Bot
- RPA Program guides: how to structure your center of excellence, specific challenges with change management in an RPA context, get executive buy-in, etc.
- Business Process guides: possible ways and examples about what and how to automate a common business process
- Discovery and Assessment guides: how to find and assess use cases for automation potential
- Refactoring guides: show how you can modify an existing solution to be more maintainable, reusable, etc.
- Tricks: smaller guides with useful tips that aren’t very well-known or easy to miss
Guides provide a more in-depth look into a topic. As such, their primary aim is to get you thinking about that topic. But I won’t lie: many of the guides are going to be rather passive. I will add exercises to stimulate some thought, and some will be split into more hands-on patterns, but ultimately, it will be up to you to make the most of these.
The best way that I envision guides to be used is to treat them as input into your own projects: read something interesting, try to add it to your RPA program, and see where it fits and where it doesn’t. The second entry point I’m counting on is that you have a certain problem and want to know how other people solved it.
I am also planning to accompany some blog posts, patterns or guides with videos that show you how to create a certain effect step-by-step. “Monkey see, monkey do,” is very much a thing given the visual nature of RPA development.
But due to my lack of experience with the medium and the way videos and publishing them generally works, updating them is very difficult, which goes against the grain of the living document approach I intend to follow.So we’ll have to see how useful they turn out to be in the end.
That’s it for the first post. If you’re still with me: you, (insert honorific here), are a Legend! Keep it up and soon enough, your RPA skills will soar to the high heavens.
That’s all from me for today - I hope you enjoyed reading about my plans for this site, even though I turned out to be rather long-winded. See you next time!
Hah, fooled you! Did you seriously expect me to provide a summary to support your procrastinative laziness with regards to note-taking or encourage skipping meaningful content?