paulchinonline.com

Guilt by Association: Effects of Unofficial Sites and Applications

By Paul Chin

Originally published in Intranet Journal (15-Apr-2005)

back back to portfolio


As children, we were always warned never to hang around with those little hell-raisers so full of pent-up energy that they always seemed to get into trouble wherever they went. And when they did—whether it was for breaking window, cutting class, or graffiti casting the school principal in less-than-flattering light—everyone known to hang around with them was automatically assumed to have been an accomplice. This is what's called guilt by association.

Fast-forward a few decades, and this advice should still be heeded—but it's going to take much more than a grounding and the loss of TV privileges to control. As intranet developers and owners we have to prevent non-sanctioned internal Web sites and applications from adversely impacting users' perception of the official corporate intranet. Accomplishing this begins with an understanding of the three Cs: cause, consequence, and cure.


The Cause

Web sites are notoriously easy to build. Web server software and site authoring tools can be downloaded for next to nothing, and a Web site can be put together in a matter of minutes without any experience. This spells opportunity for wannabe designers and developers, but disaster for IT personnel and content owners who are trying to maintain some type of infrastructure standard with the organization's official intranet.

Great care and consideration is often taken to implement a solid framework for the development and management of a corporate intranet—a tool developed specifically to support an organization's business processes. But then, with the ease with which Web sites can be built, a whole slew of small, non-compliant sites begin to appear all over the network. And, whether directly or indirectly, they become associated with the official corporate intranet. As more and more of these sites spread throughout the network, they will threaten to unravel the cohesiveness you tried so hard to build.

There are two types of non-official sites that all corporate intranet owners need to be aware of:

  1. Water cooler sites that affect users' perception of the intranet
  2. Renegade applications that affect the physical intranet infrastructure

Personal or group water cooler sites are what I call Web sites built for the sake of entertainment or curiosity. They're usually put together at the spur of the moment with whatever tools are easily available and offer nothing substantial in terms of adding value to the official corporate intranet. Water cooler sites are designed by either neophytes just entering the world of Web design or by more advanced programmers testing a new tool or technology. While there's nothing inherently wrong with these types of sites, they may be looked upon as frivolous in the eyes of management and the user community—especially if you're in a conservative business culture that may not support water cooler sites.

A far more dangerous influence to the official corporate intranet are non-sanctioned renegade Web applications that are built outside the development and infrastructure standards of the corporate intranet environment. These sites are developed by experienced, non-IT affiliated programmers who take matters into their own hands—whether because of prior bad experiences with IT or assumptions that it would be quicker to bypass them—and develop an application independent of the official intranet for use solely by their own department or workgroup.

Renegade developers have a good level of programming or design skill, but they will use whatever tools and technology they are most comfortable with, regardless of corporate development standards. While this may seem benign to casual users—after all, if it helps their department and immediate users, why not?—it will have greater meaning and far-reaching consequences to IT and intranet content owners.


The Consequence

As was the case with those schoolyard hell-raisers, unofficial sites that have nothing to do with the corporate intranet may become falsely associated with it by mere proximity. The risk here is that the user community may cast a blanket opinion of the official intranet and all other unrelated sites as a whole rather than the distinct and separate entities that they are.

Users' perception of the intranet as a business tool will be affected when they see general interest water cooler sites with comic strips and movie listings alongside database applications. Water cooler sites, while not officially part of a corporate intranet, are a fun way to get to know your colleagues and can help improve morale—but they can quickly undermine the integrity and credibility of the official intranet if they become too closely associated with it.

Renegade applications, however, can have more damaging consequences, affecting the physical integrity of the intranet's infrastructure. While independent, renegade sites do have their uses within a self-contained department or workgroup, they will become a nightmare for IT to manage should anything ever happen to the owners of the site. Let me illustrate this point by laying out the this hypothetical, yet all too familiar, scenario:

