CSS-FD SIR J-8 AES Technical Architecture_DRAFT_v2.0.pdf

Solicitation #

Attachment J-8

Federal Aviation Administration

Common Support Services – Flight Data (CSS-FD)

Automation Evolution Strategy (AES)

Technical Architecture

November 2024

Federal Aviation Administration

800 Independence Avenue, SW

Washington, DC 20591

Automation Evolution Strategy (AES) Technical Architecture ii

PAGE LEFT INTENTIONALLY BLANK

iii

Executive Summary

The Federal Aviation Administration (FAA) Automation Evolution Strategy (AES) promotes reuse of software capabilities while increasing the speed and agility in making new functionality operational. AES promotes these goals by envisioning the future National Airspace System (NAS) consisting of loosely coupled and well-defined services (i.e., Mission Services) that can be developed and sustained independently. This will increase opportunities for safe incremental improvement, reuse, competition, and parallel development. Mission Services expose software functionality through well-defined Application Programming Interfaces (APIs), which other Mission Services can leverage.

Whereas Mission Services provide NAS functionality and data, Mission Applications are created to achieve goals of NAS users. Mission Applications support users’ goals through human-machine interfaces and APIs. A collection of Mission Applications, Mission Services, and/or Common Mission Services of which the development, deployment, and operations are controlled by a designated program or group is an authority domain. Mission Applications and Mission Services are grouped into authority domains, which provide a layer of control when communicating between services in different domains. When a Mission Service exposes its functionality for use by a Mission Application or Mission Service from another authority domain, it is considered a Common Mission Service.

The primary difference between a Mission Service and Common Mission Services is that if a Mission Service interface changes, it does not need to coordinate with another authority domain to identify impact of the change and establish a transition plan that minimize impact to other authority domains. It should be noted that a Mission Service that is used by a Common Mission Service will need to consider if a change impacts the Common Mission Service. Depending on the change, it results in an impact to the information provided by the Common Mission Service and would require the same coordination as if the Common Mission Service interface was changing.

To improve reusability of Mission Services or transition a Mission Service to become a Common Mission Service, the details and metadata about the service offering and components should be discoverable by other service developers within the agency. Service discovery is further enabled through the use of a modern service registry. Many enterprise products are now available to support a modern Continuous Integration, Continuous Delivery (CI/CD) model for API management and service discovery such as service catalogs and DevOps viewers.

As service developers become more aware of available services being developed and leveraged via well-defined APIs, these software functions will need to be shared through multiple design patterns. One way is to share code; another is to share functions as software libraries. The target of this paper is to describe how a service can be exposed and governed as a Common Mission Service to be used by multiple authority domains. Doing this requires some careful planning through use of service encapsulation, bounded context, and API contract management.

The identification and development of a Common Mission Service begins with the research phase of the FAA’s Acquisition Management System (AMS) process to identify shortfalls and opportunities where multiple authority domains need a common function. These functions and concepts of operations are refined with each phase progression of the AMS lifecycle.

iv

Considerations should be made for a modern approach to best identify and communicate the needs for investment within the AES layered technical architecture.

v

Table of Contents

Executive Summary ..................................................................................................................... iii

1 Introduction

1.1 Background

1.2 Purpose

1.3 Scope

1.4 Analysis Overview

2 AES Mission Software Layer

2.1 Overview and Definitions

2.1.1 Concept of Common Mission Services

2.1.2 Conceptual Grouping of Services by Dependencies

2.1.3 Mission Partner Interaction Example

2.2 Notional Use Cases

2.2.1 Cross-Authority Domain Example (CSS-FD/FMDS)

2.2.2 Service Analysis of CSS-FD Example

2.2.3 Service Analysis of Notional Conflict Probe Service

3 Sharing Mission Service Functionalities

3.1 Microservices vs. Service-Oriented Architecture (SOA)

3.2 Considerations for Reuse

3.3 Considerations for Common Mission Services

4 Service Discoverability

4.1 Service Descriptions

4.2 Service Registry

4.3 Responsibilities of Service Providers

5 Acquisition Management System (AMS) Considerations

5.1 Research for Service Analysis

5.2 Service Analysis and Strategic Planning

5.3 Concept and Requirements Definition

5.4 Initial Investment Analysis

5.5 Final Investment Analysis

5.6 Solution Implementation

vi

5.7 In-Service Management

6 Conclusion

Appendix A References

Appendix B Acronyms

Appendix C Summary of AES Mission Software Layer Definitions (Lexicon)

List of Figures

Figure 1: AES Layered Service-Based Architecture [182]

Figure 2: AES Technical Architecture

Figure 3: Basic Concept of Common Mission Services

Figure 4: Conceptual Grouping of Services by Dependencies

Figure 5: Conceptual Grouping of Common Mission Services

