Tag Archives: Governance

More on WSRR

Today we finished our week long workshop with the Hursley guys. I really feel we got a good grip on the capabilities of the WSRR. Yesterday I showered praise on the product, so today, being a Libra, I will rant a bit about some drawbacks, before I end on a more positive note.

My main concern with the product is that it still pretty raw. A lot of the configuring goes on in XML and properties files, and functionality is tweaked using Java plug-ins. This is both a strength and a weakness. A strength, because it is flexible and standards based. A weakness, because it makes it really easy to get lost in all the config files. I’m not sure it is a big problem for our customers – after all, that’s why they hire consultants 🙂 . But I sure would love some tooling that could simplify some of the more routine tasks, such as customizing the navigation tree.

But at the end of the day (which it literally is – I’m awaiting a late night flight to Finland), I feel very positive about the possibilities with this product. A different story is the one about the learning curve for both us and our customers when it comes to implement governance from a people’s perspective. I think I’ve quoted this before, but i do it again, because it illustrates the core problem: Everybody wants governance, but no one wants to be governed. We will have to strike a balance with our customers between too much procedural rigor and too little. Most will likely come from a history of no governance at all, so we will have to find ways to introduce sufficient, yet pragmatic processes, especially when we start using tools to enforce procedural compliance. This will require other skills than the purely technical ones required to install and configure WSRR. It will be a most exciting journey!

My hope is that we will soon have a first version of Baseline implemented for WSRR – I’ll keep you updated in this space.

Vegas – Wednesday

Today I’d like to focus on SOA Governance, a hot theme here at Impact. I’ve been going to a couple of sessions and am beginning to realize the confusing breadth of tooling available to us and our customers. One particular session focused on the respective communities involved in the service life-cycle and the supporting tools for the phases of this cycle. The three rough phases are Building; Configuring and Executing; and Managing services. It turns out that IBM offers tools to support these 3 broad activities. Rational Asset Manager will help developers find all sorts of assets in order to assemble them into solutions. WebSphere Service Registry and Repository will be used to configure various aspects of a service, such as policies and endpoints, and will be able to leverage these configurations in run-time. Tivoli Configuration Management Database, finally, will be the supportive tool to manage the services in runtime. Into the picture also enters Tivoli Composite Application Manager for SOA that somehow interacts with the previous product.

The session outlined how these products managed various sets of a service’s metadata throughout the service lifecycle. Through various connections, they can also propagate the metadata between them. I won’t pretend I understood all the details, but what I did understand is that only this layer of the whole SOA cake is big and confusing. How on earth shall we help our customers digest this, I wonder? This product proliferation, with the various offerings partially overlapping each other, screams out for simplicity, not one of IBM’s most prominent attributes 🙂 .

Again, as we did with systems integration, we will have to find the simple story and packaged approach to this. Stay tuned!

Oh, by the way, I got myself certified (the two SOA tests), which was fun. Especially the second test was strange, with a lot of fuzzy questions. I did pass it with a hair’s breadth, so obviously some luck went into it, but hey, that will be forgotten quickly!

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.