An organization is looking to improve the methods it uses to develop and integrate IT systems into its operations.
An organization needs common definitions of the simple concepts that are used in many applications to improve the efficiency and consistency of the work of its developers. However, it does not have a strong skill base in modeling.
Some organizations do not have a strong skill base in data modeling. This is often true where developers are using agile development, because their focus is on rapid prototyping and delivering solutions incrementally. Without constant refactoring, the code developed using this approach can become bloated and inconsistent. As a result, mature agile development teams have a strong emphasis on standards and consistent approaches.
How is it possible to bring the benefits of a common information model to a team of agile developers who do not want to spend time creating, or learning, a large data model?
The mobile development team at GKDMR Travel is working on three new applications:
- A customer application that will work on a smart phone or tablet and enable people to maintain their customer details, see their loyalty status and any outstanding offers they have, and browse the holiday destination catalog, in which they can view other customers’ feedback, book holidays, comment on their experiences, and pay their balance.
- A tablet application for the staff working at the holiday destinations allowing them to receive the guest lists and details of the meeting points, receive instructions, report incidents, and interact with guests while they are on holiday through text messages or email.
- A tablet application for the staff in the travel agent’s office for helping with customer enquiries, booking holidays, documenting issues, noting stock levels of brochures, and reviewing the current promotions.
These applications need to be generated quickly, with iterations to allow the potential users to provide feedback on the suitability and ease of use of the applications. How does the team ensure consistency in the way these applications use the enterprise data around personal customer details, stores, products, orders, packages, and payments?
- Employing a common information model takes time. The team needs to learn about the existing content, develop new definitions, and correct errors.
- Agile development is often used where the requirements are evolving with the code. This is particularly common when the project is exploring a new technology, capability, or approach.
- The iterative nature of agile development means there is not time to wait for new model content to be developed, reviewed, and approved before it is used in the code.
Create a common information model that defines a clear meaning for each concept and a simple structure for how to record information about an instance of this concept.
The concept beads common information model is defined as a set of discrete concepts, as illustrated in Figure 3.1.
Figure 3.1 The structure of a concept beads common information model
Each concept definition has a business language description and preferred structures, possibly shown as a logical model for design documentation and then physical artifacts for different programming environments. These physical artifacts could be XML structures, JSON interfaces, Java object definitions, or any others that are commonly needed by developers, as illustrated in Figure 3.2.
Figure 3.2 Adding detail to a concept beads common information model
The concept beads style of model is used like a Chinese menu. Developers select the concepts they need for their code, link them together as appropriate, and include them in their code. Developers will adopt the standards defined in the concept beads common information model rather than create their own if the standards are easier to use, so the common information model artifacts should be placed so they are easy to search and download into the developers’ tools.
Changes to the definitions are developed and iterated on using an agile governance approach. Because the common information model is very modular, changes are localized and can be developed, approved, and deployed in a short period of time.
- The concept beads common information model can be developed incrementally as part of an agile development process. New elements can be developed as required by the development team and integrated into the model within the sprint (iteration) that identifies a new concept is required.
- The concept beads model is easy to consume, particularly by developers, because only a small part of it must be understood for it to be used, and it can be simply translated in programming artifacts for direct consumption into code.
- The concept beads model is flexible because concepts can be linked and combined in whichever way the developer wants.
- The concept beads common information model does not provide any guidance on how concepts that are frequently linked together should be related. This means there will be inconsistency in the relationships that are coded. This can be particularly problematic when trying to aggregate information from across sources for analysis.
- There will be situations where the attributes of a single concept bead are not well matched to the needs of a particular project. There needs to be rapid, responsive processes to discuss whether the common concept bead should be updated, or whether the project is given an exception. These processes are covered in more detail in Chapter 5, “Governance.”
GKDMR Travel begins its definition of a common information model by defining a collection of common concepts that are used repeatedly by its developers. Figure 3.3 shows a selection of these concepts.
Figure 3.3 A selection of concepts for GKDMR Travel’s common information model
Each concept is then expanded with a textual description, a logical model definition, and an optional number of physical implementation examples. Figure 3.4 expands the address concept to show these different definitions.
Figure 3.4 Concept bead definition for Address
The developers can download the standard formats directly into their workbench. The back-end applications that they need to call to connect to the business applications use similar structures. The developers who use the standard formats are far more productive than those who do not.
The AS 4590-2006 standard from Standards Australia is an example of a concept beads model that is a technical standard for addresses.
Systems of Engagement–based “born on the web” companies may benefit from this as their starting point.
If the relationships between concepts are important, and benefit exists in having consistency in how they are represented, then consider either the continuous fabric pattern or the encapsulated view pattern.