Services and Capabilities Architecture

FAS-IT architecture starts with a Services and Capabilities Architecture that is tuned to meet the needs of FAS. As you can see, the entry point is through a User Access layer that exposes generalized Business Services such as contract writing, financials, sales, and the like. These business services reach down into FAS systems such as Fleet, PPM, CRM, and CALM. Lastly, data is shared into a data lake where analytics and other data processing is accomplished from which visualizations and reports are supplied. This architecture provides the context and informs all FAS-IT architectural practice.

This conceptual view of FAS systems and the context around them was developed several years ago to provide a simple, yet holistic view of how the modernized systems could support the FAS business architecture through an ecosystem of an Enterprise Data Architecture, set of shared services, and API and microservice architectures.

The FAS Business Services are comprised of capability-based services grouped according to their function. If you were to look at GSA in general, and FAS in particular, you would expect to see systems that enable contract writing, e-commerce, product acquisition, and managed services, such as fleet, transportation, and travel management. Integral to the business operations would be basic business functions such as financial, communication, sales tracking, and customer management that would support and integrate with the forward-facing systems. These capabilities would comprise a layer that different kinds of users would interact with to do their work.

Supporting these capabilities are the actual systems FAS and GSA IT has developed or is modernizing to manage different parts of the enterprise. It is in this layer that you will find systems such as Fleet, PPMS, FSS-19, CALM, Catalog Management, GSA Advantage, etc. These are labeled "Core Systems" in the diagram above because they consist of an aggregation of business capabilities to operate as a complete functional entity for that business.

The lowest layer identifies the various data stores driven by the Enterprise Data Architecture creating the assets and authoritative data sources that power FAS business.

This view, updated as modernizations become more solidified, has served FAS well through the years, communicating a business architecture that all of the technology-focused architectures should align with.

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.