Target

From PGFSOA Wiki

Contents 1 Service Oriented Vision - The Target Architecture [Document Section 3] 1.1 Service-Oriented Enterprise (SOE) 1.1.1 Management, IT and Business are All Service Focused 1.1.2 Sustaining SOE through Federated Governance 1.1.3 Model Based Acquisition Processes 1.2 Service Oriented Architecture (SOA) 1.2.1 Federal SDLC and EA are Integrated and Support SOA 1.2.2 SOA and Interoperability Will be Well Established 1.2.3 Standard Federal Government Services Will Emerge 1.2.4 Model Driven Architecture Will Be Embraced 1.3 Service-Oriented Infrastructure 1.3.1 Service Management is Coordinated Throughout the Federal Government 1.3.2 Increased Collaboration with 3rd Parties 1.3.3 Tool sets to Manage the SOI

[edit] Service Oriented Vision - The Target Architecture [Document Section 3]

This section presents a vision of the future when the benefits described in the previous section have been achieved. The vision presented here presumes that the IT-enabled business improvement required to embrace SOA has already been largely achieved throughout the Federal Government. As such, this Service Oriented Vision presents an idealistic future that has been extrapolated from an understanding of today’s promising technologies, standards, and best practices and an assumption that they will mature and converge -- ultimately enabled by automated tool sets.

The service oriented vision described here sets the stage for the subsequent sections by describing the objectives, behaviors, and outcomes that federal architects should strive for. The Target Architecture we ultimately seek to achieve provides the necessary context for understanding the subsequent sections. The SOA Adoption Roadmap presented in Section 5 is a roadmap to achieve this vision. The Keys to Implementation presented in Section 4 identify critical success factors and challenges that organizations need to address to realize this vision.

While “target architecture” notionally represents the end point in the evolution (that is, time independent), in reality the target will need to evolve to keep pace with the rampant technological innovation of our time. So take heed, this section of the document, this vision, will become stale over time. Chief architects and CIOs should keep abreast of both enterprise objectives and technology trends and then work together to periodically revise their organizations' target architectures. On the bright side, because SOA enables agility and innovation, as agencies mature their SOA capability, they will find they can more rapidly progress toward their target architecture.

The Federal SOA Vision

The SOA vision is that federal agencies become more agile from a management, operational and acquisition perspective by employing a “service model” with continuously improved automation support. For example, an agency that has achieved the Target Architecture would exhibit the following characteristics:

• IT responds more rapidly to meet the demands of changing business and mission needs.
• Government organizations routinely organize into ad hoc partnerships to automate collaboration models.
• Government can more easily and effectively recapitalize IT components to leverage the latest commercial technology capabilities and reuse standard government and industry solutions and services.
• Government services are easier to access, deliver higher value, and extend across organizational boundaries.

As the Target Architecture is adopted throughout the federal government and these characteristics are manifested within bureaus, agencies, and departments, we can expect to see streamlined lines of business, more robust and useful end-to-end services, and new government capabilities converge to deliver more effective mission fulfillment. But the vision extends far beyond an isolated federal government. These same characteristics will be leveraged to adopt industry domain standards and will engender more extensive collaboration with business, state and local government, and international partners.

The next section provides a top-level overview of the Target Architecture.

Overview of the Target Architecture

Because there are many interdependent aspects to the target agile enterprise, we will divide the discussion into three major parts (see Exhibit 3-1):

• Service Oriented Enterprise (SOE): The business, management, and operational processes, procedures, and policies that support a services model. In essence this is an organizational behavior model aligned with the service model and designed to facilitate and govern its effective maturation.
• Service Oriented Architecture (SOA): Enhanced architecture practices that leverage robust models to capture and facilitate service architecture engineering best practices. SOA is the application of the service model from EA through segment architectures to solution architectures.
• Service Oriented Infrastructure (SOI): The service-enabling environment, itself delivered as a collection of robust enterprise services that enable runtime connectivity and interoperability. SOI represents the operational environment that supports the service model.

