Request for Offers (RFO) Addendum

RFO Number: RFO0298

Addendum Number: 1

Date of Addendum: 1/22/2018

Original Posting Due Date, Time: 1/26/2018, 4:00 PM CT

Revised Due Date, Time: 2/2/2018, 4:00 PM CT

Title: eHEAT Modernization project – Application development using Java/JEE

SCOPE OF ADDENDUM: Modifying process schedule, correcting a typographical error

and posting questions received and the State’s answers. In this Addendum, changes to

pre-existing Work Order language will use strike through for deletions and underlining

for insertions.

Changes to RFO

Process Schedule

Process Milestone Due Date

Posted December 22, 2017

Deadline for Questions January 12, 2018; 2:00PM CT

Anticipated Responses to Questions Posted January 19, 2018

January 22, 2018

Proposals Due January 26, 2018; 4:00PM CT

February 2, 2018; 4:00 PM CT

Anticipated proposal evaluation complete February 14, 2018

February 21, 2018

Anticipated work order start February 28, 2018

All instances of the term “SOAL” in the RFO are changed to “SOAP”. (This was a typographical error.)

Questions and Answers (some duplicate questions have been combined/paraphrased)

Q: What is the term of the contract?

A: Per the RFO, the project is anticipated to start on 2/28/2018 and the development and

testing should be finished within eight (8) months after the actual start date. The State will

retain the option to extend the work order in increments determined by the State.

Q: What testing/automation tools are they using?

A: MNIT Commerce staff is planning on using Selenium, Spring Testing, JMETER for performance

testing, SPOCK, JUNIT. Developers responsible for unit testing to adequately cover code.

Q: What is the current technology in the system?

A: JAVA JEE MVC based application SQL Server database 2012 Struts 1.3 and JDBC technology

Q: How will the requirements for the new system be defined and documented? (given that this is a

replacement/migration and there are no BA resources on the team)

A: A team of business analysts are working now on requirements. Detailed requirements are in progress for 14 modules. The Business Analyst team is creating detailed requirements with Use cases, User Stories or one liners. Business process models, business object models and business event models will be given to the developers. Each set of detailed requirements will be discussed with developers by business analysts, project team in face to face meetings.

Q: Is there an incumbent for the eHEAT project who will be bidding on the modernization project? A: No. Q: Are you open to developers and QA resources that do not have 2 engagements of at least 12 months in

public sector environment? We ask that question because we have a good supply of highly skilled resources in MN who have worked with Fortune 500 clients like Target, US Bank etc., but don't have public sector experience.

Would you consider moving this to a Desired Skill or changing it to two 6 month engagements?

A: The public sector requirement(s) are part of the Mandatory (pass/fail) Qualifications. RFO submissions that do not meet all of the Mandatory Qualifications will be failed and removed from consideration. These Mandatory Qualifications will remain as is.

Q: If the resource is no longer available at the time of interview, can we substitute with another resource

with similar experience and rate?

A: Per SITE Program rules, resource substitutions are not permitted during the evaluation process. If one of your proposed resources becomes unavailable during the evaluation process, your entire proposal would be removed from consideration.

Q: If the resource is no longer available after the proposal has been awarded, can we substitute with

another resource with similar experience and rate?

A: The resources that are proposed in your RFO response must be available to start work on the project. The RFO provides for the possibility of resource replacement(s) during the course of the project, but this does not contemplate resource replacement(s) prior to work even starting.

Q: What is the address where the developers and QA have to be onsite 75% of the time?

A: Department of Commerce, State of Minnesota, 85 7th Place East, St. Paul, MN, 55101

Q: Can you interview the resource over Skype and then interview in person if they clear the Skype round so

it saves travel costs and resource's time?

A: In person interviews only. Q: Is the eHEAT application being redesigned from scratch with new frameworks (like moving from Struts

1.0 to Spring MVC etc.) or is it just adding new features and upgrading the underlying JDK, app server, and frameworks?

A: Yes, we expect the eHEAT application will be redesigned by the vendor developers with

JPA/Hibernate, Spring, and adding new business features. Developers will be using various specifications of JEE. Looking at workflow APIs.

Q: Will the UI be redesigned as well or continue using the existing layouts and style-sheets with the

modernization project?

A: Yes, we expect the UI will be re-written using JSF, Primefaces by the vendor developers. Q: Is there a QA instance of eHEAT app that we can use to understand the effort involved for each module? A: Not until the contract is awarded. Q: Is there a modernization requirements doc that has details on what new features are being added to

each module? That will help us in estimating the hours more accurately.

A: Yes, see end of Addendum for relevant documents. Q: Can we reuse the existing source code?

A: It will be useful but not likely re-useable. Q: As per the RFO, it is mentioned that MN IT needs at least 1 Senior Developer. How many resumes we

can submit for this position?

A: This RFO is seeking a team of up to five resources – at least one Senior developer, up to three mid-level developers, and [exactly] one Quality Assurance resource. Within these parameters, it is up to each responding vendor to determine how many personnel are needed to complete the project. Each vendor is limited to the submission of one team of resources. Do NOT submit alternate or back-up resource choices for the individual positions. Only submit as many resources as would actually comprise your team and perform work on the project.

Q: How many resumes we can submit for each position?

A: This RFO is seeking a team of up to five resources – at least one Senior developer, up to three mid-level developers, and [exactly] one Quality Assurance resource. Within these parameters, it is up to each responding vendor to determine how many personnel are needed to complete the project. Each vendor is limited to the submission of one team of resources. Do NOT submit alternate or back-up resource choices for the individual positions. Only submit as many resources as would actually comprise your team and perform work on the project.

Q: We are not able to arrive at the exact number of hours required to complete deliverables at this stage. Is

it fine, if we submit per hour rate of each proposed resource and not total cost?

A: You must fully complete the Cost Proposal Worksheet that is contained at the end of the RFO – note that it has two pages. The total cost is required for your Cost Proposal submission because that is the number that we will use to do the cost scoring, and we need the costs to be expressed in a consistent manner across all submissions. Merely including the hourly rates is insufficient and will result in your proposal being removed from consideration. Please utilize your best estimate of the number of hours needed to complete the work.

Q: Are there more detailed requirements for the modules or does the existing application encompass all the

requirements for this engagement?

A: A team of business analysts are working now on requirements. Detailed requirements are in progress for 14 modules. The Business Analyst team is creating detailed requirements with Use cases, User Stories or one liners. Business process models, business object models and business event models will be given to the developers. Each set of detailed requirements will be discussed with developers by business analysts, project team in face to face meetings. Requirement documents included at end of Addendum.

Q: Is the intent of the modernization engagement to also modernize the User Experience? If so, has that effort

