SOA Explained

I recently came across this nifty little SOA primer animation. It is a really good, condensed “SOA Elevator Pitch”. If you want to convey the essentials of SOA to your boss or any other person that doesn’t seem to get it, you may want to try this one.

Embracing Employee Turnover

As a relatively young and successful company, we’ve been blessed with an extremely loyal work-force over the years. When we approached a 100 employees a year or so back, we were deeply disturbed when some people had the bad taste to actually leave us. Well, it was time to wake up to reality I guess… 🙂

One of my valued colleagues (Stephan), who is leaving us for a customer (good luck, Stephan!) pointed me to this article. Very refreshing and strangely moving, it really lifted my spirit. As is often true with good ideas, this one is apparently not a new one, but it was for me, and suddenly I looked at the whole issue with fresh eyes. Highly recommended reading!

Expanding our Horizons

It is quite clear from recent months’ events that our customer base is maturing rapidly toward SOA and BPM. Stuff like WSRR and WPS have been around for a couple of years, yet interest from customers have been lukewarm at best. No real business has been generated, and I must admit I despaired a little a while back, thinking that we would never get the chance to get real SOA dirt under our fingernails.

Well, not any more. We have several customers already in possession of WSRR and DataPower. Many are on the verge of embarking on the BPM-track with WPS. Excitement is in the air, and I really can’t recall a time in Zystems’ history where opportunity leaped at us quite like this. Only problem is to keep up with the challenges of absorbing all this.

Our immediate challenge right now is to investigate the extent to which our Baseline Concept model could serve as the core of a WSRR ontology. This would finally land us with a platform that could leverage all the benefits our model could bring in terms of things like dependency tracing. The farthest we’ve got in this area is our Wiki-based Baseline Service Registry, but it is based on a proprietary product (Confluence from Atlassian) and a bit cumbersome to work with. Having WSRR host this model is very exciting prospect indeed for Mr Baseline!

Keep checking back, I’ll report on our contingent progress on this.

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.