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
Requires Free Membership to View
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
solutions?
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
that?
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.

Join the conversationComment
Share
Comments
Results
Contribute to the conversation