Why Service Delivery and Automation is important
As a younger lad, having been introduced to Systems Analysis and Design (which includes programming in a multitude of computer languages using a multitude of platforms and technologies), as I see that as time marches on with new technologies, so does the increased need to maintain and therefore automate, endpoints of legacy with endpoints to current with endpoints of the ‘external’. Critically, and in every solution devised, there is service delivery. The absolute imperative to ensure that whatever solution being devised is maintainable, available, repeatable by design and resilient. This resiliency is not just to do with things like Disaster Recovery or Business Continuity, it goes right to the heart of making sure that the solution is fit for purpose. Service Delivery flows through every part of enterprise architecture, from the idea, to analysis, to design, to production, to support and thrives within that solutions and connected solutions lifecycles. It includes the physical and digital technology that makes up the solution – yes, the servers, and the software, and the storage etc. That means, that even more crucially, it does not matter whether you are a business analyst, a programmer, an administrator, an engineer, a product manager or programme manager. You will be thinking service delivery in whatever you do, whether you like it or not. As you may know, my site is a haven to all things service delivery and includes another passion of mine, which is automation. Why? Because automation is the connector that allows the solution to be flexible, to scale, to morph, to carry out processes without human intervention (which then means better accuracy) – it supports service delivery. Of course, I don’t aim to create a wonderful robot of automation to win a prize, but am absolutely keen to learn and use my integration expertise with it! 
Anyway, lets go back to why you should understand the importance of service delivery automation. For example, lets quickly mention Office 365 as an example. Any administrative process that you are carrying out when interacting with the admin centre of Office365 carries out a robotic process. A robotic process is one where you interact with the product, and yet, the back end product is not wholly under your control. Rather, you are automating the software to carry out functions, as opposed to you directly influencing the software. You do not have access to any server based tools – you are automating those tools to carry out a process, in fact, you are being non-invasive – that’s robotic automation. Robotic automation also includes things like system upgrade, data entry and transactional processing. And the high chances are that you will not have direct access to those systems in a multi-departmental organisation. Robotic automation is definitely coming on leaps and bounds in a multi-server environment where you need information from a collection of systems. I spoke to a company which has a desire to manage specific services wanting to not only control web services on a particular group of pre-production servers, but also wanted to store results securely online because they had support groups which did not have access to those servers.
Automation comes with a price
But automation carries with it a price. The increase in automation has a detrimental affect on wisdom, that is, it will curtail the ability to continually review an already automated created process. Reasoning is that once something has been automated, it is then difficult and/or cumbersome, and therefore not desirable (particularly for large automated processes), to alter that process, without then impacting on other processes connected to it. Take for example the process to automatically upload data into SharePoint which then automatically stamps metadata on that data. Lets assume for a moment that it starts off as simple as this:
- Get a file from a network share
- Upload that file into a SharePoint document library
- Set metadata, the Title becomes the filename
Sounds simple? Yes, until you add a simple automation with that file, like:
- Once the file has been uploaded, alert the members
- Gather details from the file to pass onto a data management system
For alerting, sounds simple because you would simply set an e-mail alert, yes? But it is not so simple if that alert needs to be customised beyond what SharePoint does, or if the alert needs to trigger some other process, like having its contents interrogated to be used in another system. And as for the data being passed onto a data management system, that means additional management of ensuring the right data gets across. Then there’s the service delivery angle, ensuring that the automative process continues to be maintainable, available, resilient and supportable. So that means, either code it, or use say a workflow to customise a notification that fires as soon as the file is added and carry out other functions. The point is this. Once something becomes a target for automation, the human desire to do more with it comes arises, but that impacts on wisdom because the need to change things does not happen at the same speed as when the process came into action. This speed decreases with every new connection to systems and other processes, because of amount of work required to identify and service deliver all steps in the process end-to-end. This affects wisdom, as the sheer added number of steps in a process make it more cumbersome to confirm things like performance, audit, human response tracking, etc. Of course, one may argue that certain workflow tools tracks performance in each step. But that rarely comes from a central point – that generally comes from the application system running that step. If are able to centralise all processes under one system banner, then maybe, well done! But, I am not talking about just one tool. I am talking about automation that does not just include that tool working in one system, but all the other systems that tool may be a part of in an automative process (that is, all endpoints).
Automation is not just writing an app to display a form or a workflow
In essence, automation is one of the keys in which systems work in harmony to fuel a seemlessly connected process, machine driven and harvesting intelligence. Service delivery automation encompasses all parts of a process that requires automation in order to meet one or more of the imperatives at the bottom of this section. It is more than simply the need for someone to fill in a form (that is simply an aspect of a process).
For example, if HR wants an individual to fill in a form online once they are on-boarded, that form must be sent to specific individuals, then to other departments to assign resources, then needs to be stored, and needs to be applicable to audit (or used again when that new person changes departments or even leaves the company). So writing an app to get someone to fill in a form is not automation of a process, it is a step in that process. Another example. You want to be able to collect information on the status of all servers in your estate – specifically, the status of specific services and want to display that centrally. You don’t have access to SCOM (System Center Operations Manager), and you don’t want to code it. Again, writing an app to display the status of all the services is not automation of that process, it is a step in that process, because automation of display of that information does not end with it simple being displayed. You want to be able to act on the data, or take some automated action to resolve issues if the status is not as expected.
Automation using any technology is decided upon because one needs to address all of the following, but only works if by connecting technologies using automation techniques minimises disruption:
- Quality
- Speed
- Accuracy
- Productivity
- Efficiency
- Scaleability
- Flexibility
Don’t automate everything!
Just because you have a bicycle does not mean you fix it so it rides itself. By doing that you miss the simple enjoyment of doing anything physical, like exercising your legs. The same thing comes with automation. Just because you want to cut costs to achieve additional benefits by reducing or eliminating human involvement doesn’t mean you should immediately automate the process. A factory which distributes milk has automated the entire factory floor so that robots move the milk containers around the factory. But they still need humans to keep an eye on the robots. Certain processes you will want to be operated by humans, because at the very least you will still maintain some modicum of control, and to mitigate risk. Otherwise, you might as well consign yourself as a cyborg or a member of the Borg from Star Trek. You only automate things that you think will reduce time around time, or will reduce the requirement to chase actions. But improving things to simply reduce headcount is not going to solve anything, unless you can absolutely guarantee that nothing will happen to upset the automated process. Some companies where automation has been a success is were they actively introduce business continuity. I’ve even seen companies use a back to paper continuity plan if the automated process through computers fail. This is where, for example, they utilise legacy equipment and where they need to guarantee a process if that legacy equipment fails.
Conclusion – and a new beginning?
If you are not thinking automation for your technology set, you should be. I think that it is time to take stock of your automation alternatives. Automation of an enterprise solution using multiple technologies requires an adoption of an suite that allows you flexibility. Remember that using a tool within one platform is not enough. Maintainability, Availability, Resiliency and Supportability is key. Automation in the SharePoint space is already taking place, is driven by transactional processes across systems, to ring-fenced workflow against specific processes, to Web Analytics across Office365 and on-premise SharePoint. As this increases, so will be the need to review automation tools. On my voyage of discovery, a few of the companies I have surveyed taking automation seriously have mentioned to be a product called Automate 10, owned by HelpSystems LLC. This product provides a none scripting platform to integrate and automate a myriad of services from Amazon through to FTP through to WMI automation and across multiple servers and services in the enterprise. Am running some demos of this myself and the product seems to be very useful. Check out some automation case-studies from some products which I recommend if you are considering enterprise wide automation (not sticking to one technology or one sticking to one scripting language). Click the below screenshot to see the number of services (note – Azure is also listed!). 
There are other links to articles you should also check out, to see how some other organisations are dealing with automation.
