Enterprise architects today face a challenging landscape of application integration. For successful integration, they must use a combination of new and old integration and development technologies. Many enterprise architects are turning to lighter-weight infrastructure -- such as RESTful services -- to tackle increasingly complex integration projects. As cloud and mobile apps continue to spread, new challenges arise.
SearchSOA.com recently spoke with Maja Tibbling about SOA, cloud, ESBs and other issues related to application integration in today's fast-paced business world. Tibbling is principal enterprise architect at freight logistics company Con-way Inc. Below is part one of the two-part Q&A. Here, Tibbling talks about the role of SOA in integration, the future of cloud integration, and the current state of the ESB. In part two, Tibbling shares insight on new trends in application integration.
Your business is pretty well-famed; people have seen the trucks on the road. We wonder about the technology behind that. How do you apply technology to a big business problem?
The integration practices in companies like ours are taking off. We have very large transformative initiatives in all three business units right now.
Logistics is all about remaining connected with suppliers, with carriers, with trading partners, with regulatory agencies—all of the different parties that allow us to do business on behalf of our clients. In order to do this really, really well and differentiate ourselves, the integration parts have become absolutely key and core to success. In fact, the initiative that we're working on currently was sold to the top level of executive management of Menlo Logistics as part of their overall transportation solution with the notion that doing transportation without this connectedness is not possible anymore.
You've been a prominent thought leader in SOA for some time. What is the role of SOA in integration today from your perspective, especially in terms of real-time business?
We are actually proving over and over again how important [services] are. The business people behind the scenes are able to offer the abstraction of the service layer to our clients, for example, which allows them to interact in ways so they can see and understand the semantics of what we are expecting. Then, internally, we can translate into what we call a "canonical model," which I've written on in the past. That allows us to have a common semantic—internal, in the enterprise—that any endpoint can then take, understand and translate to its specific endpoint needs.
The integration practices in companies like ours are just taking off.
The way it has evolved, most packages these days offer some level of SOA interface. But that means that, internally, we can have a common understanding and then interact with either a cloud SaaS product or a third party package or a homegrown package, using services.
How do you see cloud integration developing? Is there a services foundation there?
What we're seeing is that even Integration-as-a-Service is beginning to play a role. There are so many levels, as we all have come to understand, with use of cloud. You may have just hosting infrastructure as a cloud, for example. Or, just hosting where you're only allowed certain access into the packages.
We're dealing with outsourcing some of our ERP systems. On those hosting systems, we're not allowed to directly access databases anymore. Luckily, these third party packages have service interfaces—we now interact with them via our ESB. We can then mediate to their services directly out in the cloud.
One of the things that's grown up along with SOA is the ESB. Do you see a role for the ESB in the cloud and integration? Or for only certain types of transformations?
There are many business processes that are orchestrated through an ESB. For those types of orchestrations where there's no one sitting at a webpage or at a mobile app waiting for a response, those can easily be orchestrated through an ESB that lives out in the cloud. There are many vendors now, that offer lightweight ESBs out in the cloud for just that type of orchestration and service access. Where it isn't appropriate is if I'm sitting there with a mobile app and I want a direct response for something.
If I want to get the lowest latency possible and if the mobile app is coming in through a browser here in Portland, and we have our data center here, and our apps run here, we don't want to go out to the cloud to have it orchestrate mediation to a service that's back over here. That will probably create a user experience that's not adequate. Until they've resolved some of those latency issues, that has been our experience. We try to keep the ESB for real-time user experience close to where the data lives.
Follow us on Twitter at @SearchSOA.
This was first published in July 2012