October 17th, 2009

Of snow, rocks, a book, and another partisan attack on IBM

Posted by Paul Murphy @ 12:15 am

Categories: Defenestration, Enterprise Policy, General, Government, Sun

Tags: Sun Microsystems Inc., IBM Corp., Attack, Oracle 11gR2, Mainframes, Servers, Security, Hardware, Paul Murphy

Merry Christmas!

I’ll be out of town later this week so I’m writing this on Wednesday - between staring out the window at gently falling snow and contemplating the tragic reality that if the present solar minimum leads to massive crop failures around the world next summer, Gore et al won’t be among the two billion or so facing starvation as a result of policies they advocate - policies favoring the conversion of food to SUV fuel, the doubling of fertilizer prices, and the near elimination of critical pesticides and herbicides.

Speaking up for IBM.

Here’s a bit from an article by Information Week’s senior editor Bob Evans about a justice department decision to go after IBM on anti-trust charges:

I was going to say that it’s almost incomprehensible that Justice is preparing to once again mount a vague, circumspect, and generally unsubstantiated attack on one of the most creative, innovative and valuable companies in the world, but that would be unfair. Because there’s no “almost” about it - to anyone outside of the Justice Dept.’s giant-shoe red-nose horn-honking clownish view of the world, this grandstanding effort to attack IBM and teach the company its proper place is completely and 100% incomprehensible.

If it weren’t so pathetically and potentially misguided, it would almost be funny. But it’s not -no, not by a long shot.

Perhaps I’m out of phase on this, and perhaps all of us should sleep more comfortably knowing that our Attorney General’s trust-busting warriors are out there protecting all of us from IBM’s devious schemes to dominate -yes, to monopolize -the mainframe market.

While I think that IBM regularly resorts to non market means (e.g. the courts, the press, financial markets, and politics) to go after competitors they can’t beat in the marketplace and that this often amounts to legal but dishonorable conduct, the reality is that Evans is right here. For the U.S. Justice Department to after IBM on its mainframe business is unfair, unreasonable, and utterly perverse because that monopoly is not sustained by anything IBM does - on the contrary, from the Future Systems project to PowerLinux, IBM has repeatedly and honorably invested real money and corporate goodwill in trying to break customers out of that ghetto - but by the insistence and loyalties of a customer base that’s forty years out of date and absolutely refuses to advance.

The bottom line on this is simple: if the customer demands the right to buy mainframes at dollars to the value penny, then the customer’s bosses should fire him but IBM’s executives owe it to their shareholders to take the money and run - and if Holder wants to prosecute somebody on this, he could perhaps be reminded that most data processing managers are middle aged white guys who pay taxes and vote Republican.

That Sun TPC/C thing

The single best report I’ve seen so far from the Oracle OpenWorld techfest is by Ben Rockwood. Here’s what he says about Sun’s TPC/C benchmark result:

Larry drove the point about synergies between Oracle and Sun home in 2 ways. The first was talking about the previously released Sun/Oracle ExaData v2 product (pictured above). The second was to show that Sun’s technology today, pre-acquisition, is the best platform available for Oracle even against IBM’s monster POWER 595 system which consumes 76 standard racks. Sun’s solution that beat it consumes only 9 racks, is fault tolerant, based on SPARC (Niagara), got 25% more throughput, gets 16 times better response times, and obviously uses a hell of a lot less power to boot.

I had a conversation with the PAE guys there and got a lot of great details on the configuration and how they made it work. Here are some highlights…

So the Sun system that beat out the 595 was based on T5440 (UltraSPARC T2) systems connected to the new F5100 Flash Array. In order to make all this work in a fault tolerant way COMSTAR was used and throughout the process required absolutely no modification! Apparently the biggest “problem” they ran into some some minor tweeking in the mpt and sd drivers because they weren’t designed to hand the extreme number of IOPS coming from the flash arrays. More shockingly, when they got the TPC-C number that beat IBM the CPU’s were 50% idle! And, if you can believe it, during the whole time Sun was working on this benchmark of all the flash modules involved, only a single one failed! Just one!

Ok, it’s not ROCK (which technologies by the way, are up for resurrection!) but beating IBM with a production ready, off the shelf system, providing nearly instantaneous response at 50% CPU sure rocks.

Oh, and the most interesting thing at OpenWorld for non Sun users? Oracle 11gR2 has a flash memory extension of the SGA - add:

db_flash_cache_file = /lfdata/lffile_raw
db_flash_cache_size = much more than ram (e.g. 128GB)

to your setup file, mount an F20 Flash Accelerator card in a PCIe slot, and those nasty OLTP transactions that access some enormous working set suddenly go a lot faster. This is dumb in a Solaris/ZFS environment, but brilliant everywhere else because it makes the system’s biggest bottleneck disappear for peanuts.

Blackbelt IT?

And, speaking of opportunities for failure .. things are a little slow right now, so I’m about to dive into the long delayed business of rewriting the infamous Unix Guide to Defenestration series as a single book.

Since it really has two messages and two audiences: a strategic one aimed at senior executives telling them that IT should be delivered by IT professionals but run by user management; and a tactical one describing how Unix can be combined with smart displays to provide the efficiencies of centralized processing with the business value of fully decentralized control; pulling this together is going to be a neat trick - and one that probably requires a new title.

I’m wondering about “Blackbelt IT”, but if anyone has a better suggestion (and no copyright aspirations), I’d sure be happy to hear it.

March 27th, 2009

From Chapter Four: The Unix and Open source Culture

Posted by Paul Murphy @ 12:15 am

Categories: Defenestration

Tags: Data Center, Open Source, Data Centers, UNIX, Operating Systems, Storage, Hardware, Data Management, Software, Paul Murphy

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

Controls

The most important thing to note about the operation of a successful Unix data center is the relative invisibility of hierarchal control. Most people work in teams that form for specific projects and disband just as quickly. Management facilitates, it does not direct. Most new work is user initiated, annual budgets are more or less fixed but re-allocations are done on the fly. Most of the CoBiT controls simply do not apply. Most of the process documentation expected by the traditional auditor has no internal purpose and either does not exist or exists only in a form designed to satisfy an auditor.

