Service-Oriented Architecture Overview

The SOA approach influences the solution architecture of CMS IT systems, from the conception of projects and throughout the system development life cycle (the CMS TLC). SOA simplifies development efforts by providing reusable portions of functionality and separating application architectures between the consumers of functionality and the providers of functionality.

Advantages and Disadvantages

A SOA is beneficial because it distributes computing rather than data. SOA systems provide functionality, called services, which they make available to other systems. The architecture for delivering these services is service-oriented because the service is the atomic building block, not the system. A “service” thus implements a unit of business or technical capability, provides an interface so it can be used (or consumed), and contains a description that defines its purpose and other pertinent metadata. Rather than copying data or functionality, a SOA uses network technology to access these services in a distributed fashion. The SOA offers a collective of interdependent services that function as a system to provide business value, unlike traditional architecture that supports a collection of systems that only operate on data and functionality within their own sphere of control.

The principal disadvantage of a SOA is that it distributes functionality and data sources. For some applications, this can degrade performance and reduce security. Architects should consider how to mitigate these issues when choosing an appropriate application and service architecture.

Need for SOA at CMS

Five sets of challenges frame the need for SOA at CMS:

  • Flexibility
  • Control
  • Mobile support and customer engagement
  • Data publication
  • Integration and modernization

CMS values flexibility and the capability of adapting quickly to change. At the same time, the Agency also must control the proliferation of data sources within the enterprise. CMS is committed to mobile platforms, which require a supporting SOA. Finally, enterprise IT modernization must allow for graceful retirement or replacement of systems without disruption to the rest of the IT environment. The following topics address these challenges, each warrant deeper discussion. “Success Factors for the SOA Solutions” presents the advantages of SOA as a compelling solution.

Flexibility and Adaptation to Change

CMS is committed to providing a flexible and adaptable environment to accommodate needs and changing requirements. Flexibility means reusing current capabilities in new ways to meet new goals. Adaptation means evolving those capabilities to address new goals. In CMS’s fast-changing environment, technology solutions that require a completely new implementation to meet business needs are less satisfactory because they take too long to execute and introduce greater risk.

Controlling Data Source Proliferation

The data source landscape of CMS’s current environment presents key problems for managing data:

  1. Business applications make their own copies of the relevant CMS data to fulfill their unique business requirements. Consequently, there are copies of the same information in multiple locations, and each copy has its own managing organization.

  2. Copies are altered to meet unique business requirements.

Over time, the continuing proliferation of data derivatives and data sources complicates the determination of the authoritative instance of the data.

The resulting data landscape has copies of data, each different from the other, and with unclear derivation histories. This landscape makes reuse problematic and encourages further deviation. CMS understands there is a tendency to produce point solutions when an organization’s development decisions only consider the needs of a single project or system. In distributed systems, these are point-to-point solutions. If unchecked, this approach spawns a self-perpetuating cycle of data proliferation: multiple copies of information abound, often scattered across independently managed instances, with limited integration and little opportunity or incentive for reuse. The filtering and augmentation criteria used to alter local copies is often undocumented, which forces projects to return to the source and make copies.

Enabling and Encouraging Data Publication

Data publication via APIs ensure that external consumers operate with an authoritative data source, rather than working from copies (as mentioned earlier). The availability of data via APIs means that mashups and other forms of data integration can be applied to derive new forms of data.

Any decision to publish data for external consumers must also balance their need for data with the need for privacy in accordance with CMS and HIPAA privacy guidelines.

Supporting Mobile Platforms for Customer Engagement

For many Americans, mobile platforms are their primary means of Internet communication, either by economic necessity or by choice. Mobile platforms, such as mobile phones, tablets, and other portable devices, interact with the digital world using web services. Making CMS services available to these mobile devices fulfills the vision of an Enterprise as a Service (EaaS) that delivers services to citizens.

REST-based web services are the de facto standard for mobile application support. For intermittently connected (“offline”) mobile and web applications, CMS recommends considering other forms of more complex middleware such as synchronization or change-set propagation (see Untether: Middleware Components to Support Intermittently Connected Web-Applications), or use of local storage (see Offline Web Applications). These solutions are out of scope for this chapter.