Exhibit 3-1: A Service Oriented Framework

SOE enables the service model by facilitating shared acquisition models, incorporating architectural alternatives in the decision process, and enabling effective collaboration across boundaries. SOE also governs the SOA and SOI activities ensuring that justifiable business drivers support IT investments and deliver intended results. SOA is an architectural style that uses modularity to decouple technical complexity from the business drivers. The run time service-oriented environment that constitutes SOI supports the implementation, deployment, and manageability of delivered service oriented solutions. These three major parts are integrated and mutually supportive.

Because the Target Architecture is forward looking, it has been derived by envisioning today’s emerging SOA related best practices and technologies in a more mature state; then imagining an organization that has fully embraced and adopted the service oriented model. This section presents the best practices and technologies that are projected to advance and enable the SOA vision presented here. These best practices and technologies have been organized in a table (Exhibit 3-2) that includes a brief description of each, a statement of how it supports the vision, at least one reference for more information, and examples of specific related standards or initiatives.

'Exhibit 3-2: Target Architecture Best Practices and Technologies'Can we put this piece in the appendix??

Best Practice or Technology	Description	Relevance to SOA Vision	Reference	Example Standards and Initiatives
Business Process Management (BPM)	An approach to improving business performance.	Enables agile business process orchestration and service choreography.	bmi.omg.org [1]	BPMN, BPXML, BPEL
Model Driven Architecture (MDA)	OMG best practice for architecting solutions.	Enables complex IT architectures and solutions to be precisely represented in simplified forms. Many of today’s integrated development environments products today incorporate MDA capabilities.	www.omg.org/mda/ [2]	UML, XMI
Composite Applications	Unified solutions assembled from services.	Enables collaboration and extended value chains	Open Service Oriented Architecture: www.osoa.org [3]	BPEL4WS,WSCI
Enterprise Service Bus (ESB)	Leverages industry standards to provide a robust integration and operational infrastructure that supports the integration, operation, and management of heterogeneous, distributed computing systems	Provides a service oriented infrastructure that enables SOA infrastructure.	-	Sonic, BEA, IBM, Oracle, SAP, TIBCO, and many other vendors offer an ESB.
Semantic Interoperability Standards	Models, frameworks, and standards for cross Community of Interest semantic interoperability	Enables shared semantics to the extent needed for cross boundary information sharing and services	www.niem.gov [4], W3C	XML Schemas, OWL, NIEM
Enterprise Architecture	Governance and IT planning and management framework	SOE concepts exist at the enterprise and segment architecture levels; SOA. SOI concepts come into play at the segment and solution architecture levels	www.egov.gov [5] www.cio.gov [6]	Federal Enterprise Architecture and related CIO Council guidance

The following subsections provide additional insight into the Target Architecture Vision by examining SOE, SOA, and SOI in more detail.

[edit] Service-Oriented Enterprise (SOE)

SOE is perhaps the most challenging of the major parts of the Target Architecture because it requires the greatest change to entrenched business practices. Enterprise architecture, as a discipline, is designed to achieve efficiencies and mission enablement by standardization, optimization and collaboration across organizational boundaries. Service orientation is an approach to architecture that is particularly well-suited to achieve these objectives. SOE, discussed in this section, builds upon the foundation laid in the 2006 Federal CIO Council report, “Services and Components Based Architecture” [CIOC, 2006]. In particular, Section 3 of that report addresses the strategic, policy and organizational changes required for success with SOA. This document takes the discussion a step further by defining what the target environment will look like when the change has taken place. The primary objectives for SOE are described below:

