Attachment_J___Task_Order_0003__FSA_Enterprise_Architecture_Program__Activity_4_Goals _Objectives _Qualities_and_Validation.pdf

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and

Validation

Enterprise Architecture Program

ED-FSA-16-R-1234 Task Order: 0003

Goals, Objectives, Qualities and Validation

Scenarios

Version 00.00.10 • 9/8/2015

Revision History

Version Date Name of Author Summary of Changes

V00.00.03 2/26/15 FSA Revised after 1/23 submission to incorporate FSA feedback. 5

Th outcome added 2/12. Further formatting done 2/26.

V00.00.04 3/18/2015 FSA Initial enhancement of Desired Outcomes (later called Goals) and Objectives for ISE.

V00.00.04 3/24/2015 FSA Tweaking Desired Outcome and Objectives for API

V00.00.04 4/6/2015 FSA Adding Qualities to Objectives

V00.00.05 4/14/2015 FSA Minor edits

V00.00.06 4/23/2015 FSA Incorporating Core Team comments from 4/17 meeting, and 4/22 comments.

V00.00.07 5/22/2015 FSA Incorporating initial Extended Team comments from 5/12 meeting.

V00.00.08 6/19/2015 FSA Incorporate Business Team comments from 6/8 meeting.

Additions for NSLDS and Continuous Deployment

V00.00.09 7/13/2015 FSA NSLDS Core Team Iteration Additions

V00.0010 9/08/2015 FSA NSLDS Business Team revisions. Further edits

Table of Contents

1 Executive Summary

2 Introduction

2.1 PURPOSE

2.2 PROCESS

3 Goals for FSA Systems

3.1 GOAL 1

3.2 GOAL 2

3.3 GOAL 3

3.4 GOAL 4

3.5 GOAL 5

3.6 GOAL 6

3.7 GOAL 7

4 Associated Use Cases

5 Objectives and Qualities Associated With Goals and Categories

6 Logical Solution Architecture Diagrams

7 Appendices

7.1 APPENDIX A: ACRONYMS AND DEFINITIONS

1 Executive Summary

This document contains high-level business goals, lower level technical objectives to support meeting those business goals, qualities that further define the technical objectives, and use cases/validation scenarios to check that a goal has been met.

These are intended to support FSA application system procurements, by increasing consideration of solution architecture in those procurements.

Goals, objectives and qualities do not replace requirements, they augment them. The seven goals are not a complete list of all FSA goals, rather they are a subset where IT architecture can have a positive influence in meeting those goals.

These goals and objectives were developed by reviewing three current FSA application systems, CPS/FAFSA, ISE and NSLDS. By reviewing three different application systems, the resulting goals and objectives are more generalized and applicable generally to FSA application systems.

For a high-level review, review the “Goals for FSA Systems” section. For further detail, review the lower level technical objectives in the “Objectives and Qualities Associated With

Goals and Categories” section.

High level logical solution architecture diagrams for the three application systems reviewed, CPS/FAFSA, ISE and NSLDS are in the “Logical Solution Architecture Diagrams” section.

For the ISE application, we considered content management without transactional work;

transactional work is currently handled by other applications.

2 Introduction

2.1 Purpose

The purpose of determining, analyzing and documenting Goals and Objectives is to create a means for evaluating alternative architectures. While this exercise was initially specific to CPS/FAFSA, and was continued for other FSA systems (ISE and NSLDS were examined after CPS/FAFSA), the process can be used for any comparison or evaluation of alternative architectures or solutions.

This exercise should be generally useful for FSA at multiple points in the life cycle of a system. Goals and

Objectives in this document may directly apply to other projects. Minimally they could be a starting point for other projects. The Objectives were initially rather more specific to the first system examined, CPS/FAFSA, but as Objectives were extended from reviewing multiple systems, they become more generalized and could also serve as a starting point for other projects or be FSA-wide Objectives. The

Objectives are in support of the Goals; a change in Goals should be reflected in changes to Objectives.

The Core Team members who developed these Objectives, and this process, were influenced by the

ATAM paper (see Appendix A). This process was modified based on Core Team member’s experience with systems, and what was seen to be missing in existing system lifecycles.

These Goals and Objectives do not replace requirements; they augment them. They add more consideration of system architecture beyond what a set of functional requirements may.

Within a procurement and evaluation of proposals, Goals could become Factors and Objectives could become Sub Factors.

An analysis of how a proposed architecture or solution meets a set of Objectives will result in a set of

Strengths, Weaknesses, Deficiencies and Risks. This is essentially asking how a solution meets an

Objective and if it does it very well, adequately, is not able to meet the Objective, or meets the Objective, but with some risk. When the results are combined with those of other evaluators, peer reviewed and discussed, the result can be a group rating of:

Blue: A solution with significant strengths, no or very minor weaknesses, and no deficiencies.

This architecture or solution provides a superior value with minimal risk.

