Today I got a bit closer to a meaningful definition of automation as it applies to the software development process. I\u2019ve been turning this concept over in my head for a while, which is partly related to the dreaded question of licensing.<\/p>\n
A few weeks ago, I was chatting a bit in the SQL Server Community Slack Channel<\/a>. One community member was frustrated with per-user licensing for monitoring and automation products.<\/p>\n This isn\u2019t the first time I\u2019ve heard grumbling about per-user licensing, of course \u2014 with any<\/em> licensing model, you\u2019re going to hear grumbling about it; that\u2019s just how licensing goes.<\/p>\n However, I think per-user licensing can make a lot of sense when it comes to automation products, because of the nature of automation. I work for Redgate<\/a>, which does per-user licensing. I also often do demos of how our tools integrate with Microsoft\u2019s Azure DevOps Services<\/a> (formerly VSTS \/ or TFS-in-the-cloud), which licenses based on user numbers.<\/p>\n But not everyone thinks this makes sense.<\/p>\n That\u2019s because they see automation as:<\/p>\n This definition isn\u2019t dumb or naive at all. This is what automation has been<\/em> in IT for many years: I\u2019ve got a problem; I create a script. The script helps save me or my team some time, and I only ever look at it again if it stops working.<\/p>\n Based on that definition, the most natural way to charge for automation tools would be based on something like the number of times the tools run, the number of servers\/cores they are run on, etc. (I don\u2019t mean to make this post about how much software should cost. I don\u2019t think that\u2019s related to licensing model choice at all \u2014 no matter how you charge, whether it be people, cores, tentacles, or whatnot, you can find a way to make it cheaper or more expensive.)<\/strong><\/em><\/p>\n\n
The nature of automation has changed dramatically in recent years<\/h2>\n