around UX happened or is that expected as part of the engagement?

A: We should have an idea of the change in the look and feel of the application prior to developers coming on board. Internal staff is responsible for guiding UI development IAW state standards and business needs. UX analysis done internally; expect developer resources to be experienced UI developers with the JSF framework.

Q: Will the development effort include all the languages or just setting up the process to include other languages

as part of ongoing production work?  Also, does the cost associated with the translations need to be included in the cost proposal or will MNIT do that?

A: The additional languages are only for the online application. State of Minnesota personnel will

be involved with translation. Development effort will need to be included in cost proposal. Q: What level of WCAG conformance is desired and/or required?

A: Per the RFO, all documents and other work products delivered by the vendor must be

accessible in order to conform with the State Accessibility Standard. Information about the

Standard can be found at http://mn.gov/mnit/programs/policies/accessibility/. The State

Accessibility Standard generally requires compliance with Web Content Accessibility

Guidelines (WCAG) 2.0 (Level AA) and Section 508 Subparts A-D, as applicable.

Q: What framework will be provided by MNIT as the Technical Framework for eHEAT Next Generation and is

that framework complete, ready for production use?

A: Yes, a (SAR) Solutions Architecture Requirements document will be finished before the selection of the development team. Framework will be ready for development work. See documents at end of Addendum.

Q: Has there been any gap analysis completed on the work required to align with the Enterprise technical

objectives and/or the refactoring effort necessary?

A: Yes, a (SAR) Solutions Architecture Requirements document will be finished before the selection of the development team. See documents at end of Addendum.

Q: For the SQL Server migration, what are the specifications of the old and new environments? A: Old is SQL Server 2012, new is SQL Server 2016. Q: We would like to confirm the name of manager and team structure.

A: Team structure consists of MNIT one project manager, two technical SMES and one architect. The business team consists of the entire energy assistance team of 8 personnel. Additionally we have 8 SMEs from the local service providers.

Q: We understand that the State is looking for detailed costs (total hours to complete, total cost for

deliverables), however the RFO does not include detailed scope of work information. Can you please provide the gap analysis with current and future state, requirements specifications, design specifications for the eHeat modernization? If those are not available, can you please provide the current technical document for existing eHeat? This will help us provide accurate estimates for scope of work to be performed and estimated hours required to perform the work for each deliverable.

A: See documents at end of Addendum. Q: If the State provides more detailed scope of work information, will the State be willing to extend the

response due date by a minimum of one week to allow for adequate response development time? A: Yes, we are extending the Proposals Due date to February 2, 2018, 4:00 PM CT.

Q: It is our understanding that RFO0246 eHeat Modernization for business analysis, including facilitation,

business models, and use cases for the eHeat modules is currently under contract negotiation. Can you please provide the following information: a. How many vendors responded to RFO246? b. Which responder has been awarded the work?

c. Will the responders awarded the work under RFO0246 be precluded from responding to RFO0298? A: There were 18 responses to RFO0246 and a work order has been executed with Advanced

Strategies Inc. That vendor is not eligible to respond to RFO0298. Q: Can you please clarify if the awarded work will be performed on a time and materials basis or on a fixed

price basis? Will there be any not-to-exceed pricing requirements?

A: Per the RFO, the engagement will be deliverable-based, i.e., fixed cost per deliverable. We are requiring the information pertaining to hourly rates and hours per deliverable in part so that we can ensure that the responders are not exceeding their Maximum Hourly Rates for the relevant SITE categories.

Q: Regarding mandatory qualifications citing “SOAL/WSDL” as in “10 years’ combined experience with

Service Oriented Architecture, JAXWS/JAX-RS/REST Web services, JAXB, SOAL/WSDL, XML/JSON, Web services Security”, is this perhaps a typographic error and should this be “SOAP/WSDL” instead?

A: Yes, this was a typographical error and we intended it to be SOAP/WSDL. See the RFO

change at the top of this Addendum.

Q: We recognize that the RFO calls for up to 5 resources but if we submitted a bid that included more than 5 resources, would we get disqualified or would the bid be equally considered?

A: The RFO calls for a team of up to five resources. Teams of over five resources will not be

considered.

Q: We recognize that the RFO calls for the resource to be onsite at least 75% of the time, but is offshore work allowed?

A: All work must be performed within the borders of the United States, with at least 75% of

the work to be performed on-site. To the extent not prohibited by the WTO Agreement on Government Procurement, foreign outsourcing of work is prohibited.

For the SQL Migration to SQL Server Production: Q: What is the rdbms name of the sql to migrate to SQL Server? Is it Mysql/Oracle? A: SQL SERVER 2012 to SQL Server 2016. Q: Does the database migration include refactoring/rewrite store procedures for the new database? A: No stored procedures in the current database. Q: How big is the data that need to migrate? How many tables and data size? A: 143 tables, 146,000,000 row count, 3 GB Application server: Q: What application server are you using? A: Websphere 8.5 is the current application server moving to JBOSS or Websphere 9.0 Q: What is the current load of the system, for example: how many request/seconds its process? A: Estimate Current Request/Sec 50

Estimate Future Request/Sec 125

Q: What is the estimated line of code that need to refactor? A: Estimated 186,280 lines of code in current application. Q: Where are the application servers hosted? Are they in the cloud or within the department? A: State data center. Q: Can the applications be offline during data migration? If they can, how long can they be offline? A: Yes, we would do this over a weekend. Q: Can you give more details about the common layered architecture that will be provided by MNIT? What

technology will be used in there for example: does it use any specific messaging queue system or microservice with restful interface.

A: Message queues are not part of the solution. Restful services may be part of the application.

SAR – Solutions Architecture requirements document is work in progress. See documents at

end of Addendum.

Sl.

No. Question

Reference from RFP /

Question Category

1. “Seeking a single vendor to provide a team of up to five resources to complete the project. At least one Senior developer, up to three mid-level developers, and one Quality Assurance resource.” What are the expected teams to be part of the RFO? A: In addition to the technical resources being asked for in this RFO: We have MNIT team of 5 individuals, the energy assistance team of 8 personnel plus 8 Service provider SMEs. There are also 4 Business Analysts that are on board until April 15, 2018.

Page-1

2. “Seeking a single vendor to provide a team of up to five resources to complete the project. At least one Senior developer, up to three mid-level developers, and one Quality Assurance resource.” In addition to the expected 4 developers and 1 quality assurance resource, please provide the size and composition of below Teams expected to be working on the eHEAT modernization project:

a. PMO b. Development Team c. Requirement Definition Team d. Testing Team e. Architecture Team f. Infrastructure Team

