Special Reports

Decentralized Development Strategies

Costs and expectations are well understood in centralized development projects, but the opposite is true with Microsoft Access and similar products. There's no standardization.

• By Danielle Ruest and Nelson Ruest
• 12/01/2004

For This Solution: Windows Server 2003, Microsoft Access, Microsoft Office, Active Directory

Organizations with special programming needs centralize internal development to gain economies of scale. Costs and expectations are well understood in centralized development projects, but the opposite is true with Microsoft Access and similar products. In most cases, Access databases proliferate, provide no standardization whatsoever, and are left to the whim of whoever is doing the development. What's worse, the centralized IT staff often creates the exact same system in other places thanks to the lack of coordination. When it comes to Access development, the old quote, "Every man (or person) is an island" holds true.

Why do organizations invest in centralized development and allow decentralized efforts to go unchecked? Why deploy the full version of Microsoft Access to all systems when most users could make do with the Access runtime for more than 90 percent of their users? If you want to control the proliferation of Access databases in your network and reduce the cost of distributed development, then read on.

Decentralized Development Strategies
Decentralized development often focuses on product enhancements. These can include word processing macros and templates, automated spreadsheets, and local database systems. Distributed development strategy (DDS) applications consist mostly of the following: word processing macros, automated word processing templates, automated word processing forms, automated spreadsheet tools, localized database applications, localized Web content development, localized Visual Basic applications, and Microsoft InfoPath applications. The most common are local database systems.

Few organizations keep complete inventories of this content, yet most organizations working with Microsoft Office generate it. For this reason, many organizations have four or five timesheets, four or five corporate letter templates, and four or five expense sheets. This occurs because organizations often overlook two core processes: inventory and communication. It is impossible to identify and manage assets where there is no inventory. It is also impossible for them to communicate to decentralized developers and let them know of reusable decentralized tools. The first place to start to master this environment is to identify and formalize the different roles that are encompassed by local development. They include:

• Application enhancer: This role focuses on enhancing Office Automation products by personalizing templates and creating macros. It also includes local form and database application development.
• Web/intranet editor: This role focuses on departmental intranet content administration and creation. It also includes Web zone content administration and creation.
• Software owners: Software owners are not developers, but rather application experts. These roles are often distributed across departments, but they can also be localized roles.

One of the major problems with localized applications is application deployment and installation. Because most deployment infrastructures are centrally controlled and are often not accessible to local or regional developers, decentralized deployment strategies must be put in place to support them. In addition, because many organizations use a standard operating environment (SOE) and this SOE is locked down, installation of local application enhancements is not allowed by default. Organizations working with locked-down systems must make allowances for decentralized installation of products. They need a decentralized distribution system that is simple to use yet conforms to standards.

DDS System Processes
The best way to ensure the viability and stability of a locked-down SOE is to ensure that no one has the right to disrupt it. For this reason, most organizations do not want to allow local developers installation rights. However, distributed development won't go away, so the SOE must include support for distributed applications.

Start by making sure the corporatewide development tools you choose include a runtime version. This means that all of the program components that are required to execute a program written by the development tool can be separated from the program and installed independently. (Incidentally, this is a basic precept of .NET Framework.) This runtime includes the components that require installation rights on a Windows 2000/XP locked-down system because they must be integrated into and registered on the system. Once they are identified, these components should be included into the core SOE build, eliminating the need for decentralized application installation each time a new application is built.

This means that files created for application enhancement can then be copied to the system instead of installed on the system. Because all users have file copy rights to specific folders, decentralized applications can easily be "installed" without actually giving any installation rights to developers. For example, all versions of Microsoft Access include runtime editions. If you have decided to allow Access development in-house, then you should include this runtime into your SOE build. This means that like all other SOE components, this runtime will have to be managed and updated as required. If patches or updates are made available for the runtime you use, you'll have to make sure it is deployed to all systems. That's the first step to a full-fledged DDS.

The second thing you need to do is educate your developers. They need to make sure that when they create applications, they design them to run with runtime components instead of requiring the full version of Access to run. If they have designed the application properly, when they "install" their application, all they need to do is copy the files to appropriate directories because the runtime is already included into the SOE (see Figure 1). They do not need to have any elevated rights to do this.

Third, you need to make sure you have made allowances for DDS applications in your SOE. The best way to do this is to create a DDS folder structure on workstations. This DDS folder structure should give change rights and permissions to users as well as to your application enhancer group or the group that contains these developers' accounts.

The fourth component is a deployment system. Local developers must be able to deploy their applications. Because they do not have access to traditional deployment tools—most are centralized—and since they do not want to go from desk to desk to manually install their tools, they must use means that work within your locked-down environment.