The concerns underlying many of the CoBiT controls apply, but the way these are addressed is very different. For example, the Unix data center will have documented backup and recovery processes, but the emphasis will be on the processes, not the documentation. An audit test will consist of someone pulling the power plug on a machine - a routine drill - not of someone pulling a plan out of a filing cabinet.

The fundamental Unix control is functionality. Users are active participants in systems operations and decisions. When asked, for example, why there is no formal service level agreement, a Unix CIO to whom you explained the concept is likely to say something like: “most of my team members are, or think they are, users; why would we have a peace treaty when there hasn’t been a war?”

Because a well run Unix environment requires very few technical staff but places significant technical and managerial demands on those few, succession is almost always a problem.

Three things tend to happen:

1. In larger shops people who train up to the point that they can take over operations, tend to leave this stable environment for one where they can more effectively advance their own careers - thereby leaving the organization bereft of internal successors;
2. In smaller shops the company tends to grow dependent on a key individual. Over time that person will accumulate small conflicts with more traditional managers in the organization who seize power over Systems as soon the key person leaves - and often plunge the whole organization into chaos as they bring in people from other computer cultures who then attempt to impose their inappropriate, but more orthodox, views; and,
3. In mergers or acquisitions the larger, more entrenched, IT group tends to dominate - and that’s usually not the Unix shop because their budgets tend to be much smaller and the IT head tends to lack organizational visibility precisely because his systems work.

Thus the most important question to ask in a small organization with a well run Unix data center is: “does top management know and value what they have?” If they don’t, succession will be a problem when the key person leaves and the company will be at risk of systems failure when it happens.

---

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.

March 20th, 2009

The Future of Unix

Posted by Paul Murphy @ 12:15 am

Categories: Defenestration

Tags: Plan 9, UNIX, Operating Systems, Software, Paul Murphy

Present day commercial Unix versions are well behind the research community. As far back as 1982 the single machine focus of Unix development became an issue in the research community. Accordingly a number of people at Bell Labs including Dennis Ritchie and Rob Pike, both of whom had contributed to the origination of Unix, decided to try to design a truly network based machine operating system.

Plan 9, named after the movie Plan 9 from Outer Space (itself full of bad puns and a defining moment in the history of “B” movies) rethought core Unix ideas about how to implement system resource allocations in the context of a large network rather than a single computer. Thus the original Unix focus on using one machine as a communication nexus among many users was extended in Plan 9 to multiple networked machines - all with multiple users.

Here’s a bit from a paper by Rob Pike and six of his colleagues explaining part of the impetus behind it:

Plan 9 began in the late 1980’s as an attempt to have it both ways: to build a system that was centrally administered and cost-effective using cheap modern microcomputers as its computing elements. The idea was to build a time-sharing system out of workstations, but in a novel way. Different computers would handle different tasks: small, cheap machines in people’s offices would serve as terminals providing access to large, central, shared resources such as computing servers and file servers. For the central machines, the coming wave of shared-memory multiprocessors seemed obvious candidates. The philosophy is much like that of the Cambridge Distributed System [NeHe82]. The early catch phrase was to build a UNIX out of a lot of little systems, not a system out of a lot of little UNIXes.

The problems with UNIX were too deep to fix, but some of its ideas could be brought along. The best was its use of the file system to coordinate naming of and access to resources, even those, such as devices, not traditionally treated as files. For Plan 9, we adopted this idea by designing a network-level protocol, called 9P, to enable machines to access files on remote systems. Above this, we built a naming system that lets people and their computing agents build customized views of the resources in the network. This is where Plan 9 first began to look different: a Plan 9 user builds a private computing environment and recreates it wherever desired, rather than doing all computing on a private machine. It soon became clear that this model was richer than we had foreseen, and the ideas of per-process name spaces and file-system-like resources were extended throughout the system - to processes, graphics, even the network itself.

By 1989 the system had become solid enough that some of us began using it as our exclusive computing environment. This meant bringing along many of the services and applications we had used on UNIX. We used this opportunity to revisit many issues, not just kernel-resident ones, that we felt UNIX addressed badly. Plan 9 has new compilers, languages, libraries, window systems, and many new applications. Many of the old tools were dropped, while those brought along have been polished or rewritten.

Why be so all-encompassing? The distinction between operating system, library, and application is important to the operating system researcher but uninteresting to the user. What matters is clean functionality. By building a complete new system, we were able to solve problems where we thought they should be solved. For example, there is no real ‘tty driver’ in the kernel; that is the job of the window system. In the modern world, multi-vendor and multi-architecture computing are essential, yet the usual compilers and tools assume the program is being built to run locally; we needed to rethink these issues. Most important, though, the test of a system is the computing environment it provides. Producing a more efficient way to run the old UNIX warhorses is empty engineering; we were more interested in whether the new ideas suggested by the architecture of the underlying system encourage a more effective way of working. Thus, although Plan 9 provides an emulation environment for running POSIX commands, it is a backwater of the system. The vast majority of system software is developed in the ‘native’ Plan 9 environment.

Plan 9 is open source and available from the vita nuova site.

The ideas behind plan 9 represent much of where Unix is going today - with Sun, in particular, developing many of these ideas in Solaris, the technically most advanced Unix variant, by concurrently expanding its OS vision outwards through network manageable resource allocation and inward to multi-core SMP on a chip.

---

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.

March 13th, 2009

From Chapter Four: The Unix and Open source Culture

Posted by Paul Murphy @ 12:15 am

Categories: Defenestration

Tags: Noorda, UNIX, Operating Systems, Open Source, Software, Paul Murphy

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

Roots (2)

In its present form this commitment to publication and peer review, originally derived from the core academic and scientific approach giving rise to the science breakthroughs achieved in the forties and fifties, has given shape to the open source movement.

Thus as early as 1973, universities were given more or less open access to Unix system code and its ideas then became the nucleus around which significant communities of expertise developed at centers like Berkeley, MIT, and Carnegie-Mellon, among many others.

