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.

Mr Baseline’s EAI Crash Course – Part I

In the unlikely event that someone outside the circle of folks already familiar with the work we do at Zystems should find their way to this blog, I will spend the next couple of posts outlining our take on EAI.

Introduction

Integrating IT systems has traditionally been a complex and arduous task, and will remain so for the foreseeable future. Using sound methodology when tackling systems integration can substantially alleviate the complexity and avoid some of the pitfalls involved. This series of posts will outline some of the key features of such a methodology. It will also describes the Baseline methodology that enables an organization to get started with a fully implemented integration platform in 2-3 weeks.

The Problem

If you’ve ever tried to get more than a few IT systems to communicate with each other, you’re familiar with all the problems involved. Over time, you end up with an almost organic web of interdependencies. Obscure, poorly documented point-to-point connections (or interfaces), involving a bewildering collection of formats, protocols, and technologies, make up an infrastructure that only the most courageous dare tamper with.

One of the reasons for this is that most of the integration work has been done as part of the various projects dealing with developing and implementing the systems being integrated. This way, no coherent view on system integration exists. Each interface will be designed and implemented from scratch and choice of methods and technology will be entirely up to the people involved in the different projects.

As more and more demand is placed on the IT infrastructure to be flexible and responsive to new business demands (agile is a popular buzzword for this), the spaghetti approach becomes less and less satisfying.

Towards a Solution

Some years back, a way of dealing with this problem emerged in the shape of an architectural mode called Hub and Spoke. This architecture was built around the notion of having one central piece of software (the Hub) deal with all the complexities of inter-system communication. A new class of software, called Message Brokers, entered the stage, providing the technology to build those hubs.

Deploying this kind of middleware is, in itself, not a guaranteed way to integration nirvana. Although you now have a bunch of software components that can help you connect your systems with each other, nothing stops you from keeping the point-to-point mind-set, and you may end up creating a somewhat more coherent and smaller bowl of spaghetti. It will still lack the consistency that is required if you want control and transparency.

In the next post…

…I’ll introduce our view of the ESB and what you should expect from an EAI methodology.