Green: A solution may have some strengths, has some weaknesses, and no deficiencies.

Yellow: A solution with one or more weaknesses, but weaknesses that could be mitigated.

Weaknesses could be mitigated with careful oversight, but this requires additional Government interactions and risk.

Red: A solution with significant weaknesses or one or more deficiencies, representing significant risk to the Government.

Such an evaluation should be defensible by tying the evaluation back to how alternative solutions met the

Objectives.

The above discussion is focused on procurements, but determining and documenting Goals and

Objectives can be done at any point in the lifecycle to evaluate alternatives. For CPS/FAFSA, and ISE we considered four possible solution stacks against the Objectives, in advance of a procurement.

Sharing this information with potential bidders should result in higher quality proposals that better meet

FSA’s needs, and employ technologies consistent with other FSA application systems and FSA Target

State architecture. Sharing Goals and Objectives in advance of a procurement can also “level set” the proposals – since they all have to respond to the same Objectives – making evaluating proposals easier.

During the very early phases of development a more detailed application architecture should be developed. That architecture, or perhaps several alternative detailed application architectures, could be evaluated against the Objectives to determine a preferred alternative.

2.2 Process

2.2.1 Summary

Two (2) activities (creating two work events) were used to analyze and document the four (4) stacks that will be considered for use by FSA to process applications for Student Aid, replacing the current systems, CPS/FAFSA (NEO). These were revisited again for ISE and NSLDS. The two activities were:

A process to research and document key technical Objectives (not complete requirements), with associated Qualities and validation scenarios (Use Cases). These were mapped to FSA’s goals.

A process to develop a high-level solution design that meets the Objectives, and research and document Strategic Architecture Alternatives/solution stacks from several software/support vendors, and evaluate these against the key technical Objectives.

These processes will be more fully explained in a future document.

2.2.2 Developed Goals, Objectives, Qualities and Validation Scenarios

What Are Goals, Objectives, Qualities and Validation Scenarios/Use Cases?

The terms Objectives, Qualities and Use Cases are from a paper titled “Use of the Architecture Tradeoff

Analysis Method (ATAM) in Source Selection of Software-Intensive Systems”. As we worked with the

Objectives and Use Cases within the Core Team, we added “Goals” as something at a higher level than an Objective, and particularly meaningful to the business, while Objectives were more technical and are needed to meet a Goal.

We define Objectives, Qualities, Use Cases and Goals as follows:

Objectives: Should be meaningful and clearly indicate some level of success or importance to the business or technology groups; should be observable and/or measurable.

Qualities: The qualities of an Objective that the design should address; these serve as a scoping mechanism for evaluating the design. The quality attributes should provide insight to the design team by identifying the most important qualities of the solution they need to address.

Use Case (aka Validation Scenario): A “Validation Use Case” is an example that the design team can run through to demonstrate that their design achieves the identified Objectives and exemplifies the identified quality attributes of the Objective. A “Single Use Case” can be used to validate multiple

Objectives. Each Objective must should at least one “Validation Use Case” identified.

These definitions were extended to include:

Goal: A high level business outcome that was clearly desirable to the business stakeholders, in the case of CPS/FAFSA and ISE, with Customer Engagement. Goals should resonate with business stakeholders more than technical Objectives.

The meaning of “Use Case” was altered to tie back (map) to a Goal rather than an Objective. This limited the number of Use Cases desired.

Using a multi-tab spreadsheet as an analysis tool, and multiple discussions within a core team, an initial list of Objectives was extended. FSA goals and enterprise architecture goals were reviewed and the

Objectives mapped to them. Objectives were reviewed against the categories developed from a

CPS/FAFSA Target Solution Architecture diagram to check that each Objective could be mapped to a location(s) in the target solution architecture. The same categories were reused for subsequent application systems analyzed.

Objectives were tied to Goals. Goals are high level business objectives, while Objectives were the technical Objectives that supported those Goals.

There was useful “back and forth” between Goals and Objectives, Agency Mission and Goals, Target

Architecture Goals, and the categories from the Target Solution Architecture.

This work was initially done within a Core Team, then peer reviewed and enhanced with an Extended

Team, and then reviewed and enhanced with a Business Team. These iterations were repeated for each application system analyzed. The resulting Goals, Objectives, Qualities and Validation Scenarios are in this document.

2.2.3 Target Solution Architecture

With Objectives in mind, a logical target solution architecture was developed and refined, for each application system examined. This target solution architecture resulted in a three level breakdown into categories, which in turn became the rows in the solution stack. This is detailed in the accompanying document, A4-Solution Architecture v00.00.12, while simplified two level breakdown versions of these diagrams of the CPS/FAFSA Solution Architecture, the ISE Solution Architecture and NSLDS Solution

