Help IT and DevOps: Simplify Account CreationAnirban Banerjee
98% of Enterprises that we talk to have IT teams that are working at capacity. IT and DevOps are often fighting fires, playing the gopher hole smackdown. In the midst of all this madness one of the most disruptive things for someone’s thought process is requests for account creation for new employees. Why is this annoying because its an easy task that is repetitive and brings no joy or satisfaction to the person completing it. Lets face it, when have we got kudos for creating 10 accounts on cloud service XYZ. The only time IT and DevOps get credit is when they avert a major issue, handle DDoS attacks, can claim the system has been running in a stable way for X days and such. From my experience the words “And we created 400 accounts this quarter on Service X,Y,Z“ have never been mentioned in a presentation to showcase your work. Even though creating these 400 accounts took an average of 3 minutes for each request, and that is if you know exactly what to do, have the right information about the hire, which group etc. – Where did these 20+ hours get factored into ? Your business is probably spending hours on mundane activities like this, wasting time from your valuable admins and DevOps. Something needs to be done.
The question then is – Why do something that is not seemingly worth doing? I understand that account creation is critical, no accounts no work gets done – but then why is it that account creation is not highlighted more as a separate project to get recognition for the time you have spent?
The absence of layers for IT and DevOps
IT and DevOps is a fluid organization. Unlike sales and marketing where most people are chalked up into nicely defined buckets of who is going to do what, based on the skill set and training they have IT and DevOps are a different animal. Case in point, for sales you will often find pre sales, sales engineer, Sales leads, VP of sales, account manager, post sales support concierge and more roles. Each one of these roles is neatly defined and despite some crossover everyone understands their part in closing a deal and keeping the customer happy.
Now take a look at IT and DevOps. Do you ever hear pre, post being attached to a title? No. The reason is that as an IT or DevOps person you are technically solid, hence the expectation is that you can move mountains when needed. It and DevOps folks are some of the most versatile and quick thinking people I have met. In fact at time DevOps people have often surprised me with their intimate knowledge of the TCP stack and why an esoteric command fails to produce the expected result on a command line.
IT and DevOps often jump from problem to problem, project to project, spanning the breadth of the entire technical organization. The layers in terms of title are primarily to denote seniority or a specific intention with which the person was initially hired. Yes, you may have the title of network engineer in the DevOps team but you have probably helped debug and fix integration issues.
This lack of layers and moving horizontally between projects makes it difficult to attribute what it is that and IT and DevOps person is doing. Look at it this way, in a typical quarter there are 2-3 main projects that everyone is trying to focus on. These 2-3 projects suck up 70% of time on a daily basis – the remaining 30% gets bucketed into “the usual stuff” . What if someone would not have to do the “usual stuff” or could reduce it from 30% to 5% or less. Would the extra time lead to better code, better testing, better debugging and more? Maybe yes.
Why is account creation a time sink?
Account creation spans two segments: Web applications and Servers. There is a third group of applications like older ERP systems installed on premise but the user interfaces for most applications are moving over to the web (at least the administration area).
Account creation on web applications takes a lot of time because of one simple fact – the lack of standardized processes and interfaces. The way Zendesk will allow you to provision a user is different from the way market will let you provision another user. Some applications do have SAML support and do allow your SSO system to create a user but then you run into issues of – how much flexibility does the SAML/SSO option give you. One of the reasons for this problem is that as companies when we design dashboards for our customers we focus on the usability features as if the company employee is browsing our dashboard performing various actions. Rarely have I seen the design process being the other way round where you set up the dashboard for automated access from the get go. There is a trade-off here – if you want to design he dashboard for automation from the start you will need to spend more time spec’ing your system interface than with a more traditional web based user driven interface.
Account creation on servers also takes time: Lets understand thought that account creation on servers is a bit more streamlined that web applications. How so? Server account creation depends on a standard set of commands or modules that plug into your directory system like LDAP. This helps with scripting, automating various stages of the employee’s account creation process. Nonetheless SSH key management, provisioning, distribution, passphrase generation and management, LDAP based authentication all take time and if you don’t have domain expertise here will often lead to costly mistakes that will come back to bite you.
Whichever way you look at it, account creation is a pain.
So what – should we stop creating accounts?
No, absolutely not. The point is that we need to help IT and DevOps maintain their sanity, use their time effectively to forward the business in the right direction. We need to work as a team not as disparate groups that juggle hot potatoes from one to the other.
Account creation is here to stay. It is a great indicator of a company headed in the right direction. If you are adding more employees, providing more services to customers your business must be doing something right. This is a good problem to have.
Also, there will never be a 100% solution to this problem. We have to accept that. Look at the state of SAML adoption for SSO. I won’t even talk about OAuth for now, but given that SAML has been around for many years lets give it the benefit of being the standard that’s the grand daddy in the market.
How many websites and applications do you think are SAML/SSO enabled? 20, 30% maybe. From our research it is less than 5%. That’s right – don’t believe me, just try the following exercise. Ask your IT team – How many applications do we use and are they SAML enabled. I think you will find a good answer right there. That is if you team already has a good way to understand what are employees using – and if so you are in the teensy weensy 8% of enterprises who actually know where employees have accounts.
No matter what standard you can come up with for account creation, applications will not jump on the bandwagon because of one simple truth – you will rarely get paid more if you have a standards enabled endpoint. Customers with enough clout may demand that you have a standards enabled endpoint but they will not pay more.
So what is a solution?
One of the solutions that we have seen work at enterprises is developing custom user account creation modules for the services they are using. The other approach is to buy commercial solutions, which claim to be bulletproof (but they are not). If you are an enterprise focused on spending the time and effort to do things for the long haul, you should look at the option if building your own solution.
One way to build a good solution is to use phantomJS and Selenium based browser stacks. These are very easy to use and will help you specify workflows that are quickly modifiable and customizable. Once you have a browser stack in place you can “train” the system to click through and access applications, visit dynamic fields. Oh and did I mention that recaptcha solving code is available for $10 (just google it), you can plug that into application stack.
If you do choose a commercial application, don’t fall for the – yes we have deep integrations with everything – statements. Ask the vendors, how do you handle websites that you have not integrated with. What is the process, do we have to pay for integrations? A little bit of aggressive questioning will save you the disappointment of installing a solution for a 90 days rollout period and then finding out it only solves 30% of your needs.
The path forward
Account creation is a necessary business task for us all. It is important to make sure that employees get quick access to what they need. At the same time the workload for IT and DevOps needs to be balanced in a reasonable manner. Any enterprise that is concerned about making efficient use of its most valuable resources – its people – should take a serious look at how they are spending time provisioning and creating accounts and whether they can streamline the process. I wish you and your team the best and hope that you find a happy place where your team no longer has to manually cater to account creation requests.
FREE TRIAL or TALK to our CEO!