A: MNIT providing 1 PM, 2 development SMEs, 1 Architect, 2 – Infrastructure team members consisting of 1 Middleware person and 1 database person. 4 Business Analysts on board until April 15, 2018. QA resource will coordinate testing with the energy assistance team and service provider SMEs.

Page-1

3. “The team will assist with the rewriting and migration of existing JAVA/JEE

applications to latest technologies, migration to new environments, creating unit and

integration tests, perform optimization and tuning of applications, and creation of

Sec: Business Need

Page-1

Sl.

No. Question

Reference from RFP /

Question Category

technical artifacts documentation.”

From a business requirement perspective, has the State changed/re-engineered e-

HEAT related business processes, OR, will they remain the same as in the legacy

(current) e-HEAT system.

A: Most business processes will remain the same and new processes are

being designed as a result of the business requirement work.

4. “Design, develop, code and test solutions using Java/JEE technologies for projects

identified under eHEAT Modernization initiative.”

Please confirm if State expects multiple projects to be executed as part of this RFO

A: eHEAT modernization is a stand alone project.

Sec: Business Need

Page-2

5. What is the anticipated start and end date for the project?

A: Per the RFO, the project is anticipated to start on 2/28/2018 and the

requirements should be finished within eight (8) months after the actual start

date. The State will retain the option to extend the work order in increments

determined by the State.

Project Duration

6. Are there any business drivers associated the anticipated project duration?

A: The sole business driver on this project is the fiscal year start of the energy

assistance program; this means no go-lives will occur in the September to

October timeframe. The initial work order under this RFO will not include

duties pertaining to go-live; however, at the State’s option, the work order may

be extended at a later date to include such duties.

Business Driver

7. “Development of production support”

Please clarify what does State expects Vendor to perform/achieve from the

statement.

A: For the vendor we would expect knowledge transfer of all design and coding

done as a result of this RFO. Best practices on error handling and usage

monitoring, Audit logging.

Sec: Business Need

Page-2

8. “Data Analytics” Please confirm if by Data Analytics, State is referring to Reporting, or, is there Analytics using specific tools included. If so, please provide details of the tools. A: Preparing data to be used by Tableau for analytics and reporting.

Sec: Project Milestones

and Schedule

Page-4

9. “Anticipated End Date: Finish Requirements 8 months from the start of the project.” Please confirm if State expects the project to be completed within 8-months from the start of the project A: Per the RFO, the project is anticipated to start on 2/28/2018 and the requirements should be implemented within eight (8) months after the actual start date. The State will retain the option to extend the work order in increments determined by the State.

Sec: Project Milestones

and Schedule

Page-4

10. “Anticipated End Date: Finish Requirements 8 months from the start of the project.” Please clarify the basis on which State came up with the duration of 8-months for the project A: Based on metrics of previous projects, estimated 2 hours of development time for every hour of business analysis.

Sec: Project Milestones

and Schedule

Page-4

Sl.

No. Question

Reference from RFP /

Question Category

11. “Data Analytics” Please confirm if by Data Analytics, State is referring to Reporting, or, is there Analytics using specific tools included. If so, please provide details of the tools. A: See above (#8).

Sec: Project Milestones

and Schedule

Page-5

12. “Participate in Scrum meetings, organize work in sprints” What is State’s expectation towards Sprint duration for this project? A: We will organize sprints for development 2 to 3 weeks in duration.

Sec: Responsibilities

Expected of the Selected

Team

Page-6

13. “Description of the business analysis or modeling methodology used” Please clarify if its vendor responsibility to provide business analysis or not. A: Business analysis is being done by another vendor who will be on board until April 15, 2018.

Sec: Submission Format

– Work Plan

Page-11

14. “Descriptions of the tools that will be used” Please clarify what tools is being referred to. A: Specify any Development, QA, IDE, and bug tracking tools you may use. Jenkins, Maven and SVN will be used by state technical team.

Sec: Submission Format

– Work Plan

Page-11

15. Is there a need to make the To-Be eHEAT application accessible through smart

phones and tablets?

A: Yes, we expect To-Be eHEAT’s ‘Household Application Submission’ module

be mobile responsive.

Mobility

16. Is State looking for a fixed price quotation or a T&M based contract?

A: Please refer to the Cost Proposal instructions in the RFO. You must

complete the Cost Proposal Worksheet contained at the end of the RFO and

include the name of each resource working on each deliverable, the proposed

hourly rate for the resource, the total hours and the total cost. The work order

itself will be deliverable-based, i.e. fixed cost per deliverable.

Engagement Model

17. In order to provide a fixed price quotation for the project deliverables it will be

necessary to review business requirements and functional details of the To-Be

eHEAT system.

Can the state provide any documentation in support of this so that we can provide

fixed price estimates for project deliverables?

A: We have only completed the high level requirements. We have included

some relevant documents at the end of the Addendum.

Documentation

18. We are aware that State of MN had conducted a requirements definition project prior

to this RFO. The RFO puts a 20% factor on vendors proposed work plan. In order

to provide a work plan, we would need to understand the detailed business

requirements. Please provide the following documents so that vendors can provide

a relevant work plan.

Detailed use cases and business requirements documents?

Newly defined requirements, application architecture related artifacts if any that were created during the requirement definition project that led to his RFO

A: Use cases and detailed use cases are in progress. The project is just

Business Requirements

Sl.

No. Question

Reference from RFP /

Question Category

entering the detailed requirements phase. We have included high level documents at the end of the Addendum.

19. Did the state use a 3rd party contractor for the Requirement Definition project?

If Yes, please provide the name

A: Yes, Advanced Strategies Inc.

General

20. Please confirm if the contractor that executed the Requirement Definition phase, is

allowed to bid on this RFO?

A: No, they are not.

General

21. The state has already defined the number of resources and the roles and skill levels

for the 5 project positions.

Can state provide inputs as to what was the basis of estimation towards defining this

team size

A: Based on current understanding of application and business analysis.

Team

22. Who will be responsible for project management of the development?

A: MNIT will be responsible for project management. However, senior

developer from the vendor team will be responsible for managing work within

the team and will be single point of contact. State Technical SMEs would give

direction on technical architecture and design of the application. Regular code

reviews are planned with state technical SMEs.

Project Management

23. Who will be responsible for technical architecture definition of the new eHEAT

system?

A: MNIT.

Technical Architecture

24. Who will be responsible for database administration related activities during the

project

A: MNIT.

DBA

25. Can you provide a quantitative inventory of current eHEAT system components that

must be refactored/rewritten/migrated to new technologies?

We require the following:

a. Number of Java classes – 944 b. Number of JSPs – 247 c. Application physical data model – 149 d. Number of external interfaces – 3 A: See the numbers next to each item above.

Application components

26. How much time in terms of business days duration, should we allocate towards User

Acceptance Testing (UAT)?

A: UAT and all testing activities, two months duration.

User Acceptance Test

27. Will State utilize MNDOC personnel, Community Action Agency personnel, Utility

Company personnel towards User Acceptance Testing (UAT)?

A: MNDOC personnel - eight personnel, Community Action Agency personnel -

eight personnel, Utility Company personnel towards User Acceptance Testing

(UAT) - very small effort for utilities.

User Acceptance Test

Sl.

No. Question

Reference from RFP /

Question Category

28. What is the State standard platform for automated test cases?

A: We are looking into Selenium but open to suggestions.

Test Case

29. Has the state determined a budget for the project? If so, please share the same.

A: Documents at the end of the Addendum should provide guidance; however,

we have no specific budget amount to share at this time.

Budget

30. What is the State standard for security testing?

A: We are declining to answer this question.

Security

31. a. Please confirm the expected duration of Warranty once application is put in Production

b. Please confirm if regular Business hours will be used to provide support during Warranty period

A: We are not specifically asking for a warranty at this time.

Warranty

32. Please provide current State technical architecture standards towards the following:

1) Web server 2) Application server 3) Database platform 4) Reporting platform 5) Code development

