Printer Friendly Version
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:

• is sitting on a desktop, rather than a proper server, that may not be backed up properly
• is running on non-standard Web server software
• was built within a non-standard development environment
• has its own separate security model, access control lists, and authentication methods
• no longer has a knowledgeable owner who's familiar with its inner workings

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."