How to Transform IT into an Agile Service Broker

Written by Joe Kozlowicz on Tuesday, May 31st 2016 — Categories: Software Development

Agility, DevOps, scalability…they often sound like a lot of buzzwords. But you can transform your IT department into an IT as a Service broker within your own organization by adopting DevOps and cloud methodology. The end result is greater productivity, both for your users and your IT team.


What Kind of Agility Are We Talking About?

aspects of agile IT deliveryCloud services and DevOps have gotten a lot of attention in the past couple of years as a new paradigm. The end goal is to break down siloed teams in development, quality assurance, and operations to streamline and increase development speeds.

So what if you’re not a developer? You can still benefit from agile methodology, which includes more frequent deployments, automation, quicker restoration of backup/recovery data, and continuous improvements to your IT services.

When you’re deploying and supporting your general use applications, usually you’ll plan, gather quotes, provision, test, and deploy as a single project. That initial project plan will translate almost directly to your final environment, barring any significant adjustments during testing. With a continuous agile approach, you will be able to better adjust your infrastructure to match shifting requirements for compute, memory, storage, security, or other configurations.

Three main tenets of agile service delivery are self-service, scalability, and high availability. In other words, your IT infrastructure should be accessible to users and they should be able to deploy the services they need when they need them – with or without involvement from IT.


How to Implement Agile IT Service Delivery

When focusing on those three main tenets, you’ll realize that there may be a few extra steps involved compared to a typical application deployment. For one thing, if users are going to be able to self-deploy, you have to consider a portal to facilitate this access.

Your infrastructure design should include not only the base servers/virtual machines and associated components (network, storage, backups, etc), but also how users will provision and request services. If you are going full automation, you’ll also have to architect a fulfillment process. If a user logs in and downloads a new app, how does your virtual data center scale out the additional required resources? Is it logged for review? Do you have software licenses available?

Going hand in hand with an automatic provisioning process is scalability. If your in-house data center or existing cloud environment could potentially run out of resources, you may need a hybrid solution to pull additional VMs when necessary. Ongoing monitoring of consumption, VM health, and physical infrastructure will help you deliver on high availability goals and keep users online.

The shift to agile IT service delivery moves you from a project-focused team to an ongoing service delivery team. Your IT infrastructure is not dependent on a given application or service – instead it is an ongoing delivery of resources for a variety of uses. That means you’ll undergo a constant cycle of Release, Support, Review, and Improvement, similar to the DevOps teams using your infrastructure.


Designing Your Catalog

An IT service broker functions by providing a catalog of apps and services that users can pull from at any time. You’ve probably experienced the flip side of this, which has emerged with the consumerization of IT: shadow IT services. Your users are able to pull out a credit card, order their new app on demand, and start using it almost immediately.

By setting up a service catalog, you can deploy applications or virtual machines to end users in an efficient manner and stop them from turning to public services.

For applications, this is pretty simple: the user chooses an app, provides credentials, and a new VM is deployed with preconfigured settings, or they are added to an existing VM that runs a multiuser application.

For new virtual machines, start by asking requirements in your catalog to discover the end use. Is the VM for development, testing, or production? Are there compliance implications, like the storage of health, personal, or financial information? What service levels are required?

From there, you can dynamically provision a VM in a specific cloud or with a specific set of requirements. Your catalog should have preconfigured sizes of VMs (storage, CPU, RAM) as well as site locations/zones, machine policies like network and security settings, and application policies.


Moving from a reactionary project-based IT methodology to a service-oriented agile delivery team takes some culture adjustments. Talk to your team and any superiors about why a new type of IT will make sense, how it will solve business challenges, and to gather feedback to better implement these methods for your specific organization. Some new roles may be required, or at least adjustments of existing roles. The rewards, however, can be great, as your team spends less time putting out fires or planning for future major deployments and can focus more on supporting and iterating on a successful, scalable infrastructure design already in place.