The Database Design Alalysis - Business perspective

The Database Design Analysis phase - Where it all starts.

The business perspective

The analysis phase of our database design website deals with the early stage of a business system lifecycle. This is the phase we enter after strategic requirements are in place: The scope of the system, key technical requirements, and the tools for each stage of development, etc. is decided. Economics are most likely also determined.

We may also (most likely) have a rudimentary information model, and we know about key functionality that is required. The main purpose of the analysis phase is to bring all these pieces together to form a business model containing all entities with their attributes, domains and relations, together with a complete function model with its hierarchy, as well as domain constraints (on attributes), business rules (constraints), and events that trigger functions. The output of the analysis stage will be carried over to the design phase of the development project.

The one most important thing to remember in the analysis phase is: Our scope is to determine WHAT should be made, not HOW.

In many projects, I have overheard participants starting to talk about how a given function should behave Colors, buttons, defaults etc. However, all of that belong to the design phase. You have to stop this at once: The analysis phase is about the BUSINESS, not the SYSTEM. The system shall reflect the business, not the other way around, as sometimes unfortunately happens.

Actually, the analysis phase is an excellent time (and the right time) to learn the business in-depth. I do not insist that you know the business in detail. The business itself knows its business. Therefore, your chances of failure are high without business participation. On the other hand, I have witnessed failure in projects where the business wanted to control the whole process alone, and just use 'hired hands' to execute their demands. A balance has to be established.

As with many other things in life, neither to little nor too much of a thing is a good thing.

'Good judgments are based on experience. Experience is based on bad judgments'.

The importance of a professional Database analysis team.

The complexity and degree of computer involvement in the business is constantly growing. No wonder; each 18th month, we can buy hardware with twice the performance at the same price. We are therefore able to put more demands on our software, until we reach some limit. However, it only takes another 18 months; then we can buy new hardware without these limits... and so on.

There is also a good reason for it: We may very well rely on a standard system for our accounting or payroll routines, we can use market standards in word processing and spreadsheets, and so on. What separates a high-performing business from a failure is the way the CUSTOMER is reached for, and how he is treated. That is customer marketing and customer care. The customer is always the business. If you do not have customers, you do not have a business.

If such a business exists,however, please let me know.

Such systems, systems that give the business an advance compared to its competitors, we may call strategic systems. If two businesses buy the same strategic system from the shelf, then they do not gain any system advantage towards each other. On the other hand, the business that is fastest to respond, and deliver, and at the same time is competitive, will definitely have an advantage. In a world with rising competition and globalization, this will grow more and more important. Good news for the software industry and the analysis team...

In the analysis stage, we need an analysis team of both business experiences as well as experienced system analysts. In addition, we need tools that can help us seeing the overall picture, as well as helping us further forward.

Top business experience is required in the analysis team in order to get in-depth understanding of the business itself.

Remember: Our model, at this stage in development, must reflect the business, not some constraints given by any tool or personal preferences. This happens all too often and usually with not-to-good results.

In the analysis team, the system analysts must have an expert level knowledge of business modeling. By business modeling, I mean exactly that. I do not mean expert knowledge of f.i. Entity Relationship modeling without relating it to the real world. However good a person may be educated, nothing beats the experience earned from several similar tasks at the equivalent level of complexity. How does one gain experience then? Participate under a tutor. I would never hire a consultant without experience and trust her to understand the complexity of my business, all by herself.

I will not go into detail as to the total project staff is composed. This will depend on many outside factors, such as degree of participation from each party, size of the project, formal requirements (public sector tends to require at higher level of project staffing, partly due to rigorous documentation requirements), etc. What we focus on is the tightly performing party that determines the final business model: The experts on the business together with the system analysts, preferably more than one in this phase.

Due to the increasing complexity that tends to be taken into systems development, I cannot imagine a development project of any noticeable size that should not use a development tool as support for the analysis team as well as for each stage other of development. I regard the tool(s) chosen as an integral part of the team. In many cases, the tool is also the communicator between the business and the analyst. I have often started a project by going through the way we communicate with each other. In my experience, the business soon finds Entity Relationship diagrams familiar, if not as familiar as to the system analysts. However, they are a means of communication that work. The same may be said for function diagrams, or function hierarchies. They are even easier to understand for a non-system person.

That is why the eBook on ‘Entity Relationship Modeling – Principles’ is in the writing, and soon will be published on this site as a free eBook, which you are free to use in your ongoing or upcoming projects.

As for choice of modeling tool, I give no concrete recommendations: I have used Oracle Designer (formerly Oracle CASE*Method) for the last 15 years, and I have found it to be a powerful and rich system, which delivers in many more areas than I have needed to use it for. I am probably a little biased here.

However, a toolset should include reusable objects: The results from the analysis phase should be the basis for generating tables and all other database objects for use in the design phase, as well as functions should be used for generating candidate modules. Furthermore, the database objects and candidate modules should be used to generate the DDL (Data Definition Language) scripts for physically building all the elements of the database, as well as the candidate modules should be used to generate running program modules. Not that I expect a system to be 100% generated – far from it. However, with such functionality you could show a prototype, which illustrated the resulting, needed functionality, but without the last finishing touch or the most advanced business constraints built into it.

For more visualization of this article, visit http://www.databasedesign-resource.com