2. The Importance of Planned Notes Development (by David Shimberg)

The Importance of Planned Notes Development

A few months ago, an executive at a large corporation came to me with an astonishing confession. In the three years his company been using Notes, they’d accumulated more than 2,000 Notes databases, each of which was used by a different sector in their 15,000-user population. No one in his 300-person IT department knew which applications were active and which could be scrapped, much less what any of the applications did.

But this was the least of his troubles. Valuable product, supplier, and customer information was hopelessly splintered. While several databases tracked the same information, few of them could share that information. For example, his marketing, sales, customer service, and accounting departments all had their own customer tracking databases, which meant that new customer information had to be entered into each database separately. Since no one had created a system to update and synchronize the databases, they were badly out of sync; some customers were listed in as many as four databases, with each listing containing conflicting information. Employees had no way of knowing what was correct and what was not.

Of course, providing IT support for all of these databases was extraordinarily expensive. Since no common database architecture existed and few of the original programmers were still at the company, when an application broke, IT had to first analyze (or guess) the application’s design and intended function. Only then could IT determine what was broken and how to fix it. Even simple repairs were time-consuming and costly. Instead of boosting the organization’s efficiency, this company’s Notes system had become a terrible drain.

I wish I could say this is a rare scenario, but in fact it’s a classic example of what I call a popcorn Notes enterprise: a company that develops new Notes applications in response to specific business problems, without regard for the application’s long-term maintenance or its organizational impact.

Popcorn Notes enterprises range in size from extremely small to very large corporations. When I encounter one, I like to ask them how they develop their non-Notes applications, such as SQL-based billing databases or C++ order/entry systems. Most reply that their IT department has a software development process that includes needs assessment, technical specifications, coding guidelines, and testing parameters. This raises the question: If you use a blueprint for your non-Notes development, why in the world don’t you use one for Notes?

Notes Development Is Different

The concept of a structured architecture system isn’t new. IT has employed standards for software development—for user interfaces, database structure, security, software quality assurance, maintenance, and deployment—for years. In the past, however, IT managers rarely had to enforce these standards across the entire organization. After all, what accounts payable clerk is going to code a FORTRAN interface to a DB2 back end?

Notes changed this dynamic, putting the ability to develop solutions into the hands of the people with the problem. Many organizations cite the ease with which applications can be developed in Notes as one of their main reasons for purchasing it. But all too often, a year or two later these same organizations find that they have thousands of poorly documented and inconsistent applications with redundant information.

Organizations that do implement and enforce structured architecture guidelines for their Notes applications retain control of their company information and enjoy benefits in the areas of software development, application maintenance, and capacity for future growth. I’ll look at each of these areas in turn and show how having standards for development can make a difference.

Implications for Development

Establishing and enforcing universal standards for Notes software development means that all applications will have the same technical characteristics and basic design. Developers can create new applications more quickly by starting from common application templates and sharing code.

Many organizations turn their development guidelines into database templates to ensure that the user interface remains consistent from one application to another. Having developers begin with a common template speeds development and reduces the amount of training and technical support required by users when new applications are deployed.

Developers who use a common design methodology for their applications can share code for common database features, such as mail-merge functions, calendar/mail integration, archiving, logging, keyword lookups, and workflow. Over time, these organizations develop libraries of reusable code that developers can simply plug into new applications as needed. For example, a developer could use a mail-merge function from one application in any other applications that required it. In addition, if a developer improves the mail-merge function in the future, he can publish the improvements to the entire development team through a central repository.

Once an organization has built up its inventory of development objects, it can even consider shrink-wrapping some of those objects for sale to other IT organizations.

Implications for Maintenance

IT departments that enforce software development blueprints greatly reduce their long-term maintenance costs. Since all applications share a common architecture, efficient support no longer relies on the original application developer.

If the original developer leaves a popcorn Notes enterprise, his successors have to dissect his application to determine its design and functionality before attempting to repair or upgrade it. Deciphering someone else’s logic can delay repairs and modification projects for days, if not weeks. On the other hand, if the original developer leaves a company that has a structured Notes architecture system, his successors will already be familiar with the application’s basic design and functionality and will be able to implement changes to it on schedule. Furthermore, should the IT organization decide to outsource support for that application, a consultant could be brought up to speed much more quickly and effectively.

As I mentioned earlier, having code libraries can help disseminate improvements made by one developer to the rest of the development team. Some code libraries can even automatically update a particular function in all applications in the organization that currently use it, greatly simplifying ongoing application maintenance.

Implications for Growth

My customers report that the three most important areas for their future growth are:

· Migrating existing applications to Domino R5

· Integrating front-office Notes applications with back-end enterprise resource planning (ERP) systems, or with business management systems (BMS) such as PeopleSoft

· Transforming existing Notes applications into e-commerce solutions

When an organization without a standard Notes architecture decides to migrate its network to R5, it has to migrate each application individually. Developers have to consider the impact of the migration on every aspect of each application’s design, including user interface, views, forms, agents, and security. Migrating to R5 can be an interminable, labor-intensive process of recoding, testing, and tweaking for each application.

Organizations that use a standard architecture only have to answer these questions once to migrate up to 80 percent of their applications to R5. Once they’ve determined the impact of the migration on their standard architecture system, they only have to deal with the minor customizations in each application to complete the migration. The entire process is completed much more quickly and accurately.

These organizations have a similar edge when they integrate their Notes databases with back-end ERP and BMS environments. Most of their work is complete once they’ve determined the impact of the integration on their standard database structure. They can even develop new standards to ensure that future Notes applications integrate seamlessly with the back-end system.

Finally, with predictions of e-commerce activity hitting billions of dollars in the next few years, it’s small wonder that so many companies want to use Notes to develop Web-enabled applications. However, e-commerce systems like ERP and BMS require a standard, uniform interface to Notes data for effective operation. An unstructured array of Notes applications will require an inordinate amount of work to provide integrated access through the Web.

Establish Standards

Most popcorn Notes enterprises claim that it’s unfeasible to implement standards and then migrate all existing applications to them: the effort isn’t worth the cost. For the most part, I agree. However, I believe that the cost of putting off the move to a structured architecture can easily be measured in the ongoing cost of supporting and maintaining legacy applications.

So if your company lacks a blueprint for Notes development, I recommend establishing architecture standards, enforcing them in all future application development projects, and migrating your most business-critical applications (at least) to the new standards. This will minimize your maintenance costs and ensure smooth operations in critical areas, while conserving your development resources to support future growth.