All posts by Scott Alan Miller

Started in software development with Eastman Kodak in 1989 as an intern in database development (making database platforms themselves.) Began transitioning to IT in 1994 with my first mixed role in system administration.
Business of IT, IT Management

The SMB IT and Vendor Relationship Dilemma

2 Comments

When most people compare enterprise IT and the small business IT markets they generally think about size and scale.  Enterprise environments are huge and small business IT often consists of just one or a few IT professionals holding a company together.  The differences between these two classes of environments are much deeper than just size.  Thinking of the small and medium business market as being small-scaled enterprises is a great way to misunderstand what this market is all about.   There are fundamental behavioral differences between these organizational types and I would put forth that this behavior is likely a far better determinant between what constitutes a small or medium business and what constitutes an enterprise business from an IT perspective.

One of the places in which this difference in behavior is most visible is in vendor relationships.  In the enterprise space, as well as in large businesses, vendors act very much as a partner with the corporate IT department.  Often vendors will have dedicated representatives who spend some or possibly all of their time at the customer site and are available to answer questions, make contact with support, provide input and guidance – whatever is needed by the IT department as it relates to that vendor’s products and in some rare cases even outside of the scope of the vendor’s own products.  In exchange the vendor has nearly constant access to the “ears” of IT and management in order to inform them and to sway their opinion in favor of said vendor’s products.  This also gives the vendor direct access, in many cases, to the “on the ground” IT people who are using their products and providing them with critical, non-management feedback.

In many ways this relationship causes “the conversation” between the vendor and the “market”, as proposed by Levine, Locke, Searls and Weinberger in their groundbreaking 1999 tome “The Cluetrain Manifesto”, to take place in-person, in real-time in a way that is very traditional and effective.  When the company wants product information it simply contacts its vendor representative and that rep will provide samples, get documentation, give a presentation, organize training sessions, obtain roadmaps and more.  If the products do not meet the company’s needs the feedback is immediate and meaningful.  The relationship is symbiotic and everyone gains from the tight communication channel that is created between the enterprise IT department and their vendors.

The small business market sees none of this.  There are many reasons for this.  The scale on which the SMB IT department operates does not allow a vendor to dedicate a sales resource, let alone a technical resource, to a single client.  This one, simple difference breaks the communication channel leaving SMB IT departments in a far different position than their enterprise counterparts.  Any conversation held between an SMB IT manager and a vendor is an ad-hoc, temporary conversation.  Vendors do not get to know their clients.  They don’t have a deep understanding of their business.  They don’t see their clients as individuals but as a pool of consumers more akin to the standard, personal consumer market than to the enterprise where each customer is well known and appreciated individually.

The differences in interaction are not solely from the vendor’s perspective.  In the enterprise the IT department typically has resources with time to dedicate to interacting with vendor representatives.  Technical support roles such as server administrators may work directly with sales and engineering resources for support issues and purchasing recommendations while architectural professionals may use vendor representatives to assist in capacity planning, system design or to establish performance metrics.  In the SMB there do not exist these dedicated internal roles and the available IT resources are often overworked and spread too thinly between many different tasks leaving little or no available time to focus on single issues such as these even if the vendors were to provide such resources.  Enterprise departments often manage to even allow regular, “in the trenches” technical staff to attend sales luncheons and other vendor-sponsored events only loosely tied to their job functions.  In the SMB space this is all but unheard of.

Another key difference between the SMB and enterprise markets is in the way that they purchase for IT.  Enterprises generally view their purchasing process in terms of services.  These may include warranty services, datacenter management, software customization, hardware leases, software customization, etc.  The small business market generally sees purchasing in terms of products – either hardware or software.  Small businesses think in terms of buying desktops, monitors, servers, software licenses, etc.  Small businesses purchase the same whether buying directly from their vendor, from the channel or from the local store.  The transactions are very simple.  Enterprises think of a server in terms of its monthly support cost and total lifespan while SMBs simply see a price tag.  This does not mean that SMBs never purchases services – only that they do so typically in a very up-front, set price sort of way although they typically purchase far fewer services than do enterprise IT departments.

Enterprise IT environments have the distinct advantage of large scale peer interaction both internally and externally.  IT professionals working in large environments are constantly learning about new products, technologies and techniques from their counterparts within their own organization as well as from peers in competing organizations in their market verticals.   This gives enterprise staff an advantage in working with their vendors because they see how these vendors interact with their peers locally and elsewhere and get feedback on how other vendors in competing areas work with their clients.  This creates a competitive market for vendors based on their level of service to their clients.  In small and medium business there is very little insight into these relationships at other, similar companies.  SMBs naturally do not get interaction with a direct peer group.  At best they can hope for peer support groups for organizations of similar size, but even that is extremely rare.  Vendor relationships with the SMB market are very much isolated from peer review and market pressures.

