Entity Relationship Modeling - Level of Knowledge
(Page 13 of 21 )
In the analysis team, the system analysts must have an expert level knowledge of business modeling. By business modeling, I mean exactly that. (i.e. I do not mean expert knowledge of Entity Relationship modeling without relating it to the real world.) However well 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 staff composition. 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. This means 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 tools 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.
Analysis progress
With the tools of today’s technology (laptops, projectors, computer networks and not least, the Internet), the analysis process can take place literary anywhere. Actually, most processes are mobile. For all practical puposes, we are more mobile: some parts of the analysis progress may take place at the business office, and other parts at the analyst’s office. They can communicate on the net at any time, collaborating outside of formal meetings. No doubt, this is increasing performance in the analysis progress, as well as saving time, and thereby costs.
For instance, sometimes I do vital parts of a project at my home office, but my tools repository (Oracle), resides on the server park at the office. I can also get limited access to it for my customers, if I wish.(Sidebar: The invention of home offices is perfect for employers: We, the employees, work both day and night, and on top of it, we love it…Crazy world). OK, back to business: While we may have inherited a sketch of an ER model from the strategy phase of the project, now is the time to start asking the difficult questions. We will be probing that sketch, and stressing both the model and the business representatives (yes, I am now talking on behalf of the system analyst; since you are still reading this, most likely you are also one).
Next: Experience vs. Inexperience >>
More Development Cycles Articles
More By Alf A. Pedersen
/ 53 
