Posts

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:

Factor Description Impact
Process Knowledge 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. Medium
Integrated Platform 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. High
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. High
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. High
Change management 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. Medium

In the next table, I will describe inhibitors for self service IT:

Factor Description Impact
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. High
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. Medium
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. Medium
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. Medium

Header Image Copyright by trickmonet.

In this post, I want to sum up what is all necessary for self service IT. In the two tables below, you will find the different requrements.

General requirements:

Need Description
Scaling and Elasticity Platform is built to scale to a specific quota. Elasticity is built-in.
Pay-per-use Platform provides the ability to charge the departments/users on their usage.
Device independence Easy tasks and monitoring should be possible; platform should be built on internet standards
On Demand Instances and Applications should be available once the user needs them
Simple to use Users must only see what they need to work on. Provide a simple and clear interface.
Quota configuration and User Roles Each department gets a specific quota of IT resources; departments can also set quotas on projects, applications and websites. Different user roles are necessary.

Technical requirements:

Requirement Description
Resource Automation Offer possibilities to automate resources and processes; usually done in Infrastructure platforms.
Simple API Provide an API to interact with the platform. The API should support: launching, controlling and stopping applications.
Service Orientation Service orientation is a key factor for Datacenter Integration. The concept has these aspects: services, interoperability through an Enterprise Service Bus and loose coupling.

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.

Image Copyright: Intel Free Press

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.

Header Image Copyright by: Alquiler de Coches

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.
self service storage

self service storage (C) Seth Anderson

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.

Platform Automation Complexity
SaaS Very High
PaaS High
IaaS Low
No self service for IT?

No self service for IT?

Image Copyright by L.C. Nøttaasen

 

Simple to use

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.

simple to use IT self services at Intel

simple to use IT self services at Intel (C) The Intel Free Press

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.

Device independence

As with Cloud Computing, device independence and the use of Internet is an essential requirement for self Service IT Solutions. Self Service Platforms should be accessible via standard technologies such as HTML. Especially monitoring tools should be offered by the platform. Since self Service IT Platforms are basically within enterprise environments, it is necessary to have advanced security such as corporate firewalls applied.

on demand for self services

on demand for self services (C) David Fisher

On Demand

The goal of self Service IT is to improve processes within the enterprise and to improve the performance of the IT department. Processes should be more transparent and easier to use for end-users within the enterprise. Therefore, it is necessary that a self Service platform show immediate effects. If the user needs to create a new marketing website, the instances should be launched within some minutes and if scaling is needed, it should also be possible within some minutes. The user should get access to new instances once the user needs or demands for them. There should be no form to fill out and send to the IT department just to have instances available after some days or weeks.

For Cloud Solutions, Scalability and Elasticity are key requirements. In private Cloud Solutions, this should also be supported, even if scalability and elasticity might has a lower border as we see in the public Cloud. Private Cloud Computing environments basically use dedicated Hardware and resources are not shared. Public Cloud Solutions use resource sharing, which is basically not available in private Cloud Solutions. Scaling applications means that we can add a new instance of Linux or a Windows Server. Elasticity is something “more advanced” to that as described by Reuven Cohen, an opinion leader in Cloud Computing (Cohen, 2010). Reuven describes scalability as the possibility to “grow to the demands of the users on a platform” whereas he states that elasticity is something that reflects real-time conditions. A platform might have millions of users, but if this platform is only available in the United States, there might be significant fewer load on the servers during night. The load will be much higher at peak times and elasticity means that unnecessary instances are shut down if the load is lower or that new instances are started if the load is higher. Elasticity is something very important to self Service Platforms, since they basically exist within an enterprise environment. Demand might change over time as not all enterprises act globally and even if they do, different platforms are used in a different manner. Let’s look back to the marketing department introduced earlier; especially in marketing, different groups of users are targeted and it is about targeting regions individually. What works well for customers in the United Kingdom might not work for customers in France and therefore, the website(s) might be different. That makes elasticity important since unused instances can be shut down to use the now free instances for other applications and services.  (Owens, 2010) defines Elasticity as „the golden nugget of Cloud Computing“ and a key inhibitor to move to Cloud Environments. A very similar definition on what Cohen defined as elasticity is also provided by the National Institute of Standards and Technology  (Mell & Grance , 2011):

 

