We recently spoke with Maja Tibbling, Lead Enterprise Architect at freight and logistics giant Con-way, Inc. The...
conversation included discussion of role of SOA in cloud computing, as well the role of SOA in infrastructure building and application modernization.
SearchSOA.com: As an architect, do you think certain SOA patterns become building blocks? Can we think of messaging, software patterns, ESB, and so on as infrastructure?
Maja Tibbling: In a way, I think that they're building blocks, but they're really more like tools in a toolkit. There are building blocks as far as pure technology building blocks, but there are tools that put together the entire SOA infrastructure.There are several pieces to the architecture. One of the most important pieces is the ESB.
One part that I feel very strongly about - especially for businesses like ours that have a lot of end points - having an ESB with the assumption that everybody has already adopted SOA and is already there with services of some sort is not often realistic. So having an ESB that is also a full-blown message broker is very important.
That is one place where people get frustrated with SOA - that everything isn't SOA yet. In fact, you need to be able to create the illusion of full-blown SOA in the middle. That abstraction needs to be there so that everything looks the same in the middle. Then you're integrating with endpoints - they need to be talked to. This means that sending [a B2B message] out to a client, or a socket to some legacy system, whatever it is, that you can hide that behind services.
I guess that message and object brokers will be with us a long time.
Tibbling: Yes, for example, at Freight we still have lots of legacy mainframe apps. They're not all offering services that can just be made SOAP calls to. That isn't going to happen. Not even HTTP posts. You can't use RESTful services with them either. They need to be interacted with [in their own language]. It's the systems that aren't mature enough to have an SOA implementation - you need to still be able to include them in your SOA topology or you are missing big pieces.
With regard to application modernization, what are the backend issues these days? Actually, we are wondering if people are going to take a shot at moving some of that mainframe stuff to the cloud …
Tibbling: I'm seeing wishful thinking around that. This is my prediction: I see CIOs looking at the promise of the cloud – things like Amazon EC2 and all of those things being offered today, and some wishful thinking that they could just migrate applications that have been running for the last twenty-five to thirty years on the mainframe. And wishing we could get rid of them.
It's my belief, however, that we're still years and years away from that. What I do see though, is that those companies that have taken the initiative to wrap their [mainframe work as] services and have taken a holistic approach, it gives them a little more flexibility to redeploy some of their logic.
If they manage to tease apart the dependencies, for example - if they find a cloud app that can do part of what they've been doing in a legacy app, the migration is much less painful nowadays because you don't have to deal with standing-up new infrastructure. There are so many pain points that are relieved by taking a cloud architecture for certain things.
Don't think it's appropriate for everything, obviously. It is probably not for things that are differentiators for you. But as an example, take a very old claims system, which for companies other than insurance companies is not differentiating. It's not the core competency. There are cloud apps out there that might do the trick and there are certainly packaged apps.
Still, migrating off the mainframe is not free - especially if you have things written in legacy technologies. So I don't see it happening in any big way, for most companies, anytime soon. But, to put a finer point on it, that's where SOA has saved a lot of people, because it allows them to get ready to migrate pieces and parts as it become economically feasible.