request for offers (rfo) addendum - minnesotamn.gov/buyit/14atm/rfo/rfo0298a.pdf · q: are you open...
TRANSCRIPT
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:
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.
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