A: 1) WebSphere/JBoss 2) WebSphere/JBoss 3) SQL Server 2012 4) JPA/Hibernate 5) Java/JEE 1.8, JSF/Spring MVC, Primefaces, Quartz scheduling, JAX-WS/RS/Rest Webservices, Eclipse/Intellij

Technical Standard

33. On the one hand, State has specified the number of resources and onboarding

cadence of the project team. However, on the other hand, State has also asked

vendor to provide fixed price cost estimates for project deliverables without providing

adequate information towards size and complexity of the work entailed.

In this scenario, how does the State expect to establish proper delineation of

accountability for project deliverables when the State has decided the size and

constitution of the project team.

A: We are estimating the resources based on project high level requirements

and standard metrics of a 2 to 1 ratio of coding to requirements. If there are

significant changes to requirements we are open to re-visiting assumptions

during the course of the project if needed.

General

34. Has the current eHEAT system documentation been maintained consistently since

the product was launched back in 2004?

A: No.

Documentation

35. Can you please share current eHEAT system documentation?

A: Current documentation has been included at the end of the Addendum.

Documentation

36. Please confirm if all vendor resources will/must be located at MNDOC facilities in St.

Paul, Minnesota.

A: All work must be performed within the borders of the United States, with at

least 75% of the work to be performed on-site at Minnesota Department of

Commerce offices in St. Paul, MN. To the extent not prohibited by the WTO

Work location

Sl.

No. Question

Reference from RFP /

Question Category

Agreement on Government Procurement, foreign outsourcing of work is

prohibited.

37. Please provide exact version of technologies used in current eHEAT application

A: Answered above.

Technical Stack

38. a. Please confirm the list of interfaces which will need to be involved during Interface Testing with new application?

b. For each of the Interface in-scope for testing, is there an expected duration which would need to be put aside for testing with each of them?

A: SWIFT – State system for Accounts payable 2 Print and Mailing services Energy Vendors interface DEED – State agency for income verification FacsPro – Provide eligibility determination for Weatherization application Possibly DHS – State agency for other aid to be included in income determination. Possibly SSA for identity verification Address verification interface Duration of Interface testing is To Be Determined

Testing

39. Are there any Interface level dependencies which Vendors need to consider when

planning engagement with Interfaces in-scope?

A: Answered in #38 above.

External Dependencies

40. Can a vendor, with principal office in US, execute some of the project activities from an offshore development center outside US, like Canada?

A: All work must be performed within the borders of the United States, with at least 75% of the work to be performed on-site. To the extent not prohibited by the WTO Agreement on Government Procurement, foreign outsourcing of work is prohibited.

Location

41. a. Does State expect the vendor to conduct Performance Testing? b. If yes, are there any specific performance and availability related requirements,

including concurrency, response time etc.? c. Are there State approved tools expected to be used for Performance Testing? A: a. State expects the vendor to conduct Performance Testing b. SAR document included at end of Addendum c. JMeter or open to suggestions

Performance Testing

42. a. Please clarify where would the meetings with SME (specifically for requirements and gap analysis) be held?

b. Does the vendor staff need to travel to locations other than St. Paul for project purposes [Requirements Verification, User Acceptance Testing (UAT) etc.]?

c. If yes, please provide locations, time/duration and frequency of such travel.

A: Meetings will occur at Department of Commerce facilities or via Webex. Vendor should not incur any costs for travel.

Budget/Travel Expenses

43. Please confirm that the State will provide necessary office facilities, phones, cubes,

software, etc. to the contractor onsite resources?

A: Yes, office space is in the vicinity of MNIT personnel, with phones and

laptops provided.

Budget / Infrastructure

44. Are there any specific time-slots during the year when State would prefer not to have

User Acceptance Testing (UAT) and/or Production Launch scheduled?

A: Production launch should not occur from September to October. The initial

General

Sl.

No. Question

Reference from RFP /

Question Category

work order under this RFO will not include duties pertaining to go-live;

however, at the State’s option, the work order may be extended at a later date

to include such duties.

45. Please confirm that no bonds or damages are required under this RFO.

A: We are uncertain what you mean by this question. Please refer to the RFO

and to your SITE Master Contract to determine requirements.

Contract

46. Will any preference be given to a particular group of companies (for example, local,

non-profit, minority owned)?

A: See the RFO for information pertaining to the Preference to Targeted Group

and Economically Disadvantaged Businesses, and the Veteran-Owned Small

Business Preference.

Contract

47. How many State SMEs will be allocated to this project during various phases of the

project for further clarifications, reviews etc.?

A: Energy Assistance team has 8 personnel participating on the project, 8

SMEs from Community action teams are participating, 1 Architect, and 2 MNIT

technical developers.

Subject Matter Expertise

48. a. What are the different environments available for this project? b. How many Test environments will be available for vendors? c. When will the environments be made available for Vendors to start development? A: Dev, Test, and Prod environments in addition to developers local workstation environments. 1 Dev and 1 Test environment available for vendors Dev environment would be available by end of March 2018 Test environment would be available by end of April 2018

Environments

49. a. How many Business Staff will need to be Trained as part of this project? b. Can we assume all training will happen in St. Paul or should we plan for travel? If

so, which locations? c. Can we propose train the trainer based training? d. Please confirm if Training Materials can be provided in Soft Copies format A: Training of business staff is not the responsibility of the vendor under this RFO.

Business Staff Training

