|
Information Modelling Workshop |
|
Our information modelling workshop has now been extended to 4 days, to address current requirements and concerns. It is based on over twenty years practical experience in data analysis and information modelling, and is aligned with the latest developments in information systems and software engineering - including UML and XML. |
Data analysis/information modelling has been practised in the IT industry for many years, for a number of related purposes: database design, information system design, data warehousing, and system integration and migration. Despite the recent popularity of object technology and object modelling, and despite the growth of component-based development (CBD) and open distributed processing (ODP), data modelling remains an important technique for software developers - regardless whether these models are expressed as entity-relationship diagrams, in the data modelling extension of UML, or in some dialect of XML.
Although information modelling remains a key component of traditional top-down structured methods and database design, it finds good practical use in many other types of project. For example, if you need to map data between interfaces and between systems, then you need logical and physical data models representing the interfaces and systems that you're trying to integrate. All of the following need some element of data modelling: data warehousing, data mining, data migration, enterprise application integration, system merger, legacy mining, B2B, BizTalk, web services. If you want to use a web service or a software component, you either have to adopt its vocabulary, or map its vocabulary to yours - and these are both essentially data modelling activities.
The basic questions of
information modelling are as important as ever. How does the marketing
department's
notion of CUSTOMER map
onto the accounts department's notion of CUSTOMER? How do we identify
instances of CUSTOMER? How many instances of CUSTOMER do we have?
If we have dozens of different ways of identifying instances of PRODUCT,
how can we rationalize this situation? And so on.
The aim is to introduce software development staff to the purpose, concepts and techniques of data analysis and data modelling. The training should enable them to perform and/or manage data analysis and modelling tasks on real projects. They should be able to create and modify data models, and integrate these models into system solutions in a variety of contexts new build, legacy integration and COTS.
We recommend that the students should have the opportunity to practise these new skills within a short time of receiving the training, and that some degree of support is made available to them during their first project. We are happy to discuss the planning and provision of this support.
The aim of data analysis is to achieve a clear understanding of the data structure of a system or interface, whether actual (AS-IS modelling) or required (TO-BE modelling). The aim of data modelling is to document this understanding in an unambiguous modelling language or notation and perhaps to record it in a software tool that supports one or more notations.
The traditional way to teach data modelling has been notation-led or tool-led. This starts with the constructs in the modelling language, or the commands in the tool, and then shows how each of these can be used to represent simple situations in the "real world". The student is then given simple exercises, which typically consist of translating a piece of text into the chosen modelling language perhaps by underlining the nouns. In our experience, most students find this kind of exercise fairly trivial, and they come away having learned little, ill-prepared for the actual challenges of data modelling on real projects.
Our approach is the reverse of this. We start by understanding the place of data modelling in the software development process to provide a robust bridge between a practical situation and a practical solution. We assume that the student will have little difficulty using any reasonable notation or tool, once he or she understands the thinking processes involved. Our exercises are designed to simulate the actual tasks of data modelling in live projects which is much more likely to involve working with, merging and extending existing models, and creating mappings between multiple models, rather than producing small/simple models from nothing.
We also believe that modelling is an interactive process, not a solitary one and that the students learn from debating different solutions with one another. We therefore construct exercises that encourage such debate.
From a notation point of view, the differences between Entity-Relationship modelling and UML Class modelling are fairly trivial and we will provide practice in both notations. However, there are some important, although subtle, differences between the traditional notion of Entity and the modern notion of Object, and the students should appreciate the similarities and differences.
We have a significant amount of training and support material available, including a number of case studies from various industry sectors. We also have documented a large number of patterns both recommended micro-solutions to common problems, and also negative patterns pitfalls to watch out for when modelling, or when reviewing the work of others. This material will be available to the students as an ongoing resource.
Our general plan is as
follows. The mornings are spent on highly interactive discussion, usually
with the whole class together, interspersed with fairly short illustrative
exercises. The afternoons are spent on extended practical exercises in
groups, brought back together periodically to compare results and identify
general lessons. However, this framework is flexible, and can be varied
according to the needs of the class.
| Day
1
AM |
Motivation:
The Need for Corporate Information Management
|
|
Data
and Object Modelling Overview History and Present Status
|
||
Context:
The Place of Data Modelling in the Solution Process
|
||
| PM | Exercise
1: Simple Modelling
In this exercise, the students are given a simple scenario and required to model it. Among other things, this exercise helps to highlight the different ways each group interprets the scenario, and the investigation (fact-finding and negotiation) that would be needed to choose between or reconcile different interpretations. Exercise 2: Model Review In this exercise, the students are given an existing model, challenged to identify its strengths and weakness, and recommend improvements. |
|
| Day
2
AM |
Using
the Data Model
|
|
Refining
the Data Model
|
||
| PM | Exercise
3: Start from the Information Needs
In this exercise, the students are given some business information needs, and challenged to support them from an existing data store (whose logical model is provided). The exercise is then reversed, and students develop scenarios that can/cannot be supported by a given data store, to understand the degree of flexibility implicit in the data structures. |
|
| Day
3
AM |
Quality
Goals: What The Data Modeller is Trying to Achieve
|
|
| Quality Data Modelling Patterns and Pitfalls | ||
| Managing the Data Model(s) Coordination Issues | ||
|
|
|
| PM | Exercise
4: Evolving an Existing Model
In this exercise, the students are presented with a series of increasingly complex demands. The task is to evolve and extend the data model to accommodate these requirements, and also to clearly articulate the implications of any changes that they make. |
|
| Day
4
AM |
Mapping
from one data model to another
|
|
Data
Interfaces, Web Services, APIs and Exchange Protocols
|
||
| PM | Exercise
5: Negotiating Information Exchange
In this exercise, each team is given a different problem, with a different perspective, and required to develop a data model from this perspective. The teams then negotiate interfaces and protocols for the exchange of information, while each preserving the integrity of their own model. |
|
| Brief Recapitulation and Review | ||
Richard Veryard has been a practising data analyst and modeller, as well as teacher and mentor, for over twenty years. He first developed and taught public data analysis courses when working at Data Logic / Altergo in the early 1980s, and this led to his first book Pragmatic Data Analysis which was published by Blackwells in 1984. More recently, he has published three books in the BCS Practitioner Series Information Modelling: Practical Guidance (Prentice-Hall, 1992); Information Coordination: The Management of Information Models, Systems and Organizations (Prentice-Hall 1994); and Component-Based Business: Plug and Play (Springer Verlag, 2001). He worked at JMA/Texas Instruments Software for over ten years, and has been a freelance consultant since 1997. He is a regular contributor to the CBDi Forum.
Recent information modelling assignments have involved information strategy planning, data warehousing, and data migration mostly in banking and insurance. He has previously worked in a range of other industry sectors, including Manufacturing, Retail, Oil and Gas, Utilities and Telecoms.
For in-house courses, we assume that the client will provide a suitable venue for the course, together with equipment, stationery and refreshments. We recommend a seminar room with the seats arranged in a U-formation. The presenter needs a data projector and screen, and a flip chart.
We recommend a class of between 7 and 17 students. The exercises will be carried out in groups of 3 or 4 with a maximum of 5 groups. There should be space for each group to work independently on the exercises either in the corners of the room, if its large enough, or in separate rooms. Each group should be provided with its own flip chart and other stationery.
In addition to training, Veryard Projects Ltd is happy to quote for general support in this area, including product/process review, team mentoring and coaching, and tool strategy either on an adhoc basis or as part of an ongoing support contract.
| top |  |
|
|
Copyright © 2001 Veryard Projects Ltd http://www.veryard.com/infomgt/immdworkshop.htm |
