The problem with Standard Operating Environments

Actually, how do you know your SOE is up to scratch and anywhere near optimal for the users?

By Rick Jelliffe
February 2, 2010 | Comments: 3

It is very common for institutions such as governments, universities and companies to have a Standard Operating Environment (SOE): a list of operating systems, applications, utilities, APIs, templates and configurations that each user will have. This solves many problems: it reduces the cost of installation and support, it makes sure everyone has a minimum capability, it guarantees that applications will run broadly, it simplifies licensing and procurement.

However, the Standard Operating Environment brings with it its own set of problems. I don't see that there is much recognition of these problems: it is a matter of religion that the positives of an SOE will always be greater than its negatives. Or that the answer to a counter-productive SOE is just a different SOE.

So what are the problems with SOEs? Rather than speak in the abstract, I'll take a real case.

Basically every SOE I come across requires the support of Internet Explorer 6: including a government tender I was looking at last month. IE 6 was released 10 years ago. But IE 6 has notoriously bad support for Web standards like CSS formatting. So the effect of having IE6 in the SOEs is to prevent the adoption of web standards. System integrators who have tooled-up and skilled-up to support standards (as broadly implemented) for other clients have to do extra work to support the non-conforming system. We have to find kludges to do things that are easy to do.

Most readers would be familiar with the recent German and French government security advisories to adopt an alternative to Internet Explorer 6: but those security advisories actually refer to IE 6,7 and 8: any version of IE at all. Now a patch may come out to fix the particular issues in due time, one hopes. But IE is a particular target because of its popularity. So the effect of requiring IE in SOEs is to encourage hacker attacks on IE and promote IE's vulnerability.

Many readers would be familiar with the biological argument against monocultures, as applied to software. These kind of issues where excessive use of the visible tactic causes an unseen long-term strategic problem are of course very difficult for organizations to factor in to their decision-making.

One of the problems with SOEs arises because an SOE typically amounts to "use Microsoft", in effect. I think the SOE must be a great sales tool for Microsoft (and Lotus), because it shifts the procurement mentality from best-of-breed or horses-for-courses, which would encourage a manageable plurality, to one-size-fits-all. If the FOSS efforts to make Linux the basis of SOEs were successful to the point of broad market domination, we would be in the same boat (however, we are so far from that!)

The problem is that many organizations have put off upgrading in recent years (although I don't think it has hurt Microsoft's profitability): they avoided moving to Windows Vista or Office 2007 because they judged the previous versions good enough, and wanted to extract the maximum benefit from them. So the effect of having an SOE was that moving to a new one became too much trouble.

To take a real example, very often I see that SOEs require Java 1.4.2 JRE: this was released in 2002 or 2003 and was declared to have reached its End of Service Life by Sun at the end of 2008. Java 1.5 in 2004 was a big upgrade and brought with it many important improvements. Requiring Java 1.4.2 basically says "Do not use any improvements that have come out in the last seven years."

Two other problems I will briefly mention are first that SOEs discourage happy accidents: this is where some user tries some technology, finds it useful, adopts it and the technology spreads virally. The big example is the WWW browsers and servers. They certainly were not part of any SOEs, and they have utterly revolutionized computing.

And second the problem with SOE is that they assume that the makers of policy do understand the user's issues: in the 1990s, many organizations had a kind of two tier SOE policy: clerks had to use PCs and designers had to use Macs. Even today, there sometimes is a blind eye turned for some specialist applications, but more rarely. But they don't actually have any mechanism to objectively prove that the SOE is anywhere near optimal.

So the problems with SOEs include:

  • SOEs act against plurality, and encourages insecurity and other monoculture problems
  • SOEs act against upgrades and perpetuate substandard products and versions
  • SOEs become progressively divorced from mainstream capabilities
  • SOEs act against experimentation and organic development
  • SOEs act against niche requirements