That early geographical clustering of expertise around machines and Computer Science or Engineering faculties led to an explosion in Unix variants and the research that went into them. As a process this wasn’t very different from what we see in open source development today. Time scales were longer mainly because the people involved worked in smaller, more isolated, clusters because pre-internet communication methods took too long to allow geographically dispersed teams to form and succeed, but the basic processes of open peer review and contribution haven’t changed.

In 1976-77 for example, Ken Thompson, one of the key originators of Unix, took a six-month sabbatical from Bell Labs to teach at UCB (The University of California at Berkeley) where he laid the foundation for what became the Berkeley Software Distribution (BSD) series of Unix releases on DEC PDP and VAX equipment.

Thus the “release early, release often” strategy that supports the evolution of Linux today, applied equally to the evolution of BSD Unix in the late seventies and early eighties. The key difference is simply that a new Linux kernel release can now be made available in minutes to thousands of people without regard to physical distance but, in 1981, ground breaking Unix development work at Berkeley became immediately available to only a handful of local colleagues while people at places like Rutgers or The University of Alberta either waited three months for a new distribution tape or invented their own solutions.

The other phenomenon we see today, businesses like Red Hat trying to use open source for commercial advantage, existed then too. Noorda’s Novel networks, for example, started by commercializing network technology as a means to implement device sharing. Here the difference in time scales is far less: it took two years to get a business off the ground then, and it takes about that now.

This “trial and review” process was not understood in the seventies and eighties with the result that the traditional assumptions about code development and the power of externally imposed standardization often prevailed - particularly in textbooks and among the press.

