Mr Baseline’s EAI Crash Course – Part V

Baseline Start-kit

From the outset, our hallmark at Zystems has allways been simplicity. We’ve tried to make a complex issue (systems integration) seem simple, especially in terms of how to buy it and what you get. More and more companies are doing it; it’s called packaging. When we started out seven years ago, the middleware market was still pretty immature. Vendors, consultants and customers mostly grappled with technical issues. Yet our first project was sold and delivered as a packaged solution at a fixed price. I dare not think what would have happened had we failed that first one…Anyway, that first project and it’s success became the core of the story we started using when we approached customers with what became the Baseline Start-kit. The whole approch we had with new customers was simple: we started off with a tale most IT-professional could relate to: systems integration hurts, and we’re in a mess. We then moved on to offer the pain-killer: order and consistency (Baseline) using proved middleware from a well respected vendor (IBM). Then came the punchline: We’ll do all this in a couple of weeks at a fixed price. It was irresistable. We created so many new license deals in a short time for IBM in this tiny corner of the world that Swedish and international IBM big shots strated looking at the peak in their executive dashboard sales charts and quickly reined us in as a partner, a most fruitful relationship we’re still nursing and developing.

Today, the Baseline Start-kit is a set of services aimed at introducing and implementing an ESB in an organization in 2-3 weeks. It includes:

• Architecturing and installation of relevant IBM WebSphere products
• Training of the customer’s staff in using the WebSphere product (as well as Baseline Methodology and Software components)
• Completing a simple first integration project, using the Baseline methodology
• The Baseline deliverables themselves (Document Templates and Software Components)

This simple approach has landed us long and prosperous relationships with some of Sweden’s largest companies through the years, and, of late, companies throughout Europe and the US. So the old saying holds: Less is more.

In the next post…

…I’ll look at Baseline from an SOA perspective.

Does SOA require an ESB?

For those of you not subscribing to InfoQ, I just want to point you to this article, dealing with one of the cornerstones of how we recommend our customers to design their ESB, with or without an SOA perspective: Don’t Let Consumers and Service Providers Communicate Directly. It ends with a conclusion that I see pop up over and over again (and one that I agree with): No, an ESB is not strictly required to build an SOA, but it can sure help.

Interpersonal Mush

I’ll take a break from the EAI crash course today, it’s Sunday, after all .

I’ve just finished re-reading Clear Leadership by Gervase R. Bushe. He’s talking about interpersonal mush as being all the misconceptions and fantasies we all carry around about our colleagues, which creates a sort of haze in an organization. This mush makes it hard to make clear decisions, know who’s responsible for carrying them through, actually follow through on decisions that we all verbally agreed on and a lot of other stuff that members of any organization muddling along will recognize as more or less natural law, because we’ve never seen any alternatives.

I remember reading this book a couple of years back when we were only a handful of people and thinking that yes, I could recognize this from numerous (if not all) client companies I’ve ever worked with, but we were somehow magically spared from this mush. Well, since then we’ve grown, and sure enough, as we become more and more people sincerely pushing for growth and change with lots of good will, no matter how well intentioned we are, the mush creeps in.

Reading the book is a real eye-opener. It illustrates how certain basic human wiring will inevitably lead to interpersonal mush, unless we are aware of how we, as human beings, work and apply some disciplined techniques in our dealings with each other.

One of the most blazing revelations I had when I re-read the book has to do with what Gervase calls organizational learning. He outlines how we, when we try to decide a course of action, will operate from more or less clear maps of cause and effect. We will almost never try to uncover our conflicting maps (i.e. you have an idea of what will cause a desired outcome different from mine). Instead we will argue around superficial aspects of the problem, never really getting to the core problem, which is our differing perceptions of what will work and what will not. Gervase suggests techniques for uncovering those maps, until we reach the core assumptions. More likely than not, we will realize that either there will be facts supporting both assumptions, or (maybe most commonly) no facts. So what we’ll do is we make a best guess at what set of assumptions are most likely true, decide a course of action as an experiment, and agree to revisit our decision to see if the experiment confirmed or falsified our theories, always ready to change direction if our assumptions turn out to be false. In my view, this notion of decision-making as a constant process of experimenting and adjusting according to the results is the only way to navigate the uncharted waters of the precarious and ever-changing sea of business in the 21 century. The days when “experts” could be trusted with rational decision-making are over – we are all in this together, and all good ideas need to be floated and assessed for a company to flourish and gain competitive edge.

Now, for this to work at all, without people feeling threatened and guarding their pet theories in the face of evidence against them, a climate of interpersonal clarity (as opposed to interpersonal mush) must be established. Gervase paints a very convincing picture of both why the mush appears and how we can get rid of it.

For the interested reader, here is a paper outlining some of what’s in the book.

Mr Baseline’s EAI Crash Course – Part IV

Roles and Organization

Defining a number of roles, and delineating their responsibilities, is a crucial part of any successful software development effort. Baseline defines a detailed process for producing deployable solution packages, and identifies a number of roles. Having clear demarcation lines between the roles ensures a concept know as Separation of Duties.

As an example, the project team involved in producing a solution package is never allowed access to either QA (acceptance test) or production environments. This means that the people responsible for producing the code are physically unable to put it into production. Instead, a well defined process of handing the solution package over to the operations staff is defined in Baseline. After verifying the completeness and quality of the package, operations personnel are then responsible for deploying it.

IBM WebSphere and Software Components

Although Baseline is not tied to any specific ESB software vendor, we at Zystems currently work exclusively with IBM WebSphere business integration software, making us the leading consultancy outfit in this niche in Northern Europe. Comprehensive as it may be, WebSphere business integration software still lacks certain features, often involving small subsets of large, expensive WebSphere packages. Therefore, we also provide a number of software components complementing IBM WebSphere offerings.

Examples include various adapters to connect applications to the ESB; a testing tool called Testline, used to build automated test suites for unit and regression tests; and a transaction tracking application called Baseline Track & Trace, enabling complete transactions to be tracked through the ESB and searched using logical identifiers, such as order numbers or article numbers.

In the next post…

…I’ll talk about the Baseline Start-kit, which is our methodology for kick-starting a company’s introduction of an ESB.

Mr Baseline’s EAI Crash Course – Part III

Baseline

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.