Printer Friendly Version

This summer millions of people will flock to theaters to watch the once innocent Anakin Skywalker turn his back on the powerful and spiritual leaders of the Jedi Order to high-five and drink cheap beer with the dark side of The Force. In this final installment of the Star Wars series we will find the answer to the question that's been on everyone's mind: Why did Anakin make that transformation from Jedi — heralded as the "chosen one" by his mentor Obi-Wan Kenobi — to the walking tin can we all fear as Darth Vader?

In April, I wrote a piece about the side effects that unofficial sites and applications can have not only on an intranet but an organization's entire IT infrastructure. I discussed the problems associated with renegade development — non-sanctioned development done outside official IT channels — and why it's dangerous to allow it to go unchecked. Shortly after that piece ran, I received a number of e-mail messages from self-confessed renegade developers who were more than happy to share their own personal war stories and why they took matters into their own hands. Some did it out of developmental curiosity, some did it because they tried to go the official route and were not able to accomplish anything, and some did it because they simply had no other choice.

What can intranet owners do to prevent skilled non-IT developers from answering the siren song of the dark side and becoming full-fledged renegade developers?

Discuss this article in the Intranet Journal Discussion Forum.

When Good Developers Go Bad

Long ago, in a galaxy far, far away, information systems were created by a small number of highly skilled programmers. They wrote applications in archaic languages that sat on huge mainframe computers — but not anymore. Today, as average computer users become more technically inclined and development tools become easier to acquire and use, non-IT developers have entered the arena of program development. The nature of this fast-paced, technical culture calls for applications to be put into place as quickly as possible — and by any means. Applications can result from:

• Development by official IT developers
• Sanctioned development by non-IT developers under the guidance of IT
• Non-sanctioned development by renegade developers without any knowledge or involvement from IT

Gone are the days when applications only came from a closely knit group of knowledgeable Jedi knights. Now, new applications can be brought to life by anyone able to wield a light saber. But with this power comes danger. Without proper guidance, these non-IT developers can fall prey to the influences of the dark side: Renegade development.

Renegade development can be defined as the implementation of any substantial application built by non-IT affiliated developers outside of official IT standards and infrastructure. It takes place when there's an application requirement within the renegade developer's department or workgroup and is fulfilled internally with little-to-no knowledge, influence, or involvement from IT.

The good news is that renegade developers are not as sinister as those dreaded fiends from the dark side. They can't crush your larynx with a wave of the hand or make you bark like a dog just by looking at you. In my experience, renegade developers don't intentionally go looking to break official IT development standards. They don't necessarily go looking for trouble; unfortunately for all involved, that's where it often leads.

But it's a little unfair to lump all non-IT developers into a single group. There are really two distinct types: First, there are those who knowingly and blatantly disregard IT and its established development standards. Second, there are those forced into renegade development because they have no other choice.

The first type is the toughest to convince that working with, rather than against, IT is in everyone's best interest. They're the ones with the hacker mentality and view IT as an unnecessary barrier to their goals, exhibiting an “I can do this without them” attitude. These developers don't work within IT's development environment and view the organization's established standards as a restriction. Rather than working with IT to build a solution, they skirt the issue and go underground, placing their need for developmental autonomy over the long-term welfare of the application and the users it's meant to support.

The second type, however, became renegade developers not by choice but because they were driven to it by past bad experiences with IT, long delays and turnaround time for system delivery, or IT teams who were unreceptive to their ideas. The irony with these types of developers is that IT — the harshest critics of non-sanctioned development — itself is the root cause of the problem. How can IT expect non-IT developers to wait idly by for much needed applications within their department and not take matters into their own hands when they have been stymied so many times in the past by going through proper channels? IT needs to look closely at themselves to see if they're contributing to the problem they're trying so hard to eliminate.

Why Renegade Development is Dangerous

The modus operandi of the renegade developer is to find the solution to a problem within their department or group as quickly as possible with whatever tools they're familiar with and are at their disposal. This not only breaks an organization's established standards but also undermines the entire development and system infrastructure set up by IT.

The problem with many renegade developers is that they operate with blinders on, seeing only to the needs of their users in the here and now. While their intentions are good and their on-the-fly solution may meet users' immediate requirements, they're actually risking the longevity of their application and putting users on very shaky ground by not involving IT in the development process.

It's very risky for users of renegade applications to put all of their faith on a system maintained by a small group — in some cases a single person — within their department rather than a larger governing body such as IT. Aside from all of the technical issues, system ownership will play a big part in defining the long-term life of any application developed without any IT involvement.

All it takes is for the application author to leave the department or company and users, as well as IT, will be left to deal with an orphaned application that no one wants to take ownership of. The users, many of whom may not be as technically inclined as the application's author, will not have the know-how to take over the responsibility. And IT will not want to deal with it if it's in contravention with the established infrastructure (see "Guilt by Association: Effects of Unofficial Sites and Applications" for more on the implications of orphaned applications).

Development standards are established for a reason. Whether to ease application maintenance or reduce total cost of ownership, standards are required to keep development and the resulting applications from turning an organization's IT infrastructure into smörgasbord of unrelated and unstructured systems.

Renegade applications raise many concerns for IT teams responsible for maintaining overall IT integrity because they:

• Are not included in IT's official security model — internal and external security, user and group access control, and authentication method.

• Are not included in IT's overall application integrity plan — system architecture, maintenance and backup procedures, and disaster recovery and business continuity.

• May have been built with non-corporate standard development tools, language, and platform of which only the developer (and no one from the official IT development teams) is familiar with.

• Are at risk of being abandoned should the developer leave the company.

Page 2: Preventing Renegade Development Requires a Change in Attitude