Architecture are in https://fsa.share.ed.gov/teams/to/EITASIG/EAProgram/Shared%20Documents/4.%20Solution%20Architecture/A4-Solution%20Architecture%20v00.00.12.docx

Figure 1 Logical Solution Architecture Diagrams.

The Goals and Objectives are mapped to the high-level categories (boxes) in that CPS/FAFSA Solution

Architecture diagram. The high-level categories from the ISE and NSLDS Solution Architecture diagrams were a subset of those from the CPS/FAFSA Solution Architecture diagram; the categories from

CPS/FAFSA were reused for the subsequent application systems.

3 Goals for FSA Systems

There are seven major Goals sought in future versions of FSA Systems. These are listed in Table 1 .

Goals for upgraded Systems (CPS/FAFSA, ISE and NSLDS)

1 The user (student, parent, partner) experience evolves and improves over time leveraging technologies to simplify user interactions across an ever-changing landscape of user interface technologies and devices.

2 FSA can deliver new or improved transactional services leveraging complex edits and business rules quickly and cost effectively.

3 FSA systems are continuously improved and updated over time ensuring total replacement is not required when the contract ends.

4 Students and parents have the ability to access a single integrated web site (ideally using a single web address) to obtain information and complete transactions necessary to receive federal student aid assistance.

5 FSA manages enterprise static content consistently across client-facing systems and makes approved changes to static content consistently, across application systems.

6 PII is not released to unauthorized entities by any FSA application systems. FSA application systems are resilient to malicious attacks.

7 Award recipients can authorize the sharing of their data with trusted parties safely. FSA can receive transactional data from trusted parties.

Table 1 Goals

3.1 Goal 1

User Experience evolves over time: FSA leverages technologies to simply user interactions over time.

As new improved technologies become available, they are leveraged by FSA to improve and simply the user – student, those advising students, and partner -- experience.

3.2 Goal 2

Quick and Cost Effective Transactional Services: FSA can deliver new or improved transactional services quickly and cost effectively.

Application design separates functions and isolates where changes need to be made when adding new services or modifying existing services, such that these changes can be made quickly. Application development should use agile techniques to quickly code, test and deliver new or altered functionality.

3.3 Goal 3

Continuous Improvement: FSA systems are continuously improved ensuring replacement is not required when the contract ends.

During the life of a contract, code quality will be monitored, evaluated, and scored using code evaluation tools. Desired code quality metrics need to be met by contractors such that code quality – and resulting system quality – does not deteriorate as enhancements and changes are made to the system. All application code and information required to build an executable system will be available to FSA at any time during the execution of the contract. Applications/websites will be built with current versions of software. Software will be upgraded as releases or newer versions are available and deemed stable, and as older versions are no longer supported by the SW vendor. Where feasible standards-based software packages will be used instead of proprietary software, which is expected to have shorter lifespans.

3.4 Goal 4

Single Integrated Web Experience: Students and parents have the ability to access a single integrated web site (ideally using a single web address) to obtain information and complete transactions necessary to receive federal student aid assistance.

FSA would like to integrate other FSA applications into the ISE experience ensuring the user is not aware of any switching of physical websites as the user navigates through FSA functionality. Branding and other content will be consistent across applications/websites. These FSA applications would include NSLDS, StudentLoans.gov, Myeddebt.com, FAFSA.

3.5 Goal 5

Real Time Static Content Changes: FSA has the ability to make approved changes to static content in real time.

Static textual content and similar can be updated across the pages/applications/websites supported by different contractors, at the same time, without requiring a PRR and release, across all pages/applications/websites that present that content.

3.6 Goal 6

PII is never released to unauthorized entities; FSA applications/web sites are resilient to attacks:

All PII, regardless of who/what provided it to FSA, is never released to unauthorized entities by any FSA application systems. FSA application systems are resilient to malicious attacks, and resist test – and real

-- attacks without being compromised, or releasing sensitive information. Not all forms of attack can be handled immediately without impact, but attacks should be detected and appropriately responded to.

3.7 Goal 7

Award recipients can authorize the sharing of their data with trusted parties safely:

Students/award recipients can authorize the sharing of their data with registered and trusted parties through secured and managed web services. This could be authorization to a specific entity, for a specified timeframe and be withdrawn at the end of the timeframe. Such authorizations, revocations, and accesses should be logged. FSA can receive transactional data from registered and trusted parties, while not accepting updates from those not so registered and trusted.

4 Associated Use Cases

The Validation Scenarios/Use Cases to test for the above seven Goals are:

User researches student aid options, looks up their current aid awards, fills out a FAFSA.

FSA has a requirement to adjust or change some static content and publish that content in 60 minutes. This requires several systems to publish the revised content.

Contractors supporting application systems/web sites that use the above revised content are notified of revised content being available prior to go-live date/time and can verify their systems work with the new content, before they publish it to production. Contractors take the last step of publishing revised content after they have confirmed the revised content works properly on their system.

