Are you ready for developers to be your new IT buyers
It's already likely that your developers are putting virtual machines on services like Azure and Amazon Web for development and testing, or signing up with New Relic for developer tools. None of this activity commits you to anything when it comes to deploying a service. But once they start using an API like Twilio for telephony or Azure DB for storage, or MasterCard's fraud scoring API, or the AccuWeather prediction API, or ABBYY's Cloud OCR service or Melissa Data's Address Check service, or any of dozens of other cloud APIs and SDKs that would be useful in the apps they're building then they're not just making decisions about tools for building apps with. They're making strategic decisions about what services your business will use.
And they're buying those services not through central purchasing accounts, but with individual developer accounts that they set up, that you have no easy way to keep track of.
The developer stage of guerrilla IT
This is the next stage of guerrilla IT, from your developer teams rather than from line of business units. Your next phone system might arrive not because the facilities team negotiate a contract or the IT department installs a unified communications service, but because a developer building an app that needs voice calls signs you up to Twilio's Elastic SIP Trunking VoIP service.
[Related: Why the enterprise cloud needs shadow IT to succeed]
It's a trend Twilio CEO Jeff Lawson calls "the composable enterprise" because he believes "Composable APIs have already turned developers into substantial buyers of technology inside the enterprise. This is an extension of a 20-year trend where technology buying responsibilities are moving from the CIO to line of business to pieces of apps bought by developers."
Developers pick tools and services they're familiar with and that they believe will solve their problems. That's a major change in technology buying, and it's proving to have some big advantages for your business. "It used to be you sign a check and then you find out if this technology you bought solves your problem," points out Lawson. "This puts the developer up front and it puts figuring out if the technology solves your problem up front. With lightweight APIs, they're easy to adopt and easy to figure out if they work, often before you have to pay anything for them."
Letting developers buy technology piecemeal has implications for how you pay for technology. It can be hard to track your IT spending if more and more of it shows up on employee credit cards. And as APIs spread from IT-centric services like data cleansing into standard business services like telephony, your developers may not have enough expertise on pricing to know if they're getting a good deal.
Some businesses have found their BYOD pilots costing more than their entire company-provided device program, because the amount allocated to cover user data plans was far higher than the tariffs an experienced facilities team could negotiate with a carrier (and users in the pilots claimed the full amount, however much their actual bill came to).
On the other hand, your data center is far more likely to be energy efficient if the electricity bill goes to the IT team than if it's picked up by facilities management, because then you have both the expertise and the incentive to get those costs down.
Tapping developer expertise for choosing and buying services can free up IT to be more strategic themselves. "The value an IT department brings to the table is less about the racking and stacking and the buying process these days," Lawson points out "As things become easier and easier with cloud, the role of IT is increasingly oriented towards customer facing solutions and adding value."
Embracing change, the benefit of developer involvement
Cracking down on what your developers are buying can be counterproductive. "Two years ago, our number one customer let us know they were leaving the service," explains Brian Harry, who runs Microsoft's Visual Studio Online cloud service for developers. "We asked why and they said we started this as a side thing and now management has found out we're doing this and management has not approved using the cloud for company assets' so they wanted to move back to on premise systems."
[Related: CBS Interactive CIO says shadow IT is an opportunity]
The Visual Studio Online team helped the developers migrate their code and accounts in Microsoft's Team Foundation Services. "But nine months later we got another call saying they wanted to come back," Harry remembers. The developers missed the simplicity of the cloud service, and the regular updates and new features, so they'd talked their management team into signing off on cloud.
That means the development team at a business changed not just a single purchasing choice but the whole company attitude to cloud services. "It's about time, and comfort and understanding the value of a cloud service and how to avail yourself of that," Harry suggests.
It's also about being able to manage and monitor what your developers are committing you to, and what you're getting in return. That means you may want to use tools like the cloud service monitoring in Microsoft's Azure Active Directory Premium (which also lets you take control of the accounts developers use for Azure services) or identity management systems like Xceedium's Xsuite (which lets you manage AWS accounts as well as Office 365 and VMware vSphere).
It makes sense to keep track of developer accounts alongside the admin accounts you already need to manage, to make sure you can access the services you're relying on if the original developer is on vacation or leaves the company.
And once you start relying on the services that your developers are choosing and buying to run your company, you need to care about service availability and performance (as well as any financial implications if they don't meet their SLAs). You need to do initial due diligence for evaluating service and terms of service, and plan for ongoing monitoring (tools like Apigee, Mashery's API Management or APImetrics' API performance monitoring and analytics will help here, or you can use something like Azure API Management to offer approved APIs ready for developers to use).
But you want your developers involved in the technology decisions. Lawson suggests that developer buying, "can be substantially less risky because the risk is tied to the size and the scope of the project." That doesn't mean unpicking a bad decision will be painless, so whatever tools you pick to manage this trend, the first thing to do is find out what your developers are already buying for you and set policies around how that happens.
Like cloud purchasing by line of business teams, developers buying services that become increasingly strategic is a genie that isn't going back in the bottle.