email article printer friendly more resources

Decentralized Development Strategies
Here's how to manage and control Microsoft Access database proliferation in your network.
by Danielle Ruest and Nelson Ruest

November 1, 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.