Mr Baseline’s EAI Crash Course – Part VI

The final installment of this EAI crash course isn’t about EAI but about SOA. So what’s the connection? To be sure, EAI and SOA are not the same thing at all. In fact, they address different domains. EAI is very much a technical discipline, mostly very IT-centric, delivering the technical solution to how disparate systems should talk to each other. SOA, on the other hand is (or should be) mostly about delivering business value through a complete overhaul of the way a business is managed, where the architecting of the business is the starting point for the implementation of this architected design using IT.

This description, as many of you know, rings pretty hollow in the mundane corridors that many of us inhabit. Mostly, business management still view SOA as primarily an IT issue, and IT struggles to “deliver SOA” despite the fact that it simply can’t be fully done without extensive management commitment.

However, what can be done while we’re waiting for the rest of humanity to see the light is to start putting an SOA-enabling infrastructure in place. And this is where EAI and SOA converges, in the shape of the ESB. It turns out that a well structured, well documented ESB where the Service concept is part of the basic design patterns is an ideal foundation for SOA. There is a journey of learning to be done, where the technical aspects of designing, implementing, deploying and maintaining services can be mastered. Using Baseline, the community involved in EAI can prepare themselves technically and organizationally for SOA, so that when the business folk eventually are ready to start requiring some real business centric services, the skills and delivery capabilities are in place, and requirement realization can be swift.

We believe strongly in this approach to SOA, so much so that we formalized this in the Baseline SOA Roadmap. Its purpose is to help companies start on their SOA journey. It won’t be SOA at first, but the transition to SOA will be that much easier when the basic skill-set is in place.

The roadmap itself is pretty simple:

1. Put an ESB in place
2. Make sure it is designed and documented using a structured, service-centric methodology (such as Baseline)
3. In the day-to-day EAI work, start identifying and implementing reusable services, applying appropriate design patterns
4. Eagerly await the rest of the business to jump aboard!

We actually got inspired to do this by one of our clients who said: “We started of doing systems integration using Baseline, and when the SOA buzz arrived, we realized that, hey, we already have an SOA!” I would have to assume that they meant the SOA-enabling infrastructure – the organizational overhaul issues are squarly outside Baseline’s domain!

This post concludes the EAI crash course. If yo want to know more about Baseline, please visit our website.

Vegas – Summing Up

So – that was Vegas. Vegas is a bit like a freak show: you watch it with a mixture of fascination and horror. In the final analysis, it is not a place I wish to visit too often. It is all surface – (almost) nothing is for real. The only time I felt grabbed was when we visited the bar with the dueling pianos at New York New York. Professionalism and showmanship swept me away, as good music sometimes can do. Being an amateur musician myself, I really can appreciate musical craftsmanship when I run across it, and this was it. Hearing those guys pound away at Bohemian Rhapsody was a real treat (even though my initial awe was somewhat subdued the next day, when I passed the bar and heard it again. Maybe not as improvised as it seems?)

Thursday was mostly spent in meetings and some additional test-taking (passed the Message Broker Developer test, flunked the MQ Designer test). We really got some pretty good attention from various IBM:ers – always encouraging.

Friday morning I got myself introduced to WSRR, something we at Zystems are about to start working with in earnest.

We finished of with a slow afternoon by the pool and dinner (featuring a monstrous Bone-In Ribeye steak) at Mon Ami Gabi. Well worth a visit. It was actually the best meal we had all week – cooking in Vegas is pretty bland if you ask me.

On the way home, United managed to screw up so we missed our connection in Washington. We ended up 6 hours late, courtesy of Air France. Our luggage is still adrift somewhere between Vegas and Gothenburg. Two out of three times this has happened to me when going to the states – not an impressive track record for the US domestic aviation industry!

All in all it was a terrific week from a professional standpoint. Lots of useful info, a few certificates and meetings that have the potential to really boost business if we manage to capitalize on it.

Next year Impact will be held at the Venetian, also in Vegas. Not being a Vegas fan, I think I pass up my place for a colleague more into plastics than I am .