A knowledgeable, non-IT wannabe programmer working as a Systems Administrator within the Project Management department decides to build a Web-based application on her high-end desktop. The application is designed to help Project Managers and teams coordinate project deliverables and share information with all personnel working on related projects. The entire application is developed and based on a Linux/AMP (Apache/MySQL/PHP) environment. The Systems Administrator in this scenario acts independently, developing this application outside IT's knowledge, and then rolls it out for use within her department.

As time passes, the application evolves from a single person's idea into an integral system within the department. But then the bomb drops; the author and manager of this application decides to leave the company, orphaning the system. By then, the application has become so ingrained in the department's day-to-day operation that it must be continued. The average end-users within the PM department are not as tech-savvy as their recently departed Systems Administrator, so no one is willing, or able, to take over the system.

With growing demand for support, IT is forced to adopt this rogue application and fold it into the official intranet where it should have been from the very beginning. If that isn't bad enough, the corporate intranet development standard happens to be Microsoft-centric, using IIS and .NET ASP.

Now, with the application's originator long gone and only spotty documentation available, IT must deal with the fact that the application:

IT is left with two options, neither of which are too inviting: The first is to leave the application as-is and simply link to it from the official intranet. The second is to retrofit the application to conform to the corporate intranet environment standards.

The first option will require someone knowledgeable in Linux/AMP to maintain the application outside the official corporate intranet. While this may seem like the simpler of the two choices, what if this trend of renegade development were to happen within several departments, all of whom will be using different technology? Maintaining the corporate intranet and multiple satellite sites will become nearly unmanageable.

The second option—which is much cleaner and easier to manage in the long-run—may require a lot of upfront work. If you're lucky, the adopted application will already be based on the same platform as the corporate intranet. Otherwise, you'll have to re-write, re-test, and re-deploy the application, keeping in mind that the retrofitted application needs to look and behave exactly like the original because you don't want users to re-learn the application.


The Cure

There's no silver bullet to preventing non-sanctioned sites from adversely affecting your official intranet. You want to maintain intranet credibility without censoring employees. The best way to do this is to make a clear distinction between the official intranet and the various unofficial sites through the use of a distinct and easily recognizable intranet brand—name, logo, color scheme—ensuring that no unsanctioned sites make use of the official intranet brand.

In the case of renegade applications, you may have to take a firmer stance. In all cases, departments and workgroups should be encouraged to work with IT in defining requirements and development parameters for applications that may be relevant for inclusion in the official corporate intranet. But it's impossible to stop non-IT developers from building their own applications outside of this framework.

A good way to curb this behavior is to take a "tough love" approach: Make it a widely known policy that any application developed outside the official intranet without IT or content owner involvement will not be support by the intranet team or absorbed into the official intranet in any shape or form. This helps prevent IT and content owners from having to constantly pick up the pieces of abandoned systems that risk the integrity of a well-established intranet infrastructure.

What you need to do is to make everyone aware of the fact that if they don't want any IT or content owner involvement and support in the building of their sites or applications, they can't expect it afterwards.

While this may not be a significant deterrent for renegade developers—since they probably won't be around to see the consequences of their application abandonment on users—it will certainly make end-users a little more cautious about accepting or encouraging unsanctioned clique-oriented development. They will have to think twice knowing that there's a chance an application can disappear the moment its developer leaves the department or company.


Closing Thoughts

You're never going to eliminate unofficial sites and applications—and I don't think it's right that you should. Your goal is not to censor employees, but rather to make a clear distinction between the official intranet and all the various unaffiliated sub-sites that may pop up within your organization's network.

But when site or application ownership falls in the hands of a small group, the longevity of that system can't be guaranteed. In order to maintain the integrity of the official intranet, you can't allow your team or your intranet to act as an orphanage for abandoned systems. Next thing you know, you'll have a dozen disparate applications knocking at your door asking, "Please sir, I want some more."


Copyright © 2005 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.