PlexNex

MIGRATION: 3 Steps to Leaving Windows & Office

Let's not beat around the bush. Clients ask me, "Sam. What ever shall we do about Microsoft's rapacious intent to lock us in for another 10 years?"

I say plainly, directly and with confidence...

Step 1 - ODF-enable your present desktop
Step 2 - get your information, business processes & messaging onto the server, i.e., into the browser
Step 3 - change to any desktop you wish (except Vista or Novell SLED10)

I frame the steps in general terms because the right & precise action will shift every six months as, for example, things like Google Docs becomes better integrate-able via the Google API to any business processes you might wish to route through there.

Recommendations Today

Step 1

Objective: get off the forced upgrade treadmill

Different strokes for different folks: right now, this could mean laying OpenOffice.org 2.x.y onto your Windows 2000 or XP machines. For less disruption to users we recommend the OpenDocument Foundation's ODF Plugin for MS Office installed into Windows 2000 or XP. We also envision an immediate move right into Google Docs for the basic-functioning workgroups -- which in some settings can be up to 85% of personnel.

Any of these moves, or combination of moves, means you'll begin soon generating new documents and workflows around ODF. That's good. Whatever changes are in store for the rest of your architecture, the soonest possible move into ODF document creation and workflows buys your working groups future flexibility.

Step 2

Objective: end-of--life Exchange/Sharepoint; get data and activity to the browser; re-engineer business processes through an open-source messaging environment that is ODF-ready.

This is the most costly, scary, time-consuming and least talked-about requirement for migrating out of Microsoft's lock-in round-house. In part, that's because when we think ODF we are thinking documents, office suites, not e-mail. Sorry to interrupt your reverie. This is also the step which varies the most from one shop to the next, so I'll be brief.

Workforces are getting distributed. Every day there are new reasons to put workflows and business processes into the browser and there are fewer cases of programmers working to develop shrink-wrapped software that needs to be installed locally; and there is a lower and lower appetite to support client-server applications when good Web 2.0 apps exist.

The radical CIO will have a plan already to get EVERY BUSINESS PROCESS in his organization into the browser. This enables personnel to be more productive: they can move around and access their data from any machine at or outside the workplace, and especially at home. The productivity gains are immense, and the cost-reduction is immense, too.

Achieving this will enable that CIO to get out of the desktop provisioning business altogether. This is the steady-state target end-game of Step 2: B.Y.O. Desktop.

BYO Desktop

BYO Desktop is the state in which the organization will provide each employee a credit of $99 per year for providing their own desktop computer. The only thing the company provides is a 17-inch flat-screen monitor and a $12 and 95-cent keyboard. Two 19-inch flat-screens for high-performers or for the jobs that need them. It's a cost-cutting, productivity-improving measure in the less-is-more mold. Sounds radical today...

"Why get rid of Exchange? I thought the problem was at the document format?" you ask. It's simple: Exchange is where the business process flypaper dangels. And that is where Microsoft is most effective dialing the document format manipulation dial. Exchange is the e-mail hub but it contains more document integration every version. Sharepoint is practically free, and it lies dormant waiting to be lit up and hoover all your workgroups' documents in. If Exchange is flypaper, then Sharepoint is quicksand: documents that go in there never come out. Microsoft can end-of-life an entire operating system, as they did with Widows 2000 in the real estate industry, with a simple security patch one Friday afternoon to Exchange that meant Exchange WebAccess would only work with IE7. Seems innocuous until you recognize that IE7 does not run on Windows 2000. Remote Windows 2000 users had e-mail turned off like a lightswitch.

Get yourself AWAY from MS Exchange if you value ODF!   

We envision Zimbra for e-mail and portal services instead of Exchange (but Zimbra still needs to talk to the OpenDocument Foundation about bringing its ODF capabilities current).

Step 3

Objective: get a desktop that is invulnerable to single-vendor leverage.

This means a BYO Desktop policy; or, for now,

• Red Hat,
• Ubuntu, or
• Mac OS X

