From Chapter Two: The appliance computing culture

This is the 23rd excerpt from the second book in the Defen series: BIT: Business Information Technology: Foundations, Infrastructure, and Culture

Note that the section this is taken from, on the evolution of appliance computing, includes numerous illustrations and note tables omitted here.

The iSeries data center tour

Sample best practices

• Use of packaged applications

  The distinguishing best practice in application appliance computing is the absence of development programming.

  The IT department focuses on providing direct services to users and limits code development to small scripts or one-offs designed only to facilitate business operations - often for things like accommodating merger or business partner service requests.

• Use of graphics based display

  Smart displays are characteristic of the environment and a widely recognized best practice in the iSeries world.

  The smart display gives users secure, high quality, and fast access to the central resource without the limitations of block mode or older style terminals and without the cost, complexity, and reliability issues associated with use of desktop personal computers.

• An SLA [Service level agreement] may exist but user control is not primarily exerted through the annual budget process.

  In the mainframe world the service level agreement is the contract between the data center and the user community. This is the peace treaty in the battle for resources and control between user groups and the data center. As such it governs expectations and is renegotiated annually as part of the budget process.

  The SLA is sometimes a critical control document in the application appliance community too, not because it applies, but because so many of its managers came from, or learned their trade in, the mainframe environment. In that environment the systems manager gets his organizational clout as a creature of Finance - giving him both an after-the-fact approach to information processing and the invulnerability to short term business pressures that come from being part of Finance.

  The mainframe SLA therefore developed as a user counter to the power and control wielded by an IT group safely divorced from responsibility for business results but, in the mini-computer world, this split didn't happen. Except for the IBM System 36 and its predecessors, minis were generally brought into businesses and other organizations at the sharp end - as part of a business initiative to cut costs or do more. As a result the conflict with users didn't generally arise until control of those systems moved from business hands to administrative hands, often through re-organizations and the hiring of former mainframers in corporate attempts to gain control of chaotic computing environments created when business users brought in several different mini-computer systems.

  It is important, therefore, in deciding whether or not the SLA is a valuable control document, to first assess the relationship between users and the computing services group. Where there is no war, the peace treaty is pointless.

• Strong business focus in planning, staff development, and relationships

  Business management, not IT management, should direct IT policy - not through the annual budget basis but on a day to day working relationship basis.

  Bear in mind that mini-computers were originally brought into organizations by users who added IT responsibilities to their other functions and saw the machine as just another business tool. Thus staff exchange, in which IT staff take on line jobs and some ordinary business users temporarily take on IT functions, is a best practice. More importantly, IT management should always encourage staff to interact with users and empower staff to act immediately on user requests.

Some notes:

1. These excerpts don't (usually) include footnotes and most illustrations have been dropped as simply too hard to insert correctly. (The wordpress html "editor" as used here enables a limited html subset and is implemented to force frustrations like the CPM line delimiters from MS-DOS).

2. The feedback I'm looking for is what you guys do best: call me on mistakes, add thoughts/corrections on stuff I've missed or gotten wrong, and generally help make the thing better.

   Notice that getting the facts right is particularly important for BIT - and that the length of the thing plus the complexity of the terminology and ideas introduced suggest that any explanatory anecdotes anyone may want to contribute could be valuable.

3. When I make changes suggested in the comments, I make those changes only in the original, not in the excerpts reproduced here.