Tod Hagan, service-oriented architecture expert and director of intelligence surveillance and reconnaissance solutions at consulting firm Modus Operandi Inc., recently spoke with SearchCIO.com
Some industry experts believe that SOA is out of
vogue -- it's too expensive, or not delivering on promises such as business agility.
What is your reaction to such statements?
Tod Hagan: Some of those things are very true. What happened in the case of the DoD, for example, the secretary of defense put out a memorandum to the community saying, "Thou shalt be net-centric to share information." So, the community thought that SOA would be the way to achieve net-centric collaboration. The problem is, the DoD organizations weren't given the funding. . . . They wanted to use SOA to tie information systems, but a lot of times they couldn't get off the SOA treadmill to implement SOA-based technology. So, there are schedule and cost concerns, absolutely. But I think that SOA is more than just evolutionary, perhaps revolutionary, design principles that are going to be met with opposition and resistance at first, but the goals of SOA are clearly beneficial: better information sharing and collaboration.
What projects are you mainly working on now?
Hagan: We're using SOA interfaces to expose information from legacy systems, where those legacy systems are often 10, maybe 20, years old. So, they don't communicate well with other systems, and an SOA-type interface is the best way to expose mission-critical data. It hides all the ugly implementation details of that 20-year-old system.
Why do you think SOA solutions are the best approach for legacy modernization?
Hagan: It provides a layer of abstraction from the underlying technology and systems. For example, some of the systems that we've worked with are written in [the] Ada programming language, which first came out in the early '80s, or even [the] Assembly [programming] language. Those are difficult software programs to interface with directly. Without an SOA-based interface, I think it would be a lot more labor-intensive and error-prone to collect information that's generated from those systems.
SOA often provides a new life for that legacy system too. You don't have to do a wholesale pull and replace of that legacy system if you can put an SOA wrapper around it. That legacy system will still have life in a modern cloud computing environment, for example.
What are some first steps to take to set a good foundation for legacy modernization using SOA
Hagan: It doesn't make sense to expose everything via an SOA interface. One of the first things is to decide what subsystems or specific functionality will be exposed. SOA is best implemented when it's a very atomic, single-purpose service, and those services can be orchestrated or combined at a higher level to produce more complex applications. For example, the Army has what's called a signal intelligence sensor, which is essentially an electronic vacuum cleaner. It flies around and collects electronic signals, such as [from] radios, cell phones and other things that emit signals. One of the important functions that it does is pinpoint a location of that emitter. You can imagine why it's important to find the location of radios and cell phones. The algorithm for pinpointing location was buried deep inside this legacy system, but that location algorithm is the most accurate one the DoD has, and it was only available to the user of that one system. So, what we did was put an SOA interface on that algorithm so that many other signal intelligence sensors can now use that same algorithm.
Why is it best to use SOA for a single purpose when SOA has been hyped as a way to share
services across departments and for reusability?
Hagan: There are cases where it makes sense for each department to have their own service or own capability, because each department has its own mission. So, it might not make sense to combine all of those departments' logistics systems. Logistics is different for the Army and for the Navy, for example. What I meant by atomic, very granular services is . . . being able to convert between coordinates systems. For example, the DoD has about 50 different ways to represent a location on a map, so a nice service would be a coordinates conversion service that can convert from one system to another. I would look more at things like that, as opposed to "OK, let's create this one service that does logistics for the DoD." That's just not feasible. You would never get the community or, in the case of a corporation, all departments with that similar service as a whole to agree on what that service would be.
That holy grail is the ability to predict the intent of your adversary. In a business world, I imagine that's the same thing: What's my competitor going to do next?
Todd Hagan, director of intelligence surveillance and reconnaissance solutions, Modus Operandi Inc.
Any advice for CIOs approaching the business about using SOA solutions?
Hagan: You better allocate the cost and schedule for it. It's not free, but certainly the long-term benefits are good. It's definitely something that's going to evolve over time. You're not going to have SOA overnight throughout your architecture. I would say the best way to implement it is to identify the most key services, offerings or capabilities that your organization provides, and look to those areas for providing SOA services.
How can you justify the cost of an SOA implementation? What are the SOA
ROI and potential benefits?
Hagan: That is hard. It takes a visionary within the company to see that the benefits are probably going to be longer-term, and they're probably going to be in the form of better information sharing and collaboration, but also increased maintainability of the [legacy] systems. If my systems have this open-standard, SOA-based interface, and I adhere to that contract, I can do whatever I need under the hood in terms of technology refreshes over time. As long as I'm adhering to that SOA contract, to my consumers. So, maybe the [ROI] angle is from a technology refresh and modernization of the underlying systems [point of view], without the impact to information consumers.
How do you think SOA can give companies a competitive advantage?
Hagan: Information sharing is the way ahead to achieve dominance on the battlefield, and what we're seeing SOA provide is advanced levels of data fusion. Now you have all this heterogeneous information and services being exposed to one network, one system. Then that information is being aggregated and fused. That level of fusion is really the holy grail of intelligence. That holy grail is the ability to predict the intent of your adversary. In a business world, I imagine that's the same thing: What's my competitor going to do next?
You use ontology modeling and semantic services as part of your SOA approach. Can you explain
Hagan: Ontology is just a data model that describes the system. In the intelligence community, you would have ontology concepts to represent, let's say, a signal intelligence sensor. There would be a concept to represent the analysts who operates that system, and for users of the system, and where that data from that systems is published. It's a way to model the problem domain.
We also provide SOA-based semantic services in the form of --. A little context here, the DoD, just like the business world, has a lot of data in unstructured form. Unstructured is simply a document with paragraphs and sentences. That's unstructured, as compared to a database, where the information in nicely tucked into rows and columns. The challenge, and where semantics provides benefits, is the ability to access and understand that unstructured data. So, a semantic service that we provide is the ability to do natural language processing [NLP] over that unstructured data. That NLP capability pulls out the ontological concepts (reports, text messages and so forth) of interest from large volumes of unstructured data.
What are some overlooked difficulties of legacy modernization using SOA solutions?
Hagan: One of the problems we've seen is you have this legacy system operating in a stovepiped environment. That system is operating independently, and it interfaces with the outside world maybe through human interaction or a text report. That's how it gets its data out. With SOA, you provide a direct connection to that legacy system. As a result of that, that legacy system may see a lot more use, and that system may not have been designed to handle that type of load. So, the underlying system that is being "SOA-tized" has to be able to handle the increase in performance that it may see.
How do you address that?
Hagan: You can cache information, which stores a lot of data in memory, since memory access is very fast. You can also do multiprocessing, or multithreading, where you create a couple different instances of the underlying system virtually. That also helps alleviate some of the bandwidth concerns. But [increased system demand] is a hard problem. Those old IBM mainframes might not have been designed to accommodate dozens, or even hundreds of users.
Let us know what you think about the story; email Christina Torode, News Director.