Figure 6: Common Mission Services Shared with Mission Partners

Figure 7: Cross-Authority Domain Example

Figure 8: Example for Common Mission Services Within CSS-FD

Figure 9: Service Analysis of NCR Architecture

Figure 10: Service Analysis of NCR Deployment Architecture

Figure 11: Notional Architecture for Conflict Probe Service

Figure 12: Shared Services Model

Figure 13: Service Discovery Example

Figure 14: Example of Service Entity Relationships (Port)

Figure 15: Example of Service Registry (Port)

Figure 16: Example of Service Registry (Compass)

Figure 17: Example of Service Entity Relationships (Compass)

Figure 18: FAA AMS Lifecycle

1 Introduction

1.1 Background

The Federal Aviation Administration (FAA) has developed the Automation Evolution Strategy

(AES) Technical Architecture, composed of a suite of documents that provide recommendations for the “To-Be” National Airspace System (NAS) architecture. AES objectives are outlined below.

• Service-Based Design: AES outcomes should promote the availability of services, rather than functions or capabilities, that are embedded within large systems. The proposed architecture should maintain loose coupling and minimized dependencies across services.

• Enterprise Scope: AES should support the implementation of services that meet the needs of multiple programs and systems.

• Incremental Development: AES should promote the incremental development of services

(i.e., DevSecOps) that can be implemented more rapidly and produce operational benefits in the near and long term. By focusing on more immediate needs and priorities, incremental development avoids unnecessary work and rework resulting from speculation about potential future operations.

• Enable Opportunities for Reuse: AES should promote reuse by providing computing resources, platform software, and Mission Services so that, when appropriate, resources and services may be reused by future Mission Service developments.

Technology is often presented in layered architectural views to help illustrate the “building block” nature of technology. Technology layers go from more physical components at the lowest layers

(i.e., physical connectivity between two facilities, or computing systems, like central processing units (CPUs), or storage, etc.) to more software driven technologies (i.e., database systems, or software applications). AES uses a layered, services-based architecture to illustrate that programs typically require acquiring capabilities from each of these layers of technology. AES introduces standardization and managed services within each of these layers. AES infrastructure standardizes technology and acquisition for computing and platform layers. Enhancements and amplification of some of these key concepts have led to the development of an AES layered service-based architecture, depicted in Figure 1, which includes the following.

• Mission Software Layer: Includes software systems acquired by FAA/FAA programs, or commercially available software solutions, delivered as software-as-a-Service (SaaS).

These are the software systems that operate the FAA’s mission of maintaining air traffic control, managing air traffic operations, and safely separating aircraft in the NAS. These systems are typically procured in a traditional “built-to-specification” model, where the

FAA issues a Screening Information Request (SIR) with a prescribed set of requirements that the vendor community at large then proposes solutions to develop the system. Mission layer software has become increasingly more standardized and more widely available as commercial-off-the-shelf. (COTS) solutions and delivered as software-as-a-service (SaaS) model. This layer contains aviation-specific applications and services built leveraging the

Software Platform Layer and Computing Resources Layer. Applications and services are built following modern architecture approaches (e.g., microservices).

• Standards-Based Software Platform Layer: Is offered in a Platform-as-a-Service

(PaaS), providing shared tools and capabilities, such as database software, development toolchains, identity access management, system messaging, or data management that programs typically acquire as standalone subsystems. SWIM (System Wide Information

Management) is an example of a “messaging platform”, offered as an enterprise service.

SWIM uses industry standard information models and standardized system interfaces to enable NAS program services producers to exchange information with other NAS programs (consumers), allowing system-wide data integration between systems. SWIM created a “publish once, consume many” model to enable multiple programs to exchange information across the enterprise through standardized interfaces. This layer contains a set of enterprise services and tools made available to programs to maximize reuse and accelerate the development and deployment of capabilities. Includes Commercial-off-the-

Shelf (COTS), Free and Open Source (FOSS) components, and Cloud Platform as a Service

(PaaS) offerings. These services and tools provide the environment/platform for the

Mission Applications (i.e. software that provides user interfaces to support the NAS operational mission) and Mission Services (i.e. software components that provide the FAA with mission-specific data and computation functions).

• Computing Resources Layer: This layer includes end-user equipment, compute infrastructure, storage, Local Area Networks (LANs), and Wide Area Networks (WANs) that tie them together. Allows for the rapid availability of infrastructure and improved resiliency. Examples of end-user equipment are workstations, displays, tablets, mice, trackballs, and keyboards. Examples of computing infrastructure are servers that run services, Operating Systems (OSs), storage, Virtual Machines (VMs), and containers. The compute infrastructure is offered as Infrastructure-as-a-Service (IaaS). This layer represents what the information technology (IT) IT server programs typically acquire in bulk early in the program development lifecycle, designed to meet system peak performance requirements, and often years in advance of deployment. As a service, these resources can be acquired as needed, where programs acquire this infrastructure as services, in a “pay-per-use” model. Hence, if more capacity is required, instead of a program initiating formal acquisition processes to acquire new hardware, a program instead buys more IaaS (compute services) to meet near term demand, then releases resources when no longer required.

