This article is more than 1 year old

The perimeterless, ever-shifting enterprise: What would a real, red-blooded IT team do?

You're not trying to build an empire, you just want to secure the bloody data

If you work in a manufacturing, plant measuring productivity is simple: you measure the number of widgets produced in a given time frame. A person in this environment must not be the one holding up the production line. Nothing more, nothing less. But what does productivity mean for less tangible "knowledge work" occupations such as those of us who work in IT?

Knowledge work is ephemeral. It is hard to monitor and harder to measure. When are you working? When you're in the office? Thinking about a project in the local café? Or when you receive a bolt of inspiration at 1:00 am just before you drift off and hastily jot notes into your phone so you don't forget in the morning?

As the boundaries that define our occupations have become blurrier, so too have the physical – and hence technological – barriers to confine us. Workers consistently operating outside the office, and critical business services are themselves frequently located in the public cloud.

The eggshell security model of hunkering down behind a single, well defended "corporate firewall" is dead. Securing an organisation's IT needs to be attended to without compromising the productivity of the distributed virtual office knowledge workers actually use, and the hard truth is that this isn't easy.

Control is key

Vendors of all sizes are aware of the practical issues facing systems administrators and, when you visit them at a conference, they'll talk the talk. The real issue seems to be walking the walk; vendors young and old have a problem with this and it isn't their fault. These vendors run smack into the same problems the organisations looking for solutions do: they don't have control.

A long time ago it used to be that organisations never thought about "licensing" software, and control over one's data wasn't even a question. We bought software and of course all our data was ours.

Slowly but surely the language changed. As the language changed our ideas changed with it. Nobody "buys" software any more, and "data sovereignty" and "data locality" are normal parts of the tech lexicon.

Once, a vendor rolling out massive changes in UIs, APIs, data storage systems and so forth would have caused hysteria even if customers had the choice of avoiding changes by sticking with older versions. Today we buy into a public cloud solution where continuous and often unexpected change that can and does break compatibility with various other products is the only constant. We're told it's a good thing and, if it's repeated enough, we proselytize this to others.

The primary rationale of dissent with regards to the religion of the new is essentially a question of control. The public cloud vendor is focused on delivering something to the customer. An application, a VM, an API, what-have-you. Doing so is hard, and it is perfectly natural for the focus to be narrow. Unfortunately, nothing in tech exists in isolation any more.

Everything has to talk to a dozen other things. Next year it will be two dozen things. Five years from now, two hundred. IT teams are having trouble building the middleware that lashes all this together and so they turn to specialist vendors.

Those specialist vendors do a little bit better at holding the night against the madness, but they often don't get any more information to work with than an end customer's IT team would, and they may have to work on integration between many more products than an internal IT team would have to track, as their customers are diverse.

Customers no longer have control over all aspects of their IT, middleware vendors don't have any more control and the upstream developers and public infrastructure providers everyone relies on have almost universally adopted an attitude of "it's your job to keep up, not our job to play nice".

Shadow IT

Bearing the above in mind it's also worth mentioning that this isn't 15 years ago when operations teams owned the budget. In an increasing number of organisations – I'd go so far as to say that by now it's probably the majority of midsize and up organisations – applications owners have the budget. And, to be brutally honest about it, in most organisations, application owners hate IT.

If there is one thing that application owners consistently report to me, it is how fed up they are with internal IT teams. Developers are impossible to work with and operations teams are seen as roadblocks. These folks don't care if it costs 10x or even 15x as much to go to a public cloud provider to get whatever IT they want because they can get it now, and without hassle.

IT's attempts to unpick public cloud projects, bring these under operations' management and so forth are viewed as desperate empire building and met with vigorous opposition from application owners guarding their budgets. They have their own empires to build, and they don't want to deal with red tape from others.

Securing the mess

Somewhere, amidst all of this political manoeuvring and techno-economic power games, real IT teams have to figure out how to secure real businesses and real data for real people trying to do their jobs. There are no blueprints for this anymore. No series of whitepapers is going to provide an "industry standard approach" to this mess.

Every organisation is different. It is going to have a different set of applications it uses, different legacy requirements and – above all – a unique middleware setup lashing all the bits together. With the era of complete customer control over their own IT firmly in the rear-view mirror trust is now the single most important commodity in tech.

Any organisation of sufficient size is going to have to outsource some of this mess. So which company do you trust? Are you willing to place your future and that of everyone you work with in the hands of a single public cloud provider? How about a collection of multiple, often competing SaaS companies? A single consulting organisation or middleware vendor?

In a perfect world, I'd partner with a vendor large enough to bully other vendors so that whatever middleware we build together has a prayer of working most of the time. I'd want my partner vendor to have enough devs on staff that they can keep up with the rapid changes of the public cloud providers, understanding, of course, that they're human and won't catch absolutely everything. I'd want them to grok private clouds and public clouds and how to move workloads between.

Above all, I'd need them to understand security concerns as relates to all these areas as well as the importance of delivering solutions that aren't full of red tape and don't feel like roadblocks to the people who now own the budget.

That doesn't leave a lot of options. Which vendors fit the bill for you? Answers in the comments, please. ®

More about


Send us news

Other stories you might like