1. Enhance Mission Focus: The envisioned SOE will reduce redundancy and allow greater resources to be directed to achieving intended mission outcomes. Government transformation initiatives will result in more agile, policy-enabled, service-oriented organizations.
2. Increase Agility: The envisioned SOE has established aclear line of sight for impact of IT investments on business outcomes. This enables informed executive decisions to be made more rapidly and with more confidence. The business of managing change has been formalized and is continuously exercised and improved. Portfolio management addresses both service-components and enablingbusiness solutions. More parallel change initiatives can be carried out simultaneously without increased risk. Architectural considerations are prominent in investment decisions. Performance-based contracting has been enabled by a well-defined SOA. Standard enterprise SLAs, security models, and capabilities are leveraged across lines of business.
3. Increase Collaboration and Interdependency: The envisioned SOE has enabled program funding to be pooled to support effective enterprise services that can be shared at lower cost and delivered at higher quality. The agency has met its responsibility to share data and is actively participating in appropriate Communities of Interest (CoI). Improved federated governance models reward initiatives that share resources and disallow undesired redundant investments. Dependable service delivery, and standard trust models enable organizations to inter-operate with confidence. Consensus policies are established to manage the service life-cycle.

The National Information Exchange Model (NIEM) provides a glimpse of this future vision today. Driven by national security concerns in the wake of the terrorist activities of 2001, NIEM became a national priority, received requisite funding, and required the effective collaboration of many independent organizations. Today, NIEM serves as a leading example of a Service Oriented Enterprise. See Exhibit 3-3 for more information on NIEM.

To achieve these objectives federal government organizations need to behave differently. The desired organizational behavior is described below.

[edit] Management, IT and Business are All Service Focused

Enterprise architecture has provided a broad-based movement throughout the federal government to bring strategic planning, portfolio management, budgeting and capital planning, business process management, and IT management together to achieve the vision of “architect, invest, implement”. Exhibit 3-4 below shows a notional value chain for how these processes fit together.

Exhibit 3 4: Overview of Management Processes

Given the rapid maturation of federal organizations EA capabilities it is not difficult to imagine a time when federal organization EAs produce well-represented target architectures that define the strategic direction for the organization in terms of service capabilities supported by transition plans for migrating to the target architecture.

As these service-based target architectures, and plans improve and visibility into these plans increases, opportunities for efficiencies and sharing will manifest more clearly. As a resultFederal agencies will exhibit the following characteristics:

• Software-as-a-service (SaaS) will become a well established federal business model. Many services will be hosted under software-as-a-service contracts with vendors or other agencies.
• Portfolio management will become more focused and agile. Portfolio assessment will focus more on performance outcomes, service levels, integration with other services, and support for planned transformation initiatives.
• Performance measurement (PRM) will be enabled because the service architecture and will provide a clear line of sight from business value chains through the business capabilities, technology capabilities, and operational capabilities that support them. This will simplify the development of more accurate business cases.

[edit] Sustaining SOE through Federated Governance

It should be apparent that the federal SOA environment is quite complex, dynamic, and large in scale, involving many actors (for example, business process stakeholders, IT consumers and producers, vendors, programs, bureaus, offices, agencies, communities of interest, other departments and multiple levels of government) residing at a variety of intra, inter, and extra organizational levels. They must all interface with a host of management processes (see Exhibit 3-4), while providing sustained business output and outcomes. SOA decreases the barriers to distributed and federated collaboration and the relative ease required to engineer links among disparate vertical service oriented domains, i.e., ‘federation”, enables less onerous approaches to governance.

Because today’s government-wide policies increasingly require federal agencies to share services, it follows that a federated governance model is most appropriate to ensure that service consumer and provider needs are met across disparateorganizational boundaries.

In the Introduction above, we identified several major challenges:

• Absent or ill-defined target federal SOA environment that is consistent with enterprise architecture activities;
• Lack of guidance to promote, demote, and retire services through multiple tiers of actors;
• Inadequate enterprise-wide and cross-enterprise management and monitoring of web services; and
• A governance mechanism that facilities the interaction and commitment of actors;
• Funding processes that inhibit cross-domain, cross government collaboration.

