If you need to build a custom application yet desire to re-use it for other customers or sell it as a "packaged" product, there are a couple of guidelines that apply. If you have some guidelines that aren't listed here, or you think mine could use some correcting or beefing up, feel free to do so in the comments.
Prepare for customization
In general, what you give people isn't going to completely satisfy them. You're doing well if people not only use your product, but find new ways in which it could help them or new systems with which it could be interfaced. And they'll tell you they need just one simple change to make that dream come true.
So figure out if and how you're going to help them. What hourly rate will you charge for customization? Do you include a price up front, because you know customization will happen, or do you charge them at an hourly rate as the need arises?
Who's going to spec out and implement the cusotmization? If you're a small company, it'll probably be the guys who write the product. In this case, you have to weigh the revenue gained and time spent on the customization, as well as importance of pleasing this customer, against time lost on fixing bugs and adding features to the product. If you're a large company, maybe you're fortunate enough to have a services group dedicated to installations and customization.
If the customization is something that benefits other customers, how do you make it a feature that you roll into the main source code? Can the engineer responsible make the changes general enough that they are re-usable by other customers? Do they make sense in the context of the product?
If you don't want it in the main source code (i.e., this is a change applicable only to this customer), can you implement the change such that it can be plugged back into the product when a new release occurs? There's nothing worse than having to reimplement a change every time your customer upgrades to a new release.
Use a framework
A couple of the questions raised in the previous section can be answered ahead of time by basing your application upon a framework. A framework provides basic services to your application, such as security, data accesss, and error logging. Ideally, the services should be flexible and, where appropriate, modular.
For example, do the error logging services let you pipe information to one or more destinations of your choice such as a text file or the Windows event log? In the past, we had a case where we not only had to send it to the event log but also to a custom application in the customer's operations center so that a human could monitor the system real time.
If you're writing an intranet application using ASP.NET, your first few customers may be content with using Forms authentication. But then you'll run into a customer that wants to use Windows authentication. Switching between either is easy at the ASP.NET level, but does your framework prevent you from doing so?
Your framework should also let you bury most, if not all, of your business and data access logic inside the framework or in modules or assemblies that tie to the framework. Put yourself into the situation where you can write your business logic once and then slap any user interface onto it.
Using the example of an ASP.NET intranet application again, maybe the bulk of your customers are content with a web interface. But then you have a customer with a group that needs a Windows Forms interface. Or maybe there is some logic that could be isolated into a web service that nobody sees. You should be able to write the code for Windows Forms application or a Windows Service and plug in your business logic as needed. Think of the user interfaces as a shell that give your customer a way to read data and fiddle with or poke at your business logic.
A framework should also provide you with a way to plug in "modules" or chunks of user interface. You should be able to provide a feature to your customer by creating a stand-alone module or a combination of modules that work together. For example, in the project I'm helping out with now, the Purchasing department manages the company's non-perishable inventory (i.e, stock inventory). When something needs to be re-ordered, they write a Purchase Order and send it off to the vendor.
Lately, we started working with the group that receives what the vendor sends . And that group needed to see the expected deliveries for the day. Our custom framework is flexible enough that we could hook up the new screen and report for that group with 5 minutes worth of effort. That 5 minutes included the time it took to make sure it was hooked up correctly.
Make everything data driven
If you're writing an application of any size, you're most likely storing information in some kind of database. Maybe your database is something like Microsoft SQL Server or Oracle. Maybe it's an XML file. Maybe it's a set of web services. Either way, it's a no brainer that you're going to have data in the database.
But if you're like the rest of us, you've hard-coded some things that should also be in the database. For example, if you're writing a custom application for your first customer, it's pretty darn easy to stick the company name, address, or email address for technical support into the source code or reports. If you're preparing to re-use the application for other customers, those things need to go into a configuration file or the database.
There are many times where one business will do something a certain way. But a survey of other businesses shows they do the same thing slightly different or use a different methodology. When you write it the first time, can you write it such that some parts of the feature are controlled via parameters in a configuration file or database? Can you implement the feature using an interface (e.g., ICostCalculation) so that you can plug in new algorithms or methodologies down the road?
You certainly can't do this for each part of the application and your customer probably doesn't want to pay you do that. But you'll find some areas where it makes sense to do so. And you can be mentally prepared to re-implement features as the need arises.
--
Sean Winstead
Tags: Customers, Products