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 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.

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.

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.