Figure 1: AES Layered Service-Based Architecture [182]

1.2 Purpose

The purpose of this deliverable is to:

• Make Recommendations for Programs Regarding What Can Be Considered as a

Common Mission Service. In support of this architecture strategy, this document describes and clarifies previous definitions for the AES Mission Software Layer, including

Mission Services and Common Mission Services. The definitions are a result of research into industry best practices and an initial transition strategy for the proposed service-based architecture. The objective for this paper is to evolve the concept of Common Mission

Services within the Mission Software Layer, both internally and externally to the FAA, to minimize duplicative effort in developing software functions among programs.

• Provide Recommendations on the Framework and Process to Make the Services

Discoverable. This paper describes the discoverability of Common Mission Services and the implications of sharing Mission Services by exposing access through the use of

Application Programming Interfaces (API). When a Mission Service is exposed via API to another Mission Service or partner outside of its immediate authority domain, this service is then considered a Common Mission Service and precautions should be taken to ensure sustainable performance across the FAA enterprise.

• Provide Guidance on Establishing a Service Registry. To maximize sharing and reusability, Common Mission Services should be discoverable and kept up to date in a service registry. Service implementers should discover available service functionality to determine if an already existing service can be used as part of their service delivery.

• Provide Considerations for Common Mission Services in the FAA’s Acquisition

Management System (AMS) Lifecycle. The AES vision, with a layered architecture approach, introduces new concepts and requirements that rely on a modern approach to acquisitions. Since the FAA uses the AMS to procure new services, some considerations and recommendations are provided to support the AMS process.

1.3 Scope

The scope of this deliverable is intended to communicate and disseminate the research around policies to manage Common Mission Services, their interfaces, and considerations when procuring such services. This includes the following.

• Provide Definition and Context as to What a Common Mission Service Is or Will Be

Within the AES Vision. By providing clarifying definitions and examples, the AES vision can be more accurately and effectively communicated throughout the agency to affect cultural change and adoption of the best practices promoted by the strategic objectives.

• Identify Stakeholders and Consumers That Will Utilize Common Mission Services.

Descriptions of current stakeholders and consumers will provide examples for future identification of opportunities for reuse or exposure of current Mission Services to other domains as Common Mission Services.

• Define Data Exchange Mechanisms for Services (i.e., APIs). It is well understood that

APIs will be the primary point of interaction between applications and services. Further clarification on API differences such as request/reply and publish/subscribe APIs can support the understanding of API interactions.

• Describe Service Discoverability and Registry with Modern Platform Layer Services.

This paper provides results of research into various registry technologies that can be utilized across the enterprise.

• Provide Recommendations for AMS Process Integration. This document identifies key takeaways for consideration when developing Common Mission Services and Mission

Services throughout the AMS lifecycle.

1.4 Analysis Overview

This volume of the AES Technical Architecture contains an analysis of Common Mission

Services, service discovery, service registry, and integration of these concepts into the AMS lifecycle. This assessment includes the following sections.

• AES Mission Software Layer (Section 2.0) – Defines and depicts various examples of

Mission Services and Common Mission Services.

o Overview and Definitions (Section 2.1) – Describes the AES Mission Software

Layer and its current definitions and evolves them to better explain and differentiate between Mission Services and Common Mission Services.

▪ Concept of Common Mission Service (Section 2.1.1) – Describes an example interaction to depict the concept of Common Mission Services being exposed outside their authority domain.

▪ Conceptual Grouping of Services by Dependencies (Section 2.1.2) –

Describes and defines application, composite, and independent services based on their dependencies on other services.

▪ Mission Partner Interaction Example (Section 2.1.3) – Explains how the exposure of service APIs to mission partners constitutes a Common Mission

Service.

o Notional Use Cases (Section 2.2) – Provides multiple examples (e.g., Common

Support Services – Flight Data (CSS-FD), NAS Common Reference (NCR), Conflict Probe Service) of notional architectures and authority domains to better describe how Mission Services are structured and exposed as Common Mission

Services.

• Sharing Mission Service Functionalities (Section 3.0) – Describes the differences between microservices and Service-Oriented Architecture (SOA), as well as considerations for service reuse and sharing.

• Service Discoverability (Section 4.0) – Describes the need for service discovery, functions of a service registry, minimum service data element descriptions, and examples of various registry technologies.

