Recently I came across a blog post written by Mark Pascall from web development company 3Months. Pascall was reflecting on what he’s noticed while looking at RFP/RFI documentation and associated briefings. His location means that much of this work comes from Government organizations and with this comes a tendency to have a conservative approach towards IT – both in terms of where applications reside, and what tools are used to build those solutions. At a recent briefing, the vendors were informed that the IT manager (who was one of two people evaluating the proposals) had a preference for a Microsoft Sharepoint solution and that the solution would be hosted in-house.
Pascall diplomatically concedes that he doesn’t have enough information to accurately assess whether in fact Sharepoint is the best solution for the task at hand, and similarly we don’t know the sensitivity level of the data the application will have access to so aren’t able to definitively comment on the in-house requirement, but this situation does raise some interesting questions about IT’s involvement in procurement processes around technology
In the old days (read, five or more years ago). It was IT who would have to run solutions – both from an application management and infrastructure operations perspective. As such it was critical that they have an active role in the procurement process – there’s no point building an application that won’t work on the infrastructure it’s destined to reside upon after all. But the world has changed and things are now different. The breaking down of the silos between the business, development and operations was something I talked about at length at the recent DevOps conference in Israel – in my keynote I talked about the macro changes that are occurring and how the reinvention of the business-development-operations relationship was necessary to deliver on the changing demands for business.
We’re already seeing this occurring – I wrote recently about how force.com is democratizing the development process and with it the business can start to create their own applications using business data without any involvement from the development or operations part of the organization. Similarly, even when a problem requires the creation of a custom application which can’t be build on a force.com-like highly declarative platform, the rise of PaaS solutions means that operations needs no involvement in the application space. And even at the lowest of levels, when applications are built upon raw infrastructure – a rise of automation tools and platforms means that much of the heavy lifting of operations can be automated.
Which brings us back to Pascall’s post. Reflecting on the stated customer requirement for a specific solution and hosting arrangement, he rightly points out that:
when vendors hear that there is a preferred technology platform they tend to translate this to “no point in responding unless you say you are going to do it in that technology”. Also our experience is that for a new vendor to host a web application within an IT department’s infrastructure tends to introduce risk/time/cost to the project. Your average IT department has a lot of processes and procedures (rightly so) set up over many years to ensure that risks are minimised and internal systems run smoothly.
Of course IT would justify this increased control and complexity using it’s rote answer – as Roman Stanek from GoodData wrote recently when discussing enterprise software sales, it’s all about requirements for the “-ilities”: scalability, reliability, security, availability, and so on. Sure that’s the answer that IT gives, but how valid is it really given this brave new world where silos are being broken down, self service is possible and easy and the business can take responsibility for much of what it needs?
The role of the moderns IT department, CIO and Operations Team is changing and the rise of agile methodologies, self service, cloud, mobility and agile changes their landscape forever and, in my view at least, for the better. I’d go out on a limb and suggest that, at least for a significant proportion of solutions, there is no real need for IT to be involved in the evaluations and buying process. Sure there needs to be some broad scoping done, and IT has a role to set some boundaries within which the business can work, but beyond that IT’s job is, first and foremost, to get out of the way.
Of course more cynical folks would suggest that IT’s demands to be a central part of a procurement process have more to do with a desire to seize and hold on to power than they do with ensuring the safety of the organization. But in part it is also caused by cultural and human issues. IT doesn’t know what it doesn’t know. And it’s in the middle of a broken, siloed and adversarial situation that helps no one. Which brings me full circle to the main point of my keynote at DevOpsCon – this is not a technology problem looking for a particular solution. Rather this is fundamentally a human issue.
IT can no longer justify being the department of no. Rather it needs to find its way to being a genuine partner of the business – it needs to help set parameters and then simply get out of the way. Trying to shoehorn a consumerized technology landscape into a strictly command and control organizational structure doesn’t work. IT needs to be reinvented and rationalized Yes it will cause pain and there will be plenty of people who feel disenfranchised and marginalized, but for any organization that wants to be about outcomes, and not simply process, there is no other option.