SMB IT professionals seldom get a chance to attend industry events like their enterprise counterparts either.  They often do attend some but few by comparison.  This provides fewer opportunities for SMBs to learn about vendors with whom they do not already have a relationship.  This is very beneficial to big vendors like HP, Dell, IBM and Microsoft who need no introduction to any IT professional, but smaller vendors, new vendors and niche vendors will often find it hard to make SMBs aware of their existence let alone find an opportunity to discuss their products and services directly with them.  Making connections between SMBs and vendors capable of meeting their needs is a significant challenge in most cases.

SMBs also suffer from not having industry publications and other vertical resources available to them in most cases.  SMB IT managers may use general resources from the IT field such as technology publications and online magazines to investigate what others in their peer group are doing, but targeted materials designed specifically for their technology needs are rare if not non-existent.

Another difference in how SMB and enterprise IT departments behave is in their driving force behind purchasing.  Enterprise customers typically purchase products strategically.  This purchasing may be driven by a desire for datacenter consolidation, power reduction, features, easing administrative burdens, market pricing advantages and more.  Careful cost analysis will often cause them to buy opportunistically and a tightly coupled vendor relationship helps to enable this.  SMBs, on the contrary, are typically tactical (demand-driven.)  They purchase new products when the old are no longer serviceable, no longer meeting demand, no longer supported or additional capacity is needed.  They will seldom buy when market pressures make purchasing most advantageous but will do so quite suddenly with relatively little research leading up to the point of spending.

The SMB market is very likely to be keenly aware of the bottom line of any purchase.  This seems obvious but in the enterprise space there is normally much more room for a technical specialist to ask for features that carry extra cost because they simply feel confident that they will be beneficial.  Enterprises are often more likely to trust the hunches of their technical staff and to pay for “soft benefits” that are not easily quantifiable.  SMBs will almost always look at the bottom line and if a feature does not meet a clear requirement or provide a rather certain return on investment then they will typically opt for the lower priced option.

The final difference that I would like to address is in how prices are determined.  Enterprise customers typically negotiate a blanket discount rate that applies to everything that they purchase from their vendor.  Getting pricing on new products or price comparing many products is easy.  Very easy.  Pricing for the enterprise is quite transparent making it very simple to do cost analysis on one solution over another.

In the SMB market prices are generally negotiated on a purchase by purchase basis.  Because of this SMB IT departments generally have only a very general idea of the price differences between two different solutions – especially if those products come from two different vendors.  Gathering enough data to do a large cost analysis study is both time prohibitive and ineffectual as prices continuously change and vendors will change discounts regularly based on other factors and behaviors.  SMB IT managers cannot simply go to a single web site and look up many different discounted prices and do a quick comparison of many different products giving them a strategic disadvantage over their enterprise counterparts.

This leaves us with a significant challenge.  Now that we see why small and medium businesses are fundamentally and behaviorally different than large enterprise businesses we have the obvious question of “how are vendors and SMB customers going to overcome their natural barriers?”

To some degree there is no simple answer.  Both vendors and small business IT managers need to be aware of how vendors and their customers behave and think so that they can begin moving toward each other in a meaningful way, but this is only the first step.

Vendors need to have dedicated small and medium business representatives who specialize in the needs of this market.  These need to be professionals who have truly studied the market and understand how very small and moderately small businesses behave, what products are generally in use, what their architectures normally look like and more.  Vendors often think that SMB IT managers spend their day thinking about ERP, CRM, rapid disaster recovery planning and datacenter consolidation problems as do enterprise CIOs but, in fact, most are concerned with desktop management, virtualization, basic security and maybe even purchasing their very first server!  Vendors need empathy with the small business market in order to service it well.  Even vendors with amazing products that are perfect for this market often fail to inform their potential customers on when these products may make sense for them or may lack the ability to support them in the configurations that make the most sense.

Most importantly vendors need to find a way to join the conversation (as put forth in “The Cluetrain Manifesto”). In the enterprise space the conversation takes place inside the organization as well as in peer groups and conferences.  It is everywhere and finding it is simple.  Small businesses struggle with joining the conversation themselves – mostly because they cannot always find it, but it is there.

A perfect example of where this conversation is beginning to emerge is in online technology social media platforms like the SpiceWorks Community.  This online community has hundreds of thousands of small and medium business IT professionals and managers online and engaged in ongoing discussions on everything from low level technical problems and architecture concerns to product selection and vendor relationship management.  A few progressive vendors have joined the community and are interfacing with their customers and potential customers in a mode that, in many ways, mimics the behavior found in the enterprise.  Suddenly vendors and customers have an opportunity for personal interaction and open dialogue.

Through this conversation between vendors and customers there is a real opportunity for vendors to learn about the needs and desires of their customers, interact with customer peers, share resources and, most importantly, simply have an open discussion where concerns and needs can be exposed and addressed.  Customers have questions, often a lot of them.  There is not time during a sales call requesting pricing for the customer and the vendor to get to know one another and become acquainted with each other’s needs and offerings.  Through ongoing conversations, not only when a customer is considering an immediate purchase but on a regular basis, the relationship between vendor and customer can be formed allowing them to understand one another, feel comfortable reaching out with questions and suggestions and more.

