Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Data Analysis
Instead of focusing entirely on architectural issues at this stage, it offers a refreshing perspective to be able to look at the data. Ask the customer (even if you are your own customer) about the information content of each page. When is this different, does this change at the same time as that, where does this input come from? This lets you ask yourself what entities you must therefore store as relational data. When you start to get a picture of the data, you can ask yourself where and how it is going to be processed.
There can also be structural data, of course. If the organization needs to represent its departments on the web, each department has certain things in common. The techniques of normalization can help here to avoid falling too early into the trap of overcomplicated design and to suggest lines along which the software might be partitioned. Suppose you have a department entity: how should the department's data appear to the users? Will every department use the same page template or will there be a need to vary the presentation? Does the department determine the page style? Which classes of users will be putting in what type of data? Sometimes it is useful to be able to offer drill-down, expanding the detail of summarized figures with pages lower down the hierarchy. Where in the web would this be useful? The operational data may live in an entirely different database from the structural information. There is no reason why web processes cannot use multiple data sources.
This initial uncertainty about how well it will be possible to fulfill the users' expectations can add pressure, but it is important to have considered more than one alternative for as many aspects of the system as possible. The whole exercise is a little like fitting a jigsaw puzzle together. The earlier pieces are more difficult to fit together because there is less context in which to determine their overall and relative positions. At this stage of a design, I find myself doing a lot of wondering—will this entity relate to that, will separate activities share data, which pages will use which parts of the database, and so on. It is almost as useful to find something that won't work, and understand the reasons why, as to find something that will work.
Brainstorming techniques also can be useful during the early stages of design. If you have not come across the technique before, it is a small-group activity in which ideas are generated with no "that could never work" censors in place. Participants are encouraged to free-associate, and to propose even the most outrageous and impossible ideas. After the idea-generation period is over, critical evaluation is used to examine the ideas for any useful germ of relevance. Surprisingly often, brainstorming can produce innovative design ideas. If you have never considered using this technique, you might be interested in a visit to http://www.brainstorming.co.uk/.
Finally, you have to decide what framework you are going to use to support the structures you are imagining. However, you will have begun to realize that compared with the classic web servers, very little has been done so far with their lightweight counterparts.