• Considerations for AMS (Section 5.0) – Provides takeaways for identifying and defining

Mission Services and Common Mission Services as part of the AMS lifecycle.

2 AES Mission Software Layer

2.1 Overview and Definitions

The AES Technical Architecture, shown in Figure 2, describes a layered services-based architecture containing Mission Applications and Common Mission Services at the Mission

Software Layer. An application is software that is designed to be used (and potentially installed) by human end users. Example applications include mobile applications, web applications, and

Personal Computer (PC)-based applications. A service is a software functionality together with the policies that control its usage. Services can be further classified based on their functionality.

Applications and services interface with Mission Services using APIs accessed by an API gateway.

Figure 2: AES Technical Architecture

The previous AES definitions for Mission Services and Common Services are defined as follows.

• Mission Application: Software that provides user interfaces to support the NAS operational mission.

• Mission Services: Software components that provide the FAA with mission-specific data and computation functions.

• Common Services: Mission Services intended for use by multiple consumers.

The term “Common Services” is confusing because most services are expected to be used by multiple consumers. Furthermore, services exist at every AES layer, including the Software

Platform Layer and Computing Resources Layer. Therefore, further clarity is needed to help differentiate a Common Mission Service from other services that may exist in the Software

Platform Layer or Computing Resources Layer. Additionally, there is a need to clarify “multiple users” because, in general, the term service already implies multiple users. Thus, the new AES definitions for a Mission Service and a Common Mission Service are defined as follows.

• Mission Service: Software components that provide the FAA with mission-specific data

(e.g., flight data) and computation functions (e.g., tracking, conflict probe). This software is deployed as a service within an authority domain that provides NAS data or functionality.

• Common Mission Service: A Mission Service that is exposed for use by other Mission

Services or mission partners that reside outside its authority domain.

2.1.1 Concept of Common Mission Services

In order to explain Mission Services and how they are managed, the concept of authority domain is introduced. Since these services are managed by an authority domain and the exposed service interface is via an API, the term API should also be defined. The following definitions support the evolved concept of Common Mission Services.

• Authority Domain: A collection of Mission Applications, Mission Services, and/or

Common Mission Services of which the development, deployment, and operations are controlled by a designated program or group. The operational responsibility of this domain applies to the mission software layer.

• Application Programming Interface (API): Provides access to functions within a

Mission Service or Common Mission Service. Please note that API Management is currently under investigation as part of an FAA investment analysis. API-related best practices will be addressed through follow-on material from the FAA.

Figure 3 depicts a mission user and their access to a Common Mission Service through two different Mission Applications. The difference between the two applications depicted is the access to a Common Mission Service, either within the same authority domain as the Mission Application or indirectly between two different authority domains. All access to Mission Services is provided by APIs designed for that purpose.

Figure 3: Basic Concept of Common Mission Services

Within each authority domain, the opportunity is available to offer Mission Service functionality in addition to using its functions in the performance of their primary goals. While it is possible to develop Common Mission Services from within existing legacy NAS systems, the intent is to define the concept for future service analyses of new system development.

Currently deployed services can be viewed as providing common support functions to more than one program. Examples of these services include System Wide Information Management (SWIM) publication services such as the SWIM Flight Data Publication Service (SFDPS), SWIM Terminal

Data Distribution System (STDDS), and Traffic Flow Management System (TFMS). Following the revised definitions for Common Missions, these SWIM publishers would be classified as

Common Mission Services because the data they provide is consumed by users outside of their authority domain. Further analysis into the software components that make up these SWIM publishers may result in identifying additional software subcomponents, which may be configured as Mission Services. These software subcomponents may be useful as reusable software components for new programs. Alternatively, they could also be exposed via APIs, which would classify them as additional Common Mission Services to support other programs as well as integration functions to build new services. New services can be designed to make use of existing

Common Mission Services that can be integrated to develop new functions and capabilities.

2.1.2 Conceptual Grouping of Services by Dependencies

Common Mission Services are defined as services exposed for use outside of their current authority domain, which means that there are other users dependent on its functions. However, there is a confusion regarding the notion of “Common Services” in which Mission Services that have dependencies with other Mission Services are mislabeled as a Common Mission Service.

This is not the case because some Common Mission Services may be standalone and operate without dependencies, and other Common Mission Services may be an orchestration of several other services. Therefore, to clarify how Common Mission Services may be used, constructed, or otherwise orchestrated within other service offerings, the following definitions provide additional conceptual groupings of services to separate the concept of service dependencies from API governance of Common Mission Services.

• Application Service: An application that is deployed as a service and uses other composite and/or independent services to provide the information to the user.

• Composite Service: A service that has dependencies on other applications or services to provide its data or functionality.

• Independent Service: A standalone service that provides data or functionality without dependencies on any other application or service.