Vendors have more than simply the chance to answer product questions when they are part of a larger conversation.  They can also provide input into conversations that are not necessarily directly related to their own products.  They can provide insight into larger architectural and design decisions.  In many cases they can take the time to explain how their products work or why they are valuable to their customers.  It is not uncommon, especially in the SMB space, for potential customers to have no previous knowledge of products that are available to them or if products would apply to them, work in their environment or integrate with their architecture.

Because the conversation is an opt-in experience vendors can talk with customers or potential customers without the need for a sales or marketing interface.  The customers are ready to hear about products.  They want know and they want to learn.  This is a marketplace where sales lead generation is already done simply by the fact that the customers are present.  They have already given the vendor their ear.

Learning how to behave in this open conversation marketplace is difficult for many vendors – especially those that are very well established large businesses. Adapting is critical as those companies that are perceived as caring about their customers will have a significant advantage over those companies who appear to find it a burden to stoop to interacting with small clients.

Large businesses are accustomed to keeping the SMB market at arm’s length often arguing that the “channel” – the reseller and system integration market – was their interface to small business.  The channel, however, acts as a chasm keeping small businesses from ever speaking directly to their vendors causing both to rely on a third party, who may not share any common interest with either, to broker any semblance of a conversation.  The channel is not incentivized to act in the interest of either party and will likely only present products and services that they themselves support and those with the greatest profit margins rather than exploring niche product options and exotic solutions that may be a better fit.  The interest of the customers are then not passed back to the vendors leaving the vendors guessing blindly what products and services would be useful to the SMB marketplace.  The lack of experience with SMBs often means that vendors are completely unknowledgeable about their customers or in many cases simply do not even have those customers.

A perfect example of this breakdown in communications is with IBM.  I watched an active online conversation involving IBM where a large group of heavily experience SMB IT professionals were discussing IBM and its place in the SMB space – what products it offered, how they would compete with other vendors and IBM’s specific relationship with small businesses.  In this conversation I heard repeatedly people speak about IBM’s only SMB focused offerings being its desktops and laptops.  I was shocked, as I suppose was IBM itself, since IBM stopped manufacturing these products many years ago having sold that division to Lenovo.  Even experienced IT professionals taking an interest in IBM, enough to participate in what evolved into a virtual panel discussion on their role in the market, were kept so far removed from IBM itself that they were unaware of even who IBM was and what they offered in the market.  A significant eye opener for everyone.  Likely this breakdown in market communications has been caused by IBM’s reliance on the channel to provide them an interface to their customers and that channel finding it better to sell Lenovo products as IBM products to customers who know the name IBM but do not know Lenovo than to take the time to educate their customers.

IBM is certainly not alone here but with their relatively recent divestment of their desktop and laptop business to Lenovo has created a unique and dramatic challenge in their interface to the SMB market.  IBM’s key competitors, Hewlett-Packard and Dell, use their desktop, laptop, display, networking and printer products as their key “in” with SMB customers and then, once chosen as a vendor, are able to make the relatively rare server sales to this market as well.  IBM has the challenge of selling servers and services to a market that is guaranteed to be buying its desktops and other products from a competing vendor.

Sun (now a part of Oracle) has long faced this same challenge in this market.  SMB IT managers understand desktops and laptops well – this is their bread and butter, what they deal with primarily every day.  Most SMB concerns are desktop related and the bulk of their purchasing is done there.  SMBs do not buy servers in large quantities with rare exception and using a different vendor for infrequent server purchases, which would involve separate vendor relationships and managing different support contracts, is not something that SMB IT managers are going to seek out.  Companies like IBM and Sun need to be involved directly with these customers and make them aware of their unique product offerings, such as Power and Sparc platforms in this example, to even have customers understand who they are and what they may offer.

This issue, hardly unique to IBM and Sun, is exacerbated by the use of the channel.  SMB IT shops will generally only turn to one system integrator, managed service provider or vendor to supply them with hardware.  Since PCs drive SMB IT this means that SMB shops will, by necessity, be turning to managed service providers who are partnered with someone who supplies desktops.  That then makes it rather unlikely that those service providers would additionally be partnered with someone like IBM or Sun.  This then, in turn, causes that service provider to automatically recommend products only from the vendor(s) with whom they are partnered further isolating customers from potential solutions from alternative vendors.  This isolation can be mitigated through direct vendor to customer relationships even if purchasing itself is still handled through a channel provider.  It is in both the vendor and the customer’s interests to interface directly and to engage in a conversation.

It is not uncommon to see IT managers choose a vendor based primarily upon that vendor’s willingness to engage in an open conversation.  Customers like vendors with whom they have a relationship.  They really like knowing that when something goes wrong or when a great new, but not entirely understood, opportunity arises that they can turn to a vendor representative, especially in an open community like SpiceWorks, and ask them for assistance or guidance.  No one expects the representative themselves to have all, or even any, of the answers.  They expect that person to have the resources necessary to reach out internally at the vendor and engage the right people.  Not only is this method friendly and cost effective but it is also very low stress.  Customers often don’t know where the problem may reside and do not have contacts internal to the vendor, unlike enterprise customers who often deal with specific issues so often that they know the necessary resources at the vendor, and without a representative to whom they could turn they may be left without the necessary contact information or channels to get the assistance that they need.  In some cases this may result in customers feeling that the product is poorly supported or just does not work and in others could result in new opportunities being lost or the customer turning to another vendor whom they know offers a workable solution.