These broad challenges reveal an underlying theme - interaction and essential, if not mandatory, participation of vested actors within and across multiple levels for common enterprise services as notionally illustrated in a SOA-centric view in Exhibit 3-5. Adding additional complexity is the relationship of business units and process “owners” such as the Communities of Interest (COI) with regards to direction andoversight of a particular service. As such, traditional IT governance archetypes tend to focus on one organization (there are of course exceptions) or while supporting complex organizations are themselves rudimentary. In any case, the relationships at each level for enterprise-services illustrated in Exhibit 3-5, will rapidly extend beyond the direct authority boundaries of the concerned organizations. In effect, the interactions at each layer are similar to a commercialalliance and taken altogether resemble a networked hierarchy or federation.

As we envision our target SOE, we expect to see standardized and proven bilateral and multi-lateral governance models become available. These will mature to include:

• Standardized contract language to assist agencies to procure business and IT capabilities;
• Standardized service level metrics andagreements;
• Effective funding models to support shared services and shared infrastructure;
• Procedures for holding service providers accountable for SLA terms;
• Portfolio Management models that focus on collaboration around common business and IT services.

Additional information on federated governance can be found in Section 4 - Keys to Implementation.

[edit] Model Based Acquisition Processes

Model based acquisition processes will leverage modeling standards and best practices to provide more accurate descriptions of organizational requirements in solicitations. In conjunction with service based target architectures, organizations will be able to substantially reduce the effort required to define their requirements and, because the requirements will be more precise and understandable, perhaps even testable, they will mitigate downstream risks of selecting vendors and contractors that do not sufficiently meet their needs. Model-based acquisition processes will also remove much of the guesswork for vendors and contractors, because the government’s needs will be more clearly understood. Model based acquisition processes directly support the business agility and agile recapitalization benefits of SOA, and as a result, will yield improved mission performance.

Model based acquisition processes leverage precise models developed in accordance with open modeling standards (e.g., UML, BPMN, and IDEF). Precise models reduce ambiguity, provide a more structured way to convey information, and lay the foundation for standardizedpatterns to evolve and be exploited. For a graphical depiction, see Exhibit 3-6: Modeling Service Orientations Example.

Exhibit 3 6: Modeling Service Orientations Example

Exhibit 3-6 Modeling Service Orientation example needs to be clearer; specifically inside the boxes, the components are not clear. It is hard for the reader to understand the relationship among different components under discussion.

[edit] Service Oriented Architecture (SOA)

The Service Oriented Architecture (SOA) is at the center of the Service Oriented Framework presented in Exhibit 3-1. The Service Oriented Infrastructure (SOI) is required to enable its operation and the Service Oriented Enterprise (SOE) is required to manage and govern it. The SOA is also the area in which federal chief architects and federal CIOs have the greatest ability to control the Target Architecture.

The three primary objectives for SOA are described below:

1. Provide line of sight traceability from mission to implementation. The envisioned SOA is driven by accurate, vetted business models. The business models are supported by a layered service architecture designed to automate and support the modeled business. Traceability is provided by tracking service dependencies.
2. Deliver agile, executable architectures. The layered service architecture is policy driven. Business policy is governed by the business, IT policy is governed by OCIO. The service portfolio is managed to increase andenable effective business and technology capability reuse. Architecture policy facilitates introduction of new technology capabilities, the use of 3rd party services, and the publication of services for external consumption. Recapitalization can and shouldoccur for individual service components.
3. Ensure semantic interoperability. Semantic interoperability is achieved by employing standard schema (or ontologies). These standard schemas are developed through data modeling methodologies to ensure that the data are complete and consistent. Schemas are published to the collaborating community by an authoritative source (e.g., government authority, standards body, or COI). Modifications to the schema must also be vetted through the governance processes established by the authoritative source. Self service, on-demand interoperability test environments are available for the collaborators. Automated test scenarios must be passed to deploy to operational environments.

To achieve these objectives, federal government organizations will need to embrace SOA and change the processes they employ to manage and develop systems. The desired behavior is described in subsequent subsections, but before further discussion ensues, we should establish a reference framework.

An SOA Reference Framework

According to the Organization for the Advancement of Structured Information Standards (OASIS) Reference Model for Service Oriented Architecture, “Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. In SOA, services are the mechanism by which needs and capabilities are brought together.”