FSA would like to perform an independent inspection of the system, providing a fully functional developer environment to FSA’s agent with minimal or no support from the incumbent contractor.

Legislative changes require a rapid change to mission critical transaction functionality requiring change to the user interface navigation, capturing of additional data and changes to required edits.

Annual program changes have been identified and must be implemented before the beginning of the new award year.

Contractor provides an annual assessment of the quality and complexity of their solution demonstrating continuous improvement over time demonstrated by metrics that are tracked and trended over time.

Student authorizes a third party entity to access and use that student’s data, stored within an FSA system, for a specified timeframe. That third party has access to that student’s data for that specified timeframe. Further, the student can withdraw authorization at any time.

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and Validation

5 Objectives and Qualities Associated With Goals and Categories

In order to meet the Goals the following Objectives and associated Qualities were identified. These are presented in table format so that relationships between Objectives, associated Qualities, Goals, and where in the Logical Solution Architecture – the Category -- the Objective and

Goal are met, is clear.

System Category Objective Quality Goals

NEO, ISE,

NSLDS

Edge Caching 10. Web sites shall restrict traffic when demand exceeds capacity.

An ability like Akamai’s visitor prioritization capability.

(http://www.akamai.com/dl/product_briefs/product-brief-visitor-prioritization.pdf)

Quick and Cost

Effective

Transactional

Services

NEO,ISE.NSLDS Edge Caching 20. Static content of a site shall be identified and cached at the edge.

Edge caching technology services such as Akamai are fully supported.

Real Time Static

Content Changes

Quick and Cost

Effective

Transactional

Services

NEO,ISE,NSLDS Authentication 30. The solution shall enable a single sign-on experience allowing the user to sign-in once using a single credential set for all FSA services.

Web sites integrate with FSA’s single sign on capability using the PAS/AIMS solution for the appropriate end users. FSA User ID solution is integrated into the solution.

User session is maintained even if the entire content of the page is cached to the browser or edge service.

Full Audit trail of the types of services used during a session as the user navigates through the site – for example: FAFSA, Promissory notes, counseling etc.

After user logout or timeout, cache is cleared of all PII and transactional information.

Single Integrated Web Site http://www.akamai.com/dl/product_briefs/product-brief-visitor-prioritization.pdf http://www.akamai.com/dl/product_briefs/product-brief-visitor-prioritization.pdf

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and Validation

NEO,ISE,NSLDS Application

Security

40. Application security shall be externalized from the application using role based security.

The application will be enabled to accept a roles identifier from the external authentication system (AIMS or PAS) to apply authorization for access to page functionality.

The application will be responsible for fine-grained application authorization.

Single Integrated Web Site

NEO,ISE,NSLDS Web

Applications

50. The solution shall enable students and their parents to research and receive FSA services through a single integrated web site providing both content and transactional services.

Single Domain Name consistently displayed in the address bar.

Consistent branding (look and feel) while using that single integrated website, while portions of a page are coming from different systems.

Responsive web design making the solution capabilities easily accessible regardless of device size or display resolution, so supporting desktop, tablets and mobile devices

Broad browser, browser version and device support.

Easy to add support for new browsers, browser versions and devices

Smooth transitions as the user navigates the site

Context sensitive content after user sign-on status.

Additional menu choices may become available.

Account status or notifications may be displayed.

Centralized messaging or notification facility that can be leveraged by independent efforts through an API.

Single Integrated Web Site

NEO,ISE,NSLDS Web

Applications

60. An integrated and seamless user experience shall be created from the web sites integrating content and transactional functionality from independent FSA or trusted partner web sites.

FSA will have the ability to integrate separate and distinct web sites into the ISE in a seamless manner.

When a web site is embedded in ISE, that web site’s headers and footers will be suppressed.

All web sites will use a common CSS style sheet and other branding elements published and managed by SAOW from a central CMS. Branding updates will be versioned. All websites will use the same version.

Updates (Enterprise Style Guide Bundle) will be bundled, versioned, approved, and made available to client systems.

Similarly, content will be made available to other FSA social media channels.

All headers and footers will used standard HTML markup supplied by SAOW.

Separate and distinct websites will publish shared content from a shared/centralized CMS. They will be notified when revised/new content is ready for their systems.

Single Integrated Web Site

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and Validation

NEO,ISE,NSLDS Web

Applications

70. The solution shall enable rapid time to market and low cost delivery when extensive site changes/enhancements and branding changes are implemented.

Branding and formatting elements of the solution are externalized using technologies such as style sheets or skinning frameworks. These are centrally managed and stored in a CMS.

Centrally managed content can be verified to be 508c compliant.

Websites can pull shared content/branding from a shared/centralized CMS, verifying it works on their systems, before publishing to production

Enterprise Style Guide Bundle and documentation is provided to contractors starting new projects. Updates are pulled from the CMS, handled by change control.

Contractors/teams supporting websites are notified (approval workflows) when new/revised content is available. They verify it works on their systems and then publish, or work rapidly to correct minor content issues so it can be published.

When required, content is converted to the appropriate format or language for a specific application/website or channel.

Real Time Static Content Changes

Quick and Cost Effective Transactional Services

NEO,NSLDS Web

Applications

80. Edits shall be externalized and centralized ensuring they are written once and reused throughout the application.

All edits applied to data will be managed at a single source (such as a rules engine). Also, technologies such as the bean validation framework may be appropriate for this Objective as well.

Single Integrated Web Site

Quick and Cost Effective Transactional Services

Continuous Improvement

NEO,ISE,NSLDS Web

Applications

90. The solution shall ensure simple model view controller architectures are leveraged to simplify the programming model around single and multi-page forms.

The solution uses well understood patterns such as delegates or facades.

Each page (or multi page form) should have a single controller to populate the page data, process transactions, respond to Ajax calls and process actions requested by the page (page navigation, page closing)

When specific page navigation rules need to be applied, the solution uses a framework intended for this purpose.

Single Integrated Web Site

Quick and Cost

Effective

Transactional

Services

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and Validation

NEO,NSLDS Web

Applications

100. The solution shall ensure all web site transactions will support optimistic locking.

All web transactions will implement optimistic locking. If the data is changed by another before it can be committed, the user is informed that the data was changed while they were editing it and required to start over (their changes are lost)

Quick and Cost Effective Transactional Services

NEO,ISE,NSLDS Build and

Deploy

110. The solution shall provide metrics tracking and trending complexity and quality of the website code supporting the identification and reporting of results after refactoring project.

The solution can present trending reports indicating the complexity of the system over time and the impact of refactoring projects.

The solution can present trending reports indicating compliance to coding standards and best practices over time and the impact of refactoring project.

Continuous

Improvement

NEO,ISE,NSLDS Build and

Deploy

120. The solution shall ensure full suite of automated unit tests are maintained testing as many elements of the website including pages, java script, controllers and models

The solution tracks and trend the percent of the application unit tested.

Quick and Cost

Effective

Transactional

Services

Continuous Improvement

NEO,NSLDS Work Flow 130. The solution shall ensure that Workflow is externalized so Web App, API and Batch

Interfaces can leverage and integrate with the work flow engine regardless of implementation technology.

The workflow engine will integrate with the application’s business services layer and centralized rules engine to ensure there is no duplication of business logic.

Workflow can have integrated user interactions and automated work steps as long as all transactions are processed by the application’s layers business services to ensure there is no duplication of business logic.

Quick and Cost

Effective

Transactional

Services

Continuous

Improvement

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and Validation

NEO,NSLDS ESB 140. The ESB shall enable the

API and Business layers to implement functionality in a binding neutral manner taking the responsibility for proxying between disparate protocols.

(Note the standard binding protocols of the application will be the native bindings for the language(s) used in the solutions

At this time, FSA does not have a traditional ESB, but FSA would like to externalize all protocol proxying to the ESB layers as well as all security.

API’s should be developed in a protocol neutral way.

The ESB is responsible for managing the client protocol interactions and binding to the API implementation.

Quick and Cost

Effective

Transactional

Services

NEO,NSLDS Business

Services

150. The solution shall provide a simple business centric object model to ensure business rules are consistently applied to all transactional and non-transactional data establishing a simple well-defined set of transactional, stateless and loosely coupled services to execute enterprise level business functions.

The solution uses well understood patterns such as delegates or facades.

Technologies such Enterprise Java Beans (EJB) are used to manage transactions at the method invocation.

Technologies such as EJB’s are used to inherit transaction context form a parent object, if available.

Cycle neutral design eliminating the need to clone the business layer for each award year.

The layer is transactional with the ability for super classes to inherit transaction control, enabling business facades and/or aspects to support specialized functions such as batch, web services and security.

Single Integrated Web Site

Quick and Cost

Effective

Transactional

Services

NEO,NSLDS Business

Services

160. The solution shall ensure that business rules are externalized and centralized for easier management.

Centralize edits and business rules such that they can be leveraged both by on-line, batch operations and API operations.

Technologies such as rules engines or bean validation should be considered for externalization of business rules.

Use of a rules engine to capture and apply cycle specific edits and business rules enabling the Business and Data access layers to be award year neutral. (Note: the web layer is likely to remain award year specific).

Centralization of edits with re-use of the edits and business rules in the Web, batch and External Partner API layers.

Single Integrated Web Site

Quick and Cost Effective

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and Validation

NEO,ISE,NSLDS Business

170. The solution shall ensure that edits (field, cross field, page and transaction) are centralized and externalized from the application code.

Web page edits should not be coded in the web pages.

Frameworks such as bean validation and rules engines are good candidates for centralization and externalization of field, page and transaction level edits.

Externalization of business rules and data edits to ensure award year neutrality at the database and business layers.

Single Integrated Web Site

Quick and Cost Effective Transactional Services

NEO,NSLDS Business

Services

180. The solution shall implement a business layer centralizing all transactional processing.

Technologies such as EJB externalized the transitional responsibilities ensuring the calling program does not need to consider or manage transactional scope.

The architecture needs to solve for stateful and stateless transactions. EJB’s are well suited for this.

Quick and Cost Effective Transactional Services

Continuous Improvement

NEO,NSLDS Business

Services

190. The solution shall ensure methods in the business layer can manage their own transactional state directly or join a transition if called when the calling object is managing the transaction.

EJB’s should be considered. As well as supporting the stateless and stateful transactions.

Quick and Cost Effective

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and Validation

NEO,NSLDS Business

200. The solution shall provide multiple binding options to support batch units of work, API Security and native binding.

Enable multiple binding methods to the business layer enabling the following aspects:

o Through the use of batch façades, atomic transactions managed at the business layer can be expanded and controlled to create larger units of work for optimized batch processing.

o Through the use of a security façade, access to business layer transactions can be authenticated and authorized to support access by external partners.

o Through the use of business facades, larger complex transactions required by UI functions can be easily created using the more atomic business layer functions.

o Support for local bindings (native bindings) for highly efficient processing requirements such as batch and on-line processing.

o Support for remote binding (Web Services Bindings – SOAP, REST) for access by systems that run out of process to the business layer – such as external partners or internal systems. (Note: it is unlikely that remote interfaces will require remote transactional protocol support such as IIOP or RMI).

Traditional Enterprise Service Bus capabilities (ESB) are desirable but should not limit or constrain native binding and transaction management. (Note: Compensating transaction rollback needs to be considered for traditional ESB’s for when compound transactions are processed by an orchestrated flow).

Quick and Cost

Effective

Transactional

Services

Continuous

Improvement

NEO,NSLDS Business

Services

210. The solution shall ensure transactions support optimistic locking when called by the

Web or API layers.

Web transactions are intrinsically long (seconds). All transactions must implement locking. Optimistic locking is best suited for long running transaction.

Quick and Cost Effective Transactional Services

NEO,NSLDS Business

Services

220. The solution shall ensure transactions support pessimistic locking when called the batch layer.

Optimistic locking can generate considerable overhead.

When the business layer is accessed by batch programs, it must be able to support the alternate pessimistic locking strategy.

Quick and Cost

Effective

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and Validation

NEO,ISE,NSLDS Business

230. The solution shall ensure transaction methods can be instrumented and monitored real time.

FSA uses Wily as its real time. Transactions can be monitored using this technology.

Quick and Cost

Effective

Transactional

Services

NEO,NSLDS API 240. The solutions shall enable a security layer to authenticate and authorize access to external partners. (See

Security, also)

Solution is integrated with Participation Management that will be responsible for authorization of external parties to access web services.

Solution is integrated with AIMS ensuring authentication with FSA’s standard. DPA credentials are never to be used to access an API.

External partners will be provided with a variety of authentication mechanisms ensuring the right authentication mechanism for the access requirement such as Username/Password, Certificates and/or SAML

Authentication of partner facing API’s are authenticated from AIMS using the Partner Management system for provisioning of accounts.

Authorization of partner facing API’s are authorized using the partner management system.

Quick and Cost

Effective

Transactional

Services

Authorize sharing of data

PII is never released to unauthorized entities

NEO,NSLDS API 250. The solution shall enable

Internal and external binding protocols are managed by the

ESB.

Quick and Cost

Effective Transactional Services

NEO,NSLDS API 260. API methods shall be monitored real time.

Transactional Services

NEO,NSLDS API 270. API methods shall be throttled based on partner

SLA’s.

A single partner is not able to overload systems adversely impacting throughput and response times for other users.

Quick and Cost Effective

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and Validation

NEO,NSLDS Security 280. The solution shall ensure that outbound student data to approved partners is authorized by the student and access is controlled by the user. The solution shall enable a security layer allowing students and parents to authorize access and revoke access to personal data to external partners. Award recipients shall authorize the sharing of their data with registered and trusted party’s application systems through secured and managed web services.

The student has the ability to de-authorize a non-trusted partners access to their data at any time.

oAuth standard should be considered for managing data access permissions

Students and Parents have the ability to explicitly grant access to third parties (approved by FSA) to receive or submit data on their behalf to FSA using their FSA ID.

Students and Parents have the ability to revoke access to any information or services granted by them to third parties using their FSA ID.

FSA will have a full audit trail of activity related to authorized access to student and parent data by third parties.

PII is never released to unauthorized entities

Award recipients can authorize the sharing of their data

NEO,ISE,NSLDS Security 285. PII shallnot be obtained by anyone other than authorized means via the web interface, APIs, or other programmatic means. System shall be resilient to malware and DDOS attacks.

Systems successfully withstand tests run by security testing company.

PII is never released to unauthorized entities

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and Validation

NEO,NSLDS Security 287. FSA shall receive transactional data from registered and trusted party’s application systems.

Solution is integrated with Participation Management that will be responsible for authorization of external parties to access web services.

Solution is integrated with AIMS ensuring authentication with FSA’s standard. DPA credentials are never to be used to access an API.

External partners will be provided with a variety of authentication mechanisms ensuring the right authentication mechanism for the access requirement such as Username/Password, Certificates and/or SAML

Authentication of partner facing API’s are authenticated from AIMS using the Partner Management system for provisioning of accounts.

Authorization of partner facing API’s are authorized using the partner management system.

PII is never released to unauthorized entities

NEO,NSLDS API 290. The solution shall provide secure mobile friendly protocols for external partners

FSA will have the ability to provide secure access services using modern protocols that are mobile friendly including REST, JSON and web sockets.

Mobile applications (hybrid and native) will be fully secured when interacting with FSA through web service interfaces (API’s).

Client side page rendering will be fully supported and secured.

Quick and Cost Effective Transactional Services

Continuous Improvement

NEO,NSLDS Batch

Interface

300. The solution shall ensure batch processing supports parallel processing that can be scaled both horizontally and vertically

Transactional Services

NEO,NSLDS Batch

Interface

310. The solution shall ensure batch processing fully supports checkpoint restart for restarting batch jobs that fail or otherwise do not complete as expected.

Quick and Cost Effective

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and Validation

NEO,NSLDS Batch

Interface

320. The solution shall ensure that batch processing supports units of work that bundle more than one transaction committing all transactions or rolling back all transactions as a group.

Transactional Services

NEO,NSLDS Batch

Interface

330. The solution shall ensure that batch processes manage the transactional state allowing the business layer objects to join the transactions managed by the batch layer.

Transactional Services

NEO,NSLDS Batch

Interface

340. The solution shall ensure that the batch layer supports real time monitoring of unit or work processing.

Transactional Services

NEO,NSLDS 350. The solution shall ensure that tracking and trending of capacity and processing time consumed by units of work is supported.

Transactional Services

NEO,NSLDS Data Base

Servicing

360. The solution shall establish a simple and well defined set of data access services ensuring referential and data integrity.

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and Validation

NEO,NSLDS Data Base

Servicing

370. The solution shall ensure that data used in transactions can be locked using optimistic

(Web and API) and pessimistic

(Batch Interface)

Use of standards based data access framework(s) (such as

JPA, Hibernate) enabling rapid changes to the underlying data structures with minimal impact to business objects.

Quick and Cost Effective Transactional Services

NEO,ISE,NSLDS Data Base

Servicing

380. The solution shall ensure read only data can be accessed without locking.

Transactional Services

NEO,NSLDS Data Base

Servicing

390. The solution shall ensure that Object to Relational data access tools are leveraged for transactional and read only data when appropriate.

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and Validation

NEO,ISE,NSLDS Content

Management

400. The solution shall centralize content so information is always consistent throughout the integrated site.

Raw content is branding and format neutral.

Full release and approval workflows are supported.

Real time content releasing is supported through workflows.

API’s are available for server side includes of content by applications.

Branding elements such as header, footer, navigation menu and other branding elements such as common style sheets and images are centrally managed but available to development projects contracted separately from the content management solution.

Global stable resources such as branding and style sheets are versioned and packaged for static integration if required.

When shared content is revised, applications/web sites using that content are made aware, verify that their applications/web sites work properly with the revised content, and publish that content at an FSA-specified date and time.

Support for versioning, such that content searches can return all versions of content, it can be determined what content version is being provided by an application system/website, application/website support teams can query the CMS to determine what is the current version of a piece of content.

Single Integrated Web Site

Real Time Static Content Changes

FSA manages static content consistently

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and Validation

NEO,ISE,NSLDs Content

410. Content shall be externalized to a content management system enabling real-time content update.

Each application system/website support group is made aware when revised content is approved and available, and is able to test with that new content, and then publish it in production.

If for whatever reason the revised content does not work on an application system/website and cannot be published into production, this should be reported on and highlighted in workflows.

New projects are provided with an Enterprise Style Guide Bundle and supporting documentation.

Updates to content/branding are handled via change control.

Single Integrated Web Site

Real Time Static Content Changes

NEO,ISE,NSLDS Content

Management

420. Externalized content shall be managed at both the project

(application system/website) and enterprise level.

Each application system/website support group is made aware when revised content is approved and available, and is able to test with that new content, and then use it in production.

Local-only Content can be managed locally or stored in the enterprise CMS.

New projects are provided with an Enterprise Style Guide Bundle and supporting documentation. Updates to content/branding are handled via change control.

Copies of content from the enterprise CMS may be retained locally to an application system/website, provided the application system/website support group is informed when revised content is available.

The central CMS is loosely coupled to the various applications/websites that use content from the central CMS. The technologies used by the central CMS should not directly impact which technologies are used locally on specific applications/websites, but should be able to pass content to them.

Single Integrated Web Site

Real Time Static Content Changes

ISE Content

Management

424. Content managed at the enterprise level shall be pushed or made available to all client applications/websites and social media sites, so that content is consistent across client applications/websites and social media.

Each application system group is made aware when revised content is approved and available, and is able to test with that new content, and then publish it in production

Content is provided to client applications/websites in the format they use it. For example, one application may receive an update for Angular JS, while another site may need the same update, but in HTML format, or an application displaying content in Spanish will receive text content in Spanish, or a site supporting mobile devices will receive content in a format appropriate for those mobile devices.

FSA manages static content consistently

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and Validation

NEO,ISE,NSLDS Content

425. The solution shall ensure applications that are users of

Content Management do not risk breaking by automatically using revised content. Rather they are informed of its availability, test using it, and then use it.

The support teams for applications/websites are informed when content their systems use has been revised. They are notified to test that their system presents the revised content correctly, and once that is verified publish the revised content on their production system. If their application systems/websites or social media sites cannot successfully use that content, this is handled as an exception by approval workflows.

Applications/websites and social media sites should have the ability to roll back content and use a previous version if problems are noted, but this is not an issue for the central CMS, other than providing the appropriate version of the content.

Single Integrated Web Site

Real Time Static Content Changes

FSA manages static content consistently

NEO,ISE,NSLDS Content

Management

430. The solution shall ensure persistent caching is enabled to minimize the risk to the application running in the event the content management service is not available.

Applications/websites can operate and start up and operate, presenting content, even when the CMS is not available.

Single Integrated Web Site

Real Time Static Content Changes

NEO, ISE Content

Management

432. The solution shall provide simple easy to use content creation and content management tools along with appropriate training for FSA users of these systems

Whether content creation is built into the CMS, or the CMS can manage content from multiple tools, content creation and management should be easy for FSA staff creating and managing content.

Single Integrated Web Site

Real Time Static Content Changes

NEO,ISE,NSLDS Build and

Deploy

440. The solution shall ensure an FSA centralized continuous build process is available to monitor code quality and automated unit testing and promotion from development through testing, and ultimately into production, throughout the development cycle.

Not just Agile Development, but Continuous Delivery, all scripted.

Scripts invoke code quality evaluation and scoring tools, tests, build environments, and promote code.

Continuous Improvement

Quick and Cost Effective Transactional

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and Validation

NEO,ISE,NSLDS Build and

Deploy

450. The solutions shall ensure that all deployments are fully labeled and immutable.

Deployments are self-contained, versioned and deployed into Containers via scripts

Continuous Improvement

Quick and Cost Effective Transactional Services

NEO,ISE,NSLDS Build and

Deploy

460. The solution shall ensure that all external project code dependencies are managed through repositories containing both the executable binaries and source code.

Single Integrated Web

Site

Continuous Improvement

NEO,ISE,NSLDS Build and

Deploy

470. The solution shall ensure that FSA can build, deploy and run the solution with no direct involvement by the contractor.

Continuous Delivery scripts are available to FSA Continuous Improvement

NEO,ISE,NSLDS Build and

Deploy

480. The solution shall ensure that FSA can provide access to the source code and runtime environment without direct involvement by the solution’s support contractor.

Scripts to build development and test environments are available to FSA

Attachment J FSA Enterprise Architecture Program – Activity 4 Goals, Objectives, Qualities and Validation

NEO,ISE,NSLDS Support

Environments

490. The solution shall provide an integrated development, test and production environment that will allow teams with specialized skills and knowledge to work on elements of the web site without having formal partnership and/or other contractual dependencies with other contractors allowing FSA to more effectively compete work on this site and reward innovative contractors with expanded scope and responsibilities.

Plug-in architecture is available to allow independent project teams to develop and deploy dynamic (transactional) content with no dependencies with other contractors.

Content and other common branding elements being centrally managed are versioned and integrated into the site.

New projects start with an Enterprise Style Guide Bundle for common branding/content

Centrally managed automated integration testing framework providing comprehensive testing scenarios submitted by contributing development efforts.

Plug-in architecture is technology natural allowing solutions to be developed using any web development technology such as PHP, Python, JSP, JSF, ASP.

Single Integrated Web Site

Real Time Static Content Changes

Quick and Cost Effective Transactional Services

NEO,ISE,NSLDS Build and

Deploy

500. The solution shall ensure that simple automated setup of environments are supported for dev, test and other environments.

Once proper authorizations have been processed, the developer will use documented and scripted processes that are highly automated to create an environment.

An environment will include a full runtime (with database) and optionally developer desktop.