Printer Friendly Version

What's IT to do if renegade developers were to leave an unofficial system at their doorstep and then disappear into the night, never to be seen again?

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 Adoption Process

The transfer of intranet ownership involves two separate phases:

• Integration: A one-time process that will be handled by technical staff during initial adoption. Depending on the work required, the orphaned system will either be fully integrated into IT's infrastructure and official intranet environment or it will be simply linked to as a satellite application. The latter usually occurs when the effort of full integration is too high for the small payoff.

• Governance: An ongoing management process that will be handled by the department level content owners of the orphaned intranet and the organization's intranet governing body (if there is one). If the content owners of the orphaned intranet remain the same after the original developer leaves, nothing much needs to change; otherwise, new representatives and content owners will need to be assigned.

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:

1. Are any of the original developers still in-house?
2. Where is it housed and what technologies are used?
3. What's the current user-base?
4. Is there a similar official system that can be retrofitted?
5. Should the intranet be adopted as-is or fully integrated?

Are Any of the Original Developers Still In-House?

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.

Article Tools

Print this article E-mail this article Discuss this article Related resources

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.

Where is it Housed and What Technologies are Used?

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:

• Current home: Is the intranet residing on an IT server, a departmental server, or (worst case scenario) someone's desktop?

• Server type: Is the intranet running on a Windows- or a UNIX-based system?

• Web server type: What type of Web server is being used (e.g., IIS or Apache)?

• Intranet type: Is the intranet based on static HTML (and if so, does it conform to the newer XHTML specification?), a dynamic scripting language (e.g., PHP, ASP, JSP), or a "packaged" development solution (e.g., Microsoft SharePoint, Macromedia ColdFusion, IBM WebSphere)?

• Database: Does the intranet rely on a database (e.g., IBM DB2, Oracle Database, Microsoft SQL Server or Access), either as its entire backbone or for specific applications?

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.

Go to page: 1 2

Printer Friendly Version