[Update: I just visited Air France's web-site, and my luggage has apparently arrived in Gothenburg. So hopefully I will have it back this afternoon so my family can get their gifts!]

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!

Vegas – Tuesday

Today’s most thought-provoking session was delivered by Marc Hoffman of EmeriCom. He talked about Enterprise Business Architecture as a disciplined way of engineering a business, starting with a vision, and then in a structured and tool-supported way break down this vision into goals, requirements, processes and services so that you can actually trace the impact of a requirement change all the way to whatever IT-assets need to be changed in order to realize this change.

He started of with a brilliant analogy, showing how a house is built using a blueprint. He then proceeded to show, supported by a hilarious animated slide, what happens if we skip the blueprint. A truck arrives, dropping of bits and pieces of the house, and it is haphazardly put together, finally turning into something resembling a house but functionally very much less so. He then went on to state the obvious fact that any complicated structure needs architecting to be able to achieve whatever goals we have for building it. Self-evident as that assertion might seem, most enterprises are not architected in a structured fashion, making them less efficient than they might have been otherwise.

It turns out that there is now tooling to support this emerging engineering discipline. As with most other things SOA, the hurdles are in peoples heads, not the technology. Asked if it isn’t a tough sell to most execs, Marc admitted as much, but adding that those who did apply these structured methods had gained substantial benefits from it.

Vegas – Monady

This is my first experience with a really big IBM event, and boy is it big! Some 6.000 people buzzing about like busy ants getting to and from sessions, of which there are an overwhelming number.

The opening session was a hilarious show, mixing professional presentations with the wits of Drew Carey. He had gathered a bunch of comedians doing improvisations prompted by input from the audience. The most impressing of these was when one of the guys cracked a title of a song on a given theme (“veterinarian songs”, no less). Then two other guys proceeded to sing while allegedly composing the lyrics as they went along. Titles included the challenging “Put your hand in your dog and cough”…

Well, enough of these ramblings, what I wanted to focus on today is a session with a customer panel telling about how they got their respective SOA initiatives of the ground. I must say I did not have high expectations for this session, but the guys in the panel turned out to drop quite a few gems.

What was shining through was the fact that the challanges of SOA rarely, if ever, are technical. Instead, it’s all about organization and perception. One of the panel members stressed the fact that one of his most efficient tools to gain acceptance for SOA was inclusion, because, as he put it, “everyone wants governance, but no one wants to be goverened”. This is just a variation on the age-old not-invented-here-syndrome, but it seems to me that in this we find one of the most basic reasons for resistance to SOA. So, what to do? Well, his recommendation was to create some kind of virtual organisation, maybe an SOA reference board, have both integration specialist and application owners and developers meeting regularly to discuss all matters concerning shared services and integration. Also, he suggested, let the chair of this body circulate among its members to strengthen a sense of common ownership. In this context the same guy also quoted a simple but potetially powerful principle that could foster this sense: “Only build services that you don’t consume, only consume services that you don’t build”. I realize that this contains all sorts of political and other pitfalls, but as a general idea, it strikes me as brilliant. It highlights the essentially collaborative nature of SOA, and, if promoted, would serve as an antidote to silos and fiefdoms.

The proverbial Low Hanging Fruits were also addressed, and a recommendation that I have seen elsewhere was put forward by the panel. In the best of worlds, the SOA initiative is actively sponsored by top management, but when this is not the case, actors on lower rungs can still create success stories around SOA by applying SOA principles to infrastructure issues like security and compliance. Armed with those success stories, SOA champions can use them to prove the real value of SOA. And, one member stressed, never ever sell SOA as such to non-IT folks. Always focus on solutions to business problems and promote SOA as an enabler.

In my opinion, wise counsel was given, and also encouragement. This was three real companies realizing real SOA benefits. To be sure, they had a long way left to go. When asked what percentage of their total application functionality was delivered through shared services, answers ranged from 10 to about 50 percent, and, as one member put it, we may never get to a 100 percent. But they all agreed that the journey is worthwhile and maybe even unavoidable.

Impact in Vegas

On Saturday I and 6 colleagues leave for the States and Impact in Las Vegas! I must confess that I’m a tad excited. Just putting together my own personal agenda for the week is a substantial undertaking. On the face of it, more sessions than I can possibly digest look interesting, so right now I’m suffering from slight decision agony.

Anyway, I’ll try to blog here on the highlights of the week, so keep checking back!

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.