Tag Archives: Baseline

New Stuff

As I’ve talked about before, we have a concept called the Baseline Start-kit. It is basically a combination of a set of well defined services combined with reusable Baseline assets, such as naming conventions, document templates and software components.

Last week me and a couple of colleagues spent 5 days putting together a Baseline Start-kit for DataPower. It was the first time we made such a focused effort, and it was great fun, as well as efficient. In the past, Baseline artifact have been harvested piecemeal over longer period of times. Now we feel that the Baseline Start-kit framework, as well as the existing Baseline structure is solid enough to work as a template for new products and domains. In the pipeline, WSRR and BPM are awaiting similar treatment. Check back!


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.

Mr Baseline’s EAI Crash Course – Part II

The Enterprise Service Bus (ESB)

These days, we refer to the hub as the ESB, or Enterprise Service Bus, and we clearly define its responsibilities:

  1. Connectivity. The ESB should be able to transport data using one of a clearly defined small set of protocols, such as HTTP or some message queuing protocol (e.g. JMS).
  2. Protocol Conversion. The ESB should be able to convert data sent over one protocol, so it can be forwarded over another.
  3. Data Transformation. Different systems will send and receive data in different formats, such as fixed length flat files or XML. The ESB should be able to transform (or map) data freely between such formats.
  4. Routing. A key feature of any sound integration architecture is loose coupling, meaning that the sending application should know as little as possible about the receiving application. Therefore, no data is sent directly between sender and receiver, but is always routed by the ESB.

These activities are collectively called Message Mediation. As simple as it may seem, designing and implementing an ESB around these four key capabilities is complex and requires careful design. Without a solid methodology, the full potential of the ESB will not be realized.

Methodology Key Features

After having completed a number of integration projects, you come to the not-so-startling conclusion that a lot of the stuff you do is done in pretty much the same way regardless of the systems involved. You map from one format to the other. You connect the ESB to various systems by reading and writing files in directories, or reading and writing records to database tables. You document your work. You deploy similar artifacts in similar ways to the same environments (e.g. test environment and production environment).

A sound methodology should capture those general components and make them available to all people involved in integration projects. Examples of such components include reusable software, document templates, procedures, and roles.

If you think you’ve seen this before, you may well be right. RUP (Rational Unified Process) is an example of such a methodology. RUP, however, is an all-purpose software engineering discipline, not immediately applicable to systems integration work (or any other specific software engineering endeavor, for that matter). What we will focus on in this series of posts are the specific features of a systems integration development methodology.

In the next post…

…I’ll introduce you to Baseline, the methodology we use at Zystems to deliver EAI solutions to our customers.