Can service-oriented architecture (SOA) make the trains run on time? With vision, diligence and a lot of up-front planning, it is sure making business services more flexible at the National Railroad Passenger Corp. , which now has SOA best practices to share.
Better known as Amtrak, the railroad embarked on its SOA journey about five years ago, initially to provide more flexibility to its marketing division users. CIO Ed Trainor's team was up against a mainframe environment that handled the railroad's large volumes of transactions like a charm but balked at integration, let alone Web services. His staff members held their noses, screen-scraped and wrapped and delivered Web services.
Then Trainor got serious. He established a chief SOA architect position and created a vision, which he stresses is critical to SOA success.
"We made a significant investment to outline a long-term SOA architecture for how all this stuff should fit together and integrate," he expl...
To continue reading for free, register below or login
To read more you must become a member of SearchCIO.com
ained.
Today, Fred Falten, the chief architect hired two years ago, continues to drive the SOA-enabled infrastructure for Amtrak's business applications. His mission is to deliver reams of information internally and to Amtrak customers, including a reservations system that gives passengers "more information than they probably need" on every travel option on any given day.
Here, he shares that experience and offers SOA best practices from his journey in this step-by-step guide to SOA.
1. Start with the plan for the "big, enduring effort." A plan gives business partners the confidence that you know what you are doing, Falten said, and that you have strategy in place. Then as funds and opportunities arrive, you can plug in projects that complement the overall direction. "It's that simple, and, quite frankly, that very complicated."
2. As you start to implement, standardize the data schemas that you are going to pass around the company. That will enable interoperability and guide your choice of any high-end products you might have to buy. If possible, pick an industry standard. The nonprofit Open Applications Group Inc. has a set of standards for message payloads, Falten said. Amtrak relies a lot on OpenTravel Alliance, or OTA, a travel industry standard.
3. Consider the technical requirements of your SOA environment when choosing a standard. Does your environment have to be high-availability? Does it need tremendous capacity? Is it highly transactional, or are you a big document mover with a low number of transactions?
An engineering firm, for example, would likely want to go with a product with a Simple Object Access Protocol (SOAP) stack, which performs well for big documents. On the other hand, a financial institution will want to look at SOAP products associated with high-volume and rapid transactions.
Some companies might require high reliability 10 hours a day. Amtrak requires high availability 24/7, because it's running all the time.
"Those two factors alone would cause you to choose very different types of architectures for your SOA environment and very different vendor products for your SOA environment," he said. Once you understand your business and what schemas are appropriate for it, then you go for it.
4. Add a SOA registry and repository over time to keep track of your services, then monitor them to ensure reuse and performance. "When you get to 20 or 30 or 40 really good business services, then you start seeing that things get reused," Falten said. But to ensure that they are, you need governance. "You can't skimp on the capacity, monitoring and registry of services."
Right now, Amtrak manages and monitors the message traffic passed among its various Web services with the help of some homegrown tools and the CentraSite SOA governance and lifecycle management product from Software AG. Amtrak can now predict when the application service might be getting overloaded or when the bandwidth on a network supporting the SOA environment is congested.
"We can predict the seasonal changes, the buyer patterns that cause us to have more or less traffic. We have a pretty good idea from our monitoring and analysis through CentraSite of what we need to do to provide for capacity before it becomes an issue," he said.
5. Plan to eventually expose services to business partners or customers (not as easy as it sounds). Amtrak, for example, has some travel brokers that sell tickets on its behalf; they can access the railroad's reservations systems now, but with a lot of handholding.
"Sometimes the services you would love to expose are the hardest ones to expose, and you have to be realistic about what you can really do," Falten said.
Case in point is Amtrak's mainframe environment. Because of its antiquity, it is "hostile to the idea of integration in general," and in particular to the building of high-performing Web services, Falten said. The solution, which predates him, was to build wrappers on the front end of the mainframe to expose the service, "but that makes it a much more complicated environment than you want." (See sidebar.)
6. Keep the big picture in mind with every service you create. "Always think about how the service can be reused. Make the extra investment to not just have the project at hand be the mechanism that says, 'Here is what the interface definition should be,' but take the extra time to think about what would the entire company, or at least the next reasonable set of potential users, want."
In addition, don't make services that are too granular. Falten said it is all too easy "to fall into the trap" of exposing each transaction in the existing transactional environment as a service.
"That makes it so fine grained that it is usually meaningless to other applications and other potential service users," he said. "Take the extra time to think about how an external business unit would want this information to be presented."
Let us know what you think about the story; email: Linda Tucci, Senior News Writer
