In this post, I will describe success factors and inhibitors for self service IT. I will evaluate how the impact of each factor might be. There are three possibilities: high, medium and low.
The first table will display the success factors:
Self Service IT involves a lot of automation. Automation is not only done in terms of technology automation but also for processes. Therefore, it is necessary to be informed about processes in place within the enterprise. If the IT department is not aware of processes within the enterprise, knowledge about processes should be established, which involves time the employees have to invest. This is also associated with costs.
Users should easily adopt the platform and should get what they are already used to. This means that the platform should be integrated into existing services. This will significantly drive up the speed how users accept the new platform.
Work with the Users
It is especially necessary to work with the end users that are targeted to use the platform. This is an important way to find out what the users really need. Because the users eventually have to use the platform and if they don’t accept it, the platform might fail.
Internal Service Charges
Self Service IT Platforms are built with internal service charges. This has a great benefit to the enterprise since managers can see costs where they actually occur. The IT department might even be cost-neutral instead of expensing money. Top Level managers can have quick reports about the IT usage and costs of each department such as marketing or finance. On a self Service platform, departments only pay for what they need and the costs are accounted to the department itself.
A distinctive process for Change management helps the enterprise to introduce new platforms such as a self Service IT platform. This also includes not only implementation but also training.
In the next table, I will describe inhibitors for self service IT:
No Process Orientation
Processes are important aspects for self Service IT implementations. Automation often requires processes that show the path to the automation. If the company has no process orientation in place, the entire corporate organization might need some distinct changes. This is a significant problem for self Service IT Platforms.
Lack of IT awareness
Providing self Service IT also means that users have more responsibility. More responsibility leads to more knowledge users need to have about technology and the platforms. Especially in IT, we see some sort of age gap (Deal 2007), where young people learn IT-related topics faster and old people have problems. This could broaden the gap, if the platform is not easy to understand by all users.
Lack of IT acceptance in the enterprise
To implement self Service IT platforms, the IT department should play an important role in the enterprise. The IT manager (CIO) should probably also be integrated in the Board or extended Board to have access to enterprise decisions and strategies. If the IT department only plays a supportive role instead of a strategic role, it might be hard to cooperate across different departments and processes.
A “one size fits all” approach
Users in an enterprise are different and so is their knowledge. Some users might be will trained in IT, others not. Delivering a standard tool that all users in an enterprise have to use will affect the adoption of the system in a negative way. Unskilled users will have to call the IT support more often, which will create costs. Therefore, it is important to built self Service platforms specific to the needs of different user groups.
Self Service Platforms often provide a lot of possibilities and features, but not all of them are necessary to end users in all situations. Therefore, it should be possible to disable features if they are not required. Disabling features should not affect the platform itself. This approach is also described as Service Oriented Architecture (SOA). (Jossutis, 2007) defines SOA as the following:
“Service-oriented architecture (SOA) is a paradigm for the realization and maintenance of business processes that span large distributed systems. It is based on three major technical concepts: services, interoperability through an enterprise service bus, and loose coupling.” – (Jossutis, 2007)
(Jossutis, 2007) describes 3 main aspects of SOA: services, interoperability and loose coupling. A service can handle different things such as providing simple read or write operations or more complex functionality that might be used in workflows. Services are normally described in an abstract way, which should help bridging the gap between IT and Business. In a self Service Platform, different services enables us to simply disable services that are not necessary, add new services to the platform or enable existing services. As stated earlier in this section, adding or removing services should not affect the platform in any kind. To achieve this, it is necessary to decouple the services.
Another key concept of SOA is loose coupling, which basically states that services should continue to work even if other services are missing and that services might not know about other services. Loose coupling also means that dependencies should be removed. If one service is updated to a new version, all other services that might interact with the now updated service should still be able to work without any modifications. This requires a very abstract way of communication: messaging. Messaging via an Enterprise Service Bus improves interoperability for system integration. Services now simply don’t communicate with each other directly but they rather post messages to an Enterprise Service Bus. The Enterprise Service Bus keeps the message alive until someone (typically a service) processes the message. Services usually don’t know about the service they are interacting with since it is like in a fabric: Person A leaves a message that the new tools are ready for pick-up. Person B that is in charge for picking up tools sees the message and brings the Tools to another department. The communication is much more asynchronous now, since the service simply doesn’t know when the task will be processed. This type of communication is very similar to the communication used by people on smartphones/mobile phones. Person A sends a text message to Person B and Person B will eventually reply (or maybe not) to Person A. Synchronous communication would now be if Person A simply phones Person B. (Miller & Cardoso , 2012) also describes SOA as a key driver for Internet-based self Services in their work on SEASIDE.
In the last chapters, it was often mentioned that especially one thing is important: a simple UI and administration. Since this should be integrated in existing platforms, the platform should offer an API that allows handling these steps. API stands for “Application Programing Interface” and allows system integrators to access the platform via API Calls. The API should basically be independent from the implementing language (e.g. Java, PHP or .NET), what suggests the use of web standards such as ReST or SOAP (Gudgin, et al., 2007), (Fielding, 2000).
Each platform and level (such as SaaS, PaaS and IaaS) might need different API Calls. For Infrastructure as a Service self Service Platforms, the following possibilities should be included:
Possibility to start/stop Applications. This is abstracted from starting instances as this rather deals with starting/stopping templates. Platforms usually allow to start/stop different instances. Most of the time, we want to start or stop a set of instances. When we focus back at the WordPress example listed above, we have to start a frontend Server, a Database Server and adjust a load balancer. The platform should support to launch templates instead of single instances.
Possibility to control Applications. The Platform should support a way to control instances in their behavior. This basically means that triggers for elasticity can be set on different parameters such as average CPU Load. The platform may even decide on it’s own how it scales their applications. If this is the case, it is only necessary to set a minimum and maximum instance count.
Get System Performance Data. Application Administrators usually want to know how their application performs. This Data should also be integrated in existing platforms or even e-mailed to the person that launched a specific application.
Set Alerts. If the application performs bad, application owners should be informed about this. The platform should allow users to set the way they want to be informed (e.g. by e-mail or by short messages). This should reduce the time to react to an outage or bad performance of the platform.
A major challenge for self Service Platforms is to provide the possibility to ease the way on how applications are delivered to end-users. The IT department should work on providing templates that users can launch. Departments such as the marketing department should not work on launching instances with a specific application on it (such as WordPress or SharePoint) but they should rather launch the application itself without knowing what type of resources are used under the hood. Therefore, it is very important for the IT department to provide easy tools that integrate in existing platforms. If a simple API is provided the platform, this API can either be reused or extended by the IT department.
The easiest way to implement a self Service Platform is to provide an IaaS-Platform. Some IaaS self Service Platforms that are available open source are described and evaluated in Chapter 2. Infrastructure as a Service often serves as a foundation for Platform as a Service or Software as a Service Platforms. There are also some Platform as a Service Implementations available such as ConPaaS (Pierre & Stratan , 2012). Software as a Service Applications usually needs a lot of customization to make them available as self Service Applications.
To transform the IT to a self Service IT, there are some possible process optimizations available: IT departments could start with the most manual, the most time critical or the most error-prone process. If a process is manual and there are a lot of repeatable tasks, there is a good chance that this process can be transformed into an automated task. Time critical processes also have huge potential in automation since it might be possible to save money by reducing time-to-market.
Once the processes automated are identified, there are some other steps the enterprise might execute:
Break down high-level processes. Processes, which are defined as high-level processes can now be split into smaller, granular components. It is also possible to include sub-processes if needed.
Create abstract processes. Identify locations where lower-level processes can be „packaged“ and reused in multiple high-level components. This reduces process complexity and improves maintainability of processes.
Identify process triggers and end-points. Process Triggers are End-user requests, time events, … and end-points are Notifications, validation actions…
Identify linkages and interfaces between steps of each process.
Codify any manual steps wherever possible. Manual steps can be automated by adding custom code.
A critical characteristic of self Service IT is the fact that users can utilize applications and instances. This characteristic leads to a higher demand for automation and integration of resources and processes. As described earlier, user interfaces should be easy to use and this can be achieved by taking away complexity from the end user. In any case, complexity for self Service IT Platforms should be at a very low level as this will lead to confusion of users.
Let us once again look at the process of creating a new website. The Marketing Department decides to create a campaign for a new product. This campaign needs a website promoting the product, which should be run on WordPress. The marketing department should have a link in their platform where they can create new instances. After clicking this link, they can create a new domain by buying one from the domain registrar. Most domain registrars allow automation of this task as well (Namecheap.com, 2012). Next, the user would configure what type of website it would be – in our case a marketing website. The user would select the template and in the last step configure elasticity by setting the maximum number of concurrent customers on the website. The process for the user takes some minutes and the instance gets launched immediately. Domain registration and assignment is done via API calls. This can significantly reduce the time-to-market. In the background, some tasks are handled:
A virtual Instance with mySQL is launched. This instance is the database Backend for the Website. Since it is about elasticity, the Database has to be in a separate instance as we might have more Web-Frontends. Provisioning the Database on the Webfrontend will remove any scaling possibility, since Data won’t be consistent over different servers once updates to the content are done. Furthermore, this approach allows easier scaling since the database itself can also be scaled out if there are serious performance issues.
A virtual Instance with WordPress is launched. This instance serves as the webfrontend for the new Website. No single data is stored on this instance as this instance will be cloned when the load increases. This instance is also connected to a Load Balancer. The instance will run a LAP-Stack (Linux, Apache, PHP) to execute WordPress.
The Content Delivery Network is configured. To improove the website’s performance, content of the Website such as Videos and Images are not delivered by the instances themselfs but rather via a powerful content delivery network. This might be outsourced to popular providers such as Akamai.
The Domain is registered with the domain registrar. Some Domain registrars provide the possibility to register domains via API Calls. When marketing launches a new instance, they also enter a Domain. As soon as they found a suiteable domain name, the task of registration is automated and once the domain is available (registration might take some hours) it is assigned to the new website instance(s).
WordPress Services and Plugins are installed and configured. The WordPress services are configured and plugins are installed. Plugins like social Media integration are added automatically to the Platform.
As with Cloud Computing, resource and process automation sees different complexity based on the delivery model (SaaS, PaaS, IaaS). In case of IaaS, the self Service Platform would only provide virtual instances. The instances can be delivered with different configurations such as Web Servers. Key consumers of IaaS self Service Platforms are departments that require virtual Servers e.g. for Compute purposes. The complexity of automation is rather low since the only thing that are delivered to the consumers are virtual instances. The platform could provide some sort of scaling features but it is not explicitly available in IaaS environments. The next platform Level, Platform as a Service (PaaS) is aimed at development departments within the enterprise. A department could order or develop a new Software for internal or external use. The platform should provide deployment automation and automated scaling, which lowers deployment effort. Software as a Service has the highest level of automation complexity. Typically, when Software is deployed (either via the IaaS or PaaS model) a lot of configuration is necessary. As with our former example (WordPress installation for the Marketing department) a lot of steps are involved. The WordPress example is seen as SaaS by the marketing department but as IaaS by the IT department. Table 1: automation Complexity by delivery type outlines the complexity as seen by resource and process automation.
Since users of the self Service Platform are now end-users and not members of the IT department, the platform should provide a clear and understandable interface. The platform should also offer the possibility to integrate within existing platforms such as the internal portal to lower confusion of end users and improve the level of integration of different applications. A simple platform helps the end users to learn about the capabilities and possibilities of the self Service Platform. Furthermore, it lowers the support calls to the IT department. Self Service Platforms transfer a lot of responsibility from trained IT staff to end users in departments within the enterprise. This requires a lot of attention to design such portals, since users must only see what they need to see. If marketing regularly needs to launch new websites, this possibility should be presented to the end user in a simple and understandable way. Typically, end users don’t care about how powerful their instances are, unless it is a technical department. The marketing department might only be interested in how many customers can use this platform. If we set up a website powered by WordPress, the type could be indicated like that: “each instance allows 1 million views per hour”. This would give a much better understanding to the end users how many instances they might need and how they can estimate costs that will occur by each instance they decide to launch. The platform should allow elasticity on that as well. If instances are not needed any more, they can be shut down automatically. The end user shouldn’t care about that.
Quota Configuration and User Roles
With self Service Platforms, end users get more responsibility as with the traditional way how people deal with IT. More responsibility might also lead to greater risk of misuse. People could launch instances and simply forget that other departments might also need instances. This could lead to a over-utilization of the datacenter. Usually, resources within a company’s datacenter are not infinite and unused instances can be used better for other load. Therefore, the platform should allow some sort of quota configuration. A quota configuration within a self Service IT Platform offers the possibility to set how many instances a specific user or department can use. The IT department could set that the marketing department can utilize a maximum of 100 concurrent instances of a specific type (e.g. 4 cores with 8gb of RAM per instance). This could start with a coarse-grained configuration (e.g. 100 instances maximum for the marketing department, 100 instances for the R&D during business hours and 500 after 8pm) and gets fine-grained in the departments. This would mean that each department gets more responsibility on how to use the available IT resources, but it also requires someone that is responsible for IT within a department. Typically, this would be a manager or assistant to a manager. The IT responsible can now set different quotas within their own quotas (let’s assume it is the marketing department with a maximum of 100 instances). Different websites, applications and projects would have different quota sets, which are combined with the department quota. However, this requires different user roles with different rights.