The fifth component is official support for decentralized developers. They are a part of every network and, as such, they should be organized as a team that provides a specific function at local levels. This team should be structured through standards and processes just like every other part of your IT infrastructure. These processes should include centralized systems for decentralized development support. Part of this system should include documented development standards to ensure that everyone creates applications based on the runtime only. It should also include tutorials and FAQs. Providing an official support hotline for local development also helps. Finally, it should include an available application directory that developers can browse for source code.

The sixth component is an application depot that stores all of the elements required to make the application work properly. One great advantage of this central storage folder is that all applications are protected by normal backup procedures at all times. This is much better than having the applications stored locally on client systems. The folder structure for this depot should include a master directory for the application. This master directory is named after the application asset number (four digits is usually sufficient). Subdirectories should include: clients—all client components that must be copied to a PC; documents—all product documentation or links to user documentation on the Intranet; icons—the application's icon on the desktop; shortcut—the program's shortcut; Source Data—if the application requires shared data, it should be located here; and UserGroups—this folder contains the list of authorized users.

Users should be allowed read and execute rights on this deposit. Developers should be allowed read, write, and execute rights to their own particular application directories. New application directories should be created centrally through the inventory and asset management process. This process should automatically publish information on the application to the central Intranet Application Inventory Page.

The seventh part is focused on an additional tool: a code-signed Visual Basic Script that replaces the normal application shortcut on the desktop and supplements the central application deposit. This script performs the following steps:

1. Shortcut launch: Instead of launching the application, the VBS shortcut begins the authorization and update/installation process.
2. Authorize users: Is the user authorized?
   1. The VBS shortcut reads the file GROUPS.TXT within the USERGROUPS subfolder to determine if the user is authorized. If yes, it moves to the next step. The developer only needs to add the user's name to the list to authorize him or her.
   2. If the user is not authorized, the shortcut stops the operation and displays an Unauthorized User message.
3. Install/update verification: Is the application on the user's PC?
   1. If yes, is there a new version of the application in the central deposit? If yes, update the code on the user's workstation. If no, behave as a normal shortcut and launch the application.
   2. If the application is not on the user's PC, the shortcut copies itself to the PC and then proceeds with the next step.
4. Install/update/launch: Does the application include local or updated local components?
   1. If yes, copy the contents of the CLIENTS subfolder to the local PC, and then launch the application.
   2. If no, launch the remote application.

This last step is essential because many runtime-based applications do not require any code on the client's system and can run completely from a central location.

This simple program serves several purposes: It automatically updates local components if local components are required (All the developer needs to do is deposit the new code in the central folder once and the shortcut will update all authorized clients.); it validates user authorizations; it automatically installs local components if local components are required; and it automatically performs an application validity check at start-up.

Decentralized developers can use the VBS shortcut to manage all of their updates and installations. By properly placing all of their applications within the structure of the DDS Depot, they can facilitate their application management process. They can use the VBS shortcut to automatically install applications on user systems. This can be done through a simple e-mail message to the user. Before doing so, the developer must ensure that the user's name is included into the GROUPS.TXT file on the server. When users receive the e-mail message, all they have to do is launch the link that leads to the shortcut—links must be sent because Outlook blocks VBS files—and the VBS program will automatically install, then manage the application through its lifecycle. The VBS program the shortcut refers to should be digitally signed in order to ensure it is a safe program to run.

One single VBS shortcut program can manage all of the decentralized applications within a corporate network. The only object developers need to modify on the VBS shortcut is its properties; one single seed shortcut is required. They must modify it to ensure that it points to the appropriate application directory on the server (see Figure 2).

Several other technologies can be integrated to this process as technology changes within the network. For example, the VBS shortcut could verify actual user groups within a security database such as Active Directory instead of user lists in text files. But this change would require central administrators to give DDS developers rights to manage their own distribution groups within the security database.

Decentralized Application Support Process
To make the most of your decentralized applications and recover this lost investment, follow these steps:

• Inventory all decentralized applications.
• Create a centralized or localized application depot on a server in your network.
• Implement a strict directory structure for application storage.
• Create a code-signed Visual Basic Script to replace the application's normal shortcut.
• Distribute the application "shortcut" via e-mail using a link to the actual shortcut. You can also just deposit it on the Departmental Intranet Page.
• Communicate with and train users.
• Communicate with, train, and support DDS developers.
• Prepare centralized DDS development guidelines and make then available to DDS developers.
• Centralize the DDS Depot administration.

If you complete these steps, you won't have undue proliferation of Access databases in your network. You will no longer have any duplicate programming. Your organization will no longer have to pay for the full version of Access on all of your desktops. Runtimes are free of charge. This means that the only ones requiring the full version of Access will be designated DDS developers or application enhancers. That should save you enough money to support DDS development on a full-time basis in your network.

About the Authors
Danielle Ruest and Nelson Ruest (MCSE, MCT) are prolific authors who try to make system administration an easier world to live in. Feel free to send comments or questions to [email protected].