Manage Learn to apply best practices and optimize your operations.

Q&A - Enterprise Architect Maja Tibbling - Pt.1: "No SOA, No Cloud" recently spoke with Maja Tibbling, Lead Enterprise Architect at freight giant Con-way, Inc. The topic was the status of SOA as cloud computing begins to emerge. recently spoke with Maja Tibbling, Lead Enterprise Architect at freight and logistics giant Con-way, Inc. The topic was the status of SOA as cloud computing begins to emerge. For her it is a clear case of "No SOA, No Cloud." Over recent years, Tibbling helped lead Con-way's migration from components to service oriented and event driven architectures. She appeared in our pages on several occasions. These include a 2007 appearance in which she described Con-way's use of semantic objects for event driven SOA. It wasn’t that long ago that SOA was hot. Then it was 'dead.' Then it wasn't. Where are we today?

Maja Tibbling: SOA is definitely not dead. If anything it is on its way to becoming more [established]. So you could view it as being dead in that it has become less of an earth-shattering notion for people. Because vendors are doing everything they can to ensure that services and APIs and such are being offered by their packages. The industry for Enterprise Service Buses and for integration technology to bring together diverse systems using SOA as the backbone has taken off completely. It has enabled the entire cloud computing revolution. These are the things going on in the industry right now. The cloud could not exist without SOA. That would not be possible. The leveraging of events in the form of event processing would not be possible without SOA. All these things are coming still. So it's not dead. It's evolving rapidly.

How are SOA principles playing out these days as Con-way Freight?

Tibbling: Certainly the technologies have evolved the principles of what we're implementing. We have three main business units that are evolving separately from a technology perspective.

Con-way Freight is the one that really adopted component based development already in 1995 and that evolved into SOA as that emerged. Along with enabling technologies we've all been evolving continuously in that realm where we're using not only services, but orchestration of services and composite services. We now have a full blown hand-held [device] deployment that is using some of the same services as the Web apps, for example.

We are getting enormous reuse because of the holistic approach we took architecturally from the beginning – where we took a look at the business and asked what is the correct granularity to encourage reuse? And, how can we protect the backends so they can evolve independently? Where we today have homegrown apps, we know we might want to replace some block of business functionality with a package someday. Or we might want to change databases. Change models. Evolve into a cloud app. All of these things are where Freight has gone and where [it] will continue to go. Because we took a holistic approach, we are realizing over time the full capabilities of what the promise was.

Menlo Worldwide Logistics, our logistic arm, is now diving into and embracing [SOA]. They have much more in the way of packaged apps. So there, we're diving into it from the view of let's have a common language in the middle – to take a canonical approach using an ESB. We are seeing if we can start tying these things together with orchestration and business processes so we can see them both coming together from the inside, with B2B messaging, all the way in, and executing full order-to-cash type scenarios over time. That initiative is about a year old now and already they have some of it into production. 

It's our philosophy to have that ESB and canonical model in the middle. Even though nowadays every vendor has to supply some integration features in their packages or they won't make it. So we have that notion where you adopt the philosophy of the ESB as an abstraction [so] that you can federate other ESBs into it and it can still be one ESB. We want our enterprise ESB to be the one that is visible to people. And then we interact with that ESB. 

That's what we're doing with other packages that we need to adopt. You don't go directly to them, you go to them via our ESB. That allows us to have a common language in the middle because now if you do that and adopt SOA in that manner then you have the ability to go through that "central nervous system" to use Garner's term. It allows you to look at all the events that are happening in that middle and look at them. You get a bonus that way. Yes it takes a little effort, but you get the bonus that way.

Finally we have our Shared Apps, which is not a separate business unit, but it is the shared organization that takes care of all our back office pieces and parts. They are just now stopping with the point to point. They have so many cloud applications for various pieces like Concur for expensing, an email management app – lots of shared apps that are cloud apps. All of the interactions with those and also all the interactions with the official agencies, all of those have been point to point interactions so far. That now will have a common language in the middle for the things that they have to do and then a common interface for the applications they have to interact with.

We also, in Freight, because of how things are done, had our own homegrown CRM system. And we were able to switch to using on a very tight timeframe because all of our customer information was baked into and surrounded by services. So we're going into the cloud more than we were before and our transition is not nearly as painful as it would have been if we had not partitioned our business this way.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.