Originally published in Intranet Journal (14-Dec-2005)
IT is sometimes put into the unfortunate position of having to clean up other people's messes, forced to adopt orphaned systems by necessity rather than by choice. Non-IT developers decide to build production applications for their immediate users completely without any IT involvement because they believe they have enough knowledge to pull it off themselves and see IT as an unnecessary hindrance. But when they're no longer able to provide support for it—they're transferred to another department, take an extended leave of absence, or leave the company entirely—they hand the reins over to IT and expect them to take it over even though they had nothing to do with the application. In some cases IT might not even know it existed.
While it may be tempting for IT to just let it die, the soon-to-be orphaned intranet's users will have something to say about that. It's unfair for the user community to be put in the middle of renegade developers and IT. Regardless of why the unofficial intranet was developed outside of IT's involvement, IT now has an orphaned system with a dependent user-base on their hands and no one to support it.
The transfer of intranet ownership involves two separate phases:
Before any actions are taken to offload the orphaned system from its current home and implementing it within the organization's standard IT infrastructure, five questions need to be addressed:
One of the most frustrating things for IT personnel is trying to figure out the code and content structure of a system that was developed by someone else—especially when those developers don't have a formal IT background and break every development principle in the book. They might be forced to deal with code inefficiencies, non-standard development tools and technologies, and a slew of intranet design faux pas.
Taking over an ownerless intranet forces IT to have to reverse-engineer the system in order to understand how it works. Only through a complete understanding of the system can IT make educated decisions as to what must be done with the orphaned intranet. If the original developers are still with the organization, they can help with the transfer of ownership. This will eliminate all the time and effort required to decipher the system.
The trick, however, is in getting the departing developer to assist IT before they leave. There's not much that IT can do alone so it's best to work from the top. It must be made known to senior managers of the department where the soon-to-be abandoned intranet resides that the future of the system will be at stake if proper transfer of ownership doesn't take place while the current developers are still with the company or department.
Managers should make transfer of intranet ownership one of the departing person's final tasks before they leave. It will then be IT's responsibility to gather up as much information about the system as possible, collect all documentation, and acquaint themselves with the intranet's content owners and providers.
The most important determinant of whether an orphaned intranet is to be integrated into the official IT infrastructure is its current technological backbone. IT will need to find out:
Unfortunately, most renegade developers are primarily concerned with getting the job done—by whatever means possible—and not so much with development and design standards. They might not give thought as to the impact of their system on overall IT infrastructure. It's not uncommon to see them using the duct tape and baling wire method of development: use whatever they know and whatever they can get their hands on at low cost. This often involves use of freeware and/or shareware, some of which are only free for non-commercial use. IT will have to contend with all of these different tools and technologies.
Taking over an orphaned intranet is as much about its audience as it is about the tool. When a system is absorbed into the official intranet governing model and integrated into IT's infrastructure, all of the orphaned system's users—and everything associated with them—come with it. This includes their need for technical support, addressing the bugs that were reported to the original developers, and reviewing pending upgrades and enhancements.
The new owners of the orphaned system, however, must make it known to users that the first priority will be transfer of ownership, and that all pending requests will be on hold until the adoption process has been completed. The official intranet team, or governing body, must also decide who will be the representative of the newly adopted system and who will be the primary content providers (if they don't already exist).
When an orphaned intranet is adopted, IT shouldn't redo what's already been done. Most intranets bear similar traits, and there will always be an overlap of features—especially when a system is developed outside IT. If the orphaned intranet can't be integrated into the official IT infrastructure without a great deal of effort, it might be simpler to duplicate a pre-existing system and retrofit it to meet the specific needs of the newly acquired user-base.
For example, two departments might have very similar applications based on simple relational database searching, sorting, and reporting functionality. One is an official intranet sub-site that uses the corporate Oracle Database. Another is an orphaned intranet designed by a renegade developer outside IT's infrastructure that uses a quick-and-dirty MS-Access database (this is a very common scenario since MS-Access is so end-user friendly). Rather than re-rewriting the entire orphaned intranet application, a pre-existing Oracle-based application can be duplicated and retrofitted. All that will be required is an update to the database schema to reflect the tables and fields required by the newly adopted system and some minor code re-writes.
Once everything is understood about an orphaned intranet and its user-base, the new owners need to decide whether it's actually worthwhile to fully integrate the system into the official intranet environment or leave it as-is and simply link to it. While I've always advocated intranet integration and standardization, there are cases when the payoff just isn't worth the effort. Orphaned systems using non-standard technology might force IT to cross the line from integration to re-writing entire applications. This will be doubly complicated if IT doesn't have staff on hand with expertise in the technology used to develop the orphaned system.
Adopting as-is as opposed to full integration is a very subjective issue that requires the good judgment of IT. If, for example, the user-base is half the size of the technical team required to integrate the system, or if the system is only used on occasion, it may be a better idea to simply link to the orphaned application as-is.
Transition will be transparent to users. It won't cause any system disruptions, and won't require any new training.
Less taxing on technical staff. There will be a lot less initial work for IT since they won't have to re-write anything.
Will be harder to maintain in the long run—especially if it uses non-standard technology and in-house expertise is limited.
Standardizes all intranet sub-sites across the board, allowing for easier administration, management, and upgrading.
Much longer term payoffs. Maintaining a single intranet environment is much simpler than maintaining several non-conforming sub-sites and/or applications.
Will require much more initial time and effort on IT's part—especially if IT doesn't have anyone on hand with the expertise in the technology used to build the orphaned system.
Initial integration might cause a disruption among the user community or might require them to go through a learning curve.
I've had the opportunity to work closely with both developers and end-users during these system adoptions and have always noticed a subtle but very real threat to the outcome. It isn't a technical threat, it's a social threat. IT may feel some animosity, justified or not, toward renegade developers who didn't want anything to do with IT during development and later expect them to take over their system when they can longer support it. Users, however, should never have to bear the brunt of this frustration.
It's unfair for IT to transfer their displeasure—whether it be for the renegade developers or of having to take on an orphaned intranet—to the user community. This transference of ill-will can doom the relationship between new owners and users before the adoption process even begins. It's important for the new owners to realize that it's not the users who put the system up for adoption. Whatever feelings IT might have for the renegade developers, the user community shouldn't be held accountable for other's actions. They just want to get their jobs done regardless of who delivered, or delivers, the tool.
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.