FotolEdhar - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Embedded IT vs. central IT: Finding common ground

ITSM expert George Spalding says that the key to solving problems between embedded IT and central IT is a common language based on services and not technology components.

This article can also be found in the Premium Editorial Download: CIO Decisions: The future of IoT: New priorities and paradigms:

Shadow IT can manifest itself in many ways across companies of different sizes and in different industries -- from an IT staff that is embedded within a business unit to technology purchases made by individual users within that business unit. In this Q&A, George Spalding, vice president of IT service management consultancy Pink Elephant, puts a lens on the relationship between emdedded IT and central IT. He says the key to solving problems between the two groups hinges on bringing them to the same table and then establishing a common language centered around the concept of services rather than technology components.

Editor's note: This interview has been edited for length.

Let's talk about how CIOs should respond to the emergence of shadow IT.

George Spalding: In many organizations, the individual departments have, over the years, decided probably through real experience that they don't trust central IT. They don't trust that they'll [complete projects] within a certain budget and they don't trust that they'll meet their deadlines. And the worst part is that they don't trust that [they are] a priority to central IT. So [the business units] start to invest in their own IT shop, which we call embedded IT. And that business unit is usually looking for pretty specific solutions to their specific problems. That's been going on for 20 years [and it's] getting worse rather than better.

These individual business units do not fully understand just how out on the limb they are when they [contract directly with an outsourcer].
George Spaldingvice president, Pink Elephant

A couple things happen in the relationship between central IT and embedded IT. At some point the embedded IT group has to contact central IT and say, 'Yo, I've got this new thing coming online and you guys have to get me a server, and you guys have to put it online, and you guys have to do this and this and this.' At that point, we have a real disconnect in this world of IT service management. The disconnect is that the main IT group is -- hopefully, if they're in IT service management -- involved with what we call services.

The problem is the embedded group didn't ask for a service; they asked for a server. So they shipped a four-page spec sheet to central IT, central IT buys the box, sticks it on the network, gives them the root password and walks away from it. [The embedded IT team] then takes over. The customer, which is the business unit, now is using the new solution and complaining to their embedded IT group that it's too slow or too this or too that. The embedded IT group almost always blames central IT. And it may indeed be their fault, but no one ever told them what they really wanted.

Instead of a server with a bunch of technical specs, [the embedded IT group] should have called up and said, 'Hi, I need you guys to host an application and I need it to be fast.' IT would say, 'Well, how fast do you want it to be? How many transactions do you think you're going to have at the same time? How big is a single transaction? How much storage space does it take? How many people do you think you're going to have simultaneously?'

So, step one, we have to get the different pieces of IT talking to each other in terms of services. We should define our IT shop by IT services: How many services we offer, what we offer. And we should get specific about those services: How good do we offer them, how well do we provide them, how available are they, how fast, etc. Then that becomes service levels. And those then finally make their way into a service level agreement.

So these problems have been around for a while. How do newer developments like cloud, BYOD, mobility and so on, figure into this equation?

Spalding: Everyone says, 'We're gonna do cloud, so we don't really need configuration management. We're gonna do cloud so we don't need ITIL or ITSM anymore.' But you're still providing services to the business, aren't you? 'Well, yeah.' Well, where are you getting it from? 'We're getting it from a SaaS [software as a service] product, we're utilizing the cloud and all we're doing is front-ending.' Well, where you get the components of the service that the IT group provides to the business [doesn't matter]. You are [still] the accountable party for providing the service to the business and the business customer. Period. There's no conversation here. You can't outsource accountability. There's no way to do that. You can't do it for an auditor, you can't do it under compliance rules, you just can't do it.

I get asked, 'How much stuff should I push the cloud provider for?' And my answer is, 'How much responsibility do you have to provide the service that the cloud provider is underpinning? [If you're totally responsible] I'd get real interested in what the cloud provider's security is and what your service-level agreement with the cloud provider is.'

This presumes the lines of business are going through IT in some fashion (making the correct request is another thing). But what about business managers who have control of the budget and they're spending that money without IT's involvement? Is that a new and special concern?

Spalding: It's not as new as some people think it is. Outsourcers have been going directly to the business for years, certainly for a decade. The problem that has always happened when the business cuts the deal directly with the outsourcer is that the outsourcer is in these negotiations and cutting these deals every day. It's what they do for a living, so they're very good at the contracts. They're also very good at making the contract as long as possible. [They make] money, not on the day-to-day [work] that you're committing to; [they] make money on the changes. They know your business is going to change over time; therefore, the longer they can keep the contract, the more money they will make with the changes.

So, they go right to the business, or the business goes right to them. [The business leader says], 'I'm fed up with my IT department. I want to buy stuff directly from you.' And [the outsourcer says], 'Oh, OK. What do you want to buy?' And [they] haven't even talked to IT. [The product] shows up and things work for a while. And then there's a support issue because something went wrong.

