A database design does not begin at the time you sit down to lay out your tables and relationships. It begins when you sit down with your customers to learn the business requirements of the application they want you to build. From those requirements, you develop specifications for how the application should work. Only then is it safe to start constructing the application.
Many developers expect their customers to hand them a specification for the project. They also expect customers to provide all of the requirements up-front so there will be little need for rework. Both of these expectations are completely unrealistic. Instead, you must learn how to extract requirements from customers before you charge off and begin "the fun part" of developing the application. If you get good at it, your projects will be more successful and you will become an invaluable resource for your customers or employer. Any developer can code to specifications, but only a skilled developer can create those specifications.
Business Integration Is Key
Most developers have a strong technical focus that interferes with their ability to communicate with customers. At the same time, customers are often focused on their own area of expertise and fail to consider how the project will be affected by other business disciplines. The end result is that both the developers and the customers rush through the requirements phase so they can get on with the project. That impatience is a source of many project failures.
To be successful, every application that an organization adopts must integrate well with the other business systems in place at that organization. I’m not just talking about software systems here; I’m talking about every process or procedure that manages the flow of information within the organization. You can build the best shopping cart system in the world, but it will fail upon implementation if you neglect to account for how the data it generates will flow into the rest of the organization’s information systems.
The Four Business Disciplines
All business functions can be broken down into four major disciplines. You need to make sure that your application has been considered from all four angles before you begin constructing it. If you fail to include any one of the four viewpoints, you can rest assured that your project will be halted for rework just before implementation or just afterward.
In fact, due to the potential cost of rework and the possibility that your project may already be late and over budget, the business may decide that it is cheaper to scrap the project altogether! I’m sure you are thinking "there’s no way that would happen to me," but I’ve seen it happen more than once.
The four business disciplines I’m talking about are:
- Marketing
- Finance
- Legal
- Operations
In an enterprise environment, a development project is usually in the hands of a Project Manager or Business Analyst who is responsible for making sure that all business viewpoints are considered. But in smaller organizations, the developer is often paired with a single business representative, and neither person really understands what the other does. In that situation, it is easy to overlook important considerations, only to have them derail the project at a later time. If you find yourself in that position, your project will have a much better chance of succeeding if you take on the role of business analyst and learn a lot more about how the business operates than you originally planned.
Applying the Four Disciplines
I’ll use the web shopping cart application as an example of how to apply each of these four viewpoints during the requirements phase. At some point during the project’s requirements definition, a knowledgeable representative with authority from each discipline should review your requirements. These business representatives are effectively your customers, and they can stop your project dead if you fail to satisfy them.
First, consider the marketing viewpoint. When you talk to Marty the marketer about your shopping cart application, he may ask about requirements like these:
- Pricing, descriptions, and images must flow into the shopping cart from our product catalog system.
- We need a way to run special email promotions and give those customers a coupon or discount code of some kind.
- We need to know how many carts are abandoned before checkout is completed.
- We need a way to run store-wide sales for holidays and end-of-year clearance.
You also need to consider the financial viewpoint. Fred the Finance Manager will be focused on completely different issues:
- The shopping cart needs to integrate with the same payment processor we use for our stores.
- Order and payment data must flow into our accounting system automatically. We don’t want to have to hand-enter that stuff.
- When collecting credit card information, make sure that we collect all of the information necessary to get the best discount rate from our credit card processor.
Larry the legal advisor will have even more requirements for you:
- Make sure you encrypt all customer identification data that is stored in the database.
- Don’t save credit card information in the database at all.
- Be sure to provide pages on the site for "Terms of Use," our privacy policy, and our returns policy.
Finally, Oliver the Operations Manager will have his own contributions:
- We need to get our shipping rates dynamically from UPS, so you’ll also need to allow for weight-based shipping.
- We can get product weights for you, but we need a way to enter that into the system.
- You’ll need to get the current inventory amounts from our inventory system on a regular basis. When an item goes out of stock, we need to stop selling it on the site.
No Business Application Stands Alone
By now you are starting to think that your little web shopping cart just turned into a monster! You just added requirements relating to an administration interface and three separate interfaces to external systems!
There’s really no such thing as a "stand alone" business application. Every process you introduce into an organization must extend the processes that already exist in the organization. You aren’t really "adding on" the application so much as "fitting it in." Systems integration is a critical part of every project, and it is certainly a potential source of project failure. Remain alert to the many challenges — and opportunities — that integration presents.
Priority is Meaningless
Once you include all four business disciplines in the requirements phase, it is common for the project scope to expand dramatically. One of the most important things to establish up front is which requirements are critical (as in "show stopper") versus which are "nice to have."
While working with clients on determining what’s critical, don’t get bogged down by the "priority game." Manager-types love playing the priority game, but the truth is that priorities are meaningless. All you really care about is which requirements must be delivered in the next release.
When working with clients on the first release of a project, I always advocate that we strip the project down to just the essential requirements. The sooner the project is implemented and doing work for the organization, the sooner it starts to pay for its own upgrades. So what is essential? I ask the question this way: Is the project still worth doing if we leave this requirement out for now? For all essential requirements, the answer is "no" and for all non-essential requirements, the answer is "yes." That’s all you need to know.
The reality is that by the time the next release is being considered, the business will have come up with fifteen new requirements that are all more important than any of the things you decided to leave out of the first release. That is one reason why setting priorities is a waste of time.
Protect Your Project’s Future
Few software projects apply the rigorous requirements gathering process I just described. It is no coincidence that many software projects also fail. Granted, projects fail for many different reasons, but your project has a much higher chance of success if it has the support of your customer and it smoothly integrates into the business on the first try.
Every critical requirement is a torpedo that can sink your project. You want those requirements on board from the beginning, rather than streaking at you late in the development cycle. Critical requirements often have implications for your database design, and late changes to the database design usually have a big impact on your application code. It is a nasty situation that can blow a big hole in your delivery schedule, and a big enough delay puts your project at risk of cancellation.
The good news is that you can do a lot to protect your project’s future and improve your value to the business. If you take responsibility for making sure that your application has been considered from the marketing, finance, legal, and operations viewpoints, your project will shine and you will become a rare and appreciated resource.