These concepts and groupings provide additional benefits in decomposing service functions and are used throughout the rest of the document. This approach is based on the principles of coupling, including the Acyclic Dependencies Principle (ADP), Stable Dependencies Principle (SDP), and

Stable Abstractions Principle (SAP). The ADP states that the dependency structure between services must be a Directed Acyclic Graph (DAG), meaning there should be no path from a service back to that service—dependencies should flow in only one direction. This makes it clear which services may be affected by making changes to a specific service. The SDP states that a service should only depend upon services that are more stable than itself and services that are expected to change should be designed accordingly. Lastly, the SAP is related to SDP, except it focuses on higher-level services and states those services should be stable and have fewer dependencies on lower-level services. These principles can be applied through proper design and use of composite and independent services. In alignment with the ADP, service dependencies should always flow from application services to composite services to independent services. Application services can depend on independent services, but only if the conforming with the SDP (i.e., the independent service is stable). Otherwise, the SAP applies, and a stable composite service should be implemented between the application service and the constantly changing independent service

[241]. Figure 4 illustrates the proposed conceptual groupings and the dependencies between users and their respective application, composite, and independent services.

Figure 4: Conceptual Grouping of Services by Dependencies

As depicted in Figure 4, composite services can be made up of several other independent services

(as well as and other composite services). This diagram is not meant to depict an architecture, but to accentuate the relationships between service categories. Best practices in service design patterns include principles of bounded context and encapsulation (see Section 3.2). Composite services may also have dependencies on legacy systems to perform their functions. Meanwhile, independent services do not have any dependencies and can provide their software functions on their own without the need to use additional services or functions. Application services may interface with either composite or independent services.

The next example (Figure 5) depicts AES services with conceptual groupings by dependency.

Figure 5: Conceptual Grouping of Common Mission Services

Figure 5 depicts a mission user and their access to Common Mission Services through two different

Mission Applications. In this depiction, the Mission Service and Common Mission Services are nested to demonstrate the concept of those services being operated as independent or composite services, either within the same authority domain as the Mission Application or indirectly between two different authority domains. All access to Mission Services is provided by APIs designed for that purpose. The conclusion is that Common Mission Services can be either a composite service or independent service, focusing on the API element and whether the service is exposed outside of its authority domain. By providing additional detail and definition, this seeks to mitigate the confusion in which a composite service may be incorrectly labeled as a Common Mission Service simply because it’s used in a composition.

2.1.3 Mission Partner Interaction Example

Figure 6 depicts a mission user and their access to Common Mission Services through two different

Mission Applications, with the added access by a mission partner. In this depiction, the Mission

Service and Common Mission Services are nested in the same way as in the previous example

(Figure 5). Access to Mission Services is restricted to only their authority domain. All access to

Mission Services is provided by APIs designed for that purpose. Publish/subscribe services, which are consumed by Mission Applications or partner systems, are also designated as Common

Mission Services.

Figure 6: Common Mission Services Shared with Mission Partners

2.2 Notional Use Cases

This section analyzes notional use cases in which future programs may implement AES concepts for Common Mission Services. These applied use cases depict how interactions between services can be achieved to support the sharing of services across the FAA enterprise.

2.2.1 Cross-Authority Domain Example (CSS-FD/FMDS)

Figure 7 depicts a mission user—an Airline Operations Center (AOC) dispatcher—accessing

Common Mission Services through a more complex arrangement of applications and services orchestrated to provide flight planning and filing services, as well as interacting with other NAS services. In this example, access to Flow Management Data and Services (FMDS) as a service is provided in much the same way as the other examples but depicts the interaction among services as defined for the purpose of providing a NAS function to one or more applications or systems.

Figure 7: Cross-Authority Domain Example

In Figure 7, the Mission Service and Common Mission Services are nested in the same way as in the previous examples (Figure 5 and Figure 6) to demonstrate the concepts of those services being operated as independent services or as composite services, either within the same authority domain as the mission application or indirectly between multiple authority domains. Common Mission

Services are managed by separate programs but utilized across authority domains to support one another’s service offerings. Specifically, the AOC accessing flight planning functions within CSS-

FD is able to take advantage of the trajectory service offered by FMDS to better support their

Trajectory Based Operations (TBO).

2.2.2 Service Analysis of CSS-FD Example

As part of this analysis, the CSS-FD architecture was analyzed with the new definitions and concepts applied to the architecture to demonstrate the relevance of the Common Mission Service considerations (Figure 8). During the analysis, the Globally Unique Flight Identifier (GUFI) service was identified as an independent Mission Service, which has potential to become a future

Common Mission Service if exposed via API to other users.

Figure 8: Example for Common Mission Services Within CSS-FD