Let’s examine an example enterprise from the service perspective. Exhibit 3-7 shows a sample model of the US Patent and Trademark Office (USPTO). The exhibit shows that USPTO delivers Intellectual Property Protection services by delegating to either Trademark Services or Patent Services. Furthermore, it can be seen that both the patent and trademark service units consume financial services. While this example is an oversimplification, it highlights some useful characteristics of the service model. In this perspective, the USPTO responsibilities are clear. It delivers Intellectual Property Protection services by providing an effective environment for the three depicted government service units to collaborate. It also demonstrates the recursive nature of the service model. The service model applies at many different levels of granularity, from the largest federal government departments down to individual subsystems.

If we look inside a service oriented government service unit, we’d expect to see a service oriented architecture. By definition, that is an organized collection of distributed capabilities marshalled to effectively deliver higher order services.

Exhibit 3-8 presents a straightforward reference framework for a service oriented architecture. The top layer, Business Operations, and the bottom layer, Systems Operations are the only two operating aspects of the business. The other layers reflect a service oriented approach to organizing (architecting and designing) capabilities to support the business. The Composite Application Architecture assembles and orchestrates services to fulfill business operations while the service architecture presents useful services for assembly. The component architecture employs resources to deliver the business services.

[edit] Federal SDLC and EA are Integrated and Support SOA

Federal System Development Life Cycles (SDLCs) will be expanded to support both the solution development life cycle and the service life cycle. This will enable the agile recapitalization model by supporting solution delivery and service provisioning teams to work concurrently and more independently than conventional systems project teams. The Target SOA and supporting transition plans, as defined within the EA, will guide integration activities throughout the SDLC. Teams will stay synchronized by aligning to configuration management controlled service specifications. Project release plans will demonstrate how individual teams are executing the transition plans to converge on the target architecture. As projects progress through the SDLC, architecturally significant changes will be reflected in impacted EA work products.

With these changes in place, and once the operational service inventory grows, solution project teams will be able to rapidly deliver composite applications that better meet business needs, simplify business procedures, and enhance mission effectiveness because much of the technical complexity will now be the responsibility of the service provisioning teams. Solution delivery teams will be focused on providing intuitive user interfaces, stable business process orchestrations, and service choreographies; all developed in adherence to approved business semantic models.

Service provisioning teams will be responsible for delivering the services called for by the target architecture. They will provide the necessary services by incorporating legacy system capabilities, introducing 3rd party products and services, and through custom development where necessary. Furthermore, the service provisioning teams will ensure the consistency of data in disparate data stores and provide data aggregation services to the solution delivery teams.

[edit] SOA and Interoperability Will be Well Established

Communities of Interest (COIs) and Communities of Practice (CoPs) will use data modeling methodologies to develop standard semantic models (schema or ontologies) and approved choreographies. These semantic models will be established and changed only through a strong governance process. Each collaborator will have developed compliant services that map their business concepts to the community standards and fulfill their responsibilities in the collaboration. (See sidebar). These communities will comply with applicable Federal Reference Architectures (FRA). Proven reference implementations will be available for FRAs.

[edit] Standard Federal Government Services Will Emerge

As collaboration spreads through the federal government, best of breed common infrastructure services will emerge. Adoption of some common services across the federal government will start with infrastructure services (e.g., authentication, auditing) but quickly expand to business utility services (e.g., federal employee lookup, simple approval process, calendar services, scheduling).

In particular, the security services required to enable basic collaboration and information sharing are already in demand. Fully compliant security best practices will be formalized and integrated into management processes, governance, and the SDLC, so that a formal definition of security requirements based on enterprise policy is specified in accordance with a standard federal model. Service registration discovery and delivery protocols that include requirements for Single-Sign-On (SSO) authentication, authorization, audit, confidentiality and integrity will be integrated into a standard federal government security service that can be delivered over a network.

