Mr Baseline’s EAI Crash Course – Part III


Baseline (developed and marketed by Zystems) is a methodology that distills tens of thousands of hours spent integrating IT systems of some of the largest enterprises in Scandinavia into a lean packaged Best Practice for implementing an ESB.

Concept Model

A sound ESB will have a coherent design that permeates all solutions deployed on it. In order to achieve this coherency, Baseline defines a small number of key objects and their relationships to each other. Every solution will be modeled using those objects. All document templates are structured using the same objects.
Integration work generates a myriad of artifacts, such as documents, source code files, script files, binaries, and so on. Naming these artifacts in a consistent way is no small feat (as anyone involved in designing naming conventions will testify). Structured around the concept model, Baseline includes a comprehensive set of Naming Conventions, ranging from the naming of documents, all the way through the naming of source code files, and how to structure and name folders in a versioning system.

An example of such an object is the Contract. The Contract explicitly defines the relationship between the Consumer (another object in the Concept Model) of a Service and the Service itself. In a future post I will present the concept model in more detail.

Documents and Templates

Documenting an ESB in a consistent way is crucial for achieving a number of important goals:

  • Maintainability. Supervising and managing the ESB is a complex art, since it will involve a number of operating systems, servers, software components, and contacts with system owners. Having a set of consistently designed documents, all kept in the same place, describing all solutions deployed on the ESB is absolutely essential for this task.
  • Reusability. As elaborated later in this white paper, a sound ESB is an ideal foundation (actually, it’s more or less a prerequisite) for building a SOA (Service Oriented Architecture). One of the key promises of SOA is the concept of reusable services. However, a service poorly documented, and hidden away on some shared disk in a network, is not likely to be identified by new integration projects on the lookout for reusable services. Having all services documented in a consistent manner in a central registry is a minimum requirement for service reuse to happen.
  • Quality. Working with design and implementation supported by document templates ensures that all relevant questions are asked at an early stage (provided the creation of the documents is a living part of the design and implementation process rather than an afterthought).

Baseline provides a comprehensive set of templates and documents covering all aspects of an integration project, including:

  • Requirements collection
  • Project startup
  • Solution design and implementation
  • Testing
  • Packaging and deploying solutions
  • Supervising solutions in a production environment
  • Governance (i.e. the centralized organizational function of maintaining consistency across integration projects)

In the next post…

…I’ll continue to explore the Baseline methodology.

One response to “Mr Baseline’s EAI Crash Course – Part III

  1. You clever son of a ……. I like your way of doin this! Great as always.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s