Capacity challenges
(No Ratings Yet)
Loading ...
The aggregate supply of computing resources far outstrips the valid demand in many businesses; “considerably less than have of [installed] IT capacity is actually used,” according to the Financial Times, and rates as low as 5-10% are reported. Why is this?
In shared mainframe environments, the engineering of the hardware and the management of its computing capacity is the concern of a capacity team usually aligned with the operations group. However, this model was not followed when distributed infrastructures became prevalent. A large distributed application project might have server engineers assigned, but these engineers are typically only held accountable for the runtime success of the project, not the overall enterprise utilization of computing resources. There is also a strong assumption that the servers are “owned” by the application; sharing capacity, while it does occur, is not a prime consideration, and often entails political wrangling that the mainframe model did not encounter.
Furthermore, the variety of server and middleware architectures available to the application teams is so wide that sharing becomes very difficult; the server configurations are simply not consistent enough.
All of this is well known; however, the excess capacity problem has recently been picked up by Nicholas Carr in his critique of the corporate IT capability – to him, it is further evidence of “wasteful IT spending.”
This is ironic, as Carr (echoed by Gartner Research) has also been calling for the further decentralization of the IT capability. It is precisely this decentralization that has led to projects acquiring and treating overpowered infrastructure as “theirs” and not to be shared. If the goal is truly to reduce “waste,” then a strong centralized model with enforcement of consistent architectural standards is a must.
This does not necessarily mean a complete throwback to the mainframe days. The most interesting developments in this area are the emergence of dynamic provisioning architectures, in which standard technology stacks can be quickly created in response to new project demands, or even fast-changing transactional loads. However, even this model will require stronger architectural governance. A standard stack means for example a single preferred Java application server, middleware, and many other elements that have been far too diversified. Some variability can be supported - certainly more than the monolithic mainframe - but each degree of freedom comes with a cost of management.
The usual arguments over governance will ensue; “we need XX infrastructure because our business needs are different,” but if hard dollars are to be saved in addressing capacity underutilization hard decisions will have to be made.
Comments
Got something to say?
[More Help]