The case for SOA
Service-oriented architecture might not be easy to develop, but the economics are hard to ignore, according to participants in an FCW roundtable discussion
Service-oriented architecture can be difficult to understand and even more difficult to implement. But the technology experts who can cut through the technical jargon and intense market hype say SOA has the potential to play a major role in the future of systems development.
In short, SOA provides a framework for developing software components to manage data communications among different systems. Because those components are platform-independent, they make it possible to build services that work with multiple applications. Therefore, SOA has the potential to increase interoperability and save time and money in application development.
This new way of thinking is slow to take hold in the federal market. Similar ideas have emerged before with great fanfare, only to fade away with barely a whimper. But experts say SOA is different.
A group of federal and industry executives met in January to talk about SOA and its possible impact on the federal government. Judi Hasson, a Federal Computer Week editor at large, moderated the roundtable discussion. FCW and Thomas and Herbert Consulting, an Enterprise Architecture Center of Excellence, sponsored the roundtable, which met at the firm’s Arlington, Va., headquarters.
The participants were Michael Borden, senior practice manager for homeland security at Thomas and Herbert; Richard Burk, chief architect at the Office of Management and Budget; John Dodd, a principal consultant in Computer Sciences Corp.’s federal practice; Mark Forman, a partner in KPMG’s Risk Advisory Services; Roy Mabry, assistant to the director of the Defense Department’s Architecture and Interoperability Directorate; and John Sullivan, chief enterprise architect at the Environmental Protection Agency.
The following is an abridged version of that discussion.
Q: Where do you think service-oriented architecture fits in the federal government, particularly in an age of tight budgets?
BURK: Let’s define what we mean by service-oriented architecture. It comes in at multiple levels. It can either be at the business level, such as human resources, financial management, case management, grants management, customer management. Or it can be all the way down to something fairly discrete and precise, such as e-authentication, in which we want to be sure that the individual we are talking to or doing business with is in fact that individual.
Rather than have each agency develop that capability itself and spend a lot of money with third-
party authenticators, why not do that maybe two or three times and then have other agencies buy that particular capability or service component?
There are additional services that they can just as easily buy. They can buy it cheaper and get better service by doing it. And we are encouraging the agencies to do that. What we hope that will do is to move the line from that part of their budget that is nondiscretionary. And you now have more dollars within a fixed pie of money to use to get ahead of the game. You can invest in those services that are your value differentiators if you are in the private sector. In the public sector, part of your mission responsibility is to use technology and hopefully make good investments.
FORMAN: I believe the economics drives you toward service-oriented architecture.
The legacy of large information technology environments is lots of IT systems built for a single business process or a single purpose. It’s the epitome of a nonarchitecture or an unarchitected enterprise. We have gone with the federal enterprise architecture through a number of years of trying to get people to figure out how the pieces fit together, how systems align with business processes. But we can’t ignore the driving forces of homeland security, of the whole effort to get network-centric warfare in place and — what I believe is the heart of the initial transformation — the core administrative business processes.
There has been broad recognition of the fact that although you have different data or you do economic transactions for different purposes, it doesn’t change the fact that an accounts-receivable transaction is still issuing a bill and figuring out how it is going to get paid. And an accounts-payable transaction is still cutting a paycheck, giving somebody payment on a grant or giving somebody payment for a contract. So there are these core fundamental processes that people have recognized that, by having a common application that can be shared across business entities around a business process, you get huge savings.
In the commercial world, that recognition has been driven by the Sarbanes-Oxley Act. In the government world, I suspect it’s being driven by two major factors: counterterrorism and the need for information sharing so that we can make faster, better decisions, and the restrictions on the budget.
So people are being forced to look at how we can get these business fixes done better, faster and cheaper. Just as in the commercial world, you see those pieces, but they are done using open standards. When people see the economics, they recognize they can piece it together. When we get it done, everybody’s going to say, “Ah, you’ve gone to a service-oriented architecture.” But we’re not quite to where somebody is architecting a service-oriented architecture and building all the pieces to fit in. It’s much more organic.
Q:Are CSC clients saying, “Come over right now — I need a service-oriented architecture?” Or is it something that is evolving from other pieces, such as enterprise architecture or responses to budget pressures?
DODD: We are hearing some of that, but most of it is, “We have a transformation project to do, and we have lots of legacy systems and lots of other systems out there, and we want to deliver services to our customer” — whether it’s a commercial banking customer or a homeland security customer. So the focus is the business problem, and that’s where it should be.
This paradigm lets you take services all the way from the top, whether it’s a community or a business value chain, down to the enterprise SOA approach, down to individual applications, down to e-authentication, down to places such as the Environmental Protection Agency’s Central Data Exchange. CDX program managers didn’t know they were going to become an SOA, but they became an SOA because it made sense to go from federal to state to local with environmental data. So you apply it where it makes sense.
Q:Are you finding SOA is a way to save money?
SULLIVAN: I would say we hope to find that; I would not say we have found that to date. I don’t think any of this is going to deliver overnight cost savings. The CDX implementation that John [Dodd] is referring to — an information exchange Web portal between federal, state and local governments — is just working on the traditional flows that were happening one way or the other. So you do have indirect savings in terms of data quality, the velocity of the data being available.
In some cases, we are working toward true savings in terms of the states’ operating costs. Data doesn’t have to be re-keyed at the federal and state levels. And then, in the bigger picture, you have savings in terms of burden reduction. But that is coupling a service, such as electronic reporting, with pre-population of forms. That is where you are going to see the value in the harder-to-define things such as burden reduction.
Q:Let’s turn to the biggest agency here — DOD. Have you tried SOA yet? Do you think it’s viable?
MABRY: Yes, as a matter of fact, we have an SOA foundation in our Defense Information Systems Agency. We think SOA will give us the opportunity to provide services in the net-centric environment we are moving to so we can have more of the kind of information we need to make decisions. As a result, we think we will improve efficiency within the organization because people can make better decisions faster. And we can also expect to see improved effectiveness in the enterprise.
We are thinking about it in terms of enterprise performance and how well we do our business and the advantages of having information available to the consumer — even the unknown consumer or the unintended user. So if he or she has the proper roles or the organization has the proper role, they can get access to the information they need to enhance decision-making. We are looking at service-oriented architecture to provide that kind of capability.
Some of the incremental capabilities that are included in the Net-Centric Enterprise Services SOA foundation are basically DOD Web services captured in a profile. It includes a service directory. It includes security around those services. It includes enterprise service and management. Other increments include machine-to-machine messages and remediation services. So, in sum, we think the SOA foundation is going to give us a lot of benefit, and it basically consists of a set of services, software and guidance that enables DOD programs and systems to secure, publish, find and manage enterprise services.
Q:We see a lot of fads in technology. How do we know SOA is not a fad?
BORDEN: I would say it’s not a fad because it really is a framework, a better way of doing things. Enterprise architecture came about because we drove it from the IT community and believed it would present savings and a return on investment, help us reduce systems and reduce multiple buying.
I think SOA is that next manifestation. It is part of the enterprise architecture, but it defines that framework. I have to agree with what everybody has said here. I think people are embracing SOA because it’s not a money savings that is a reality today — it is performance.
Q:Do you think we will ever get to the point of true interoperability in the government?
BURK: Yes, I think so. We have begun to do that already. There is a place where you have to go if you want to collect new data to see whether we’ve already collected it. Now, somebody may question whether that works very well or doesn’t work very well, but that’s a good example of us saying, “Look, we don’t want to collect this data multiple times and have multiple versions of the truth.”
OMB is a place where you go and do that. Can we assist on the architecture side of that? Absolutely. The data reference model is now out. We’re going to be asking agencies to map their existing data assets to that model and then begin to work through so we can have a very precise way of saying, “Before I go out and go through the effort of trying to collect this data or even ask OMB whether I can, I want to be able to go someplace to see whether it’s already collected in the federal government.”
And we can ask these kinds of questions: What’s the periodicity? Do I have access to it? What are the query points to it? Is it in a format that I can use?
And then there’s the point that Mark [Forman] made — very accurately so — that there may be another incident that comes down the line. He was referring to the 2001 terrorist attacks. And then we had the Hurricane Katrina disaster. There are going to be other incidents that come down the line that we want to be able to respond to. And at that point in time, if we do have this system in place or a substantial portion of it in place, we’re going to be in a much better position to be able to respond faster, to predict or preclude some of the problems that we had in both of those incidents.
Q:Where do you see us in 10 years? Will we have enterprise architecture down pat? And will we have SOA down pat?
SULLIVAN: What will happen in 10 years will depend on two things. One is that the administrative business processes and how we manage this new type of relationship have to change. The way we do service-level agreements, the way we cross-fund things and communally fund things — if that doesn’t change, then we probably won’t be any further than we are today.
The other change has to come out of the IT industry. If you follow the data warehousing community, the intelligence community — especially on data warehousing — you’re not hearing SOA. But the rules of the road for warehousing and operational systems all have to evolve. Then software agreements and licensing agreements need to happen. And all of that could easily take 10 years to settle out.
FORMAN: There’s no question that the economics are going to drive us to this, whether it takes three or four years or 10 years. I think 10 years we’ll be far into it. And the reason is, as John [Sullivan] was saying, this is really not new. This is a continuation of a 25-year trend that, once we started to break applications into components and get to containers, we started to abstract the business processing from the computer.
In fact, you’ll see that it fits in the long-term trend of computing. So I actually think we’ll be through that in 10 years. Let me talk about a couple of the other issues that we’ll be looking at 10 years from now. I think we’re going to see much greater transparency in government. And that’s really what this is about.
We’re going to see more transparency because the only way you’re going to get cycle times or going to be able to leverage these shared services technologies is to make them interoperable. So I think we’ll get the advantage of integration. I think you’ll see government working much faster.