Note that Figure 8 provides a high-level example of CSS-FD applying a notional AES context and architecture. As a tenant program, CSS-FD would define and develop the Common Mission

Services with the system architecture. The Common Mission Service then becomes available through an API Gateway. . Currently, the FAA has developed governance for the Compute and

Platform layers of the AES architecture. As this governance matures, it will also include overseeing the requirements, implementation, and integration of Common Mission Services in the

NAS.

2.2.3 Service Analysis of NAS Common Reference (NCR)

This analysis delved into the inner workings of the NCR architecture to understand the subcomponent structure and identify how a service offering could leverage the AES layers in a future notional architecture. NCR was developed as a service to enable customized requests for status and constraint data available through SWIM. Examples include status data such as Runway

Visual Range (RVR) for airports and Terminal Area Forecast (TAF) weather reports. Examples of constraint data include Ground Delay Program (GDP) and Special Activity Airspace (SAA).

NCR ingests data from multiple SWIM producers across NAS domains, such as aeronautical, weather, and traffic flow management (excluding flight-specific data). The service then parses messages and stores attributes in a Geographic Information System (GIS)-enabled database, including geo-referencing of all message elements. It also performs data transformations, such as translating between units of measure or Coordinate Reference Systems (CRSs). The service provides flexible combinations of geospatial, temporal, and attribute filters for users to tailor requests (i.e., queries) for correlated subsets of SWIM data. NCR also supports both one-time (i.e., request/reply) and recurring (i.e., publish/subscribe) queries.

Figure 9 shows the NCR architecture provided by Volpe with additional colorization and overlays to incorporate the definitions of AES. It is important to note that NCR was originally developed before the concepts of AES were established and, therefore, uses terminologies such as Computer

Software Configuration (CSC) and Computer Software Configuration Item (CSCI). These are software components that may be developed using various software implementation paradigms, one of which could be microservices. Since this development precedes microservice and AES concepts, the analysis focuses on the interfaces and functionality that could be provided by the platform layer if NCR was developed today utilizing AES.

Figure 9: Service Analysis of NCR Architecture

Figure 9 depicts the Mission Application accessing the web services via a “web services gateway,” which is equivalent to the API gateway. The “pub-sub services” are Common Mission Services providing publication of NCR data. The “geospatial server” is also a Common Mission Service that provides a request/reply API to consumers. It is also outlined in a colored border, depicting that reuse of a platform service offering to provide the geospatial service functionality. The “GIS data base” is also a platform service since it relies on open-source or COTS database functionalities. Platform monitoring tools can be used to monitor this and other platform services.

“Message archive” and “monitor and control” can be considered enterprise platform service functions. The rest of the internal functions may be considered Mission Services, which all fall under the governance of the NCR authority domain. Please note that, fundamentally, the Enterprise

Platform team is responsible for monitoring, logging and reporting platform services.

Figure 10 depicts the infrastructure deployment methodology provided by Volpe. Since these functions are deployed individually in separate containers, they could also be deployed in separate cloud compute instances. The color markings differentiate the categorization of each function as either a Mission Service, Common Mission Service, or platform service. The infrastructure in which these are deployed could be provided by the AES Computing Resources Layer, rather than a hardware deployment as described in NCR.

Figure 10: Service Analysis of NCR Deployment Architecture

Overall, NCR depicts useful decomposition of their software functions, which, if developed in the future, could be incorporated as separate Mission Services, Common Mission Services, and reusable platform services. The goal of this analysis was to demonstrate how to identify these opportunities for future service analysis and development.

2.2.4 Service Analysis of Notional Conflict Probe Service

An analysis was performed on the Conflict Probe Service [239][240], which is a Research and

Development (R&D) project developed by MITRE for NextGen. In this analysis, a notional architecture was created to represent the Conflict Probe Service, a corresponding authority domain, and an application domain. Figure 11 depicts the Conflict Probe Service as a Common Mission

Service, which exposes an API for conflict probe requests. Note that the purple coloration in Figure

11 represents platform service capabilities. While the Conflict Probe Service is not currently a

Common Mission Service, it demonstrates the opportunity for this service to become a Common

Mission Service for multiple users outside of its current authority domain.

Figure 11: Notional Architecture for Conflict Probe Service

3 Sharing Mission Service Functionalities

3.1 Microservices vs. Service-Oriented Architecture (SOA)

Microservices and SOA are inherently different when it comes to sharing of service. SOA is built on the concept of a share-as-much-as-possible architecture style, whereas microservices architecture is built on a share-as-little-as-possible architecture style. Component sharing is one of the core tenets of SOA as it relates to enterprise services, which promote sharing of services across the business. Although the concept of a share-as-much-as-possible architecture appears to solve issues associated with the duplication of business functionality, it also tends to lead to tightly coupled components and increases the overall risk associated with change. Microservices architecture, on the other hand, leverages a concept from domain-driven design called a bounded context. Architecturally, a bounded context refers to the coupling of a component (or in this case, a service) and its associated data as a single closed unit with minimal dependencies. A service designed this way is essentially self-contained and only exposes a well-defined interface and a well-defined contract.

