Skip to main content

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS
A lock ( ) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

Share your experience with the FAS IT-Playbook by taking this brief survey

Conceptual Architecture

In this section of the Playbook, we set the stage for the pictorial representations created of each of the major system architectures, providing a high level set of the systems represented.

Conceptual Architecture

Since the cloud is a rapidly changing and moving target, we seek to have an "architectural horizon" in sight,- a "North Star"- if you will. This horizon is useful in that it gives us a point of reference that we can steer our current efforts towards. This allows us to be wise in selecting helpful technologies now as well as plot the course for various development efforts going forward. For instance, most of our transactional systems have a course plotted that starts with the EBTA (everything-but-the-app EC2 based stack) and heads toward adoption of containerized micro-services. Beyond that are the promises of agent-oriented and event-driven systems with messaging, push technologies and business events that will animate the enterprise by allowing it to listen-for and respond-to things that are happening in and around it. A cloud-native solution is truly different than the packaged libraries that many of us are very familiar with. Instead, the cloud provides services that, when used properly, will break apart applications and database and replace them with functions, APIs, data stores and analytical methods among other things. The cloud is an "eco-system of services" that when used together will accomplish:

Security

High Reliability

Solid Performance

Operational Excellence

Cost Effectiveness

These are the five pillars of the AWS Well Architected Framework and these provide the sieve through which all proposed and existing architectures must pass.

As stated above, FAS-IT has an architectural horizon in mind. The goal of this target architecture is to maximize the effectiveness of FAS systems to meet business needs and desires. To achieve this end, we know that development efforts now have to be shaped in such a way as to support this end state. For instance, we are promoting the idea that systems should be decomposed and realized through micro-services from capability-based components. This has the benefit of encapsulating functionality today in such a way that when the eventual state is achieved, the APIs for capabilities can be refactored to use new "managed" capabilities when they come available.

Here is a close up of a longer-term vision that continues to evolve. There are several things to notice on this diagram which can be broken into several talking points:

  1. Separation of Operations and Analytics: There is an operations and an analytics side to the FAS solution. The operations side represents a transactional system where data is essentially put in and pulled out to support transactional systems. It is the live side and the data contained in the Operations side is considered the single source of truth in that it is authoritative and always up to date. The analytics side, on the other hand, is responsible for processing, packaging, gleaning insights, and storing data in up to a near-real-time fashion. It supports the business by providing analysis, predictions (via machine learning) and reporting.
  2. Systems are Composable: The various systems at the top of the diagram use the APIs exposed by both Operations and Analytics and only house functionality and data that is peculiar to that system. For instance, Fleet has a capability that could be called Leasing. Unless other systems need to "lease" something, then that capability might only exist within Fleet.
  3. Service Oriented: Please notice that both the Operations and Analytics partitions are exposed via APIs. This provides a layer of redirection that provides flexibility in the functionality that is fronted. So a capability component or an analytics artifact can be changed without impacting the systems that use the APIs. Similarly, this pattern should be used throughout, though it is not pictured, so that component parts are more simply modified as technologies and other aspects change "under the hood".
  4. Data services should be "right sized": The cloud offers the opportunity to use situationally appropriate data storage and interaction services. For instance, a relational database might be the best solution when the system contains highly structured and relational data where a document database might be best for driving web-pages or storing data that is either semi-structured or unstructured (i.e., schema-less). On the analytics side of the house, a host of database endpoints might be in place to maximize performance, durability, etc. to meet defined SLAs.
  5. Data needs to be understood well: A data catalog is wrapped around the operational and analytics portions to show that the data contained within these two parts is well understood and defined.