While the online SpiceWorks community is hardly the only venue for vendor to customer interactions it is rapidly becoming a unique place, do to its scale, reach and unique SMB focus, where vendors and customers can make connections, join in open discussions, create relationships and get support.  The community is extremely large, over 700,000 IT professionals all from the SMB ranks and is rapidly expanding both with its online presence but also with local users groups and regional SMB IT conferences – all of which present opportunities for vendors to interact with the SMB marketplace in new and exciting ways.  SpiceWorks represents, I feel, a key component in the future of vendor relationships in the SMB IT market.  SpiceWorks acts as a broker to the conversation providing the venue and framework necessary to make customer/vendor interactions as simple and valuable as possible.  As the community continues to grow and as more vendors decide to become a part of the conversation I expect to see the value of this forum expand exponentially.  It is in communities like this that those vendors serious about the SMB IT market will succeed in differentiating themselves and engaging current and potential customers.

Business of IT, Purchasing

The Dangers of Blade Servers in SMB – Debunking the Blade Server Myth

Leave a comment

Blade Servers are the hottest trend in datacenters today.  I am sure that you have heard the hype: lower cost and better efficiency.  To be sure, blades have come a long way in the last few years and are looking better than ever, but considering putting blades into your own business is something that should be considered very carefully.  There are many hidden dangers inherent to the blade concept that are often overlooked and these hidden dangers can come back to haunt you long after you have committed to the idea of blades.

Before we look into blades themselves I want to discuss what blades are.  According to Wikipedia: “Blade servers are stripped down computer servers with a modular design optimized to minimize the use of physical space. Whereas a standard rackmount server can function with (at least) a power cord and network cable, blade servers have many components removed to save space, minimize power consumption and other considerations, while still having all the functional components to be considered a computer.”  It is important to define blade servers because it has become common, especially in the used server market, for resellers to use the term blade to refer to standard, 1U and 2U rackmount servers in the hopes of confusing customers new to the blade market.  Blades are a specific hardware category that requires the use of an enclosure and are not simply “small” servers.  Blade servers use shared components in the enclosure, such as power supplies and remote management consoles, reducing the components necessary in each individual blade server.

The first danger of blades is cost.  Blade enclosures are generally very expensive even though blades themselves are often less expensive than their rackmount counterparts.  In a quick price comparison of a large blade vendor’s offerings the enclosure was approximately $5,000 and could hold a maximum of eight blade servers.  Each blade was roughly $500 less expensive than the matching vendor’s rackmount server of the same or similar specs.  This means that a fully populated blade enclosure, at list price, from this vendor would cost $1,000 more than the equivalent computational power in traditional form factors.  And every blade slot not populated would be an additional $500 deficit.

The cost of blades is not just a total cost factor.  Blade enclosures, often holding eight to sixteen blade servers, need to be purchased up front.  If you need enough servers to match the capacity of an enclosure this is not a factor, but if you are looking to buy only a single server now you may be making a significant investment in proposed future server farm growth.  This means increased risk as well as an investment against the time-value of your dollar.

Hardware cost is always a difficult number to nail down.  Stated prices from the vendors rarely reflect reality and, as most companies know, dramatically lower prices are available if you demand them.  I have known companies to get their blade enclosures for free, for example, which completely changes the cost equation of blades.  But in the same breath one must remember that if a blade enclosure is available for free that serious discounts on traditional rackmount servers are likely also available.  So the list prices are often a good judge of relative prices even if not absolute ones.  Your mileage will vary – so due diligence is necessary to create a cost analysis appropriate for your given situation and the deal that you receive from your vendor.

The second danger of blades is technological obsolescence.  Unlike traditional racks which have gone practically unchanged for many decades, blade enclosures are new and relatively dynamic.  Several generations of blade enclosures have come and gone since their inception in 2001 and each subsequent generation, thus far, has required shops to replace their enclosures to support new blade servers.  This is a high risk if you are not buying servers often enough and in large enough quantity to justify the technology churn in the enclosures.  This rate of change is slowing as the technologies mature, but risks remains.  When doing a proper cost analysis of blade servers this rate of change needs to be factored.

The third danger is vendor lock-in.  Traditional rack technologies are vendor agnostic.  Most shops will mix and match not only servers but batteries, routers, switches, monitoring equipment and other gear into their racks.  Blades are vendor specific.  For a large enterprise this is of little or no concern.  In a small shop with a limited number of servers it can be crucial not to give up the ability to use different vendors and technologies.  This can be a limitation on technology but also is a limitation on leverage to obtain premium vendor pricing discounts in the future.

