If one of your requirements is to support multiple languages, you must familiarize yourself with supporting Unicode data. An in-depth discussion of Unicode support is outside the scope of this article. Besides, Joel Spolsky has already said it best. What you should know is how Unicode affects your database design (data types used), how it affects the encoding used for your Web application pages, and how you’ll need to handle localization data differently for client software versus a Web application. It’s definitely something to research if localization and internationalization (i18n) aren’t familiar topics to you.
Another feature of enterprise software that can make it appealing to an organization—especially one that employs developers—is a publicly exposed, documented API. What this means to your customers is that they can build their own customized applications and have them integrate with your system. Here are some general rules to follow:
Document your API: This will benefit both you and your customers. By documenting your API, it will help reinforce your understanding of the system as well as make you evaluate the design of your system.
Provide an SDK: An SDK with sample application code can go a long way towards making a large client feel like they’re buying an open, extensible system that they can write custom modules for. Providing an SDK with sample applications also allows you to “dog-food” your API and evaluate its quality. Software Configuration/Settings
Most systems require network and local machine-specific settings to run properly. E-mail addresses, IP addresses, directories, themes, intervals, timeouts, licensing…the list goes on. Where and how you store these settings is not as important as how you make them accessible to an admin user. I like to allow these settings to be configured during setup and then also later on with an administrative “control panel” feature. With client software, I like to try and avoid standard users being able to access the control panel application.
Provide a control panel where these settings can be adjusted. Require setup to define success or failure based on whether settings are provided or not. They might not be known at setup time. Provide security over who can access this control panel. Make users update settings directly in the database with a tool like TOAD, SQL Plus, Query Analyzer, or Enterprise Manager. Encrypt settings in the database that contain sensitive information. Allow settings to become corrupted or lost. Wrap setting update actions within transactions. Provide a chance to configure settings during setup. Force refusal of settings values because of validation failure. Remember, your validation might not always work in every environment.
Attempt to validate settings (ping IP addresses, check for directories specified, query domain for e-mail aliases, and the like) Provide helpful tool-tips and descriptive names for system settings. Not everyone will have the same interpretation of certain words. Avoid using acronyms.
You want prospective clients to be able to try out your system without too much help from you. The perception that your software is easy to use starts with the setup process (some might say it starts when they visit your Web site to download it). Any computer-savvy customer should be able to get themselves up and running with your setup without getting you involved. Take a look at what that involves:
Avoid Database Scripts: You should keep DDL and DML scripts around for your own development and testing purposes, but never give them to your clients for them to create a database for your software. Doing so is fraught with possible headaches. Some clients might have zealous DBAs who think certain data types should never be used and change them in your scripts before executing them. It sounds funny, but I’ve actually seen it happen. So, if you don’t give them scripts then, what?
Create a Database Setup: Allow the DBA or whoever has administrative database privileges to run a setup program to create the database. You can point the setup program to a separate file that contains the database scripts if you want; but if you do, make sure the scripts are encrypted and decrypt them inside the setup program. This will help you avoid problems like the one mentioned above and the user will be none the wiser. Your database setup program should create the database and all the database objects. If you want to get fancy, and you don’t have a separate database requirement, you can allow the user to specify which existing database they would like your application’s database objects created in. This is why it’s good practice to give database objects a small system-specific prefix for enterprise software so that the names are less likely to clash with existing objects.
Always Make Rebooting an Option: If you have a desktop client setup that requires a reboot of the machine after completion, make sure it allows the user to end the setup and reboot their machine manually. If your setup causes someone to lose their work (even if accidentally because they weren’t paying attention), your program is already an enemy before they’ve used it. Personally, I prefer setup programs that inform me I need to reboot but don’t do so on my behalf.
Web Application Setup: If you have a Web application setup, make sure it creates any required settings. For example, if your ASP.NET application’s virtual directory needs to be configured to run as an IIS application, make sure your setup creates it as such. If your Web application requires a database connection string or other sensitive information stored in a configuration file, make sure the setup prompts the user for the required information and encrypts it in the configuration file for them. You don’t want users at any level exposed to the inner workings of your system configuration.
Licensing: If you want people to be able to try your software before buying it, make sure that updating the license information is a simple process. Don’t make your setup program be the only place that licensing information can be input.
Web UI vs. Thick Client: This is an important decision and will have deep ramifications for deployment options. Be sure that you’re making your choices for the right reasons. Technologies such as DHTML are making Web applications more appealing because of the robust interface capabilities coupled with extremely simplistic deployment. However, Click-Once Deployment for .NET applications is attempting to bring that same deployment simplicity to Windows desktop software. Click-Once is great, but unfortunately it has a long way to go to convince both developers and managers who have suffered through DLL-hell for almost a decade now. Having said that, if your application requires a rich graphical interactive UI, Click-Once might help resolve those DLL-hell induced headaches for you.
Among those working in software, some take the title of ‘Architect’ more seriously than others. This can make it difficult to judge whether someone claiming to be an architect is the real deal. To be sure the person in charge of system architecture has the skills needed to hit the ground running, here are some things to focus on.
Has architected software systems before.
Has first hand knowledge of platform weaknesses/idiosyncrasies and how to overcome them.
Can effectively communicate the architecture of the system to the developers who will be implementing it.
Can handle the business side of software as well as the technical side (for example, working with project managers and other stakeholders).
Knows first-hand the strengths and weaknesses of many different commercial application platforms and their components.
Can properly identify cases when transactions, queuing, caching, messaging, and other system behaviors are necessary.
Has dealt with standards compliance before (ISO, ASNI, IEEE, and so forth)