Incremental SOA and Change

Computerworld had an article last January that discussed American Airlines’ approach to using Web Services and multiple enterprise service buses (ESBs) as part of their service-oriented architecture (SOA). The authors emphasized a change from build vs. buy and from using mainframes. That, however, is not the part I found interesting. (Also, several comments to the article were critical of the authors’ emphasis.)

What was interesting to me is that American Airlines adopted an architecture that permits an incremental approach to development as a way to deal with change. An important aspect of the  architecture is the use of several ESBs, referred to as hubs. Three hubs were mentioned in the article (Flight Hub, Customer Hub, and Cargo Hub) and the article indicated there were others. These hubs are highly available and distributed for disaster recovery purposes.

The hubs communicate with legacy systems, with new applications, and with each other. The ESBs/hubs allow for independent incremental change to legacy systems underlying the hubs as well as the independent development of new applications that communicate with the hubs. The architecture is designed to be responsive to change. Daniel Henry, VP of Business Technology Services at American Airlines, was quoted in the article as saying, “Our success will be defined by: Can we change it the next day? That’s our number one success factor.”

In my recent book, I discuss Incremental SOA and change. The Fifth Principal of Incremental SOA Analysis fits well here:

Realize that your SOA will never be done. For most organizations, an SOA will be ever changing because it will need to respond to the changing nature of business and technology.

The article on American Airlines is interesting. I suggest you check it out.

Copyright © Barry & Associates, Inc. All Rights Reserved. You may use this material for your work or classes. Copyright and Reprint Policy.


Published:May 22, 2013

As I See It General Commentary

Bookmark the permalink