Technical Architecture and Review

For those teams interested in a cloud solution, AEA engages early in the inception phase of a project. This engagement can start as the Enterprise Business Case is being developed. Our intent is to help the business articulate what they need to support funding decisions. Once the business case is approved, we help to shape the requirements for the "call order". Once the work has been awarded, AEA remains engaged in evaluating and confirming vendor-proposed architectures.

Throughout our engagement processes, our goal is to understand what is needed in order to design an architecture that will meet the needs.

1. Collection:

2. Requirements

3. Drivers
4. Constraints
5. Goals

6. Use Cases / User Stories

7. Deliverables

8. Conceptual architecture

9. Identified capabilities
10. Service oriented architecture
11. Workflows and business processes
12. External system dependencies
13. Other items (based on system types and features)
14. Completed Cloud Enablement template

When engaged, we routinely work through scope, requirements, drivers, etc. to fully understand the systems/software that need to be developed. The focus of the inception phase is to understand the business challenges and to derive a solution that will meet expectations. Once the solution is fully expressed and agreed upon, it is presented to the Cloud Enablement team. This team reviews and elaborates the solution for the FAS cloud environment. In the end, the goal is to provide a solution that has the appropriate balance of:

• Security
• Cost
• Reliability
• Performance
• Operational Excellence

To illustrate the engagement patterns, examples are provided below.

For reference, the FAS-IT macro-patterns are provided. These are used to aid in the discussion of component parts of transactional and analytics systems.

For more information on these patterns, please see the Architecture Strategy page.

EBC Support Example: Authoritative Catalog Repository (ACR)

The Catalog Management project desired an architecture that would help migration of the system to the cloud environment. The team wanted to plan a small substantive step that would set the stage for much of the integration work they wanted to postpone until later. A conceptual technical architecture was developed and socialized with the Cloud Enablement team.

The following architectural diagram shows the establishment of a Production Catalog with it's API in the cloud. Optional work is also identified where ACR would have a cloud ingestion path. The Catalog API would provide an endpoint for all using and destination systems to call which would require appropriate changes on their part. Eventually the plan will be to migrate CORS, SIP, EDI and the CO Holding Store subsystems to appropriate cloud entities once the Authoritative Catalog Repository (ACR) is established and operating.

The ACR EBC was approved and is now ready to go out for bids.

Call Order Support Example: Fleet Serverless Proposal Evaluation

The following diagram represents an evaluation of a proposed architecture for Fleet. By mapping the prospective architecture to our transactional architecture macro-pattern, we were able to clearly identify several gaps that needed to be addressed (added). While those components might not have been overlooked, they were not sufficiently elaborated.

This is only one layer of scrutiny in that it only identifies how certain aspects of a complete architecture are planned. Once the mapping is complete, it is also important to explore the adequacy of the planned solution parts. In the diagram above, you might ask why Lambda functions should be used instead of more integrated components running on containers. Since maintainability is a key objective, how would the host of Lambda functions be managed. These are the kinds of questions that follow the mapping exercise; mapping definitely helps to focus these secondary conversations.

Proposed Architecture Evaluation Example: PPM

When we evaluated the proposed architecture for PPM we found only a couple of things missing that needed further elaboration. First, they needed to add a CRUD layer so that data calls would not be embedded in the component layer and make adoption of improved database functionality difficult. Second, the Analytics and Reporting architecture needed elaboration. It was generally missing. We supplied our Analytics Engine macro-pattern and they were able to update their document with an appropriate design.

Here are the two architectural components that were supplied by the PPM vendor. These were vetted against the FAS-IT macro-patterns and adjustments were made.

And here is the Analytics architecture for PPM.

Though these architectures call out the technologies desired, if you have familiarized yourself with the Transactional and Analytics macro-patterns, you will see there influence in these diagrams.

O&M Effort Support Example: SmartPay

The SmartPay system is a rather small system that had requirements that differed from the normal transactional system and therefore might be interesting to introduce here. Essentially, SmartPay ingests data from two private data sources and stores it for searches from within and without GSA. It's requirements were generally:

1. It must house but not expose PCI-DSS (payment card) data; i.e., credit card information
2. O&M costs needed to be kept low
3. Terabytes of data needed to be searchable with a 7 year sunset
4. Data sources needed an interface to deposit data

Given those requirements, a simple data lake solution was proposed that would be completely serverless (i.e., using managed AWS services). This is a specialization of the Analytics Engine macro-pattern which elaborates on the planned ETL, security, search and storage mechanisms.