Most of the business press therefore saw the proliferation of operating systems research ideas expressed in multiple Unix releases as evidence of fragmentation and a loss of direction. They, therefore, referred to `the Unix wars” as if their assumptions reflected reality and indeed a few of these mistaken beliefs were later made real when some of the more successful commercial Unix users started to make management decisions based on them.

For example, Digital Equipment Corporation signaled the beginning of its own end when it joined with its dominant competitor, IBM, (and seven smaller competitors) to create the Open Software Foundation (the OSF was folded into X/Open in 1994 and is not be confused with the FSF, Richard Stallman’s Free Software Foundation) in 1988 ostensibly to establish a common Unix but in reality mainly to try to limit Sun’s explosive market growth.

By 1983, however, most major universities in the US and Canada had Vaxes running Berkeley Unix and were contributing members of Usenet - an internet precursor built using an application called “UUCP” - Unix to Unix Copy- that moved email and other documents between systems. Thus geophysically dispersed teams started to come together right about the time that TCP/IP and Sun’s NFS (network file system) started to both multiply and accelerate the connectivity links between people.

By 1985 Unix users almost anywhere in Canada, the US, and parts of western Europe could communicate on-line using highly reliable circuits and what we now think of as the open source movement had began. Its most famous contributor, at least prior to Linus Torvalds, was Richard Stallman, primary author of the EMACs editor; founder of the Free Software Foundation; and originator, in 1984, of the GNU (Great New Unix) project.

The GNU project set out to duplicate the functionality of all major Unix tools in open source equivalents. “Information wants to be free” became the rallying cry as thousands of dedicated people dispersed across hundreds of sites contributed to this effort. Today GNU’s tools form the majority of every significant non commercial Unix release including Linux, freeBSD, and Darwin (which runs the MacOS X shell). They run, furthermore, on every proprietary Unix and are often the preferred tools on Solaris, AIX, IRIX, OSF/1 (although Digital is long gone, OSF/1, now morphed into Tru64, continues to be used), and HP-UX.

The basic tenet behind the open source movement is that there is social and personal value in contributing to research and the implementation of research results in software. The most widely known analysis of the resulting open source culture has been published by Eric Raymond, author of The Cathedral and the Bazaar, an important paper which can be found on dozens of internet sites.

Here’s the abstract he gives on his website:

I anatomize a successful open-source project, fetchmail, that was run as a deliberate test of the surprising theories about software engineering suggested by the history of Linux. I discuss these theories in terms of two fundamentally different development styles, the “cathedral” model of most of the commercial world versus the “bazaar” model of the Linux world. I show that these models derive from opposing assumptions about the nature of the software-debugging task. I then make a sustained argument from the Linux experience for the proposition that “Given enough eyeballs, all bugs are shallow”, suggest productive analogies with other self-correcting systems of selfish agents, and conclude with some exploration of the implications of this insight for the future of software.

From the beginning Unix has been about open computing, collaboration, and communication between people. It is a highly technical system, but its focus has never been on the technology. “The network is the computer” is a Sun marketing slogan, but it’s also the truth about Unix systems development and use: it’s the networking effect among people that counts, not the desktop or server hardware.

Thus its value as the pre-eminent secure computing platform for commercial and web based services delivery is a spin-off from the research process in the much the same way that the microprocessor and internet were spin-offs from defense research.

---

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.

March 6th, 2009

From Chapter Four: The Unix and Open source Culture

Posted by Paul Murphy @ 12:15 am

Categories: Defenestration

Tags:

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

Roots (1)

Almost everything you really need to know about Unix (or Unics as it was first known) and the open source movement can be gleaned from a paragraph in a paper Dennis Ritchie, one of the original Unix developers, called “The Evolution of the Unix Time-sharing System”:

From the point of view of the group that was to be most involved in the beginnings of Unix (K. Thompson, Ritchie, M. D. McIlroy, J. F. Ossanna), the decline and fall of Multics had a directly felt effect. We were among the last Bell Laboratories holdouts actually working on Multics, so we still felt some sort of stake in its success. More important, the convenient interactive computing service that Multics had promised to the entire community was in fact available to our limited group, at first under the CTSS system used to develop Multics, and later under Multics itself. Even though Multics could not then support many users, it could support us, albeit at exorbitant cost. We didn’t want to lose the pleasant niche we occupied, because no similar ones were available; even the time-sharing service that would later be offered under GE’s operating system did not exist. What we wanted to preserve was not just a good environment in which to do programming, but a system around which a fellowship could form. We knew from experience that the essence of communal computing, as supplied by remote-access, time-shared machines, is not just to type programs into a terminal instead of a keypunch, but to encourage close communication.

Those last two sentences, written in 1979 and so well before Linus Torvalds modified Minix to create the Linux kernel or Sun created its “the network is the computer” slogan, bear repeating:

What we wanted to preserve was not just a good environment in which to do programming, but a system around which a fellowship could form. We knew from experience that the essence of communal computing, as supplied by remote-access, time-shared machines, is not just to type programs into a terminal instead of a keypunch, but to encourage close communication.

The story Ritchie tells about the origin of Unix is a story about the resolution of conflict between business managers and visionaries when the visionaries push their invention ahead despite management opposition, and then gain their reluctant co-operation when users adopt the product and become vociferous supporters.

Management was not supportive but users were. Then, as now, Unix disrupts organizations by reducing the importance of hierarchal reporting relationships as information conduits in an organization.

That user orientation, like the focus on collaboration, was the complete antithesis of the approach taken with the IBM System 360:

IBM System 360	Unix
Within IBM, design and development of the 360 were both top down, management driven, processes.	Within Bell Labs, the design and development of Unix was driven by technical experts and adoption was driven by users.
Multi-user access to the 360, and thus development of mainframe operating systems, focussed on keeping users, and user processes, separated.	Development of Unix focussed on bringing communities of users together.
360 architecture sales were generally driven from the top down and focussed on cost cutting through job elimination and the automation of clerical tasks	Unix deployments were generally driven from the bottom up and focussed on increasing the value of user contributions and control in both business and research.
Almost all System 360 applications were developed for business use by large well funded teams working with formal management to meet externally defined business system specifications.	Almost all Unix applications started as individual or small group research and/or academic projects with clear functional goals but no formal project management or specifications.
Almost all System 360 sales to businesses were made to people who report to, or work in, corporate Finance departments.	Almost all early Unix sales were made to front line staff in research or production.

Thus where Ritchie talks about users ratifying Unix by adopting it, mainframers talk about the strength of their user access controls and the laying off of clerical workers to fund systems development work.

Most fundamentally the mainframe culture is based on using machines to replace people while the Unix culture focuses on using machines to extend the reach of individuals and communities. Thus one focusses on automatic data processing on the 1920s card based model while the other focuses on using computers to defeat both time and space as barriers to communication and collaboration.

The resulting cultural conflicts between Unix users and mainframers have never been resolved. Today some mainframe data centers run Linux on mainframes in lieu of CMS as single user server processes with tight user controls –leaving Unix experts baffled as to why anyone would ever want to do anything so obviously absurd as to incur very high costs to impose rigorous separation on a culture that’s fundamentally about cheap and effective information sharing.

The open source movement is often seen as a natural outgrowth of the Unix cultural focus on information sharing, but this view reverses the chronology. In fact, the core Unix design was influenced by open source ideas held by some of the key designers for Multics, the project from whose ashes Unix arose.

For example, in 1965, Corbató and Vyssotsky, co-designers of the Multics operating system kernel, wrote

It is expected that the Multics system will be published when it is operating substantially…Such publication is desirable for two reasons: First, the system should withstand public scrutiny and criticism volunteered by interested readers; second, in an age of increasing complexity, it is an obligation to present and future system designers to make the inner operating system as lucid as possible so as to reveal the basic system issues.

In its present form this commitment to publication and peer review, originally derived from the core academic and scientific approach giving rise the science breakthroughs achieved in the forties and fifties, has given shape to the open source movement.

---

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.

February 27th, 2009

From Chapter Four: The Unix and Open source Culture

Posted by Paul Murphy @ 12:15 am

Categories: Defenestration

Tags: Open Source, IT Staff, UNIX, Mainframes, Operating Systems, Servers, Software, Hardware, Paul Murphy

About this grouping (3)

There is a unique Unix culture, but it developed and flourishes in the research, not business, community. In the research community cost and performance pressures on individuals combined with the general absence of cross cultural contamination to produce Unix best practices like peer review, networking, user empowerment, the open source movement, and direct end user control of systems decision making.

Those management ideas have only recently started to appear in business uses of the technology as open source products have started to displace proprietary solutions.

In large part this is due to the head start other toolsets had in developing business oriented computer cultures. Large companies generally select systems managers using their experience in other large companies as a proxy for expertise, thereby failing to recognize that the skills needed to properly deploy a technology tend to reflect that technology. As a result most of the executives responsible for large Unix sites have mainframe, mini-computer, or Microsoft PC backgrounds that lead them to mis-manage Unix.

Nevertheless the Unix cost and performance advantage is so substantial that even mis-managed and under appreciated systems often become critical to corporate operations. For example many large companies are unware that they use Unix at all but:

1. Most have at least some Unix based server, storage, firewall or other special purpose appliances;
2. Most use Linux or BSD based PC servers for web and email access;
3. Most larger organizations have one or more large Unix machines in use as database servers in otherwise fully Microsoft dominated client-server architectures; and,
4. Many organizations have one or more Unix machines, often quite old ones, in their otherwise mainframe oriented “shops” -either as experiments in cost reduction or to handle tasks for which mainframe software was unavailable, excessively impractical, or simply too expensive.

To the extent that a “true Unix” architecture exists in business and administrative organizations it is characterized by highly inter-connected servers with either smart displays like this NCD or powerful engineering and graphics workstations as desktops.

When this structure is successfully ported to business environments the resulting systems architecture strongly resembles that of the original application appliance group - both use smart display desktops and central processors - and is its logical successor in terms of management methods, user focus, and required controls.

In the iSeries or mini-computer world, IBM’s artificial perpetuation of the high costs from the seventies and early eighties means that control is now highly centralized with IT staff members having little or no freedom to respond immediately to day to day changes in user requirements. Positions are intensely hierarchal; budgeting is usually annual and “cast in concrete;” and, there is a general focus on stable delivery of core functional support applications. Fundamentally IT staff work for the IT department.

In a well run Unix environment processing is centralized but costs reflect current technologies and are small enough to allow actual control to be distributed. IT staff are encouraged to adapt processing or resource allocations to user needs and annual budgets set flexible boundaries, not hard limits. Fundamentally IT staff work for users and user departments.

Unix hardware costs less, often much less, than alternatives. Obviously any machine that can run a licensed Windows OS can run a free Unix, but cost comparisons for bigger gear are far more dramatic. For example a high end iSeries can cost in excess of $4.5 million but a comparable Sun Starfire 12K runs well under two million. That contrast is even more pronounced in the mainframe world where a 72 CPU Sun 25K at just about two million dollars will easily outperform a 128 core mainframe at well over twenty-six million - and that’s before the mainframe’s additional software licensing and staffing costs, which don’t exist for Solaris, are considered.

The result is a contrast between a Unix culture in which processing power is considered cheap and plentiful versus one in which processing power is scarce and expensive. Properly implemented, a mainframe data center focusses on maximizing the use of expensive resources, but a properly managed Unix data center does opposite - it pushes control and processing power out to the users because that’s both cheaper and more effective than imposing usage controls.

Costs and processing power are important but, from a corporate deployment perspective, the most significant benefit Unix offers is not directly related to initial capital cost or processing speed. What is most significant about Unix is that its combination of reliability and continuity allows the organization to side step both the product churn characterizing the Microsoft PC environment and the financially enforced rigidity of the mainframe world.

---

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.

---

February 20th, 2009

From Chapter Four: The Unix and Open source Culture

Posted by Paul Murphy @ 12:15 am

Categories: Defenestration

Tags: Virtualization, Open Source, Sun Microsystems Inc., CPU, Mainframes, UNIX, Operating Systems, Servers, Hardware, Software

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

About this grouping (2)

The underlying change drivers here are resource cost and scale -with the cost equation reversed for Unix relative to the System 360 and its descendents.

For example, the smallest mainframe, the z8X0, starts at about $250,000 before licensing and peripherals and has one usable CPU running at about 760MHZ. In contrast, a Dell 2650 with twin 3.2 GHZ Xeon processors running Unix against a 1TB external RAID array costs about $12,000 and handily outperforms the z800 on all measures - but people who only know mainframes still buy the z8X0.

You can use partitiioning and virtualization with Unix - but it isn’t very smart

System partitioning and virtualization are mainframe solutions to mainframe cost and process management problems - but are now widely used with commercial Unix.System partitioning began as a way of splitting a multi-million dollar machine into two pieces - a large production piece and a small development piece - to enable data centers to operate both with only one multi-million dollar machine. Virtualization began as a memory management method ensuring that one programmer’s job couldn’t interfere with another’s. Thus IBM’s interactive mainframe OS: zVM; depends on virtualization to separate users while the underlying SP layer allows the z900 hardware to be partitioned to form up to 15 logical machines each of which can load zVM to run multiple virtual machines - one per user. Companies like Sun and HP added both partitioning and virtualization to Unix because thousands of mainframe customers knew they needed them. As a result you can now get a 64 CPU Sun 20K with 512GB of fully symmetric memory for about $1.4 million and then partition it eight ways to run as eight machines with 64GB and eight CPUs each. Of course if 64GB of RAM and eight CPUs suffices for your jobs, getting a rack of three Sun 1280s each with 12 CPUs and 96GB of RAM gets you the same structure with a third more hardware –and roughly three quarters of a million bucks in change on that 20K.

Similarly the complexity of application interactions and the reliance on the reboot/reload debugging cycle has taught the Microsoft PC community to run one application per box. Today, with Linux taking over backend services in many organizations and businesses, Windows experts are replicating this structure with Linux -which doesn’t have the registry related problems this responds to- by doing one to one conversions and nevertheless getting both performance improvements and cash savings over their Windows installations.

The bottom line on business use of Unix is that the system is so cheap and flexible that it generally produces net business benefits even when mis-used. Partitioning that Sun 20K destroys the value that comes from having access to 512GB of fully symmetric memory - but the result is still a third faster than the six million dollar base z900 for about 20% of the cost.

Another way to look at this is to see that, because Unix can be used by almost anybody to do almost anything in computing, there has been little business pressure to develop unique cultural attributes.

There is a unique Unix culture, but it developed and flourishes in the research, not business, community. In the research community cost and performance pressures on individuals combined with the general absence of cross cultural contamination to produce Unix best practices like peer review, networking, user empowerment, the open source movement, and direct end user control of systems decision making.

The myth of responsibility in software

Sun now sells StarOffice licenses instead of giving them away. Why? because many potential users insisted on the right to pay.In part this is the result of a myth: the notion that a software user should be able to hold a supplier responsible for software failures. In reality companies can’t sue Microsoft because Word loses files, or SAP because their implementations failed. Read your Microsoft end user license agreement carefully - they’re not accepting any liabilities - and neither does Sun when you license StarOffice. This happens in other computer arenas too. Small consultants are replaced with international companies because the client likes the security of dealing with a company big enough to stand behind its work - but they never do, and smarter customers generally know it.

Those management ideas have only recently started to appear in business uses of the technology as open source products have started to displace proprietary solutions.

In large part this is due to the head start other toolsets had in developing business oriented computer cultures. Large companies generally select systems managers using their experience in other large companies as a proxy for expertise, thereby failing to recognize that the skills needed to properly deploy a technology tend to reflect that technology. As a result most of the executives responsible for large Unix sites have mainframe, mini-computer, or Microsoft PC backgrounds that lead them to mis-manage Unix.

---

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.

February 13th, 2009

From Chapter Four: The Unix and Open source Culture

Posted by Paul Murphy @ 12:15 am

Categories: Defenestration

Tags: Open Source, UNIX, Operating Systems, Software, Paul Murphy

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

About this grouping (1)

The cost, performance, and software availability consequences of the basic Unix commitment to openness and communication have made Unix, including variants like BSD and Linux, the dominant academic computing environment essentially since its release to Universities in 1974. As a result nearly all major research and development in the sciences, engineering, and computing takes place first under Unix.

In business, Unix is usually mis-managed at all levels. Most large companies, for example, administer Unix via Microsoft Windows telnet or secure shell and thereby cripple their own ability to use it properly while perpetuating the self destructive myth that Unix looks like this image.

In reality, Microsoft’s rather incomplete emulation of a 1981 DEC VT102 only provides limited command line access and acts like a time machine, warping the user’s view of Unix back to the state of the art in 1982.

Sun introduced SunView, the first widely used Unix GUI, in mid 1983, and experimented with the Postscript based Network Environment Windowing System (NeWS) in 1984. Every non Intel Unix for use outside the embedded products market since then has had at least an X-windows based graphics interface with many products also providing full display postscript.

Today’s MacOS X, which sets the world standard for graphical interfaces, runs on Unix. HTML and most of the related web protocols were developed on Unix -specifically on NeXtStep.

CDE (the Common Development Environment) has long been the standard GUI on large server systems as well as on most high end technical workstations while the Linux and BSD operating systems for smaller, Intel based, machines typically come with both KDE and Gnome -illustrated below.

(Images in the book are generally not included here -but Click here for Novell’s latest Linux desktop Demo)

One of the side effects of the Unix system’s low cost and flexibility is that it doesn’t force users to adapt to it -meaning that people can mis-use it as a cheaper mainframe or mini and still achieve significant cost and performance benefit relative to doing the same thing with products from their home cultures.

Consider this depiction of the key cost functions affecting the two groups that are most different. The management methods that evolved in response to the costs and strengths of the 360 architecture simply don’t apply to Unix and attempts to forcefully impose those ideas often look like attempts to race a Ferrari by towing it with an RV.

Unfortunately, this is not only possible, but will seem perfectly reasonable to those whose expectations are circumscribed by RV performance.

---

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.

February 6th, 2009

From Chapter Three: The Windows Culture

Posted by Paul Murphy @ 12:15 am

Categories: Defenestration

Tags: Disk, Oracle Corp., Server, Unix, Director, Taxes, Free Trade, Microsoft Windows NT, Microsoft Windows, Personal Finance

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

The Windows data center case study

(Long and sad, but a personal favorite - the Happy Valley Tax Authority, from 2002)

When Unix is a four letter word: the Happy Valley Tax Authority

The “I” in this scenario is that of a hapless systems consultant who didn’t do his homework before setting off to meet the client.

The Happy Valley Tax Authority, its staff and mandates, are fabrications but the situation presented, and the remedies offered, reflect the author’s recent experience with real-world clients facing similar problems. This tax authority is imaginary, but the conditions, decisions, and outcomes described are broadly based on real events.

Background

The Happy Valley Tax Authority was set up as a regional co- operative to administer tax programs for local governments along an eighty mile stretch of highway. At the time of incorporation none of the players would agree to use the largest municipality’s name for the joint effort and so the tax co-operative was named for a local tourist attraction: the Happy Valley Ranch. Although now a federally funded national heritage site, the ranch house had been built in the 1890s as a second generation cattle baron’s imitation of an English country manor, acquired a a rather different cultural status during prohibition, and been razed to the ground in an uprising of the local moral majority in 1957.

In the twelve years since start-up, the tax authority has acquired duties that go beyond simple property tax assessment and collection. One town has a hotel room tax, another provides school tax credits for couples with two or more children, while a third has an industrial land development program with both rebate and tax relief schemes to attract tenants. Today the authority collects 32 different levies from about 45,000 taxpayers; administers eight rebate, direct support, or tax relief programs, and collects tolls on one road bridge and two park entrances.

About eight months ago a town councilman with strong connections to the firm I usually work with got his council to hire the firm to do an operational audit of the authority’s effectiveness and assess what value the town was getting for its continued support of the authority’s mandate. That report was dully produced with the usual platitudinous result and recommendations for minor change.

The councilman had lunch sometime last week with the managing partner, and now Barb Rush and I have been dispatched with specific orders to “review and evaluate the use of information systems technology with a view to making recommendations to improving the efficiency and effectiveness of operations.” She works in the insolvency practice, but apparently has audit experience with the client so we’re to spend a day there and a day working out our report.

The tone for the day gets set at the 8:30 AM meeting. Not only am I the only male not strapped into a suit and tie, but Barb switches from normal to distant as soon as we enter the building. In the boardroom to which we’re conducted to wait, the informal chatter preceding the executive director’s arrival amounts to a secret handshake among initiates to a cult - I’m not good at this but Barb and the systems director deftly negotiate the protocol by talking about upgrading their home systems from ME to Windows 2000 -Professional- while others listen and nod approvingly.

Their behavior reminds me uncomfortably of ants rubbing antennae together to establish their mutual allegiance to the same queen. According to their words, neither one can get the thing to work, but what they’re actually saying to each other is “I’m no threat.” There’s nothing I can contribute to this, but when eventually asked for an opinion there’s a sudden hush and I get marked as an outsider when I say I don’t use Windows and have no idea what the problems might be.

When the boss arrives a precise eleven minutes late, Barb smoothly slides the knife in as she introduces me: “Paul,” she tells the group, “is a Unix/Mac expert who sometimes works with us.”

Findings

I’d have been better off, I think, if she’d introduced me as a child pornographer out on day parole. Their board has told them to answer questions, including mine, but everyone else at the meeting, including Barb, make it clear that they constitute a group –to whose membership I need not aspire.

The director, who attaches himself to us for the day, tells us that his systems department has a staff of nine including himself but that the systems budget is both too complex and too sensitive to share. Barb promptly agrees we don’t need it, leaving me floundering - and unwilling to ask for the service level agreement because I have no idea what she’ll say.

The authority employs a total of 68 people of whom 61 have PC desktops. All of these have Windows NT 4.0 Workstation with SP1 on 550Mhz P3 chips, 15″ screens and 64MB. The NT Servers are in four rackmounts and there’s one real surprise: an HP K220 that turns out to have 24GB of Oracle 7.31 dataspace on two refrigerator sized external disk packs that each have 32 650MB drives.

Given the patent hostility in the place, finding a K220 is bit like unexpectedly running into an old friend. I tell my two tour guides what great machines these were, but there isn’t even a pretense of interest.

The primary property tax application had been custom written for one of the municipalities involved, originally for a McDonnell Douglas Microdata running PICK. As part of the authority’s start-up this package had been ported, mostly by outside consultants, to Oracle on HP-UX with Windows 3.11 clients and they’re in the process now of porting it to NT with SQL-Server. That’s why there are nine staff, four are client-server developers on this project. When I ask whether they’re working with SQL-Server 7.0 it turns out they started over a year ago - but they’re sure the upgrade will be be no problem at all.

Overall, the production software doesn’t look too bad. There are individually licensed copies of Microsoft Office on all the PCs -but all of them, including the rackmounts, look like they came from a basement assembler so I ask Barb if the auditors had verified their license status but she doesn’t know.

There’s no formal workflow or document management program in place, but most of the smaller tax programs have some useful form of automated support. In many cases, this is fairly minimal; but the volume is so small I don’t see cause for concern. The hotel room tax, for example, applies to a total of six establishments and 82 rooms. So what if it’s managed from an old Lotus 123 spreadsheet that’s been ported to Excel? you could pretty much do this kind of thing on paper without missing a beat.

The missing workflow and tracking applications raise intriguing audit issues but Barb’s not interested in that either. On balance I’m starting wonder what she plans to do all day and why we’re even here when we get the first hint of serious trouble. A couple of assessment clerks take our visit as an opportunity to harass the systems director about database crashes. This happens all the time, they say; and often means doing work over. Right now, they say, they’re re-entering data from yesterday.

To me, this doesn’t make sense: Oracle’s 7.31 was one of those stopped clock moments in product development. Particularly on an HP K-class, it should take serious effort -something like high explosives or an idiot with the root password - to cause it to fail. So I ask the director about the PC client and the network as more probable suspects - and trigger an off scale defensive reaction.

Networking, it turns out, is incredibly complicated stuff for them. Despite using NT Workstation they rely on Windows for Work Groups for PC networking. The TCP/IP access needed for Oracle and SQL-Net is layered on using a dedicated DHCP server accessed after someone booting a PC logs into the appropriate departmental file and print server. Not only are they running half a dozen LANS on the same wiring, but they’re using 124.0.0.x for the DHCP server and cycling through 200 or so IPs to allocate new addresses for every PC reboot - triggering new rounds of cleanup and resource authentication effort each time.

There’s an external web server and a firewall too. Both are NT machines but there’s no actual content on the web site yet. It has Crystal Reports and IIS hooked up, but the application they’re developing for it isn’t ready. The director explains that the building permits system will allow people to access and pay for local building permits on the internet. Right now, he says, the municipalities do this manually and the property assessments often don’t get updated. By putting this on his web servers, he’ll integrate the databases and save the local governments money while raising tax revenues. It’s an experimental program, he says, that they’ve had to put on hold for a few months because they have had so much trouble with Oracle that they decided to expedite the conversion to SQL-Server before proceeding with the web site services mandate.

Although Barb worked on the audit team, she doesn’t admit to knowing anything about project authorizations and I don’t want to ask the director for his file because I’ve been trying to reduce his hostility and suspicion. Instead, I offer to check out the problem with the K220 for him.

He does not want me to look at the machine, but I do my best humble cowboy shuffle and, mainly because he’s deeply conflicted between wanting to throw me out and not being sure what credibility his bosses will attach to my report, he decides to accept my offer to “just check it over and see if it’s something obvious.”

There are lots of obvious somethings, but nothing bad enough to cause frequent failure. It’s still running 10.20 and has no patches more recent than 1998 but it’s got four 120 MHz CPUs, 768MB, and separate narrow SCSI controllers that go out to each of the disk packs. Swap and system disks are dedicated 1GB internal devices and there’s a DDS3 tape drive that they tell me is used for backups.

The Oracle installation isn’t what I’d do either. Cooked files, no obvious attempt to balance dataspaces across controllers, and no log mirroring at all. Inefficient, poorly structured and unmaintained, but not remotely sufficient to explain their problems. Why does it fail so often?

The answer is that it doesn’t. What’s happening is that years of disk fragmentation, inappropriate kernel parameter settings, the use of cooked files, and very long record formats, derived from the PICK system the software was first written for, sometimes combine to force Oracle to issue thousands of sequential page reads to satisfy relatively simple lookup requests. That causes long delays during which the system seems to lock up. When the DBA reboots [!] the machine to clear it, Oracle data written to system buffers but not yet flushed to disk is lost -causing long recovery times and work rollbacks.

The DBA, who acts as the Unix admin, thinks the IPL stuff he sees on screen at boot time is Unix and tries to run Oracle via a socket connection from his NT workstation. When he can’t get Oracle’s attention this way, he just power cycles the server. What’s really astonishing is that he’s had the job for over a year and reports quite cheerily that this always works.

“You need to get some help here,” I tell the systems director, “get Oracle set up right; use raw devices, balance the load across some bigger disks -you could probably pay for some 9GB disks just on power savings- maybe contract out for a part time Unix Admin. This thing should never fail, there are K220s out there with the same Oracle release that haven’t been restarted literally in years, get it set up right and it will have years of life left in it. Get some 10,000 RPM disks instead of the 3300 RPM units in the machine and it will easily out perform SQL- server too.”

While I was working on the machine the director’s natural friendliness had started to override his fears but all the faces around me close up tightly when I say these things. I’m contradicting absolute and revealed truths here: Unix is obsolete, disks are many times more expensive than for Windows, the technology is hopelessly unreliable and hard to manage -just look at their experience with it for proof- no, no, no, NT will fix everything, that K220 is the enemy incarnate, and, by association, so am I.

On my better days, I’m smart enough to know that there’s no point in arguing with a client, but this wasn’t a good day. I point out that the table definitions used in the Oracle implementation will be impractical in SQL-Server, they’re going to have to redo all the data structures, rebuild the application as a set of stored procedures, and rebuild the client. All that will take time and testing, so why not buy a whole bunch of time by fixing the K220 setup now?

It’s not going to happen. They have an all NT strategy, the director says with finality, and that’s where they’re going. Microsoft, I say, is making your work with NT and SQL-Server 6 obsolete (this is mid 2000) you’ll have to do it again for Win2K and SQL-Server 2000. This, of course, is my worst blasphemy yet, they know that their code will work perfectly with future Windows releases. I compound my mistake by asking them if this was true for the upgrade from Windows 3.11 to Windows 95? from NT 3.51 to NT 4 Server? or from Windows ME to Windows 2000 desktop?

The result is a further change in attitude. The hostility and suspicion visible before get submerged into the kind of bemused condescension usually reserved for other people’s obnoxious children or the very old. After some verbal fencing, he asks, do I have any other recommendations?

I do, but they aren’t anatomically possible, so, instead, I ask about his schedule for meeting the public information access mandate. This is a bluff, I’d never heard of it until he used the magic word earlier, but he doesn’t know that.

The deadline set by the board wasn’t realistic, he explains. It’s all the fault of Oracle running on that old HP box. They have installed an NT server outside their firewall with IIS front end that lets users run Crystal Reports but Unix doesn’t work across the firewall, so they put the project on hold until they get the SQL-Server conversion done.

I’m dumbfounded; and finally silenced. So he fills the silence by talking about having had to sign a non disclosure agreement to get early access to Microsoft E commerce Server for his building permits initiative. Microsoft’s sales guy is even talking, he boasts, about partnering with the tax authority on this. “We’ll be helping them sell their package to other municipalities” Barb chimes in, helpfully.

It takes a minute or so to absorb all of that. A couple of hours ago, while looking at the K220 I’d seen the support modem with its dedicated phone line properly in place and asked what help they were getting from HP on their Oracle problem. They’d cancelled support right after starting the conversion project - about a year and something ago - expensive, and unnecessary because they have the NT server already, he said - but when I called the number helpfully listed on the back of the K220’s cabinet, the modem had answered. This is more of the same, but worse.

By now even I know it’s hopeless, but I don’t want to think about what he just said and seize on an issue that’s been niggling at me most of the day: if I have the chronology right, they started the permits application more than a year earlier, and there are four people. This just seems way off scale for something that any competent Linux developer could whack together with a mysql/php combo in a matter, probably, of a few weeks to prototype and maybe two months to final product. So, I ask for a project plan - but the person who has the licensed copy of Microsoft Project isn’t in right now; and of course they’re using object techniques but their expert on using UML within Visual Studio is the same missing person, so they’ll send me the information later.

At this point Barb finally proves useful, she sidesteps a possible assault charge by pulling me away to go in search of the executive director because he’d asked to see us before we left for the day. When we get into his office it’s clear that he’s been briefed on my discreditable knowledge of Unix but has a message of his own to convey. The web issue isn’t important, he says. The board caved to one town’s demand for public access and didn’t really mean it, so the delay doesn’t matter. Furthermore, they’re going to love the building permits initiative, he says, and accept any delay as the cost of getting it right.

Message delivered, he and the systems director rub antennae with Barb again and we’re ushered out of the building.

Next day, I do what I should have done first, find and read the file from the previous review. It is, of course, signed by one of the insolvency partners Barb reports to- and he thought the systems operation was “forward looking”, “innovative”, “on track”, and “meeting best practices standards for highly effective computing.”

Recommendations Made

The report was, if I do say so myself, a masterpiece in the art of weasel wording. “The problems and delays encountered by the authority were,” I wrote, “due largely to rapid and unexpected change in necessary third party components affecting both hardware and software.” Then I pointed out that the need to replace or substantially upgrade all of the Authority’s computers and applications as Windows 2000 comes in “creates a unique opportunity for the Authority to formally consider its longer term systems infrastructure and staffing ratios.”

“Such a review,” I wrote, “would focus on accountability, cost, and performance as the Authority’s senior management adapts to changes in its mandate, the emerging public awareness of information security issues, and the availability of inexpensive outsourcing solutions.”

Then I washed my hands, cleaned the keyboard, changed the printer toner, and resolved never again to darken the authority’s doorway.

---

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.

January 30th, 2009

From Chapter Three: The Windows Culture

Posted by Paul Murphy @ 2:15 am

Categories: Defenestration

Tags: PC, Microsoft Corp., Desktops, Microsoft Windows, Strategic Planning, Hardware, Operating Systems, Software, Strategy, Management

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

Note to readers: in reviewing this stuff myself I’m struck by both how much and how little has changed since 2002/3 (the date of this tour). I’m thinking this whole Wintel culture thing needs revision - and one of those revisions might be a second tour, focused on the situation in 2008/9. Comments on change would therefore be of particular interest.

The 2002/3 Windows data center tour

Sample Best Practices

• Centralization and Lockdown

  Physical server centralization coupled with desktop lockdown yields the lowest cost, most reliable, client-server implementations by converting the overall architecture to an information appliance format implemented with Microsoft software and related Intel based gear.

• Outsourced Help Desk ServicesSince most PC user queries require little or no knowledge of the company’s own applications, out-sourcing the help desk reduces management complexity and cost.
• Outsourced Evergreen and Inventory ManagementSince tracking PC inventory is both critical and thankless while updating them is a never ending process, these jobs are best out-sourced.
• Formal License Management and product Inventory TrackingThe evolution of a formal license and inventory unit in larger organizations using the PC architecture was generally driven by complexity and the organizational wish to reduce overall costs by re-using assignable product licenses.

  At present, however, these functions are gaining in importance and value in direct proportion to the likelihood of a Microsoft license audit under Licensing 6.0, the need to account for all Windows capable gear (PCs running Linux are required to have Microsoft licenses under the Enterprise License 6.0 agreements), and the decreasing productive lifespan of capital equipment.

• Security “Czar”Appointing and empowering a person to head a security office whose formal role is to maintain data security and systems integrity constitutes mandatory CYA for any CIO working in the Microsoft world.
• Adaptive BudgetingThe normal annual budget cycle is inadequate to the task of fiscal management in the Microsoft world. Hardware, software, and license changes are both too frequent and unpredictable while user budget expenditures on PCs and related gear are generally uncontrollable from any central authority.

  As a result all budget funds should be allocated to the user departments but controlled centrally through corporate standards management and centralized purchasing. Some relatively small portion of the organizational IT budget is then allocated directly to the IT group under a service level agreement or comparable formalization administered by a systems steering group. The bulk of the actual systems operating budget then comes from charging user departments for services and most capital costs are met directly from the operating budgets of the departments involved.

  From an accounting perspective this means that systems costs are generally not material to the operation of any one group and tremendous flexibility can therefore be obtained to meet the challenges posed by unpredictable external cost change.

---

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.