One way to achieve a bounded context and minimize dependencies is replicate common functionality across services to achieve total independence. Another way is to compile relatively static modules into shared libraries that service components can use in either a compile-time or runtime binding. In doing so, maintaining services becomes easier by reducing modules on which the service depends and allowing services to change and evolve independently from other services.

Deployment becomes much easier as well because there is less code to deploy and also less risk that a change made to one module or service will affect other parts of the application (i.e.

proliferation of different versions of theses libraries). This, in turn, creates more robust applications that have fewer side effects based on service changes [238].

Determining the size and scope of a service is a critical design decision that can significantly affect overall system complexity and performance. In a microservices architecture, a crucial element of services is that they should be designed based on a business capability, serving a specific business purpose, and their responsibilities should be well-defined. Coarse-grained services (e.g., web services in an SOA context) or fine-grained services (i.e., services built for a specific technical capability that do not map to a business capability) may not be a suitable fit for microservices.

Business functionality and scope should drive the required sizing of a microservice. Additionally, making services too small is considered an anti-pattern. Insights can be derived from concepts such as Single Responsibility Principle (SRP), Conway’s Law, Twelve Factor App, and Domain

Driven Design (DDD) and are useful in identifying and designing the scope and functionalities of a microservice. If Mission Services are designed according to technical capability or too fine-grained, the number of dependencies between services in different authority domains can become too significant to manage and could result in what is commonly known as a “big ball of mud,” an anti-pattern that should be avoided [205][212][213][214].

In summary, while at first it may appear that microservices is counterintuitive as a share-as-little-as-possible architecture in the context of AES, they may support the development of new capability by reducing dependencies between services that do not necessarily need to become Common

Mission Services. For example, a microservice provides a self-contained software functionality.

This functionality can be deployed multiple times as an independent mission service in a larger integration of several other mission services. The result is a composite service made up of microservices, which can be exposed as a Common Mission Service via SOA. This represents a hybrid use of SOA with microservices constructing the composite service offerings. For additional information about microservices or Service-Oriented Architecture, please see Appendix A for referenced materials and definitions.

3.2 Considerations for Reuse

Software reusability is a key consideration for AES. In considering reusability, caution must be applied to evaluate all tradeoffs associated with reuse and the implications and complexities of distributed architecture, to avoid adverse outcomes downstream in the enterprise architecture.

Software reuse requires a thoughtful approach but is deemed necessary for robust and maintainable systems. In the context of Common Mission Services, reuse of common mission services is attained through exposing of the APIs to other authority domains while still being maintained and operated by the original owner. This is desirable from an enterprise perspective because it ensures software updates, security patches, and API changes are kept consistent by a single authority domain.

Please note that not every Mission Service functionality should be exposed as a Common Mission

Service. Other approaches for reuse may be more appropriate depending on the use case, and the tradeoffs should be considered first. If functionality reuse is required, some techniques for managing code reuse within a distributed architecture include source code sharing, shared libraries, shared service, sidecars, and service mesh. Software architects must identify reuse strategies. In general, developers should try to limit the amount of code reused within distributed architectures.

It should be noted that code reuse does not make a Common Mission Service. A Common Mission

Service is always maintained and operated by the designated authority domain and exposed via an

API through service sharing. A well-defined API can abstract implementation details and allow small service changes to reduce impact on users.

As such, a service with a well-defined API can abstract the implementation details for each distinguishable capability. While it does not protect the enterprise from changes in the business logic of the software, through careful design, architects can limit the occurrence of breaking changes and brittleness in architecture. One way this can be managed is through an API “contract” in which both an old API and new API can coexist until legacy users transition to the new API.

3.3 Considerations for Common Mission Services

A Common Mission Service accessed via an exposed API is sensible when it can reduce duplication of software development effort and ensure consistency of data from the most authoritative source. The shared service preserves the bounded context in cases where shared code changes frequently and operational characteristics such as performance, scalability, and availability suffer.

Reuse can be avoided by placing common functionality in a separately deployed service. Figure

12Error! Reference source not found. illustrates a proper way of sharing capabilities—C1, C2, and C3—via a shared service to be used by services A, B, and C, respectively, by exposing an

API. Considerations associated with using shared services include change risk, i.e., the risk that changes made to a shared service would affect downstream users. It should be noted that a change to a shared service is a run-time change, as opposed to a compile-based change using a shared library technique. If uncoordinated, a change in a shared service can effectively bring down an entire system. This should be considered when designing a Common Mission Service and is a lesson learned from service sharing in SOA. It is generally a good practice to use API endpoint versioning to create a new endpoint to separate each shared service change.