Take, as an example, a shop that wishes to run HP Integrity blades with their Intel Itanium processors today.  They invest in blade enclosures and begin using them.  In three years they purchase software that runs on Sun UltraSparc or IBM Power processors.  In order to use blades each of these technologies will require their own brand of blade enclosure and will significantly increase the risk in a small shop that enclosures will not be able to be fully populated.  There is much more flexibility in technologies using traditional rackmount servers because each vendor generally supplies one set of RISC or EPIC-based systems and one set of AMD / Intel-based commodity systems.  If you want more than that blades will become quite difficult for a small shop to manage.  I have worked first hand with shops that use multiple technologies like this on a regular basis making blades a most difficult choice today before considering potential future platform desicions.  The use of Apple Mac OSX must also be mentioned as Apple does not provide blade servers so any deployment of OSX-based servers cannot be integrated into a blade enclosure.

The fourth danger is the shared backplane and other key components.  A blade enclosure, while generally built with massive redundancy and with truly amazing design, still represents a single point of failure that must be considered.  If your enclosure fails you do not lose just a single server but as many as sixteen physical server platforms.  With rackmounts servers you can add redundancy simply by adding an additional server – typically one matching server for each server you need.  With blades you have to have redundant enclosures for the same level of reliability.  Again, for a large enterprise this is trivial and obvious.  For a small business the need to suddenly own dual enclosures for full redundancy will often result in simply foregoing that level of protection and increasing risk.

The fifth danger is in the cost of flexibility.  Small IT shops may not often move their equipment around.  The option is generally there, though.  If a small business owns three servers and replaces one with a shiny, new unit the option is almost always there to redeploy the old server to another role elsewhere in the company – perhaps in a branch office.  With blades the old blades can only be redeployed in a location that has a blade enclosure matching the one from which the blade was pulled.  This is a cost of lost opportunity late in the server lifecycle and often completely ignored in cost analysis of blades.  If there is not a spot ready for an older server it is far more likely to be discarded in the blade model rather than redeployed unless the company is large enough to have many enclosures available all of the same generation and with available space ready to accept an older server.

The sixth danger of blades is the high cost of storage.  Storage is a subject all its own these days with SAN, NAS and DAS as possible options.  Shops of all sizes are moving to SAN and NAS quickly and with enough network storage in place this can alleviate much of the storage risk associated with blade servers.  Many shops, however, use circular reasoning and justify SAN because of the blades and blades because of the SAN.  Taking a holistic view of the server and storage picture is crucial.

A typical blade server can house only one or two 2.5″ SAS or SATA drives.  This is far less than a typical rackmount server would provide as potential storage space.  It is common to find eight to sixteen drive bays available in popular 2U rackmount configurations – sometimes using 3.5″ drives rather than 2.5″ drives.  One popular and very cost effective 2U server can hold 28TB of low-cost storage on fourteen spindles.  You cannot put this type of storage into a blade enclosure.  Because local drive space is simply not available, blade server owners are forced to use minimal direct attached storage and use SAN or NAS instead even when DAS would provide better performance and cost (otherwise) for that particular application.

To bridge this need most blade vendors provide storage blades – blade servers that act as tiny, low volume SAN devices and fit directly into the blade enclosure.  These units are generally of rather low capacity, often just six drives, and rather expensive compared to other means of providing storage.  Additionally they use a critical enclosure bay removing one of the potential slots necessary for a blade enclosure to provide server density.  So an eight bay blade enclosure with two small storage blades would only be able to house six blade servers.

Obviously buying a blade enclosure does not mean that you have given up the ability to also use rackmount servers when appropriate.  You can continue to mix and match.  But to obtain the numbers necessary for a small business to cost justify the blade infrastructure often requires that purchases lean heavily towards blade servers to fill the enclosure(s) as densely as possible.

Much of the danger of blades is in the potential for lost opportunities.  Small businesses especially function best and compete most strongly against larger businesses by being flexible and agile.  Blades are the opposite of agile.  They require large, upfront infrastructure planning that includes technological, physical and geographic lock-in.  Even if a business plans ahead and sees no obstacles to adoption this does not mean that opportunities will not be missed in the future, caused by a lack of flexibility to adapt to changing business conditions effectively.  Once a blade enclosure is in place purchasing decisions almost certainly are made based on the investment already made and no longer on simply what is best for the company.  This doesn’t have to happen but almost certainly will.  The existing investment needs to be protected.  This is the natural reaction to have.

All of this being said, blade servers can still make a lot of sense for certain businesses.  Blade servers generally consume less power than their non-blade counterparts due to their shared system components.  Be sure to consider the power consumption differences in the storage area, however, as blades push power consumption from the server to the SAN and can often be misleading as to where the power is going.  A savings in one place is only valuable if the cost does not appear again in another.

Blades are easy to transport and relocate when enclosures are available.  This can be a bigger factor than is obvious especially when it means that there are several additional staff members capable of relocating a server.  Almost anyone can lift and move a blade server.