50. a. How many Technical Staff will need to be Trained as part of this project? b. Can we assume all training will happen in St. Paul or should we plan for travel? If

so, which locations? c. Can we propose train the trainer based training? d. Please confirm if Training Materials can be provided in Soft Copies format

A: Two MNIT technical staff need knowledge transfer, resources are in St. Paul and training material can be in a soft copy format.

Technical Staff Training

----------------------------------------------------------

This addendum shall become part of the RFO and should be returned with, or acknowledged in, the

response to the RFO.

RESPONDER NAME:

SIGNATURE:

TITLE:

DATE:

CHARTER

Charter

Project – eHEAT Next generation

5/16/2017

Table of Contents

Contents

Table of Contents .................................................................................................................................... 15

Project Name: eHEAT Next Generation .................................................................................................. 16

1. Executive Summary ............................................................................................................................. 16

2. Business Need or Opportunity ............................................................................................................ 17

Expected Benefits ................................................................................................................................ 17

Assumptions ........................................................................................................................................ 17

Constraints ........................................................................................................................................... 18

Risks .................................................................................................................................................... 18

3. Solution Proposal ................................................................................................................................ 18

4. Scope Detail ........................................................................................................................................ 19

In Scope ............................................................................................................................................... 19

Out of Scope ........................................................................................................................................ 22

5. Roles and Responsibilities .................................................................................................................. 23

6. Preliminary Cost and Schedule ............................................................. Error! Bookmark not defined.

Appendix A ................................................................................................ Error! Bookmark not defined.

Stakeholders .......................................................................................... Error! Bookmark not defined.

Authorizations ........................................................................................ Error! Bookmark not defined.

Charter/Signatures ................................................................................. Error! Bookmark not defined.

Project Name: eHEAT Next Generation

Prepared By: Andy Smialek

Date: May 31, 2017

Project Executive Sponsor: Curtis Zaun

Business Champion: John Harvanko

Project Manager: Andy Smialek

1. Executive Summary

Launched on October 1, 2004, eHEAT modernized EAP service delivery. Although it still functions well,

eHEAT needs updating to utilize innovation to improve services to households, meet program needs,

and keep pace with security. Currently, households apply by completing paper applications. Local

Service Providers then receive and scan the application and process it using physical and electronic files.

Income and other information is gathered and verified using paper documentation. The data then is

entered into eHEAT to determine eligibility, calculate benefits, and make payments. Additionally, system

security is essential to safeguard participant information. The technological innovation opportunities

include improving the speed of delivery by reducing re-entry of data, improving accessibility to

households and updating system security.

2. Business Need or Opportunity

Expected Benefits

Improve customer service by: o Reducing time from request for service to delivery of service o Reducing costs of application processing o Reducing the burden on households to submit documentation (e.g., automated

income\identity verification) o Improving user friendliness and accessibility to program services o Improving communication between households and the program

Enable local service provider staff to strengthen the relationship and work more effectively with high need households by: o Identifying households in need o Improving methods of communication with households (e.g., online status, Email, text

updates) o Enabling effective case management o Improve workflow of application for local service providers

Improve program compliance and integrity by: o Improving auditability and traceability o Enabling more effective budget management o Improving data accuracy o Improving data and system security o Improving user access management o Improving person identification

Assumptions

During Next Generation eHEAT Project, program policy-making, eHEAT enhancements, program operations changes and special projects will be limited.

Some Local Service Providers have invested significantly in scanning systems for workflow management, record keeping & retention. eHEAT Next Generation will replace much of this functionality

Weatherization will launch a web-based production management system in program year 2017. The scope of Next Generation eHEAT integration will depend on how adequately the WAP new

software enables the WAP workflow. Because WAP shares application, eligibility, and grants management functions, when WAP

software is separate from eHEAT it could confuse the Service Providers in both the development and production of these systems.

