Work-Integrated Learning Community Support and Research Portal
Following part one of this three-part series, this post will define the types of information models that exist and the role they play in directing and managing a project.
Business and technology will change over time – staff members come and go and new inventions emerge daily – but information is near constant. When the first universities opened in the middle ages, they too had course listings, important dates, scholarships, job offers, and salary records, and centuries later the institutions have evolved and the technology has advanced, but the information behind it all remains strikingly familiar.
Information modeling is about recognizing this continuity and documenting it for reference when planning changes to the organization. In the case of the WIL Research Portal, this change was the addition of a new tool to capture a set of information that always existed, but had not been addressed before. In other instances, it could be a change in an existing process or application. In either case, knowing in advance what all of the relevant information is and how it will be used helps guide the requirements of a project.
There are three levels of information models, each differing in their degree of specificity and the purpose they serve. Which one(s) might be required for any given project depends on the scale of the undertaking and how well the area is already understood.
Conceptual models are the most abstract and least detailed form, but as a result, once completed correctly they should only ever change if the basic nature of the organization changes (i.e. we stop conducting research or start a manufacturing department). Ideally, they can and should be completed independently of any project – by proactively creating models for the entire institution they can be referred to by future projects without any delay in the timeline.
These diagrams, generally depicted as labeled boxes and lines, visually say ‘here are all of the entities (people, places, objects, activities, events, ideas) that we have information about, and how they relate to one another’. As such, they are ideal for determining who all of the stakeholders in a project are; any department with a ‘students’ box, for instance, may be affected by changes to the student information system and should thus be consulted. They are also useful for identifying where the same term is being used differently, or where different terms are being used for the same thing, preventing miscommunication between departments.
A logical model digs into each of the entities and outlines all of the information that is being collected about them, or that would be valuable if it were collected. This could be at a field level or in more generic bundles of related fields (identifiers, contact information, medical data, etc.). If the information comes from multiple people/systems, these models can also identify from where each part originates.
This view is more likely to change over time, but typically through the addition of new information or the change of system names, rarely the removal of existing entries. As a result this is also documentation that can be created outside of the context of a project, and simply updated as future projects impact it.
A complete set of models for of the University’s activities can be combined to provide a holistic picture of all of the information we have about students, staff, buildings, courses, finances – any aspect of our work. This is important both for effective analysis and reporting, and to prevent extensive duplication of information, which introduces technical, security and legal risks.
The final type, physical models, depicts the specific implementations of information sets in an application or document. This can include the table structure of a database, the types of fields (date, integer, etc.), minimum or maximum lengths, and any other rules for the data.
These models will change as often as the system does, and thus are part of any project undertaking. They should, however, be updated during the planning phase of development projects, or requested early in Request for Quote (RFQ) and Request for Proposal (RFP) processes and obtained for review before a contract is signed.
In addition to being valuable documentation for operations and maintenance, when compared to a logical model these diagrams can provide a clear indication of the fit/gap of a particular system to the purpose at hand, and thereby guidance for where additional tooling might be required.
There are several benefits to having an appropriate set of information models available at the outset of a project, rather than as afterthoughts or optional supplements. The first is that if multiple parties are involved in design, development, communication, or any other aspect of the work, documented models will help ensure they are all working from the same playbook and can coordinate effectively. For the WIL Research Portal project specifically, this allowed one team to start collecting data in a spreadsheet designed to match the database structure the development team was going to make, resulting in a populated prototype within a very short timeline.
The second major benefit is the ability to plan and prepare integrations between systems with relative ease. Any potential issues resulting from differing data formats, missing fields, etc. can be identified early and addressed before they cause delays during implementation. Particularly for large-scale projects, at least a physical model should thus be a pre-requisite for intake to even begin.
Check back Tuesday for part three of the series, which explores "co-operative labour".