When combined with a very aggressive SAN infrastructure, blades can be very beneficial to a virtualization environment.  This combination gives the maximum cost and flexibility advantage to businesses large enough to leverage it.  The SMB market mostly consists of businesses for whom this would be very prohibitive, though, and this solution will continue to be relegated to businesses at the larger end of the SMB spectrum.  Virtualization will, in fact, reduce the number of servers needed by most businesses making it even harder to justify blades to smaller businesses where previously a dozen or more servers would have been needed but today only two to four are needed to not only meet but to surpass earlier service levels.

If you can support adequate densities or get really aggressive vendor incentives then blades can be quite cost effective if you calculate against your risks.  Blades are always a little more risky, but if your cost is reduced significantly in buying them then they may be very much worth the risk in flexibility.  The cost of the enclosure is a key factor here.  If your enclosure is free then suddenly the cost savings of a blade system can be enormous – especially if a large number of blades are purchased providing really good enclosure density.

Blade servers are a great technology and show a lot of promise for the future.  As enclosure lifecycles slow, new technologies emerge, costs are reduced, volumes increase and, hopefully, as vendor-neutral standards emerge I am confident that blades will become the de facto standard in even the smallest datacenters.  I see this as taking at least another market cycle before this will really occur.  Most likely, in my opinion, it will be another five to seven years before the form factor truly displaces the rackmount server in general utility.

Uncategorized

Using a Wiki for Quick Documentation

1 Comment

If your business is anything like the businesses with which I normally deal one of the hardest items to tackle is documentation.  This can include all kinds of documentation from human resources processes to accounting practices to core business procedures to the information technology department’s system records.  Businesses need good documentation for many reasons.

Traditionally small businesses simply end up doing without key documentation and have to reinvent the wheel every time something comes up for which the people currently working have not had a chance to memorize the process.  Larger businesses often place their limited documentation into Microsoft Word or Adobe PDF files and store them away in an unsearchable file server or possibly even on paper – putting them into large, ringed binders that no one even knows exist let alone how to find necessary information within.  These are not effective processes, but there is a simple solution.

The solution is a web-based application known as a Wiki.  Most people get their first introduction to a Wiki through the ubiquitous online encyclopedia Wikipedia which is built on a Wiki platform (MediaWiki, to be specific), but this is hardly the only use for a Wiki.  Wikis are simple document repositories designed to allow many editors to easily create and modify online documentation.  The whole concept of the Wiki is about being simple and easy.  The full name, Wiki Wiki, means “quick” or “fast” in Hawaiian.

Wikis have now been around for several years and have begun to become popular in many businesses.  Wikis are generally very lightweight and there are many vendors making both open source and proprietary Wiki products in addition to several hosted services available online.  You can really pick out a Wiki based on your particular needs.  Most Wiki products are free and for the budget conscious business there is no reason to need to consider a Wiki to be a cost center.  This is a simple product that your IT department should be able to roll out for you quickly and easily giving you a documentation repository right away.

At first the idea of a Wiki is a bit foreign to most people.  On the Internet we often encounter Wikis in use for system documentation.  This is becoming increasingly popular. Wikis are often used to allow anyone to log in and make documentation changes.  This can be a good way to get started with your Wiki.  You can also start from the beginning with detailed user access controls allowing only certain individuals to post documentation in the system instead of allowing a documentation free-for-all.  Your needs will depend upon your type of organization.

What makes the Wiki concept powerful is the ease with which anyone can hop on, search for documents that they need and create or modify those documents if they cannot find the information for which they are looking.  The entire concept of the Wiki really encourages staff to make use of the format.  Lowering the barrier to creating useful documentation is the best possible way to get documentation created, and because the documentation is so easy to modify it makes it far more likely that that document will be kept up to date.

A common feature amongst Wiki systems is the idea of tracking changes to Wiki pages.  This means that if someone goes in and makes a change to a page that people using the Wiki system can view past versions of that document to see what changes have been made over time and by whom those changes were made.  This feature also makes it very simple for a system administrator to roll back bad changes if someone is not posting appropriately.

One of my personal favourite Wiki features is the idea of subscribing to a particular Wiki page either through email or an RSS feed.  The subscription model allows any staff members to be alerted to changes to documentation in which they take an interest.  These can be staff members for whom a particular Wiki page is critical to their job functions such as HR managers following changes to the corporate employment policies pages or just interested staff members who want to know when a page changes such as managers subscribing to the cafeteria’s lunch menu page or developers subscribing to a page about a particular software project’s status.

This method is a wonderful way to allow anyone to keep up with any publicly available knowledge without needing to interupt the actual process to view status.  Useful at every level of the organization and extremely simple.  So often organizations do a poor job of keeping everyone “in the loop” who needs to be and with the Wiki subscription model everyone has the opportunity to take responsibility for keeping themselves informed through whatever method is most useful to them.