For reference, AES interface and configuration management of public APIs will be addressed by a future API Style Guide and the ATO Cloud Infrastructure Configuration Control Board (CCB).

The CCB is an oversight body, comprising many FAA stakeholders with varying roles and responsibilities. The main function of the board is to serve as an advisory, referral and coordination body among FAA ATO Cloud Enterprise and tenant stakeholders. As such, the CCB will capture, approve or deny action requests or APIs. Currently, the FAA is defining guidance for long running service calls and other performance-related concerns.

Figure 12: Shared Services Model

A concern for shared services is that performance may be impacted due to network and security latency. General-Purpose Remote Procedure Call (gRPC) and other asynchronous messaging protocols can help mitigate some of the performance issues by significantly reducing network latency. If a service is shared as a Common Mission Service, as other services come to depend on the shared service, the service must be able to scale to support added users. Scalability can be challenging to manage, particularly with multiple services concurrently accessing the same shared service. Another concern is fault tolerance. If the shared service becomes unavailable, services requiring the shared functionality may be rendered inoperable until the shared service becomes available again. In conclusion, due to downstream effects of service sharing, careful consideration should be given in how a Common Mission Service is designed and implemented.

4 Service Discoverability

The goal of AES is to support the sharing and reuse of service offerings and software functionality, and to do so, potential service implementers need to know what current offerings are available.

Service discoverability refers to identifying suitable services using tools and information provided to a service registry, which is searchable by users to discover details about a particular service or function. This process of service discovery is similar to an investigative process (see Figure 13) and service owners should provide the details to simplify discovery. This means not only providing details about the already exposed Common Mission Service, but also providing the details around the functional service components that could be reused through the sharing techniques described previously.

Figure 13: Service Discovery Example

4.1 Service Descriptions

Service descriptions provide sufficient detail for a potential user, consumer, or new service developer to identify service functionalities and whether the scope of the function fits their requirements. The following list is a minimum set of data elements to support discoverability of services.

• Service name

• Environment (e.g., Mission Essential Operating Environment (OE))

• Authority domain

• API, Extensible Markup Language (XML)/JavaScript Object Notation (JSON)

• Security

• Dependencies (i.e., composite vs. independent)

• Terms of service (e.g., sharing, licensing, etc.)

• Point of contact/organization

• Functional description documents/artifacts (e.g., Department of Defense Architectural

Framework (DoDAF) SV-4)

• Performance characteristics

• Resiliency and Reliability, Maintainability, and Availability (RMA)

It is important that enough detail about the service that stakeholders can identify reusability of a service or its service components. Figure 14 depicts a related entities map of service entities and how they relate to a service component. This view is part of an enterprise tool called a service registry that supports discoverability.

Figure 14: Example of Service Entity Relationships (Port)

4.2 Service Registry

A service registry is an enterprise tool that supports discovery of Mission Services and applications. It is meant to be a Human User Interface (UI) and provide good User Experience

(UX) to enable discoverability easily and effectively. The aforementioned service descriptions and documents are stored in a service registry and repository and made searchable by attributes. The

FAA currently provides a NAS Service Registry and Repository (NSRR), which provides a tabular catalog of SWIM services, data producers, and documentation.

One of the challenges for maintaining a registry is ensuring the information stored in the registry is consistent and current. Figure 15 shows an example of a service registry product, Port, which depicts current information about a service supported through plug-ins and API hooks to maintain the latest information. If information in the registry is not reliably current, the result is distrust in the information amongst stakeholders and lack of adoption. If this occurs, stakeholders may choose not to consider the provided information or contact system owners directly to ask questions, expending significant time and resources.

https://nsrr.faa.gov/

Figure 15: Example of Service Registry (Port)

Appropriate access to the registry is also necessary to ensure cohesive use by FAA service users, developers, and researchers. Furthermore, fine-grained access control should be provided to ensure users do not have technical information that does not pertain to their operation. In the past, all information in a Data Information Document (DID) would provide details about all the types of information contained in a publisher, even if that information was not propagated to public distribution due to Sensitive Unclassified Information (SUI) rules. The result, however, was consumers requesting information that was unavailable to them. This scenario should be kept to a minimum through use of fine-grained access and policy enforcement.

Hosting of the registry should be managed from a centralized location, such as the Administrative

OE (A-OE) network to ensure easy maintainability and updates from all other OEs. This means that future service developers should be able to provide automation points back to the registry service to maintain current updates, bug reports, logging, and other useful data relevant about the service. Figure 16 shows an example of another service registry provided by Atlassian called

Compass, which depicts service…