They top my present list due to a) robustness of the software; b) stability of development community; and c) their well-established and uncompromising respect for open standards. I said to avoid Vista (self-evident) and Novell SLED 10; the latter is the very best Linux desktop today, but it is so now tied to Microsoft's mal-intentions for your future that it is best to be categorically avoided.

Go forth. Migrate!

Hiser on Don Marti's LinuxWorld Podcast

Don Marti was Editor of LinuxJournal during its long and important middle phase. He's now back at LinuxWorld.com as Senior Editor.

MP3 (24:02)

Don & Gary Edwards and I spoke together a few weeks ago about the GPL-ing of Java and the conversation turned to our file format work on ODF at the OpenDocument Foundation. This led to the LinuxWorld Podcast, which Don recorded late last night after my return from Boston.

Hiser...

"We have to stop being coy...if we're serious about the success of Linux in the market-place -- either desktop or server -- we have to be realistic about aggressively attacking some of the choke-points these gorillas are exerting..."

Don's questions were excellent -- they're questions we've been hoping to field from the Linux sector for years now. I ramble through the points (am fixing that), but the conversation represents our views clearly,and hopefully for a wider than usual audience.

Our Document & Device Contexts

In trying to understand how people at work and play use document creation tools, we first need to identify what's on the menu (or in the rack, as the case may be), looking at the spectrum holistically.