As I mentioned before, there are many Wiki products available on the market today.  There are enough that choosing one is actually a rather formiddable task.  Some key differentiators between products include their use license, the data store architecture – typically filesystem based or database based, their platform dependence and their integration with other products and authentication systems.  Of course there is also the option of choosing a hosted Wiki service that hosts your Wiki online – mostly this is popular with companies using Wikis as a means of serving their customers rather than for private, internal documentation.  There are so many Wikis from which to choose that the site WikiMatrix is dedicated to helping you choose the Wiki that is best for you.

Before you dive into the world of exploring Wikis on your own I will mention a few that are rather popular and worth looking into early on in your Wiki decision making process.  Popular Wiki platforms include MediaWiki, DokuWiki, TWiki and pmWiki.  These are just the tip of the Wiki iceberg but provide a good look into the features that you should expect to see throughout your search for the best Wiki for your implementation.  The Wiki choosing wizard on the WikiMatrix web site is a great place to begin as well.  Each of these Wikis that I have mentioned thus far are available for free and rather than spending a lot of time studying their benefits you may wish to simply download one or more of them, install them on a spare server and give them a try.

In addition to stand-alone Wiki products like we have mentioned here there are also Wiki engines built into several enterprise content managment and portal systems such as Microsoft’s Sharepoint, Alfresco and Joomla.  For any businesses looking to make a larger investment in an enterprise content management system having a Wiki functionality built into that product can provide a single, unified Intranet web portal interface to serve many different internal documentation and document storage needs.

Wikis are powerful and affordable tools that small and medium businesses can leverage today, even in a climate of budget cuts and uncertainty, to document processes, ease documentation burdens and increase internal communications and efficiency.  It is unlikely that we will see the popularity of the Wiki concept wane but rather they are already beginning to take their place as a staple of the business documentation and communication process.

Uncategorized

MicroBlogging for Business

1 Comment

If you mention microblogging to anyone today the first thing that you are going to get is an ear-full about the importance of social media and platforms for enabling the conversation and about customer interaction.  Okay, fine.  Over-hyped and poorly understood buzz that we can probably safely ignore for now.  Social media matters, yes, but spend some time on Twitter and, while a lot of people are talking, you will quickly learn that very few people are listening.  The platform is going somewhere, but right now most of the people talking in the microblogging space are talking about microblogging.  This will pass.  For now we have other concerns that are more immediate.

While I tend to quickly dismiss microblogging as the “next big thing in social media” as mostly hype from the marketing folks trying to convince people to look at them for another ten minutes I do think that the concept of a highly limited, easy to use, microblogging architecture to be one of great potential import to business.

When I talk about microblogging for business I am not talking about the popular notion of sending your intern out to post about your product on Twitter in order to garner market attention.  What I am talking about is using an internal microblogging infrastructure to deliver status about the people in your organization to your organization.  In the same way that companies have internal blogs delivering information to their own staff the microblogging platform can be an internal tool for our organization and not just something that we use to tell our friends across town what we are having for lunch.

Other social communications tools like traditional blogging, instant messaging, email, etc. started as over-hyped social media, even if the term did not exist yet, and ended up becoming standard, well understood business communication tools that are important pieces of the corporate communications toolkit today.  Microblogging will be the same.  And, like all of those communications tools that came before it, this tool is one that your company can start using today to get the benefits years before your competitors catch on.

Microblogging offers a potential boon to inter-team communications in companies of just about any size.  By providing an easily accessible microblogging platform for the use of your team you provide a simple way for individuals and teams to provide small, manageable amounts of status information to the rest of the company in a highly consumable format that is easily understood.  In the smallest organizations, those with less than five people who all sit in a single office, this may not matter, but start adding any additional number of people or start putting those people in disparate locations and suddenly microblogging matters.

Instead of hypothesizing about microblogging out of context let’s dive right into some sample scenarios and see how microblogging for internal use can help your company.  Remember that like many social media technologies, the leading microblogging platform, Laconi.ca, is completely free and something that your IT staff can roll out for you today.

Scenario 1: The Saleman

John is a salesman.  He works for your company but is almost never in the office.  He spends his days on the road, often in other cities.  You are lucky if you have face time with John twice per month.  Several people would benefit from knowing John’s status, but John is incredibly busy and does not have time to manage any extra email traffic.  He carries a BlackBerry but only answers emails from his current and prospective clients during the day and is exhausted at night when he gets back to his hotel room.  He communicates the bare essentials to you, his boss, but allows you to provide the necessary information out to anyone in the company who might need to know what customers need or new accounts might be coming online.  This makes you both a bottleneck and a point of failure.  What if you don’t communicate the necessary information to the right people quickly enough?

The solution?  Microblogging.  If your firm had an internal microblogging platform you could have extended it to John’s BlackBerry (iPhone, Windows Mobile device, regular cell phone, whatever) so that instead of sending you a quick email John could have posted all relevant information to his own microblogging feed.  Then any interested party in your organization could look at that feed to get up to the minute data straight from the horse’s mouth rather than having it unintentionally filtered and delayed.  People who need immediate updates could be subscribed to John’s feed while people who just want casual sales updates from time to time would just visit his web page when they felt it necessary.  Everyone gets the right data at the right time and you have more time to worry about the business itself.