Today, the IT Infrastructure Line of Business (ITI LoB) serves as the umbrella, a cross-agency initiative driving agencies toward a unified federal SOI.

[edit] Model Driven Architecture Will Be Embraced

As SOA, Business Process Management (BPM), and model driven architecture (MDA) converge, federal EA best practices will evolve to exploit them. MDA provides a set of guidelines for structuring specifications as standard models. Transformation techniques are then employed to enable automated generation of systems and services compliant with specified reference architectures.

As the convergence of MDA and BPM continues, it will enable the development of platform-independent models (PIM) expressed in domain specific languages to create executable business process models. BPM capabilities already provide the capability to design, simulate and test business services in business context before they are deployed.

[edit] Service-Oriented Infrastructure

The natural result of a Service Oriented Enterprise applying Service Oriented Architecture to enable its objectives is a functioning collection of services resting on a service-based platform. The platform is the Service Oriented Infrastructure (SOI) which provides more than just the communications environment that enables service-based integration. It also provides the capability to register, locate, and deploy services as well as monitor and manage the service architecture.

The objectives for the envisioned SOI are described below:

1. Provide a secure, reliable, resilient infrastructure: The envisioned SOI provides a reliable, flexible, policy driven platform to enable the target SOA. SOI services are centrally managed and used consistently in support of cross domain integration. A standards-based security/trust and semantic model enables trusted delivery of valuable information between organizations. Resilience capabilities are designed into the infrastructure (e.g., COOP, IOI, COG).
2. Operate to Quality of Service (QoS) needs: The envisioned SOI will provide one or more inter-operating environments that support the full range of enterprise QoS needs within a reasonable budget.
3. Automate service development, deployment, and operations management: Service lifecycle runtime tools and platforms are mature and established in federal agencies.

To achieve these objectives, federal organizations will need to change their current development and operations practices. The desired behavior is described below:

[edit] Service Management is Coordinated Throughout the Federal Government

Service registries (and/or repositories) will be organized and coordinated so that service consumers can identify and locate candidate reusable services. Service registry/repository management will have to mature as an important aspect of the configuration management and operations disciplines. Processes will be developed to allow useful services to be promoted so that they are available across a broader scope. Either central management or sophisticated protocols will be established to enable the varied collaborative environments to be coordinated. The registries will provide sufficient information for consumers to determine whether a service will fulfill their requirements.

Adaptive embedded testing and certification will enable agencies to deploy and consume service based capability with confidence and federated registries will enable registered services to be identified across the entire federal government.

[edit] Increased Collaboration with 3rd Parties

Federal IT infrastructure will comply with SOA standards to enable federal government business partners and collaborators to interact with agencies in real time. As service best practices are adopted, the government will be able to extend their value chains to their partners including State, Local and International governments, business partners, associations, and citizens themselves. One example of this currently under development is the Nationwide Health Information Network, which defines a set of common services to be used by both public and private sector organizations to exchange electronic health record data with trusted partners. [i]

The envisioned SOIs will be inter-operable, efficient, secure, robust, modular, composable platforms for service execution. When broadly adopted and mature the envisioned SOI will support the following:

• Standard, composable middleware adapters (e.g., JBI, SCA and their successors) as the primary means of automated integration across organizations;
• Infrastructure services and adapters to dynamically enforce policy for security, interoperability, and quality of service;
• A set of fully compliant security-based services will intrinsically support solutions. For example the SOI will provide solution architectures with standard services that provide: single sign-on, access control, identity management, and consolidated user profiles; and
• Scalable Federal IT infrastructure.

[edit] Tool sets to Manage the SOI

The envisioned SOI will be supported with robust development, deployment, and operations management tools including:

• Service Registries and/or repositories to manage the service lifecycle and service meta data;
• Service management tools to monitor SLA compliance and security breaches and anomalies;
• Message translation accelerators (e.g., for XML);
• Application, service, and business monitoring tools;
• Modeling tools;
• Testing tools;
• Activity logs that log each invocation of a service; and
• Tools to implement policy enforcement.