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!