So who do you call? You have to call the outsourcer. And the outsourcer says, 'Well, in our contract, we have the following time frames for support and replacement and uptime.' [The business unit is] now on [its] own. They can't really expect support from IT, they can't expect help from IT, because it's not an IT product, it's not an IT service. They're on their own. That's the part that I don't think they fully comprehend. These individual business units do not fully understand just how out-on-the-limb they are when they do that.

How should that problem be solved?

Spalding: The way to solve that particular part of it is that you pass a law inside the company that says technology purchasing has to go through a certain purchasing process, [such as] if it's over a certain dollar amount it needs to go through a certain person. That way we get a flag that says, 'I'm about to sign off on a contract for $200,000. Have you heard about it?' Somebody from IT has to sign off, or at least they're notified, if nothing else.

But let's assume that what we really want is [for them to] start talking to each other. We would like a common language and for everybody to say, 'I see where you're coming from, and I'm willing to go in that direction.' To me, the answer ends up being services. In other words, if we are in the services business and if they involve IT in the provision of services, then we can all focus on having that service be successful, no matter where it's coming from. If they're coming from the embedded group, if they're coming from the central group, if they involve an outsourcer or a cloud provider or a SaaS provider, if it's coming from outside, no problem. We're still basically centralizing something that says, 'This is the name of the service that we're providing.'

It's that definition of a service that enables us to have the conversation that we're trying to have.

How do they change the purchasing process and have that conversation? It seems like a simple solution but …

Spalding: Well, [the purchasing process requirement is] a nice operational thing. At least we get notified, somebody has to initial a purchase. But we really haven't won any hearts and minds with that stuff. The only way that IT can, in the end, win this game is they have to become the provider of choice. IT has to do such a good job that they're the ones I always want to go.

And -- here comes the part that IT has a tough time with -- let's just say I'm a really good IT shop and I'm swamped; I've got a backlog of projects and now a business unit says, 'I need this and I need it in three months.' Right now, we see IT saying, 'Sorry, I can't do it.' Wrong answer. IT has to say, 'What did you say, three months? OK. Give us a day and we'll figure out how we're going to do it.' So the answer is not no; the answer is yes. IT might say, 'We're going to completely outsource this project, and we'll manage it and here's the timeline.' Then, they can be held accountable. And IT should be held accountable. [But the business unit has] to come to us first, and IT has to say yes instead of no. And then IT becomes the provider of choice.

Frankly, the business unit doesn't care who actually wrote the damn thing. They just want to solve their business problem. So why wouldn't we go outside? Think of building a house. If I'm a general contractor, do I do the electrical work myself? No, I hire an electrician. Do I do the plumbing? No, I hire a plumber. I hire a bunch of subcontractors, tradespeople to do the work. So why wouldn't IT adopt that same basic concept and be the general contractor providing the service to the end customer? It's exactly what's going to happen.

So if the default answer from IT is yes instead of no, would that then lead to the conversations you're saying need to happen?

Spalding: Well, it would lead to the best conversation that we ever have with businesses. And that's money. Because, really, the answer is, 'Yes, I can provide that service to you, here's what it will cost.' And the business then has to evaluate from a business standpoint whether it's worth it.

You make it all sound so simple.

Spalding: It is simple as long as people aren't involved, as long as there's not ego and poliitics and history involved.

Next Steps

Explore outsourcing best practices for CIOs in this Essential Guide

How does John Deere enable two-speed IT successfully?

This was last published in March 2015

Dig Deeper on Enterprise ITIL and ITSM

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

4 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Has your company established a common language between central IT and embedded IT based on the concept of services? If so, how was that established?
Cancel
Even with all of the issues our company has, I will say that our governance framework is pretty good, based primarily on ITIL for general IT operations and agile for development. All of our 'embedded' people (if you can call them that) came from IT first, and we have an active say in hiring if any other group tries to hire for 'shadow IT'. So far so good. It's been pretty successful for everyone.
Cancel
It was interesting reading Spalding’s comments. As I was reading I kept thinking that this sounded very similar to the way I’ve seen some of the teams within our IT department operate. Over the course of several years, many of the teams have evolved to include their own embedded IT group, and there was generally a disconnect every time the embedded team needed to interact with the central IT group. Publishing a service catalogue and establishing a vendor management program have gone a long way in identifying that common ground between the two groups.
Cancel
I'm at a University that distributed their IT when they embraced distributed computing. We're becoming a cloud provider, even tho we really are central IT, with some large level of success. The key is getting your traditional IT staff to start thinking of delivering service instead of technology, then to deliver that service in the way that the business units, or Faculties in my case, want to consume it. Which is largely the cloud model of fast, easy, and cheap. It hasn't been an easy transition, but in some groups, like our server team, they have nailed it, and are now extending that same cloud service of virtual servers/storage to other institutions in the Province.
Cancel

-ADS BY GOOGLE

SearchCompliance

SearchHealthIT

SearchCloudComputing

SearchMobileComputing

SearchDataCenter

Close