Open Architecture and Services Oriented Architecture (SOA)- A Compelling Relationship

By Kartik Mecheri and Andrew Gordon, Unisys Federal Systems

This article exposes how Open Architecture (OA) is critical to Service Oriented Architecture (SOA) as it guarantees complete application agility, and aligns with SOA as an IT strategy for delivering interoperable, reusable, business capability.

The definition of the term "Opem Architecture", according to the office of the Navy and OSD, is as follows:

A Navy initiative for: A multi-faceted strategy providing a framework for developing joint interoperable systems that adapt and exploit open-system design principles and architectures. This framework includes a set of principles, processes, and best practices that:

• Provide more opportunities for competition and innovation
• Rapidly field affordable, interoperable systems
• Minimize total ownership cost
• Optimize total system performance
• Yield systems that are easily developed & upgradeable
• Achieve component software reuse

Open architecture specifications are made public and are based on approved or defacto standards. Fundamentally, the principles behind open architecture are focused around:

1. component-based
2. open-standards based
3. interoperability

Usage of these guiding principles of computer and software design has radically increased in both Commercial Off the Shelf (COTS) and open source software. The primary reason for this increase is that this gives the users plug and play capabilities that meet their needs, whether open source or COTS. OA in many organizations is treated as a design constraint, which is taken into account before creating and deploying systems.

Systems that are not built around the fundamental principles of OA run a huge risk of high maintenance, which leads to high total cost of ownership. These systems may result in tight integration but may not, in most cases, be extensible. The other reason for high cost could be the lack of availability of the labor pool in maintaining such systems.

As mentioned above, one of the principles of OA is openness of the architecture. OA based solutions can potentially result in:

• Complete application agility due to
• Increased labor pool
• Increased reusability of the components
• Plug and play capabilities
• Easier installation
• Improved systems management
• Easier adoption of technology
• Improved product quality, including performance
• Ease of communication between domains
• Lower cost of upgrades

From Wikipedia: "Service Oriented Architecture (SOA) is a computer systems architectural style for creating and using business processes, packaged as services, throughout their lifecycle. SOA also defines and provisions the IT infrastructure to allow different applications to exchange data and participate in business processes. These functions are loosely coupled with the operating systems and programming languages underlying the applications. SOA separates functions into distinct units (services), which can be distributed over a network and can be combined and reused to create business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. SOA concepts are often seen as built upon and evolving from older concepts of distributed computing and modular programming"

Some of the design principles for SOA are:

• Standard Design Contracts
• Loose Coupling
• Service Reusability

There are several other principles such as service visibility and statelessness that drive design decisions to implement SOA based solutions.

Since government processes are generally "common", appropriately designed SOA implementations can be exposed amongst the Common Process Users of Interest. For example, if a task order process is implemented, it can be made available to government agencies by exposing that process to be consumed by an agency on a properly secured network.

SOA can help you achieve business agility, bringing government and military the possibility of creating an information sharing environment that can:

• Evolve disparate, unconnected, stove-piped systems and processes into re-usable services putting it into a position to mix and match services, rapidly creating new applications to support changing mission requirements
• Increase the speed at which information and services can be rapidly and securely shared so others can benefit, including unanticipated users
• Securely interconnect people and systems, independent of time or location, improving federal and military situational awareness and significantly shorten decisioision-making cycles

OA provides transparency by adopting open standards. Transparency can be a measure of efficiency for an enterprise. Open standards based services permit easier integration into existing applications as well as easier development of new services. As a consequence, cross department, cross division and cross agency integration of services and information becomes realistic and achievable for an agency, military service branch, and its constituency. The principles of SOA make inter-agency collaboration possible, while open architecture based SOA makes it simpler.

The requirements for SOA also apply to the requirements of Open Architecture. While SOA focuses on multiple systems, Open Architecture focuses on a specific system. The goals for both SOA and OA are complimentary to each other. However, there are some fundamental differences that have to be recognized.

Traditionally, functions within an application have been implemented using proprietary interfaces. The cost of integration and maintenance of proprietary software can be extremely high especially if the application vendor resists implementing required enhancements to your systems, compromising your IT investment. Making OA a design constraint or a non-functional requirement during product procurement, lays a foundation for easier integration and collaboration, and extensible service oriented enterprise.

Using a RFP/RFQ/SOW contracting process example in the government, there is an obvious need to make FAR regulations available as a service in order for agencies to use the functionality or share the data (sample process is illustrated in Figure 1) in an SOA implementation. For other agencies or partners to be able to use this service, the service must be designed using the OA design principles.

Figure 1: High-level Illustration of multi-agency interaction and usage of the Regulation Service

As you can see, there are multiple advantages to this type of implementation.

• The dependencies between the partners are just the service contracts (note this is an SOA design principle). In the case of web services these could potentially be the Web Service Description Language (WSDL), and xml schema definition (XSD) of the objects and the payloads. There could potentially be a third document part of the contract, the Policy definition for accessing and executing those services and relevant operations.
• Easy integration in a multi-organization environment. It can include software vendors such as Microsoft to be able to play easily in this environment. You know what components are available and what standards are followed, both of which are the design principles of OA.

If the regulation service (please note that, service does not mean just a web service) did not follow open standards (note this is an OA design principle), the integration would be a lot more difficult and expensive in an inter-agency environment. Some of the difficulties leading to more cost could be:

• New procurement or contract with the vendor implementing the regulation service
• Longer time to implement changes across all agency users as opposed to making changes in one place
• High potential for vendor lock-in
• No reusability of government-wide functionality

Open Architecture and Service Oriented Architecture are complimentary architectural patterns. In combination, they provide great value to government (DoD and Civilian) and high potential for inter-department and inter-agency integration and re-use of business processes. Government agencies must take the power of these two patterns seriously and incorporate them as non-functional requirements or design Government. The example above is a real-time shared service that is implemented as part of an Integrated Acquisition Suite of applications in a large government agency. All or any sub-processes within the Acquisition process can be leveraged across the entire federal government with minor or no modifications to the existing services.

About the Authors

Kartik Mecheri is Chief Architect for a large government contract and works for Unisys Federal Division. He is a thought leader in the areas of open source and Service Oriented Architecture. He has over 8 years experience working with large federal procurement systems. In addition to his technical responsibilities he is responsible for providing senior government agency officials consultative advice related to the latest technologies to enable them to take advantage of the benefits experienced with emerging technologies. As a member of the Unisys consulting team he has also led large government agencies in implementing the beginning stages of a true “electronic contracting environment” and implementing the latest technologies allowing them to leverage Service Oriented Architecture and enabling an enterprise wide architecture solution. He has over 11 years enterprise software experience and a Masters in Engineering.

Andrew Gordon is Director, SOA and Open Source Solutions with Unisys Federal Systems, based in Reston, Va. He is responsible for leading the SOA and open source business vision for Federal Systems, shaping the Federal strategic SOA and open source solutions portfolio and helping federal government clients harness the power of SOA and open source as flexible, reliable, secure and cost effective options for business critical software.

Andrew has 18 years of success at leading and pioneering enterprise wide shared services initiatives and bringing to market service oriented infrastructure products at Compuware, IBM, Mercator, and Butterfly.net. Andrew built and led enterprise wide Shared Services (SOA) organizations, exponentially increasing the rate at which organizations could respond to new and changing market requirements while simultaneously delivering a massive reduction in IT cost for itself and its customers.

Author Contact Information

Kartik Mecheri
Email: kartik.mecheri@unisys.com
Phone: 703-605-2136

Andrew Gordon
Email: andrew.gordon@unisys.com
Phone: 703-439-5491