Just Enough Governance for Notes Blog

Bookmark :              

I think the most overlooked phase of application development, especially for Notes based applications, is the design phase. I’m sure there are a number of reasons for this, but one that I will discuss here is the timing of choosing the technology to be used for the application. I think most of you would agree that some technologies are better at some things than others. I think a lot of you would say that a good technology can be made to do almost anything you need it to do. But that doesn’t necessarily mean you should.

Regardless of where a new application idea comes from, the availability of a team to develop the application tends to garner the attention. In most cases, this occurs before the requirements are defined in enough detail to make a decision about the most appropriate technology to use for that application.

For example, I’ve seen cases where the next application in the development queue was assigned to the Notes development team for no other reason than they were the group that was free. Any thought beyond that probably focused on the group’s ability to perform the business analysis or on their reputation, or both. Not that those are bad things to focus on, but shouldn’t the technology choice receive at least some of that attention?

At the highest level, this might mean you should question whether a new application was best delivered as a Lotus Notes/Domino application, or possibly C++, Java or so on. Granted, multiple technologies can and probably will be used, but the primary development environment should be decided. At a lower level, you might look at the components of the environment you are using. For example, you might find that Lotus Notes/Domino is fine with a combination of Lotus iNotes, Lotus Sametime and Lotus Quickr. You might even decide Teamstudio CIAO! should be part of this environment.

There are certain realities that do get in the way of making sure the technology choice is made first. For example, in smaller development environments (like Teamstudio), we have a small number of very good developers. But their skills are not infinite. We cannot expect them to learn a new technology because it fits an application better. We don’t have the time or the money to train everyone on new technology, acquire the appropriate supporting tools, etc. Nor does it make any sense to replace the existing team with a new team.

Instead, we take what we have and force an application to fit within that environment. We’ve created some excellent good practices for Design Specification as part of the Teamstudio Policy Guides. I encourage you to take a look at this document to get some tips for the next time around.

Scott