elastictiy and scalability for self service platforms

elastictiy and scalability for self service platforms (C) Polycart

 

“Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.” –  (Mell & Grance , 2011)

 

As stated in the beginning of this section, the hardware available to run these services is not infinite and it is much lower as we in public Cloud Solutions. Better utilization of the Datacenter can now enable less critical tasks to be run overnight and use free instances. The IT department could even offer them at lower prices, as we can already see them with spot instances on Amazon Web Services, a popular public Cloud provider  (Amazon Web Services, Inc, 2012). A possible use-case could be the research department, which calculates non time-critical tasks during night and saves money by doing so. Since self-Service platforms should be easy to use, most of the elasticity has to be handled by the platform. The IT-department would only set a quota of how many instances are available for a specific service or application and set the rules and boundaries for elasticity. The consumer (or customer) only starts the new service or application and don’t have to care about scaling and elasticity issues, since it should be easy to use.

A vision of a company, where self Service IT is implemented, would look like the following: the IT department is reducing the time they invest in operational tasks such as maintaining their Servers and applying patches. Core tasks of the IT department would shift towards providing more and more Services for their End-users. End-users of different departments within an Enterprise could use these services out-of-the box. This means that they don’t need to call someone in the IT department to create new instances or applications. If the marketing department needs a new website for a product launch, they go to their self-Service platform (which is ideally integrated in the internal portal) and launch the new website. The website is automatically configured and the corporate identity is applied. These services are basically available within minutes. The IT department now works on providing more templates and more applications that are available for the user out-of-the box. This reduces the time-to-market and improves the possibilities in the IT department. In many companies today, this process is done the following way today: if the marketing department needs a new website for a product launch, they talk to the IT department. The IT department now prepares an instance – either virtual or dedicated. The level of automation can vary, but often it is not that automated. The process to create a new marketing website might take some days or even weeks. IT departments are overloaded with tasks that are actually repeatable and can be automated. Automating these processes can significantly improve the IT power of an enterprise, which could lead to an uptake in competition (Stelzer & Heinrich, 2011).

Cloud Computing is a strong driver for self Service IT. If we look at popular platforms such as Amazon Web Services[1], platforms are basically easy to use. To get started with Amazon Web Services, there is nothing more needed than a valid credit card. To register, it takes some mere 10 minutes and you are ready to go. However, corporate environments don’t use these services we call public Cloud  (Meir-Huber, 2011) nowadays in most cases. Large enterprises want to have their IT often with a familiar outsourcing provider or even insourced. This is what we call private Cloud. If we talk about private Cloud, we also need a high level of self Service and all aspects of the Cloud basically apply to private Cloud as well. Right now, we have some mature platforms for private Cloud Computing. Popular companies such as VMware or Microsoft provide some of them; others are Open Source Platforms like OpenStack or Eucalyptus. These platforms basically provide Infrastructure as a Service Tools. If other platforms such as Platform as a Service or even Software as a Service are needed, this is not that mature as we see it with Infrastructure as a Service nowadays. Additional work is required to achieve that.

(Miller & Cardoso , 2012) describes self Service IT as “Internet-Based Self-Services” and outlines the importance of self Services:

“Many worldwide economies have moved away from manufacturing and became service-oriented. As a consequence, research on Internet-based Self-Services (ISS) will foster the uptake of service exports and trading since they can replace many face-to-face interactions and make service transactions more accurate, convenient and faster.” –(Miller & Cardoso , 2012)

By this,  (Miller & Cardoso , 2012) states that self Services will allow companies to replace face-to-face interactions for processes by automated processes. This will improove the company processes to be more accureate, more convenient and faster. (Miller & Cardoso , 2012) also describes that there is a research gap so far in self Services, since this type of services have to be developed by someone – and this costs time and money. They suggest the use of different tools to create self Services out of models.

self services are everywhere - even in IT

self services are everywhere – even in IT