 |
 |
 |
 |
| |
|||||
|
|
|
Home > News & Events > MITRE Publications > The MITRE Digest > | |||||||||||||||||||
| Building a Solid IT Foundation with Service-Oriented Architecture September 2008
Service-oriented architecture. If you work in information technology (IT) in the federal government, service-oriented architecture (SOA) is one of those topics that seem to be everywhere these days. But what does it mean in terms of systems integration and the ability to take advantage of existing investments in IT assets? What are the best practices and tradeoffs? How do you go about developing practical approaches to initiating and using SOA? Based on the wide interest in SOA across federal agencies, MITRE has set up a team not only to answer these questions, but to develop and share engineering resources and know-how across government programs. Bringing SOA into the IT planning and acquisition process has become particularly important to MITRE's sponsors in the federal government because of the growing need to expand IT functionality across organizational boundaries. When SOA is the right choice, engineers and IT developers spend less time creating custom-made technology and more time building foundational systems that can be reused, upgraded, and integrated with still other systems. A New IT Model To explain further: Throughout the last few decades, most large-scale IT systems have been developed using proprietary software and hardware that meet a single organization's needs. Interoperability with other systems and cooperation with other organizations wasn't a sought-after feature. With SOA, on the other hand, developers can use innovative, interoperable tools (such as XML) to construct IT systems that move away from proprietary, one-size-fits-one solutions. Note that "large-scale" is key to this—for many smaller organizations, an off-the-shelf, non-SOA IT system may still be the best choice. Although the basic concepts have been around for more than 20 years, interest in SOA is growing in both the public and private sectors. More and more MITRE teams are fielding questions from their sponsors about SOA's benefits and risks, and our unique cross-sponsor perspective provides a natural fit for the role of SOA advisor. As SOA matures, MITRE engineers Steve Foote, Larry Pizette, Geoff Raines, and Salim Semy are among those at the forefront of this communications effort, discussing best practices and trade-offs about SOA with our own technical staff as well as our sponsors. They provide some insights into the challenges of bringing some "plug-and-play" versatility into enormous IT programs. "MITRE staff often contribute at multiple points in a sponsor's organization and get the benefit of seeing how many distributed software systems share and exchange information," explains Raines. "This provides our staff with a big-picture point of view, which is especially useful when you're engaging with an organization's CIO [chief information officer] and senior management team. That's the level where much of the planning and implementing an enterprise-wide SOA occurs." Screening the Workforce The reason for SOA's growing popularity is straightforward. "SOA is a natural step in the computing trend towards integrating and reusing capabilities rather than reinventing them," says Raines. "With thoughtful engineering, SOA holds the promise of making an IT portfolio more efficient and agile, and when this happens, costs are reduced." That's not to say, however, that implementing SOA doesn't have its management and engineering challenges. One of them involves legacy systems. Unlike other IT restarts, however, SOA can incorporate many of the available features of these existing systems. "Most legacy applications have some inherent services in them that could be reusable and were originally expensive to build," Raines says. "These systems can be used to create either data-oriented or process-oriented services that would be useful for other groups in the same organization. "The challenge is how to best encapsulate and offer those services to the community as a whole, in a secure way. Luckily, folks working on SOA are putting together a good set of technical tools and standards to 'wrap' existing services from legacy systems and offer them as reusable components to the enterprise." Semy notes that among the best practices to follow when creating services are to start small, learn, and evolve. "This approach can help in overcoming the fear that the initial investment needed is too great. Viewed in the short term, SOA usually does require investment, especially for infrastructure and initial deployment of services." Spreading the Investment Around For example, a department within an organization may require mapping functionality to complete a software project. Under more traditional program management models, that department would create the software and manage it solely for the department's own use. Using the SOA model, however, the department, as a mapping capability service provider, could offer mapping services to the entire organization. With its potential client base vastly expanded, the department's implementation and management cost could increase. Ironically, the more popular the software service, the greater the increase. So why would a department choose to take on a more-expensive, more-complex task? Again, this is where having a big-picture perspective helps. Viewed on a departmental basis, the investment required for SOA conversion might indeed seem large. But viewed on an organization-wide basis, the return on that investment becomes evident. The efficiency gained across the organization by employing an SOA can provide an excellent return on investment. "Instead of 10 different departments building 10 similar software services from scratch and then running them all for 20 years, past the edge of obsolescence," says Raines, "an organization can build it once, build it well, and share it." Building Trust, Developing a Blueprint Another considerable challenge involves building trust, both inside and outside the organization. When an organization—a federal agency, for instance—implements SOA and begins to offer software services, groups within the organization have to rely on each other to provide these services in a timely and reliable manner. Foote comments, "SOA enables disparate organizations to technically communicate and collaborate seamlessly, but it does not ensure that such interoperability will be condoned socially or politically." As the organization builds partnerships and shares services with other groups employing SOA, these groups require an even greater amount of trust. This is particularly true for government agencies, which usually have had sole responsibility for their own IT systems, with no outreach required. And just as in traditional architecture, service-oriented architecture projects require blueprints, too—but in this case they're known as governance rules, and they provide the overall guidance for any SOA project. MITRE staff members are participating in the development of governance concepts as a member of the SOA Consortium, an advocacy group comprised of end users, service providers, and technology vendors. "Successful SOA is just as much about good policy and governance as it is about technologies," says Pizette. Outreach on Paper and in Person In response to a surge of interest in SOA, MITRE is developing resources to consistently inform our employees and sponsors on SOA best practices, benefits, and risks. Among these products will be a series of white papers, two of which have already been published. The first, "Leveraging Federal IT Investment Using Service Oriented Architecture," examines how SOA builds on traditional computer engineering approaches to design services for an enterprise of consumers. The second, "MITRE's Perspective on Emerging Industry Service-Oriented Architecture Best Practices," documents important best practices for a successful SOA implementation. In addition to a significant internal review process across our business areas, MITRE has collaborated with subject matter experts in industry for feedback on the papers. Outreach is a critical part of this effort. For instance, in June, a MITRE speaker provided the opening keynote address at the SOA Institute's Washington, D.C., conference. MITRE hosted the sixth Service-Oriented Architecture for E-Government conference in September 2008. The two-day event focused on developing practical approaches to initiating and using SOA across the government. Also in September, Pizette and Raines delivered a presentation at the SOA Consortium meeting in Orlando. Their goal was to share ideas on maximizing the value of federal IT investments and to obtain additional industry feedback on MITRE's SOA papers. The changeover to SOA for information technology systems won't happen overnight, but as it occurs, MITRE will be there to provide guidance and expertise. "The work has wide customer interest and the effort has been very rewarding," Raines says. "Our goal is to be an ongoing engineering resource for our customers as they work on large SOA projects." —by Chris Lockheardt & Alison Stern-Dunyak Related Information Articles and News
Technical Papers and Presentations
Websites |
||||||||||||||||||||
| Page last updated: September 29, 2008 | Top of page |
Solutions That Make a Difference.® |
|
|