Need to consider applicant internet use for EAP households. A Pew Research Center article says, “13% of Americans don’t use the internet. Who are they?” ( http://pewrsr.ch/2caqLi3 ). The article shows some people EAP serves have a higher rate of non-web use.

National performance measures are currently “developmental.” eHEAT is used for partner reporting needs. Online income verification may require changes to the time-period covered for income

documentation. If we go this route, we might have to sacrifice the timing of information income for the sake of efficiency and program integrity.

Household results driven Strengthening the customers’ relationship with the local service providers Business objectives drive technology Equitable access for households Stewardship of tax payer money Exceptional design, coding and architecture

Proactive planning to minimize future expenses Flexibility to accommodate program changes

Next Generation eHEAT will transform business processes at the local service providers Increase of customer support costs due to end users using on-line eHEAT application Creating program audit trail within the application and storing all documents which could allow

the PPAs to conduct program audits remotely. Also allowing more extensive file review. Most service providers have a CAP60, THO, Client Tracker, for other services. Need to work out

privacy details and standardized interface with the CAPs’ software

Constraints

During Next Generation eHEAT Project, program policy-making, eHEAT enhancements, program operations changes and special projects will be limited.

eHEAT Next Generation go-live will happen before or after peak processing season (August- October), if we cannot make the pre-season make it post January

Risks

All deliverables may not get completed by July 2018, thus having a tiered release in July 2018 and Jan 2019

Key personnel can leave Success or failure will revolve around Business process redesign, successful change management

and communication Documentation and training must be detailed to support business process change 130,000 households in the system, of which 80% could apply online, telephone, online support

must be thought through to support this process change Understand the communications to end users, how the switch over affects current state to

future state of end users doing this online

3. Solution Proposal

1. Create online end user application, automating income verification and identity, have manual

work arounds for failure of electronic verification and online application

2. Upgrade security aspects of the eHEAT application and EAP program, to be inaccordance with

STATE and\or Federal regulations

3. Review and improve eHEAT workflow process flow for all users of eHEAT

4. Improve financial operations within eHEAT at all levels

5. Improve program auditability of eHEAT at all levels

6. Automated reporting

7. Ability to create reports then update in future, integrate Tableau

4. Scope Detail

In Scope

Refactor the existing eHEAT application to align with Enterprise technical objectives

o Reusable components

Security (application features, authentication, authorization, user profile maint.,

administration)

Party (Person, Organization, Roles/Relationships, Address, Geospatial)

Data Access (service layer data abstraction)

Accounting (budgeting, Federal and State Fiscal year misalignment, funding

dollar movement tracking, payments, reconciliation)

Workflow (Case, Workflows, Notifications, Status, etc)

o Standards

User Interface (colors, fonts, logos, look & feel, search & results)

Administration of reference data

Submission of applications from households

o Enabling online electronic application via internet and mobile app o Accommodating accessibility for multiple languages (Hmong, Spanish, Somali) o Accommodating accessibility for disabilities o Accommodating applicants who cannot access services electronically and rely on

manual method allowing the ability to upload pdfs of the manual applications o Allow uploading of income documents if needed

Application Processing workflow

o Enable optimal & consistent application processing workflow o Consider standardizations o Upload scanned documents (Manual Applications, income documents, Energy

Registrations, Energy Agreements, Contractor Registration) saved to the database o Understand LIHEAP regulatory requirements to save applications o Notifications for events

Eligibility determination

o Getting and/or verifying income information o Verifying person identification o Accommodating access to applicants when automatic income or person identification

verification systems fail o Determine home ownership for ERR, will be exceptions ie contract for deeds

Benefits determination

o Processing emergency requests (Crisis and ERR benefits) o Obtaining consumption information(Real time and Front loaded) o Considering Primary Heat benefit formula, possible replacement algorithm o Supplement Modeling

A16/Responsive ESS

o Services and tools o Exploring methods for sharing information to enable access to other programs (e.g.,

allowing access to information necessary for eligibility determination).

Outreach tools

o Tracking and access to information Household addresses Track previous year applicants

Fiscal Management o Document process between eHEAT (Federal Fiscal Year) and SWIFT (State Fiscal Year)

Budgets are in SWIFT, eHEAT should have hard stops to comply with SWIFT budget

SWIFT (source of record), feed into eHEAT o Daily reconciliation between vendor payments and SWIFT on a daily basis o eHEAT and SWIFT in sync o Allocating to local service providers, vendors at line item detail o eHEAT generate the Notice of Funds Available (NFAs) to local service providers, instead

of COMM-Fiscal o Allocation tab equal the Notice of Funds Available (NFAs) on daily basis o Review Refund process o Review Batch job processing o Cash Requests

Internal Controls created Define cash requests to line items in the budget as opposed to lump sum. Need

tracebility to line items eHEAT application warning when request exceeds amount available by line item

o Payments

Payments to energy vendors and mechanical contractors Centralize ERR payments at SWIFT, requiring ERR contractors to register at

SWIFT o Reports

Cash Requests by time period Financial Status Reports (FSRs) Remaining balance by user defined time period Financial Status reports by local service providers (All budget categories)

o Expense tracking, by local service providers, by energy vendors o Final Financial Status Report (FSR)State FY, allow local service providers to mark as final

Energy Vendor interactions

o Gathering consumption and customer status o Program participation in others services (e.g. affordability, discount) o Consideration of non-electronic accessibility o Energy Vendor agreements (Online, ability to upload PDFs) o Energy Vendor registrations (Online, ability to upload PDFs) o Consideration of vendor monitoring

Consumption data

Payment data

o WorkFlow Review

Local Service Providers

EAP – COMM

Energy Vendors

o Review Crisis management process

Automate the ability to identify households pro-actively at local service providers , can work if a portal with vendor

Mechanical contractor interactions

o Explore means of: Communication Information about events (e.g., inspection information) Contractor registration (Online, or upload PDFs of manual applications) -

certification(s) (e.g., W-9) & possible agreement Develop minimum State Procurement rules

Centralize payments at SWIFT

Access to information

o For performance management, Quality control, reporting, program auditing, and vendor monitoring

o Create dashboards, must define

Security

o System Security

Technical security: firewalls, encryption etc. Review Program security

Review Privacy of personal data stored and viewed in the system

Identify and Document sensitive data (SP specific data, personally identifiable information, customer specific data, etc.)

Define and Document which features should expose which sensitive data

Document which role types should have access to each sensitive data feature

o User security management

Program assessment of information security top to bottom

Use Commerce Enterprise Security Component for

Authentication

Authorization

Online verification

Password and user profile updates

Administrative reset of password

Suspension/reactivation of user account User agreements

Software feature access control Define user roles

Assign users to roles

Access expiration

User list audit capability

Notification & communication

o To households Historical Usage Proof of eligibility

o Local Service Providers o Energy Vendors o Mechanical contractors

User support

o Including training, end user applicant user support, energy vendors etc.

o Online help

o Requirements defined to provide end user support for end user online

Development of production support

o Transition to institutionalized system and on-going training and user support for applicants, Service Provider staff, and energy vendors, etc.

Integration

o WAP software Send eligibility data to WAP Send Consumption data Receive information on Households using LIHEAP funds Details to be provided by WAP, one file need to determine real time or batch Program auditing

o Service Provider data systems (CAP 60, THO, Client Tracker, CSBG annual reporting) o Energy Vendor portals o Development of A16 program o SWIFT o Fiscal department systems (State and Local Service Provider) o Address Checker o Increase integration with Tableau o Communication software to facilitate email\text communications with end users o DEED, DHS ( as possible provider of income verification) o DPS, DHS or SSA ( as source of identity verification) Lexus Nexis? o County Assessor of home ownership verification for ERR(If master at State)

Program Audit Capability o Re-design Program Audit Trail throughout all layers of the program to adopt to program

changes Access to audit information Integrating audit examination tools Inspection tools Audit Reporting

o Program Audit trail created by end user actions (must define in requirements)

Data Analytics o Program staff will provide details around reporting and visualization requirements

during the requirements phase. (reporting needs will dictate some of the information that needs to be collected.)

o Provide data mart structure for Tableau o Addresses will be verified and associated with political boundaries and census data

Out of Scope

(WAP) Weatherization Assistance Program done in a separate software application

5. Roles and Responsibilities

Personnel Resource Types Quantity

COMM EAP Team – Business Owner .75

COMM EAP Team – Audit Team Members .50

COMM EAP Team – Mgmt. Analysis Staff .50

COMM EAP Team – Other .50

COMM EAP Team – Energy .50

COMM EAP Team – AS16\Analytics .50

MN.IT COMM – PM 1.00

MN.IT COMM – Application SME .75

MN.IT COMM – in House Developer .75

MN.IT COMM – Architect .15

MN.IT COMM – Security .10

MN.IT – Central(Middleware, Secure Development and Database) .30

MN.IT COMM – Application Manager .25

MN-IT COMM – Division Manager .10

MN-IT COMM – External Developers 4.00

MN-IT COMM – External Business Analysis 2.00

MN.IT COMM – External Quality Assurance 1.00

MN-IT COMM – External Documentation Expert 1.00

Service Providers – Subject Matter experts 2.00

Total Personnel Resources 16.45

Solutions Architect Requirements

Software Architecture Requirements Specification

eHEAT Next Generation

Document Versions

Project Overview

Business Capability Requirements

Features

Party

Party is the generic term for persons and organizations. Managing parties will be consolidated into a

single component.

Payments

eHEAT payment capabilities will be encapsulated into a component that interacts with SWIFT, and

provides user access to system features related to payments.

Locations

Data related to physical locations will be managed within the Locations component. This includes

Addresses, GPS coordinates, and membership of points in geographic polygons such as service areas,

counties, political districts, etc.

Case Tracking

Applications go through a workflow until they are eventually completed. Tasks, communications, and

Information about this work will be managed in a single component. Need a workflow management

framework.

Technical Capability Requirements

Security

User Group Definition

Organization Type = Energy Service Provider

Organization Name

Inactive user minutes Auto log out

inactive user days auto lock

Sub groups

User Types

System Admin

Security Admin

Staff

Customers

User Group Hierarchy

The top of this hierarchy, though implemented in the database as data records, must adhere to this

structure so as to control how users are added into the system and keep access to organization specific

records limited to those authorized to see them. This is how users are classified in the system.

External anonymous user

Not managed by the security system. Can only access published data.

External User Login

Households

Household Representative

Service Providers

Provider

Organization Type = Energy Service Provider

Organization Name

System Admin

Security Admin

Staff

Energy Vendors

Energy Vendor

Organization Type = Energy Vendor

Organization Name

Security Admin

Staff

Contractors

Contractor

Organization Type = Energy Contractor

Organization Name

Security Admin

Staff

Commerce

Program

Organization Type = Commerce Program

Organization Name = Commerce EAP

Program Manager

Program Staff

Program System Administrator

Program Security Administrator

Fiscal

IT

DBA

Developer

Security Access Features

Defined by the developer and approved by the Program Manager. Each feature is an atomic unit of

access control that defines the nature of what a user who has access to this feature is permitted to see

and do.

Feature Name

Feature name in the security database tables must match what source code calls the feature

Application Name

The name of the application = eHEAT.

Feature Flags

Feature limits records to those belonging to the user’s organization.

Feature allows user to add records

Feature allows user to delete records

Feature allows user to change records

Feature allows user to view records

Feature allows user to export records

Feature can be undone via user action

Feature allows user to change administrative reference data

Feature allows user to change security information

Feature exposes user to sensitive data

Feature exposes user to personally identifiable information

Feature is intended for internal commerce use only

Security Capabilities

Automated Processes

Notify User Group Supervisors to audit the User Group user list

Authenticate User

Authorize User Access Rights

Lock out User based on log-in attempts

Commerce Program Manager

Review and Approve changes to Security Access Features.

User Group Supervisor

Audit user group list

Indicate which users should still have which access

End user

Request a login account

Login

Modify security questions

Modify password

Request password reset

Add/Remove/Update email addresses

Change Display Name

Security Admin

Add User

Indicate whether or not user is in LDAP

Add User Group

Add User Group Supervisor

This is the person responsible for reviewing and approving the users in their group on a periodic basis.

Associate System Features to User Groups

Associate Users to User Groups

Grant admin privileges for a user group

Suspend a user

Suspend a user group

View user/user group activity

Force a password reset

Lock/unlock accounts

Set password expiration days

Set password strength requirements

Set number of lockout attempts

Set expiration duration for automatically locking an inactive user account

Set duration for automatically logging out an inactive user

Update which users still have which access based on User Group Supervisor recommendations.

Developer

Define Security Access Features

Principles

Configurability

Changes expected to occur no less than annually must be managed via data configuration by the

Commerce Program System Administrator.

Configuration must be achievable through software that ensures changes do not violate system

assumptions.

Maintainability

The source code must be organized into cohesive components approved by the Commerce MN.IT staff

who will be responsible for ongoing maintenance.

Technical capabilities will be organized into cohesive components that are each managed independent of

each other and of business capabilities.

Business capabilities will be organized into cohesive components.

Changes made to one component shall not require another component to be modified, unless they

component is adding something new that is necessarily directly consumed by a dependent component.

Observability

The system usage must save monitoring data through regularly occurring logging and via database

timestamps and userIDs.

The system must provide UI tools to view a dashboard of system performance, volume, user access.

Communication

The system must provide helpful communication to users when the back end of the system is down for

any reason.

The system must provide Commerce Staff to see which users are logged in.

The system must provide a means for Commerce staff to communicate with currently logged in end users

via instant messaging.

The system will provide user documentation access on line that enables them to resolve most user

questions.

Controllability

System administrator tools from within the firewall

The system must provide UI tools to safely shut down the system without losing currently logged in users’

data.

The system must provide UI tools to force specific individual users to log out.

The system must provide UI tools to force specific groups of users to log out.

The system must provide UI tools to restart the system.

Changeability

Changes fall under these categories: User changes, Anticipated Admin Changes, Unanticipated Admin

Changes, Anticipated Developer Changes, and Unanticipated Developer Changes.

User Changes

User Changes include normal use of the system and could involve the user changing their own security

questions or password, or could include Commerce Staff making non administrative changes to vendors,

contractors, etc. All User changes must be documented via use cases.

Admin Changes

UI based Admin Changes include changes that can be made to reference data tables through

administrative UI tools. Admin changes occur less frequently that user changes but frequently enough to

have been anticipated through reference data designs and administrative UI tools. All UI based

administrative changes must be documented with use cases if they are done via a user interface. UI

based admin changes can be delegated to Program System Administrators.

External Admin Changes include changes that can be made to reference data tables through other

administrative tools. These admin changes occur less frequently that UI based admin changes but

frequently enough to have been anticipated through reference data designs. All external administrative

changes must be documented with change cases. The change case will describe exactly how the admin

will make the change. External admin changes might require DBA intervention. These changes are small

enough to be paid for through the normal maintenance budget.

Developer Changes

Anticipated Developer Changes require code changes by a developer but have been anticipated via the

code design by making these sorts of changes as quick and risk-free as possible. These changes are

easily made by developers with minimal risk. Anticipated Developer Changes must be documented as

“Change Cases” that describe how such changes should be made in accordance with the flexibility

inherent to the design. These changes are small enough to be paid for through the normal maintenance

budget.

Unanticipated Developer Changes require code changes that were not in any way thought of by the

initial designer of the system. These changes are high risk and require project funding.

Design for Change

1. The system will be designed so as to minimize the probability of unanticipated developer

changes through highly cohesive and lowly coupled source code design that anticipates the

most likely types of code changes. This will be accomplished through the prudent use of design

principles, patterns, frameworks and libraries.

2. The system will be designed so as to minimize the requirements for developer changes through

data driven design that enables most changes to be made through configuration data.

3. The system will minimize the need for external admin changes through the development of UI

based admin tools.

4. The system will be designed so as to minimize UI based administration tasks to those tasks that

affect multiple user groups and that normal users should not be permitted to do.

Extensibility

The system will be designed so as to follow the Open-Closed principle. Open to addition but closed

to change. In doing so, the system will be designed to favor adding new features through plug-ins

without breaking existing features.

The system will be designed so that the addition of new features will have a minimal impact on existing

features.

The system will be designed so that the addition of new aspects that must touch multiple capabilities, can

be done as a plug in to the existing capabilities.

Scalability

The system will be designed so that adding new server resources to accommodate an expanding user

base is easy.

Scoop-ability

The software third party source code world changes at break-neck speed and nothing that was deemed

irreplaceable 5 years ago, is still viewed as such today. Despite the ease with which new development

can be achieved by embedding source code dependencies on third party technologies, it is extremely

difficult to replace them when they fall out of favor. Therefore, the system must be designed so as to

minimize the cost, time, and effort of upgrading/replacing third party technologies such as middleware,

libraries, frameworks, etc., by minimizing direct dependencies on third party technologies through

abstraction layering.

Testability

The system must be constructed to facilitate rapid testing by developers and testers.

Deploy-ability

The system must be constructed so as to facilitate rapid deployment and rollback if needed.

Layering

Industry best practices indicate that software systems of this scale should be subdivided into manageable

cohesive pieces. This is done in two dimensions: business and technical. For the eHEAT system, the

spring frameworks will be used to enforce layering according to industry best practices.

Business Area Isolation

Business compartmentalization is aligned with cohesive business tasks and data that work together.

Technology Isolation

Technical compartmentalization is aligned generically in terms of common tasks that all systems of a

similar profile might have. This is done to minimize any downside of unexpected change requests. Since

storing and retrieving data is highly dependent upon changing database technology, and marshalling and

un-marshalling data in a user interface is highly dependent upon ever changing User Interface

technology, a method of decoupling changes to these technologies is required.

Layering

Layering is done as a method of decoupling User Interface technology changes from database

technology changes. The following layers will be built in the new system.

Presentation Layer Requirements

The presentation layer represents the portion of the software responsible for interacting with the end user.

It displays information, collections user data, and actions, and interacts with the business layer in

accordance with the users security profile.

UI Rendering

The user interface will be based on Java Server Faces (JSF) and controller objects to directly move data

into and out of the user interface without any integration complexity.

Data Validation

Simple data validations such as required fields and data type validations will be done via the user

interface.

User Security

Users will only be provided access to the Security Features that they have been granted via their login. A

session id will follow all data movement into and out of the user interface and through the layers to the

database. The session will retain the last action time stamp so that the session can be made to time out if

appropriate for the user group.

UI Data Transfer

Data will be moved into and out of the user interface in structures that are exactly aligned with the needs

of the user interface. This data will come from or go to the business domain layer.

Business Domain Layer Requirements

The business domain layer will be responsible for decoupling the user interface layer from the persistence

layer through translation of data when the database is organized differently than the design of the user

experience. In Spring, this is referred to as the Services.

Translation

The business domain layer will add any logic required to translate between the data structures of the

Presentation Layer and those of the Persistence Layer so that each of those layers can focus on their

own purpose without having to deal with restructuring.

Business Rules

Enforcing the users session security profile will be done in this layer.

Complex data validations and adding security filter constraints to data requests are done in the business

domain layer.

Persistence Layer Requirements

The Persistence layer is responsible for moving data between the software and the database without

exposing any database technology specified code dependencies to the rest of the software. Database

security access is performed in this layer. System Passwords that access the database are encrypted and

maintained in a protected location. In the Spring Frameworks, this is the job of the Repository classes and

the ORM classes.

Persisted Object Representation requirements

Database records will be represented as objects where appropriate.

Database views and sets of views will also be represented as objects where appropriate.

These objects map to tables, views, and stored Procedure data sets in the exposed portion of the

database.

Maintainability requirements

Adding new columns to database

This will only affect the persistence layer if it needs to use the new data.

This will only affect the business domain layer if it needs to use the new data.

Adding new tables to database

This will only affect the persistence layer if it needs to use the new data.

This will only affect the business domain layer if it needs to use the new data.

Modifying existing columns in database

This will only affect the persistence layer if it needs to use the columns.

This will only affect the business domain layer if it needs to use the columns.

Data Storage Layer Requirements

The data storage layer represents the database as well as any network storage used by the system The

data storage layer itself will have some complexity in terms of structures that should be shielded from the

rest of the system where possible.

For eHEAT, the database will be based on the existing database initially and then ETL processes will

move data to the warehouse.

Data Warehousing

Extract-Translate-Load (ETL) requirements

Moving data into the warehouse will happen via scheduled ETL processes that move data from one

database/schema to another while translating the data into the new structure.

Data Structural Requirements

The warehouse will have data structured for ease of use in reporting. This structure will be optimized

based on analysis, reporting and visualization requirements.

The design will minimize the need for many similar reports by providing highly useful views of the data

that can be easily filtered in the reports.

Reporting tool Requirements

Reporting tool must be easily configured by the end user to filter reporting data.

Reporting tool must adhere to the data security requirements of the system data.

Visualization will be performed using the Tableau software.

External Data Interface Layer

Commerce has constructed a framework for external data interfacing. This framework will be

used/extended for all eHEAT B2B traffic.

The system will provide administrative capabilities of the EDI component.

Business Continuity

See the disaster recovery document for eHEAT.

Performance

Allowable lag times

3 seconds for small data sets

30 seconds for larger data exports.

Progress bar will be provided to show that the system is still working

Concurrent user capacity

Total Users Expectation

Expected daily volume

Availability

Scheduled down times

The system will be unavailable at a recurring time each week.

Interfaces

High Level Architecture Framing

eHEAT

Spring

JPA

Security

Hibernate

SQL

SQL

Entity

ORM

Repository – access objects and tie them

together

Service – prepare object for controller

Controller – UI Data in and out of Objects –

Manage HTTP requests, responses,

sessions

View

Java Server Faces – rendering HTML

Configuration FilesORM

ORM

Entity Class is Mapped to a table

ORM

One to one mapping

<<Comment>>One to one mapping from Java Classes to

TablesCan Generate skeletons for the Entity

Classes. Use reverse engineering generator that

converts tables to Entities.

Enterprise Database

ETL Warehouse - EDI

Existing Tables New Tables

SQL

SQL

Configuration Data

SQL

<<Comment>>Synchronize eHEAT

with Enterprise Database

ETL

Party

SWIFT Interface

EDI

Payments

GIS

Address Validation

Geocoding

Point in Polygon

Data Access Framework

UI Framework

Testing Framework

Reporting Framework

Common Architectural Components

High Level Conceptual Architecture