Architecture

There's simply to much to be said and written about architecture. The short version is architecture is the work of the architect who will look at the system as a whole to design the workings of the whole.

From this definition, this page describes topics which are a little bigger than a single screen, or function in CaseTalk, hopefully allowing the reader to understand the bigger picture.

Information

The method FCO-IM is build on the premise that data structures need to be communicated. And the key to building data structures is not to build an abstract model, but to capture the concrete communication in the first place.

Employees who work together and communicate, will do so in a concrete manner. When work needs to be discussed, they will rarely use 'a customer', rather they'll refer to a specific customer. In this facts are exchanged. For IT systems to support their work properly, to give employees the tools to manage these facts, and communicate them in in automated fashion with collegues, these systems should align with the communication itself.

Up and Down

Capturing the communication on a concrete level is a so-called bottom up approach. The very detailed bottom level results in solid and high quality information, and data models, but lack the top-down support.

Even though bottom-up approach is mandatory for CaseTalk to perform model-to-model transformations, architects who describe the whole also need more global functions. Such functions all aspects that come with it, is called the top-down approach.

CaseTalk supports this using Concepts, Containers and Relations. A customer can be entered as a concept, and defined using a business definition, before facts about the customer are communicated, captured and modelled. This is a very top-down approach. Similarly Containers can be created containing the customers, employees and consultants, and whatever more. Again, a top-down approach.

Some hi-level information needs to be drilled down to reach the levels where bottom-up end. This can be accomplished using various methods.

1. Link concepts and containers to each other
2. Link concepts and containers to fact/object and label types
3. Add Fact Expressions to concepts to promote them to Fact/Object types.

Levels

Architecture typically is described on various levels of details. From top to bottom the levels can defined in numerous ways. CaseTalk, being a typically bottom-up tool, provides higher levels using concepts and containers. To support integrated levels, CaseTalk uses bookmarks. These bookmarks can point to anything CaseTalk can handle: Models, Diagrams, Object/Fact Types, or even Symbols within Diagrams.

This multi layered approach can then be interconnected. Hi-level concepts can link to other terms, or link all the way down to the bottom-up information, and vice versa.

Model Lineage

Once models are build, they usually enter continues life cycle, and versions need to be managed. Models need to be exchanged, or parts of them, and artifacts generated. All this management across models and versions requires lineage.

Lineage is loosely defined as the accounting which need to happen to trace where things come from, and where they are going to.

CaseTalk supports lineage on the finest grain as Object/Fact Type and Expressions. Models are versioned in the Enterprise Edition, and allow a containment of snapshots. Every piece of information defined in one model/version, can be merged into other models, and CaseTalk will manage the lineage for you.

This support will provide deep insights in where definitions come from, and where they are re-used.

References

To be able to perform lineage on the model elements and have version management is only one aspect of a full data management practice. More and more, the emphasize is on the 'who dunnit' aspects.

This requires CaseTalk to also support, lineage on where definitions come from, who stated certain facts, who modeled it, what's the status of Object/Fact Types, etc.

The customizable metadata in CaseTalk allow users to adjust the additional administration required to their needs through simple configuration dialogs.

These metadata can be custom annotation fields, custom attributes, and URIs to navigate from and to external documentation systems.