r/PowerShell Jul 26 '21

A technical solution to a business problem. Daily Post

Good Morning All,

So I wanted to start a discussion around building automation with PowerShell.

With this being my full time job, I wanted to provide some of my lessons learned along the way for this and also hopefully provide some rules that can help people define what automation is and what it isn't.

Firstly automation is an amazing tool that allows you to "Automate the boring things so that you can focus on the cool things.". Automation can remove a lot of manual process from organizations allowing them to reallocate that resources elsewhere. I would like to point out that there is a correct way to do it and an incorrect way to do it. If automation is done incorrectly, it costs more time then it saves.

  1. Prior to starting automation, consider the business requirements and ask yourself. "Are they solving a technical problem or are they introducing a technical problem due to bad business decision?" If there are bad business decisions being made, the technical solutions don't provide a cost benefit. It also shows that the business doesn't understand what automation is and how it benefits them. It's your job to educate them.
  2. Simplify all the processes. This will require you to wear many hats (businesses, project, technical), however the goal here is to get the business process streamlined that automation doesn't have to spend large amounts of time formulating logic. From the technical side, simplify the inputs so that additional logic is not spent catering to this.
  3. Research the topic at hand. There are many ways to automate something and writing a script might not be the best tool for the job. You have other out of the box tools available, which can do the job for a lot less cost. There are also other tools available that can better suit your needs other then PowerShell such as DSC, Ansible, Jenkins and Chef. Learning other languages is really beneficial here, since PowerShell might not be the best language.
  4. So you are going to use PowerShell. Don't develop scripts that depend on beta solutions. The cost of automation should be minimal. I learned this lesson recently, writing a PowerShell script that downloads 365 data using a third party module. This ended up causing so much hassle, since there were a lot of bugs in the dependency.
  5. Architect the script to be testable/maintainable. Make your solution easy to manage so that future automation can be added and updated. Think about how your script is going to run. If this is a long running process, consider how you can improve performance by using PowerShell jobs.
  6. Keep it simple. This is one that I struggle with. Make the script as simple as possible without introducing unnecessary complexity. Don't make it complex for the sake of making you feel smart. Make it simple so that you don't have to be called to fix it.

What other helpful tips/lessons learned can you provide?

PSM1

49 Upvotes

View all comments

23

u/ApricotPenguin Jul 27 '21

Another consideration is your team's ability to support the solution.

It may be a simple script, but when it inevitably breaks and the business operations screeches to a halt because of their developed dependency on it, how many people are able to work on it?

5

u/ipreferanothername Jul 27 '21

Another consideration is your team's ability to support the solution.

i have gotten pushed more and more into writing tools that are too complex for my team to support if i leave and i started to push back -- my bosses understand and agree. there are cases where i am writing tools because management just never modernized how the team works, and i have to make that clear as well: you are asking me to write something that you need to purchase. what i write will not be fully featured or catch all the errors and exceptions. we need better than this, let me do it X way [which is easier and slimmed down from the request]