While allowing mobile users (constituents, employees, and contractors) to leverage CMS services securely in the field, CMS must protect the Agency infrastructure and data from malicious intent to ensure effective Agency operations.

Challenges of Modernization and Integration

All systems inevitably become candidates for modernization, replacement, retirement, or consolidation. Rarely do CMS systems operate in isolation; rather, they are likely to depend on other systems and data as they perform tasks as part of a business process or data flow. CMS systems have been developed and maintained for many years, with a variety of different technologies. As technologies and products are eventually retired, it is critical to access system functionality and data until CMS acquires suitable replacements. This introduces a strategic interoperability challenge.

CMS needs architectures that facilitate systems modernization and delivery of new capabilities without disrupting the existing process, data flow, and customer services.

Success Factors for the SOA Solutions

CMS has adopted a SOA methodology to fulfill the Agency’s needs in conducting business and developing IT systems. Web Services will be the principal, but not exclusive, method of implementing SOA in the CMS environment. Messaging technologies can also implement a SOA, although the proprietary protocols may limit reuse and increase costs over freely available Internet standards, such as TCP/IP, HTTP, XML, SAML, and other markup language-based technologies. The following success factors should guide development and implementation of SOA solutions that offer greater value to CMS organizations:

  • Adhere to a Service Contract. Web Services must adhere to a service contract, guaranteeing that service producers will not alter existing Web Services without either providing a migration path or a backwards-compatible solution. A typical solution includes a versioning method.

  • Comply with Open Standards. Open Web Services standards for systems integration (such as the WS-* standards, XML, JSON, HTTP, and URI) have evolved sufficiently to provide the basis for an overall approach to integration across a large, diverse undertaking like the CMS enterprise. Design and investment decisions should favor technologies (products, designs, and approaches) based on open industry standards to avoid vendor lock-in and improve system interoperability for CMS stakeholders.

  • Adopt an Operating Model. Successful SOA implementation includes a model for sustaining and maintaining shared services across organizational boundaries. The relationship is asymmetric—the service consumer (and by extension, the enterprise) stands to gain more than the service producer. A financially sustainable operating model is necessary to ensure that service producers can continue to provide services and service consumers can continue to rely on the availability and operation of those services. The principal issue is equitable compensation for services provided; however, compensation as a business, organizational, and financial challenge in implementing shared services is outside the scope of this chapter. In addition, service consumers and providers need to establish SLAs with appropriate compensation to ensure sustainable service performance while reducing the risk of lower performance and higher operating cost.

Establish Authoritative Sources for Information

CMS’s goal is to use a SOA to establish authoritative sources to manage and expose information using Web Services rather than continue making copies. There must be a single version of the truth in the enterprise. System maintainers and architects should strive to:

  • Avoid duplication of data
  • Avoid duplication of business rules or business processes
  • Expose a single, consistent way to perform a specific business capability

Many vendors now offer support for Web Service integration capabilities, such as transformation, content-based routing, mapping integration, composable capabilities (“mash-ups”), and orchestration. Vendors also support off-the-shelf adapters for enterprise applications.

Enable Reuse by Exposing Existing Capabilities as Services

Exposing existing capabilities as services is an excellent first step toward eventual systems modernization, migration, consolidation, or replacement. It effectively isolates other applications from the specifics of a target system by identifying and formalizing interfaces.

Service architects should consider exposing existing system capabilities as web services, especially when an existing system is a system of record for a specific kind of data. This approach will help migrate existing business processes and information systems into the CMS SOA. Good candidates for web services are finer-grained data exchanges rather than large “batch” data transfers more suitable for managed file transfer and batch processing. For more information on this mode of computation, please refer to CMS TRA – Infrastructure Services, File Transfer.

Exposing existing capabilities as services is also an essential step in supporting mobile platforms to advance the enterprise mission. Mobile platforms use SOA to leverage services to a variety of stakeholders. By providing these services, CMS fosters an ecosystem of service and data consumers while also enabling its own business.