So what is the alternative?

  • Reprioritize your emphasis to favour standard formats, standard interfaces and standards architectures. In the age of standalone PCs and desktop applications, the SOE made a lot of sense. In the age of web applications, emphasis on any SOE which works against agile and efficient adoption of web-based and standard formats, interfaces and architectures is counter-productive. Rather than saying "Support IE6", say "Support any of the top three browsers that handle HTML, CSS and AJAX adequately". The SOE can drive the adoption of standards, and the standards can help with product selection, rather than merely going directly from SOE to products.
  • Avoid any SOEs where there are cascading dependencies, where you might put off upgrading some component just because it would involve upgrading some other component which is ticking along fine. Or have a priority list, so that underlying components, such as operating systems, may have an expected life of 6 years, while user-facing applications (such as browsers) may be upgraded every year or more.
  • Track mainstream technical/architectural advances and make sure your SOE positions you to take advantage of them: your organizations may not be using them currently merely because the SOE prevents them, which may keep these advances off your radar. For example, think of AJAX: does your SOE provide modern, first-class, secure support for it? If it does not, your SOE is probably getting in the way.
  • It is common that organizations with strong security priorities will have SOEs that set limits about what can be on a computer: the SOE as a maximum as well as a minimum. This of course severely limits any chance for happy accidents. But what I have seen is that when the SOE is not up-to-date (again, I'd point out IE 6 and Java 1.4.2 as the main culprits I have seen) it makes the problem worse: not only can there be no unsecure happy accidents, there cannot even be any secure happy accidents. The SOE becomes a tool for preventing natural selection, the computer stops being a laboratory for find out what just works. It is the opposite of the military maxim no plan survives contact with the enemy: if anything it encourages people to find non-SOE workarounds.
  • Adopting a standards-based approach and down-playing the standalone-SOE aspects also can allow the recognition that niche requirements may be valid. Adopting ODF, for example, may allow license savings as you roll out OpenOffice, for example, but it does not mean that a legal secretarial group with WordPerfect skills should not be allowed to keep or even switch to WordPerfect.

The opportunity cost of adopting an SOE

The former Taiwanese President Lee Teng-Hui operated, it turned out, under a theory that what mattered for a new Chinese democracy was that there should be a regular alternation of power. (He secretly funded an opposition movement, which came to power when Taiwan became a democracy, and is now out of power again.) This countered cronyism, nepotism, institutional paralysis, the conflation of 'order' with 'single party rule', the emergence of despots, and encouraged lively politics responsive to public opinion.

It strikes me that there is a similar principle at play with SOEs. Even if it is not desired to support limited plurality (by emphasizing standards rather than products), there still may be some benefit in alternating SOEs. So the technical challenge then becomes, how can we have an SOE today that will allows us to adopt an alternative SOE in a couple of years time? This is a technical issue, and the answer seems to be to adopt web-based applications and or desktop applications that are available on multiple platforms, and which use standard formats and APIs.

In economic terms, there is an opportunity cost in adopting any particular SOE: the cost of not being able to move to an alternative technology in the future.

The emphasis on a standards-based procurement and SOE policy seems key in this. But so does a larger vision that factors in the opportunity costs of not being able to take advantage of objective architectural and technical advances (some of which may turn out to be fads too!), and does not just use license fees and help-desk costs as the bottom line.

So am I saying that SOEs should update automatically to the latest version of everything, no matter the license costs and even if there is no hard requirement or objectively estimateable benefits from it? Not at all.

A couple of decades ago, I worked for a university and we were thinking about how to put in an SOE: we decided to make it entirely voluntary, and that the users could select their own alternatives for the same cost if they wanted, but without providing any support, upgrade or discounts that we could negotiate. In other words, we allowed a little market to operate, which allowed us to see whether in fact the SOE (it included hardware too) we made was a better deal for users than what they could come up with themselves if they had their druthers. (And, indeed, it was: only a couple of people did their own thing, which was perhaps good for morale anyway.)

Obviously this exact approach is not suitable in many institutions. But it does bring a good question to the fore: how do you know your SOE is up to scratch and anywhere near optimal for the users?


You might also be interested in:

3 Comments

It is a matter of scale and control. With a shop of 20 people almost any solution will work. You tap people on the shoulder and say, "Hey, upgrade your browser, there is anew virus out."

But with 200,000+ desktops to manage, then your options are far more limited. One solution pattern is to define SOE's, but typically per job role, not globally, in an organization. There is no 'one size fits all", though there likely is true that "one size fits all 'level one support engineers' and "one size fits all financial analysts". Once you do that you need to regularly revise the SOE definitions and push out updates when needed. This requires central control, and typically occurs where help desk support is similarly defined.

The other solution pattern is to delegate support to lower levels of the organization. Depending on the scale at that point they may take a SOE approach or do it less formally. But then to the extent you need interoperability between different departments in the organizations, then you define required formats and protocols for the departments to communicate.

From what I've seen, most large organizations take the first approach, to reduce help desk support costs, increase desktop security and to increase economies of scale when purchasing software and services. Sure, it can be done poorly, as you point out. (Almost anything can be done poorly). But it can also be done well, in a responsive and agile way. And you can just as easily -- perhaps more easily -- end up with an support and interop nightmare if you do not take that approach.

Like many things, this is another "architecture follows organization" question. If you have strong central IT control then you will typically end up with a SOE.

One thing that strikes me is that centralized IT staffs and field IT staffs live in completely different worlds. I have seen a situation where the centralized SOE is so out of touch that employees use their personally-owned equipment (rather than the "boat anchor") to process organizational data whenever they are outside the office. They then ask field IT to help them get their data into a format that the organization's software will recognize, so they can submit it.

Hi All,

I'm new to SOE environment. I know what it is but don't know how to deply it. Can any one help to get book or guide to learn SOE design and deployment?

Thanks in advance.

News Topics

Recommended for You

Got a Question?