Scenario 2: Software Development Teams

Software development is famous for its extensive need for communication.  Developers are famous for being unable to communicate easily between individuals and between teams.  Software development often requires a great deal of granual status updates at both a team and at an individual developer or manager level.  Microblogging is hardly a panacea for this situation, but it may be a very powerful tool in the communications toolbelt for this situation.

By giving each individual developer their own internal microblogging account they can make quick and easy status updates whenever their current task changes.  Other developers, who need to know on which components work is currently being done, can just subscribe to the feeds of the appropriate developers to know what everyone is doing at the moment.  Managers can know on what each of their team members is working without needing to stop by their desks and interrupting them unnecessarily to do so.

In this model, communications happens more quickly, more thoroughly and with less disruption to staff who are extremely sensitive to disruption and task switching.  Training the developers to make regular status updates – probably just a few per day taking less than five total minutes – will take some time but once it is part of the usual workflow it will make everyone’s life much easier.  It is also a great opportunity for people to solicite and offer help on certain problems.  A developer might post “working on the foo widget and trying to figure out the bar interace” and someone subscribing to their feed might see that and, being the bar interface expert, can shoot an email or run over to their office to help them out before they waste an afternoon reinventing the wheel or looking helplessly for missing documentation.

Scenario 3: General Office Updates

Most offices are bigger than a single space in which everyone can sit down and have lunch together.  Even a relatively small business with two offices or even two home offices could likely benefit from the advantages of simple updates.  It is important for businesses to communicate.  Internal business communications is one of the ways in which companies are able to outperform individuals – by sharing knowledge and tasks between many people.  If each of those tasks is so discrete that you need no communications then you just might be better off working as individuals doing the same tasks.

By the use of microblogging even general office staff can post simple updates a few times per day so that all of the offices have a good idea of what is happening in the other locations.  Whether it is seeing when lunch or meetings are underway, when the office has left for the day, seeing what new projects or challenges have arisen or finding out what customer interactions have taken place that day that information can be used to keep the separate offices working in a unified manner rather than as two completely separate locations with a very poor understanding of what the other one is doing.

Scenario 4: Department Information

If your company is large enough to have separate departments then microblogging may be just the tool that you need to enable departmental status updates to the organization.  This is not an appropriate solution for human resources to publish their latest employee handbook updates but it could be the perfect spot for them to announce the company picnic or open enrollment for benefits.

Many departments’ core function is to supply a needed to service to the rest of the organization.  Human resources, information technology, finance, billing, purchasing, etc. all exist to service the internal business needs of the organization.  If each department had its own microblog feed then it would be easy for each of them to provide simple updates to the entire company.  People might subscribe to individual department feeds, look at the department website when they have an interest or possibly all department feeds would be aggregated onto an employee portal web page or other unified information location to make these updates obvious to everyone.

The information technology department might post a reminder about phishing attacks or social engineering dangers or could post a status update to the email system that is currently down allowing everyone to keep working without spending their time phoning the already overworked IT department and delaying them from fixing a problem on which they are already working full speed.  Purchasing might post a link to a page on new purchasing procedures that may otherwise have gone unnoticed.  Finance may send information regarding a change in the way that employees must file expenses.  Potential examples are numerous.  How often does your organization wish to make a policy or procedure change but find that informing the company of the change can be very difficult once employees have learned the old procedure.  Updating the employee handbook or financial web site do little good if people have memorized the process and no longer reference those materials.

Scenario 5: Mentoring and Employee Growth

One of the less obvious ways in which microblogging can benefit your organization is in the area of employee development.  Senior employees, while posting regular updates to their microblog feeds, provide an opportunity for more junior members of staff, especially new employees and interns, to follow their feeds in order to gain a deeper understanding into the tasks that they complete on a day to day basis.

By giving junior employees the chance to observe their “mentors” in an unobtrusive manner they may benefit from learning how they work, how their time is spent and how they prioritize their days in addition, perhaps, to learning about their interests, what relevant books or articles they have been reading, what websites are important to them and more.  This is hardly a replacement for traditional mentoring but allowing employees to seek out information about other employees that they admire or from whom they wish to learn can be very valuable.

I don’t know the specific communication needs of your business, but I would be surprised to find that it would not benefit from an increase in internal visibility.  Microblogging can facilitate communications between teams, between peers,  between managers and their staff and even between disconnected pieces of the organization.  Microblogging offers a simple, low-overhead, loosely-coupled process that allows every level of an organization to provide status and information to all interested parties within that organization.

Microblogging does, of course, offer additional benefits outside of internal status communications that we have discussed here.  Servers and other IT equipment can post alerts automatically via the microblogging architecture giving anyone interested a chance to see real time failures and alerts on the network that may affect them.  And then there is external microblogging offering status and information out to customers, vendors and interested parties outside of your organization.  But those topics are too broad for this article.

Special thanks to Andrew T. West for his help with this article.