Bob Sutor has been using his own work habits as a reference lately. (He's Virtual, from Bankok & Taipei [PDF presentation, 15 pp.], in case you missed it, and he had an interesting post a while back about his own writing practices: since blogging entered the picture for him, he doesn't use the word-processor much anymore. Same for me; and now Bob and David Berlind have an interesting exchange related to this subject.) This self-analysis can be a productive exercise. After all, when it comes to using the PC, how different are we from Joe SixPack? (Speaking for myself, I'm a lot like Joe.)

This is just a start -- and I hope people would be stimulated to comment -- but when it comes to documents, we do quite a variety of things. Once, the office suite dominated our perceptions if not our actual practises. That one-size-fits-all hulk of a soft type-writer was where we sat. It was one good reason to pay a lot of money for a personal computer (and avoid a lot of needless repetion of effort). Perhaps that was in the Windows 3.11 days when networking -- connected computers! -- was such a spectacle, but before the Internet was big.

Then email became the killer app. And now we have quite a variety of tools which host, harbor & channel our word-hoard -- our story. I'm just going to make a list...

• email
• blog
• wiki
• photo site
• text editor
• web editor
• web forms
• word-processor
• spreadsheet editor
• presentation editor
• graphics editor
• audio editor
• video editor

(If I missed some important ones, you'll let me know.)

This list represents the variety of tools with which we, today, create our record. These are the tools -- now that the web is a writeable medium -- with which we publish our content. These are the tools with which we experience a variety of publishing contexts -- as both creators and consumers.

If we want to understand how people interact with one kind of tool -- for example, understand in some specific terms what they do with it -- then we ought to understand where such a tool fits into their palette. And also how -- in what device context -- they encounter it.

This, of course, leaves the biggest question unanswered, 'Specifically, how do people use authoring tools?' But that's what good plot is all about....suspense

My Device Contexts

In parallel with a view to document- and content-creation tools, it's important to get a look at our device contexts. The devices that are important to me in my communications and content productivity are the following:

• desk phone
• mobile phone
• VoIP phone
• desktop PC
• laptop

I use each of these devices in different ways acccording to their strengths and weaknesses. For example I use my mobile when away from the office or when perambulating around the office, and I'll use the desk phone for important conference calls which demand a robust connection (perhaps so as not to inconvenience the other members of the call and not waste the time of others with drop-out or disconnections).

I really like the VoIP phone system because it leaves traces in email -- like links to Voice Mail messages. And I'm really looking forward to getting that Asterisk PBX system up with my Cisco SIP phone. You can program the phone with XML and that's one way I can integrate my email Address Book with my phone. I seems remarkable, but programming an important part of my office system of devices will simply mean the manual editing of a simple text file (in a generic text editor on my WiFi-enabled laptop) and dropping the file into a folder on a TFTP space on my network. Documents & devices meet with XML.

These "traces" I mentioned before of my document and device activities will soon all be in XML, if they aren't already. It will have to be open XML because that way I'll be able to plug in and plug out new document tools and devices without breaking my SOA.

The Desktop Today

Does this look queer? [click image to enlarge]

It does to Microsoft and among the helpless Microsoft feeding chain -- including customers who are hopelessly committed to those systems. It is a screenshot of a Windows XP desktop and there are no Microsoft applications in the Quick Launch bar.

It's an indicator of the direction of software markets and it explains the anxiety at Microsoft. (This link is a blog entry by an anonymous Microsoft insider clamoring for scalps, with over 500 affirmative responses from other, anonymous, citizens. For example: "MSFT shareholders need to start rolling some heads, starting with [Ballmer] the monkey-boy.")

Software applications visible include...

• Firefox browser
• Opera browser & email program
• OpenOffice Writer
• OpenOffice Calc
• OpenOffice Impress
• Acrobat Reader
• N|VU (open source & free web page editor)
• The GIMP (open source & free Photoshop-equivalent)
• Apple's iTunes (music & Quicktime player)

This user can get his work done and produce work in standard formats without tithing. Also important, the programs are more elegantly built and engineered than their expensive corporate equivalents because of the user-enthusiasm which goes into their creation. This is why people like to use them.

Almost two years ago I wrote an article for LinuxWorld Magazine entitled, "The Power of Mozilla Firefox and OpenOffice on Windows." That vision is coming true.

Table 1: The operating systems people use with OpenOffice
(This table was omitted from the original article. People often expressed surprise that most OpenOffice users are running Windows. It's naturally so, and those splits have been drifting toward aggregate market-share levels, since then, as OpenOffice usage has expanded into more representative weight in the tens of millions.)

The Windows XP desktop screenshot depicted up above makes sense today. When the organization upgrades within the next 2 or 3 years, it will be to a Linux desktop (without, necessarily, a hardware upgrade) where the organization can better control its software in use as well as its software and hardware spending.

The amount of spending on Linux infrastructure and desktops is certainly lower; that's a nice one-time gain. However, the fundamental benefit is that the control of spending shifts to the consumer.

If the barrier to your organization's migration away from monopoly software has to do with your feeling of a lack of access to skilled Open Source & Free Software IT talent, then we'll fix that. I'm going to do an article series on the colleges and universities that are producing young people who are competent in administering and programming in mixed Windows/Linux environments.

They're there; you just don't want to believe it. And you're afraid to look in the right places for what you might find: a blow to your dull and frightened concept of the world.

MIGRATION: OpenDocument is in My Future

Perhaps a turning point in my year, 2005, came in one instant in June at the Massachusetts State House at the ODF Summit hosted by Peter Quinn. It was at the point in proceedings when Quinn cast the question around the room, "What's our conclusion, then?" A few people spoke and then I heard IBM's Bob Sutor in his tan summer suit say, "OpenDocument is definitely in your future."

IBM's software strategist, Doug Heintzman (with whom I had sat on a panel that Winter where I heard him express views to the effect that OpenOffice's file conversion performance was not complete) who was sitting there next to Bob, was nodding in the affirmative. At this time (June 2005), I had not yet heard IBM's confident declaration of support for OpenDocument (something I had been supporting since 2001) and it was a startling moment.

Startling because I always knew that OpenDocument represented a change in the way many people do things. And in the cauldron of influence, if Big Blue says it's okay, then it really is OKAY! June for me represented that first moment I could see clearly that OpenDocument -- as a universal phenomenon -- was going to happen.

CIOs Will Agree

If you are a CIO or IT staff at the state or municipal government level (in any country), you too will be thinking, "OpenDocument, it's in my future." If you haven't had this thought yourself yet, you certainly will in coming weeks and months as you become aware of the number of your colleagues in different locations who are proactively dealing with this technical & cultural shift.

The news last week came in from the National Archives of Australia, from the US State of Minnesota, and from the CIO of the national government of Norway. They are all going down the OpenDocument path. The news can now only point to the inevitability of arguments in favor of a single, open file format standard for office documents. Each new adoption case weakens the social contract supporting the old proprietary way of doing things with documents. In time, any discussion at the state and municipal government level about the benefits of Microsoft's new format will prompt cock-eyed glances, the same kind we got when OpenOffice first launched its reference implementation of OpenDocument in 2001.

What is so reassuring about Minnesota is that they are quite aware of Massachusetts (of the policy, the policy process itself as well as of Microsoft's tactics there). And Minnesota's tactics show how much they have taken on board. These are not ignorant people. The wording of the legislation not only establishes a positive course toward OpenDocument for the state; but by making a more specific definition of "open" in the context of the document standard, Minnesota at once paints Microsoft's ECMA strategy into its destined corner while making it practically impossible for Minnesota agencies or Massachusetts policy to revert back to support for the second Microsoft standard when the ECMA and ISO processes conclude.

Minnesota's Influential Definition

Minnesota's rigourous new definition of "open standard" (context is the file format)...

"Open standards" means specifications for the encoding and transfer of computer data that:

(1) is free for all to implement and use in perpetuity, with no royalty or fee;

(2) has no restrictions on the use of data stored in the format;

(3) has no restrictions on the creation of software that stores, transmits, receives, or accesses data codified in such way;

(4) has a specification available for all to read, in a human-readable format, written in commonly accepted technical language;

(5) is documented, so that anyone can write software that can read and interpret the complete semantics of any data file stored in the data format;

(6) if it allows extensions, ensures that all extensions of the data format are themselves documented and have the other characteristics of an open data format;

(7) allows any file written in that format to be identified as adhering or not adhering to the format;

(8) if it includes any use of encryption, provides that the encryption algorithm is usable on a royalty-free, nondiscriminatory manner in perpetuity, and is documented so that anyone in possession of the appropriate encryption key or keys is able to write software to unencrypt the data.

"Restricted format" means any data format that is accessed, stored, or transferred and is not open standards compliant.

Let me be perfectly clear about this: there is unanimous agreement among IT & standards experts as among state government IT officials that Microsoft's new file format does not meet the widely agreed definition of 'open' in the context of a format. MSECMAXML currently fails on at least points 5, 6 & 8 of the Minnesota Bill (there will be much more written on these points). After Minnesota, there will be no turning back away from a single, real, open file format standard: no turning away from a total, exclusive commitment to OpenDocument. The plain result of Minnesota and other states whose approaches succeed to further box Microsoft into its own bad strategy is that no state or municipal government can possibly argue or justify a non-OpenDocument direction. There will be no adoptions of the MSECMAXML among this class of organizations because the single-vendor dependencies in that format negate its contention. Do you recognize that MSECMAXML cannot qualify for consideration next to OpenDocument? CIOs: If the answer is 'yes,' please enter a comment. If 'no,' please enter a comment that helps us understand your issues & point of view.

As you recognize that change is inevitable across your organization, the same sequence of thoughts will come...

• How do we take the OpenDocument direction on?
• Shall we pursue the policy route (like Massachusetts), or the legislative route (Peru, Venezuela, Brazil, Minnesota)?
• What is the most efficacious way to influence all our agencies to migrate the format?
• How can we implement OpenDocument?
• What are my choices: OpenOffice.org 2.0, StarOffice 8, IBM's Lotus Workplace, Writely?
• Over time, what new options are likely to present themselves?
• What will happen with the users?
• Will they resist, even rebel?
• What about my legacy documents?
• What about macros, databases, mailing list processes & stubborn workflows (dependencies on enterprise applications) which need to be re-engineered?
• How shall I make the arguments that this action is necessary?
• Who must I convince?

If this sequence flashing before your eyes causes anxiety, you can be calm at the notion that others, too, are dealing with the same questions. Thousands of others. This means that the questions will be answered. Not only that, but the answers will be shared and improved through exposure and repetition. This is how the half-life of an ODF conversation near you -- from first meetings through implementation -- will diminish with each successive adoption case.

If we watch what happens at the Bristol City Council, at the Massachusetts Governor's IT department, in Norway and, if the legislation ends well, in Minnesota, then we will have templates, step-by-step instructions for action elsewhere. Each subsequent migration will be faster and more efficient than the last because we learn from successes as well as from mistakes. In time, again, we will come to recognize that OpenDocument migration is not so difficult, not so disruptive; that it is not so strange.

OpenDocument migration is what we did.

MIGRATION: Something to Think About

If your organization happens to be thinking about migrating to an OpenDocument-ready office suite on your Windows PCs, then here's the way we think about this complex job.

There are three themes in the work:

1.    Strategy
2.    Integration
3.    Services

Strategy is about what to do, when and for whom

Think here about the fundamentals: your organization, its shape, its size, the distribution of its offices, the numbers and variety of collaborating working groups within and across departments. Think about roles, your org chart, managment cultures (there are different ones throughout your organization).

Think about your existing systems, the diversity of OSs and applications & application-dependencies that exist. Think particularly about workflows and how users use (and abuse) the applications for things they could be doing in simpler ways.

Think about the available product choices for introducing the OpenDocument file format into the general workflow. Think about the phases of timing: which individuals & groups will be easier than others and take the easy wins first to build confidence (your own and your users).

Think about the configuration of the desktop with the new tools: how can changes be made less threatening or alterations made more prominent. How do you signify or draw attention to changes or hide them as the case may be?

Think about how you will prepare users with information about the process of change and prepare them emotionally for what they are about to go through? How will you communicate with them, with their managers, both systematically and on an informal or ad hoc basis. How will you establish and manage their expectations...about software and about their own amazing capacity to become better and more productive users when they receive their first formal PC training ever?

Think about your organization and the resources (human mostly) you'll need to deploy, where will they sit, what conference rooms will they control, how stressed will they be as pilots and deployments advance and as small pursuit teams become occupied at off-sight locations. How much whiteboard do you have? Double it! What file formats will the migration team work with together? What OS? (What works for the Team will work for the users being migrated.) Do you need a training facility? Who'll write the business plan for that? What kinds of skills will you need; who's focusing on managing & building the migration team; who's recruiting interns and community contributors locally; and, above all, where will you find the best executive assistant money can buy?

The most critical strategic consideration in a migration is how long to keep the legacy office suite around and how and for whom you will need to maintain access to it. In the migration field, this is known as Coexistence Strategy. Users are human and will tend to take the path of least resistence in their daily work. This inevitably means they will slide gradually (or abruptly) back into using MS Office for all their work if they are not given a grace period of coexistence (during which their stubborn workflows can be re-engineered) along with a finite date when they can expect to lose local access to MS Office on their PC. Some users will lose access completely, others will have limited access (say, to MS Excel only) and a few due to their collaboration patterns and perhaps interaction with enterprise applications will maintain coexistence indefinitely. Coexistence Strategy -- at both the individual and group levels -- is the nucleus of a migration project, around which all other aspects of strategy, integration and services develop.

Writing and maintaining a thorough plan is the least pleasant but most rewarded practice in migration. At the very least it permits the migration team to articulate internally its measures of success and failure and how & what it expects to accomplish with complete awareness. The Plan also is useful for communicating the process to other leadership around. You'll want the best ideas from the most experienced people in the organization; however, some people may wish to kill the project, so be careful.

These are some of the strategic elements in the migration tactical bag.

Integration is about doing it

Quite a few choices present themselves as to how you'll get the software to the users, installed, working and maintained.

There are architectural options for deploying a new office suite on, say, an environment that is 20% Windows 2000 Professional, 50% Windows XP and 30% Windows XP SP2. You could do manual local installations of OpenOffice.org 2.0 for example; you could "push" the software to desktops from a remote Windows 2000 Server using a preconfigured MSI package; you could set up redundant and load-balanced application server appliances that are specified to handle specific predicted workloads driven by a certain number of desktops. Each option you consider and its delivery must be planned, tested and managed. In a good pilot, you might try all three.

Desktop configuration, mentioned above in the strategy context, is also a deployment issue. What is the best desktop configuration? How will you configure the desktops? Does your toolset include remote config capabilities? Can you manipulate icons or turn on & off application default settings from a remote position? These are thorny questions, the solutions of which can make an outsized difference at the margin to your ability to make adjustments quickly to strategic changes of plan, to user needs and human factors and to the commonplace frequent physical movement of workers.

Quickness means many things. Slowness only one.

Services are about making it stick

The services are the things you do to make the users successful during the change and forever thereafter. They accelerate the transition; thay allay fears quickly; they help establish realistic expectations; they get people answers in a bind; they provide solace in a storm; and, done right, they make migration look easy. If you have a mentality of success, it will reflect in the thorough set of clean, seemless, effective services you assemble to make users feel as though office suite migration is just another day at the office.

The User Information Portal should be searchable and full of answers about features & functions, those missing from the new office suite and those available for the first time. Documentation should be terse, short and to the point; users don't care why, they just need to know how, yesterday! The portal should also explain -- reiterate what you informed them in the user initiation meetings -- what the project is about, its objectives and salient benefits. Context & meaning always help the motivation.

A Help mailing list is the sine qua non of office suite migration. Responding quickly to users' cries for help is important. Accuracy is rewarded, too. Maintenance of interest, confidence and the feeling of success for users in the first 6 hours of transition is priceless.

Support services are key. How will you help users with document conversion issues? What kind of service will you build for this? It probably will be outsourced one day, but for users with advanced, sensitive or timely & particular document conversion needs having a conversion & certification service may become increasingly important as the number of OpenDocument users grows throughout the organization and will be especially helpful in dealing with archives or bulks of legacy documents that need to be converted responsibly and effectively to enable the future SOA to function.

Training services may be viewed as optional (because few organizations of any kind actually do PC training or ever contemplated it for Windows & Office). The need for re-training has been argued to be a significant expense and thus a damper on the ardor of CIOs to migrate. This is a myth. The costs, if taken, are reasonable and wash out quickly in the context of productivity gains as well as direct cash costs. At minimum, a plan for a 30-minute session built into the user initiation / acclimatization meetings is one of the key elements of a successful migration plan.

Rare opportunity

Office suite migration on Windows, with the objective of introducing OpenDocument to the organization's desktops, is doable. In a world where we used to think that touching the desktop was CIO-hari kari, migrating the office suite will get easier as it and other ICT alternatives become more socially acceptable.

Migration is not to be countenanced as a rote process. Human factors, emotions, expectations -- both true and false -- weigh heavily and put a high price on leadership and the confidence-building skills of the migration team...what doctors call "bed-side manner." Slight-of-hand may measure equally in the job alongside good fundamental ICT administration technique.

Migration is an intimate process for the organization. That's why it is hard to do with a team of suits from outside. While it will occur over a period of time, you will want to internalize the learning withihn your organization. This is not to say you won't share the knowledge outside but simply that you will want to keep the knowledge around and not have it (all of it, anyway) walk away at the end of an engagement.

An office suite migration offers a rare opportunity for the ICT leadership to take stock of business processes and how effectively the computing services map to them. In fact, the migration itself may issue forth as a secondary implication of a wider policy to modularize the infrastructure, such as it did in The Commonwealth of Massachusetts whose ETRM 3.5 policy for SOA triggered all the healthy attention on OpenDocument.

You may be there too. And it all boils down to this: Migration success is based on your respect for your organization, its business processes, the users of your ICT services and on your winning mentality.