Printer Friendly Version

What's the Current User-Base?

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

Is There a Similar Official System That Can Be Retrofitted?

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.

Should the Intranet Be Adopted As-Is or Fully Integrated?

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.

	Pros	Cons
Adopt 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.	Adopt as-is Will not conform to IT infrastructure and might not be included in official system integrity measures (security model, backup procedures, DRP/BCP) Will be harder to maintain in the long run — especially if it uses non-standard technology and in-house expertise is limited.
Full integration	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.

Closing Thoughts

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.

Paul Chin is an IT consultant and a freelance writer. Previously, Paul worked as an intranet and content management specialist in the aerospace and competitive intelligence industries.

Go to page: 1 2

Printer Friendly Version