I was talking to a group of fellow BA's at a recent networking event and the topic of modelling (not the catwalk variety!) came up. I have to confess I am a big fan of the use of models during analysis work, as were a number of my other contemporaries at the event - they were particularly enthusiastic about the use of Use Case models to help define scope and specify requirements. However, I felt like a bit of an outcast as soon as I mentioned the 'D" word; none of them seemed keen on modelling data. So, I have been pondering the questions 'What is the problem with data?' and 'Why is it so scary and such a taboo subject for BAs?'.

The problem that BAs seem to have with data models is that they believe that they are for 'techies', and that somehow they relate to relational database design or object-oriented software development. There is some basis for believing this as data models that use the Entity-Relationship Diagram (ERD) notation can look detailed and technical, and do relate to the design of physical database schema; while similarly, some Class models (using the UML Class Diagram notation) do indeed form part of the design of an object-oriented software system. However, both of these notations (ERDs and Class Diagrams)can equally be used by BAs to define the business semantics and rules inherent in a business situation and, as a result, will provide rigorous definitions of the data requirements for a software solution.

When BAs create an ERD or Class model, they are modelling the concepts, entities, events and rules that their organisation needs to understand and manipulate. These may include customers, products, orders, deliveries, applications, employees, jobs, appraisals, accounts, withdrawals, policies,renewals, claims and so on depending upon the situation under investigation and in order to realise some key objective. Modelling these aspects of the data allows the BA to gain a deeper and more precise understanding of the business requirements so that these can be translated into business process and system requirements, and will provide a strong basis for the development of solutions that will meet the business needs. They also raise questions that can uncover tacit knowledge and clarify imprecise thinking.

When used to model the business system, they are often referred to as business domain models, conceptual data models or analysis class models, and they relate to business semantics NOT database tables or software components; consequently, they should be very much part of the BA's toolkit. As the domain models use the same basic notation set as is used by database and software developers, and it is often said that the BA forms a bridge between the business and IT, why not use the same modelling language and aid the communication process with developers? The models may look complex but at a domain level the techniques can be learnt and applied without difficulty - or technical knowledge.

So what's to fear folks? Get out there and model your business rules and data requirements and prove that data modelling is for business not just for techies!

The Business Alchemist