Deploying Applications Faster: Balancing Risk and Agility

I was at a Gartner conference a couple of weeks ago where the speaker said something to the effect of:

The speed of business applications is going to continue to increase. Where it may have been normal to spend months creating an application that would have a lifespan of years, we now need to spend weeks creating applications that will have a lifespan of months.

So far so good, I’m seeing this.

As a byproduct of this speed requirement, the business is going to procure, write and deploy its own applications. IT needs to disengage from this process.

This, in their mind, flows across multiple delivery platforms:

In the cloud where Shadow IT will become normal business IT.

For Mobility where users will buy their own apps or just use native apps rather than counting on IT-provided apps

For internally developed apps where businesses will need to work directly with developers in order to get the kind of speed and agility they demand.

For desktops where users demand new applications faster than IT can provide.

And with that, I beg to differ.

Applications provide the business value of technology. It’s natural and quite productive to make sure that you have the best applications available to support your business goals.

So, is it possible to make applications a business problem and relegate IT to providing an infrastructure platform? In a word, no.

One of the coolest parts of my job is the variety of IT organizations I get to work with. Some of these organizations have a very small and manageable application footprint. Some of them are the opposite case with application counts well above ten thousand. One organization we work with develops so many internal applications that they will proudly tell you that they have more developers in their organization than Microsoft.

In these large complex organizations, IT struggles mightily to manage the myriad of applications. The business moves ahead of IT, developing applications as they need them. Based on this experience, let me paint a picture of some of the things that happen when IT throws in the towel and just leaves the application layer up to the business.

Risk – Applications are not profiled for risk. Where risk is considered, it’s considered only from that business unit’s perspective. Expect to find large risks to the organization only after the horse has left the barn.

Software Lifecycle Management – Business units will be very interested in writing applications but will have very little interest in maintaining applications. They also won’t be interested in doing the hard work required to retire an application. Over time your infrastructure will need to support every operating system, browser, and platform that’s been deployed for the last 20 years.

Performance – Application performance is dependent on infrastructure. Performance can only be managed by building an application-aware infrastructure.

Data – If the data used in this application is key corporate data, likely to be used by a number of systems, IT needs to plan the infrastructure accordingly.

Business Continuity – Without an approach that includes infrastructure, there’s no way to assure business continuity.

If applications are core to technology and can’t be handed over part and parcel, what’s the solution? Telling the business to slow down doesn’t seem to be a very good way to stay competitive as an organization.

What level of control should IT exert over applications? What kind of applications does IT need to control?

In my mind, it’s possible to federate this, allowing business control over certain localized applications and keeping other “core” applications under the control of a central IT organization. Based on the criteria above we can imagine looking at individual applications and grading them.

Risk

Low – Medium – High

Lifecycle Cost

Low – Medium – High

Performance

Low – Medium – High

Data

Low – Medium – High

Business Continuity

Low – Medium – High

Depending on regulatory load and several other business factors, applications with High scores probably need to continue to be provisioned and managed by IT.

Examining our initial dilemma, what does this do to business agility? If IT needs to be involved, can they do that without slowing down the business?

With some honesty, let’s admit that in some aspects of this, delay is fundamental and probably necessary.

We can imagine airlines protesting all the overhead the FAA puts on them. Require extensive equipment checks on a regular basis, pre-flight checks on the same equipment multiple times per day. Is it all really necessary? It’s really slowing up the whole flying process and making things very expensive.

As a frequent flyer, I’m in favor of erring on the side of caution.

When the business says they have no time to involve IT in application deployments, are they really saying they have no time for risk assessments, a lifecycle plan, performance management, etc.?

I do feel that the process of creating an agile IT infrastructure for application provisioning can be achieved. This is what gains in SDDC and overall automation initiatives bring us. We’re not moving to a world where we deploy servers, storages and networks faster. We’re moving to a world where we deploy applications faster.

The accelerated rate of change in the world today is a challenge for all of us. It’s a challenge for the business. It’s a challenge for the applications. It’s a challenge for IT infrastructure. We’ll all need to accelerate together to be successful.