Administer Virtual Machines like “real” hardware

Yesterday, I had a conversation with an IT Manager who was trying to figure out how to set up, allocate, and administer a new VM Server. He's drinking the VM Koolaid, so he went out and bought a nice, big server with lots of storage and RAM and room for expansion. When it came to setting it up and getting VM's running on it, though, he was thinking way too hard.
The VM server in this case is Microsoft's Virtual Server 2005, but the problem and the solution are identical for VMWare. I needed to speak with this IT Manager because I needed access to one of the machines we're supposed to be setting up. As we talked about setup of these machines, however, it became clear that he was trying to factor the VM and the host into every setup and administration decision, and it was making all of these decisions very complicated.

For example, the first problem he brought up was access to the individual machines. He had a mental picture of a user connecting and logging onto the host server, and then gaining access to the consoles of VMs by using Remote Desktop via the host. He correctly anticipated a bottleneck here, as this would get pretty crowded in a hurry.

I pointed out to him that the VMs were going to operate as "real" machines for all intents and purposes, and that if console access to any of these machines was really needed, it could be had by connecting Remote Desktop directly to the VM -- not by going through the host. Of course, I also pointed out that in many cases, these VMs were going to play a role where desktop access wouldn't really be necessary or appropriate. If you wouldn't expect someone to march into your server room and pound on the keyboard in front of a physical machine, there's probably no need to support desktop access to a VM, either.

The same priniple applies to other aspects of management, too. The IT Manager pondered creation of one or more sub-domains to help administer the machines. I pointed out tha the decision about what tools and techniques to use for these machines should be made without regard for whether the machines are physical or virtual. In other words, if a sub-domain is the right way to administer physical servers, then it probably makes sense for VMs, too.

That's the beauty of VMs these days, really -- you can treat these machines just like real hardware (think of them as a rack full of servers or blades), but they are a piece of cake to create, move, and destroy, and you can share some big-time horsepower much more efficiently than you ever could have before. So relax and soak up the benefits, and stop trying to treat them differently. You'll make better, easier decisions and end up with a better overall environment.

Construct documents like software, please!

I'll assume that everyone reading this blog has some experience in software development. You understand the principles of good software development, and you use these techniques to build software that's modular, reusable, and easy to maintain. Yet, I'll bet that you come across some MS Word documents on a pretty regular basis that are in need of some help in these same areas. If you're not part of the solution, you're part of the problem, so pitch in and start cleaning up those docs!Most MS Word docs just aren't built according to good software development practices.

What in the world am I talking about?

Simple. I'm talking about templates and styles. Based on the docs I've seen people crank out over the years, very few people know how to use them correctly, and the result is a slow parade of documents that look almost, but not quite completely dissimilar to one another, despite the fact that they have supposedly come from the same company or even the same author.

Who cares? It depends on context and degree, really. In some cases, it's really important to get formatting just right. These cases usually aren't a problem, however, because companies employ armies of technical writers and editors to make sure that these important documents come out all right. When document authors are left to their own devices, however, things start to slide. Formats vary from author to author, and in many cases, within individual documents.

Bottom line: this looks sloppy. It's a bad reflection on the author and the company, and worst of all, it often jumps out at a reader as a first impression, and this colors the reader's view of the content. Nobody really follows the advice about not judging a book by its cover, you know.

When this problem is really obvious, it's easy for everyone to see and correct. More often, however, the problem is subtle. A font substitution here, a fuzzy logo there, some headings that aren't done quite like the others. You've probably experienced what real crispness in communication looks like -- a relentless pursuit of uniformity and professionalism no matter where or from whom a document comes. It's typically the hallmark of large, marketing-savvy companies, and it's the only thing that really casts "almost right" into perspective. In other words, "almost right" usually looks ok until it's next to "right" -- and then, it just looks sloppy.

People usually assume that "right" is only achievable through the application of ten-story über-marketing and PR divisions. Not so. The most important prerequisite is desire. If you want to look like you're all on the same team, it's not too hard to do. You know software development techniques, and you can help with this problem.

Yes, you.

Let's think about this problem like we would a software problem. There's certainly a matter of standards and documentation. In other words, would you know "right" if it ran up to you and bit you on the ankle? In the case of finding a standard, you may not be able to arbiter what's desired, but you can help document it once it's found.

Next, how do you apply this format to all of your documents? Again, you should think of this like you would a coding standard. There are manual approaches, automatic approaches, and ways to check for use of the standards.

The manual approach idea is simple: just tell everyone to use the correct formatting.

Hahahaha, haaa...hahahaaaa....., chortle, giggle, giggle.

Ok, maybe I'm the only one who found that funny. You'll probably have better luck if you make it easier for authors to do the right thing. Just as with consistency in web pages, the key here is the proper use of styles. If you know anything about Cascading Style Sheets (CSS) in html, you'll be able to grasp the intent and operation of styles in Word. They operate on selections, just like a DIV tag. They can be cumulative. They are stored either with the document you're editing, or in a global document template (normal.dot).

