When describing the configuration of services, simply installing an application is not necessarily enough for the full enablement of a service. And what about services that don’t actually require installation in order for them to work? Staying competitive means delivering applications and solutions to who it matters, when it matters. New devices such as smart phones and tablets increase consumer demand for access to content anywhere, at any time and over any network.
Technology that is deployed to enable services needs careful consideration, but above all, it should be capable of enabling the broadest range of services possible. There are a whole host of considerations when selecting a technology (or technologies) to enable a service for a user. After all, this step is key in ensuring that the service is actually delivered according to end users requirements.
It’s worth taking a moment to consider one particular point: Every IT department delivers IT services to its users every hour of every day— that’s their job. You may have a mix of manual and automated tools and processes that result in the end user receiving the services needed to do their job. Perhaps you have invested in software deployment technology to automate the delivery of applications to users. Or maybe you have many scripts, written in-house, which perform mundane day-to-day configuration provisioning tasks. Perhaps you still take on largely manual “heavy lifting,” possibly even desk-side visits to make sure the users get the services they need.
In order to successfully deliver a great service catalog-driven user experience, you need to automate the processes behind the enablement of services. If you want to deliver a consumer-like experience to your users, then you MUST automate the processes that enable those services.
Service enablement is about much more than mere application installation as it needs multi-step processes in order to ensure that the service is enabled in such a way that it is fully useable at first access by the user. Permissions might need to be altered, security group memberships amended, user properties updated, files copied, registry tweaks applied, firewalls configured; the list goes on…. In fact, application access might not even need an installation. Of course, there is absolutely a place for end-point management, where applications or software needs to be installed, but it is by no means a complete solution.
So how do we go about service enablement? Well, the first consideration is that whatever tool you use to build your processes, it must be able to accept input in the form of parameters from a service catalog – information such as user names and other user or device-specific information must be capable of being passed from the catalog service to the enablement mechanism. This is a given. You should also, when possible, select a tool that can build workflows for enabling services, which can integrate with your existing automation tools and scripts. There’s no point in re-inventing the wheel, and if you have an acceptable automated process in place then use it! However, once again, the tool should be capable of injecting user-and device-specific information into your existing processes because without this, the process of integration is difficult, if not impossible.
Many businesses today provide a host of different ways in which their users can access and interact. Different desktop delivery platforms suit some use cases better than others. Consider the widespread use of Citrix tools as remote access or branch access solutions. In fact, it is commonplace for users to use different desktop delivery platforms throughout the course of the day to enable access to different services in different situations. This can lead to a very confused and inconsistent user experience, not to mention huge complexity in efforts to manage this kind of multi-desktop, possibly multi-operating system, environment.
Services may be “context” specific in that users should only receive them in certain circumstances, even if they are granted access through the service catalog. Security requirements might require that a user can only access a particular application or file share from a certain location, or at a specific time of day. Often IT teams say “we want the user to have the same experience everywhere.” But when quizzed, a majority of them recognize that this is incorrect. What they actually want is an experience that’s predictable and relevant to the user depending on their circumstance.
For service enablement to work you need a technology that can take into account the context of the user and deliver services that are appropriate. It should also behave consistently and allow user personalization across multiple operating systems and desktop delivery platforms. This is the realm of User Environment Management (or User Virtualization depending on who you speak to.) Services should be delivered according to a rule-set based upon user context and security requirements. It is also beneficial if the tool recognizes service subscription status from your service catalog as an access principal because in the long run this will simplify and significantly reduce the time to deploy services both existing and new.
In order to select a technology that has the ability to deliver all the services you need to handle, you need to have an in-depth understanding of the services that your users consume today.