Back to TopBack to Top
 

Government technology implications: Service Oriented Architecture (SOA)

 

March 17, 2009

Doug Hadden

This is section 3.1.1 of a series of blog entries creating a Government IFMIS Technology Evaluation Guide. This includes information to assist in evaluating IFMIS options and the technology requirements for FreeBalance IFMIS implementations. These series will be combined with feedback to produce a comprehensive Technology Evaluation Guide to be published on our web site.

It is easy to be lost in buzzwords: Service-Oriented Architecture (SOA), Web-Oriented Architecture (WOA), Web Services, Composite Applications…

Software vendors are quick to claim compliance with these standards. White papers are written full of diagrams. Experts warn about security. Before you know it, there is an industry trying to govern the implementation of the standard. Experts argue about who has implemented the standard best.

It becomes difficult to understand the benefits of SOA to a government. Technical nuances do not appear to be relevant. All vendors seem to claim compliance with SOA or the intent of SOA.

History of SOA

Perspective is needed. Traditionally, software was designed for a purpose in mind and developed on a technology platform such as Java, .Net or a 4th Generation Language. These applications were designed to be self-contained , with some ability to integrate with other applications. This integration was often limited to applications using the same technology platform. Technology limited government modernization.

Large technology vendors were able to provide a portfolio of software products that provided intra-suite integration. Governments were faced, with the option of using best-of-breed applications with limited integration or a portfolio of tightly integrated applications from a single vendor that did not meet all needs.Governments could not achieve objectives with the technology choices.

There were two major initiatives in the late 1990’s that were designed to support better integration among applications. There were temporary solutions like RPC, RMI and CORBA. The development of Java enabled the “write once, run anywhere” approach. The creation of Web Services (SOAP, WSDL, UDDI) and specific XML-based industry standards enabled better integration among applications. Government found that integrating processes meant acquiring a portfolio of expensive applications, often called “monolithic” applications. Governments could not afford needed technology.

Service-Oriented Architecture promises the ability to assemble needed requirements from software components. These are known as composite applications. Composite applications will enable governments to combine Commercial Off-the-Shelf (COTS) and custom applications together. Governments will be able to purchase needed components from many vendors and get competitive prices. SOA provides choice and helps governments meet unique requirements better. SOA protects the government technology investment.

MIA or SOA?

Many software vendors provide monolithic applications. These applications are characterized by a large technology footprint. These applications often require purchasing underlying technology or “middleware”. The minimum size of an application component is large. The applications often support integration using Web Services and industry standards. But, these applications are not composite applications. Functionality from these applications cannot be purchased as an individual component for reuse by a government.

One of the main motivations for supporting industry standard integration for some software vendors is to enable interfacing applications from acquired companies. In the age of software consolidation, vendors need to interface applications together. The complexity of these interfaces are often hidden through a user interface layer.

These large applications with integration characteristics do not follow the intention of Service-Oriented Architecture. We term this: Monolithic Integration Architecture (MIA). The MIA vendors have a business model to “own the customer” by provided as much of the software footprint as possible: all business, content and reporting applications, application serving, databases, development tools, business process and business rules.

Government organization looking at technology options can determine whether options are SOA or MIA by determining whether:

  • Applications require the acquisition of a set of middleware components.
  • Individual components can be acquired rather than a complete application.
  • Open source infrastructure software can be used.
  • Integration with current government software can be enabled.
  • Applications were designed as components in the first place.
  • Applications are a series of applications acquired by purchasing companies.
The following two tabs change content below.
Doug Hadden
My Twitter profileMy LinkedIn profile

Doug Hadden

Executive Vice President, Innovation at FreeBalance
Doug is responsible for identifying new global markets, new technologies and trends, and new and enhanced internal processes. Doug leads a cross-functional international team that is responsible for developing product prototypes and innovative go-to-market strategies.

Leave a Reply