The majority of IT leaders will at some point find themselves in the midst of a conflict between the needs of their business partners and development teams, and the real-world requirements of managing a large systems infrastructure. The conflicting goals of these groups may have caused simmering frustration just below the surface for some time, then bubbling up with new pressures on software development timelines (go faster!), budget pressures or even the recognition that there is now real competition for internal enterprise infrastructure in cloud computing vendors.
For presentation sake I am combining the Development and Business views, which may include the following:
Infrastructure View:
- Standardization lowers organizational costs.
- Control of infrastructure offerings enables a reduction in differentiation, and will increase availability.
- Infrastructure managers are graded/incentivized in large part on availability and managing costs, rather than on speed-to-market.
- When developers are allowed to dictate environmental specs, organizational resources may be wasted.
- There is theoretical potential for cost savings in the management of a large-scale environment serving many internal customers.
- It is inherently difficult to itemize cost structures for a specific dev/prod environment within a large, distributed enterprise.
Developer/Business Leader View
- Software development now needs to happen iteratively, in days/weeks, not months/years. The competition/market demands this.
- A certain amount of control and visibility into the infrastructure environment is required, which may be a politically sensitive issue.
- Developers will desire a collaborative method to manage environment strategy and offerings, plan updates and patches, etc.
- There may be a perception that infrastructure costs are higher internally than what could be fetched in the marketplace.
- Cloud computing vendors can be leveraged to requisition servers, with an OS and API of one’s choosing, within a few minutes, to support demand spikes, etc. Services can be shut down just as quickly. it may be very difficult to design for this level of flexibility internally.
- Although cloud computing vendor costs appear to be transparent and straight-forward, it may be difficult to get the same level of internal transparency for comparison purposes.
This is just a sample of the views that may be held within an organization, all valid. How to find the middle ground within this conflict, and provide a nimble enough environment to quickly respond to business needs, while at the same time controlling environmental risks, variation and cost?
My own experience has been that, after initial identification of the problem, the incentives are a great place to start.
How are development and infrastructure leaders incentivized? Are they completely at cross purposes as listed above, or do they have overlapping goals and shared skin in the game? Would a blending of goals be possible, giving infrastructure a stake in the speed with which new software is built and delivered? Could development leaders be incentivized in part based upon standard infrastructure availability metrics? With these blended/overlapping goals, wouldn’t most capable leaders be able to jointly design a solution that, while not perfect, met the organization’s needs in most respects?
Your comments are welcome. If this post was helpful, you might like to subscribe to the RSS feed, sign up for weekly updates via email or follow me on Twitter.