One of the most common ways to use styles is to edit them in a master document, and then copy the master document. This can be effective, but it's not very elegant. You could also copy your styles to the global template, but that's not recommended because it's not easy to propagate those changes to the rest of your organization.

Instead, the best approach is to save your styles in a document template (.DOT). Not only does this let you wrap the styles up in a portable fashion, it also lets you present a little example of usage when somebody creates a document from that template. When preparing a template with styles, try to keep the contents of the template as relevant, complete, and accurate as possible. Try not to leave styles in the template that you don't want to be used, and make the ones that you do want to use as obvious as possible by giving them meaningful names. Consider the user, and keep things as simple as you can.

Finally, there are a couple things you can do to check for correct use of styles. The simplest is to turn on an option that flags formatting that Word recognizes as just a little bit different than the surrounding formatting. This will also check for "direct" formatting, where fonts, paragraph settings, and other formatting is applied directly instead of through styles. To turn this option on, go to Tools...Options, and click the Edit tab. Look for "Mark formatting inconsistencies", and check it. You'll see blue squiggly lines where Word sees problems. As a last resort, you can also examine formatting and styles using macros. This is a pretty intense and difficult option, but it's there if you really feel the urge to dive in.

I'll leave you with a few links for further reading. If you have any tips you'd like to share, feel free to comment here.

Styles and Reusing Formatting
Tips for Understanding Styles in Word 2002
Microsoft Word: Living with the Beast
Understanding Styles in Microsoft Word

Microsoft product management gripes

I'm generally a big Microsoft fan, but they do some things from time to time that really bug me. I'd like to think that the reasons are linked to a grand plan somewhere, but I just can't tell sometimes. I've written a few words on this subject before with respect to the .Net framework, and I've got a couple more to gripe about today.I'll start with InfoPath. I recently started to slog through an RFQ for an application that needed to do a fair bit of forms processing (they're replacing paper forms, in fact). I'm writing the technical architecture for the proposal, and these guys are a Microsoft shop, so I pull out the old MS bag of tricks and go to town.

I start with .Net and SQL Server, of course, and since this RFQ called for a disconnected client for quite a few of the users, I spec-ed a smart client. Good stuff - this was starting to look like a fun project. Next, I needed e-forms, digital signatures, validation and workflow. I started considering the options, and as I'm researching specific features of some packages, I see a lot of references to InfoPath.

It turns out that InfoPath would be a great option for this project. It's obviously a great tool for e-forms. The thing that really gets my attention, though, is that I very quickly stumble upon all sorts of articles and examples for how to use digital signatures in InfoPath and how to integrate InfoPath into BizTalk to handle workflow and integration. Great - it looks like I can knock out all sorts of requirements in a flash.

Wait a minute.

There's a small problem with this plan. Remember the disconnected clients? They don't belong to the same organization that's issuing the RFQ. In fact, they belong to a whole bunch of third-party companies. If I spec InfoPath for this project, I add around $200 to every single install for that smart client. In a flurry of keystrokes, I add hundreds of thousands of $$$ to the cost of the project. That's not gonna fly.

I pause for a moment and let the steam waft away in a little cloud of despair. I'm back to doing the forms by hand.

Now, in the big picture, this isn't the end of the world for me, but as an architect, I'm always a fan of using functionality off the shelf. InfoPath was perfect for this project, but I couldn't use it because of the way it was licensed. Now, I understand that MS needs to pay the bills, and the Office suite is a big chunk of their revenue. Still, I needed a way to license this particular Office component as an embedded component -- not a stand-alone Office executable. In this application, InfoPath was going to end up so deeply rooted in the application that it would likely not be recognizable as a separate product. It was going to be a control, like a calendar or an RTF editor. There are some great examples on MSDN about how to create an application with an embedded InfoPath component, but the articles make it clear that you've to have InfoPath installed where this software will run.

Request to Microsoft: Give architects a way to spec InfoPath without incurring this kind of cost. Maybe an application license that lets us use the functionality for a specific application (bake a key into an assembly or something). Whatever. Just let us use it in a smaller increment.

The next gripe is pretty similar. As work continued on this proposal, I needed to start working with a Project Manager to get a WBS ironed out. Tool of choice, of course: MS Project. Here's another one I'm sure you've run into. You put a project plan together, but it's held hostage on your PC. Oh, sure, you can save the plan as HTML, but if you've ever seen the output from that, you know how uninspriring that is.

Have you ever noticed that there are free viewers for every other Office application (Word, Excel, etc.), but not Project? There are a handful of vendors out there selling viewers for $30-40, and ILog's got a free viewer that works as long as you save your project as XML, so again, this isn't the end of the world, but it's another one of those real head-scratchers.

Come on, Microsoft. Give us a little help here, ok?