The Database Analysis Team - Teamwork

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 advantage 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 advantage against 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. This is what a good analysis team should disclose: 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 see 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 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 composition of the total project staff . 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 consequent stage of the development process. I regard the tool(s) chosen as an integral part of the team. The tool will also act as the communicator between the business and the analyst.

I always start 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 my eBook on Entity Relationship Modeling - Principles was written, which you are free to download and use in your ongoing or upcoming projects. (You have to subscribe to my newsletter in order to access my download page). As for choice of modeling tool, I give no specific recommendations: There are many different tools available. I have personally 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 on the user interface, or the most advanced business constraints built into it.

Return to The Analysis Phase