SACSSRRFI A3SACSSR PS TC

mountainromeInternet and Web Development

Oct 31, 2013 (4 years and 12 days ago)

115 views

RFI CDE 6110
-
99

California Department of Education

SACS RFI








Appendix 3



Page
1

SACS

S
YSTEM
R
EPLACEMENT
RFI

1

A
PPENDIX
3



SACS

S
YSTEM
R
EPLACEMENT

2

P
ROPOSED
S
OLUTION

3

T
ABLE OF
C
ONTENTS

4

Proposed Solution

................................
................................
................................
.......................

2

5

Business Outcomes

................................
................................
................................
................................
...........................

2

6

Conceptual Design
................................
................................
................................
................................
.............................

3

7

Business Components of the Proposed Solution

................................
................................
.............................

4

8

System Administration

................................
................................
................................
................................
..................
4

9

Maintain the System and Infrastructure
................................
................................
................................
................
5

10

Maintain the Application Software
................................
................................
................................
...........................
5

11

Manage and Maintain Business Rules

................................
................................
................................
.....................
5

12

Configure Workflow Engine

................................
................................
................................
................................
........
6

13

Prepare, Validate and Report UA Data to the Reviewing Agency

................................
...............................
6

14

Certify and Submit UA Data to CDE
................................
................................
................................
..........................
7

15

Review and Validate UA Data

................................
................................
................................
................................
.....
8

16

Publish LEA UA Data
................................
................................
................................
................................
.......................
9

17

Budgets and Interim Reporting

................................
................................
................................
................................
.
9

18

Technical Components of the Proposed Solution

................................
................................
...........................

9

19

Hardware

................................
................................
................................
................................
................................
.............
9

20

Software

................................
................................
................................
................................
................................
............

10

21

Technical Interfaces

................................
................................
................................
................................
.....................

10

22

Information Security
................................
................................
................................
................................
....................

11

23

Confidentiality

................................
................................
................................
................................
................................

12

24

Data Center Consolidation

................................
................................
................................
................................
........

12

25

Backup and Recovery

................................
................................
................................
................................
..................

12

26

System Maintenance

................................
................................
................................
................................
....................

12

27


28

Figure 1
-

SSR Conceptual Design
................................
................................
................................
................................
................

4

29


30

Table 1
-

SSR Hardware
................................
................................
................................
................................
...............................
10

31

RFI CDE 6110
-
99

California Department of Education

SACS RFI








Appendix 3



Page
2

Proposed S
olution

1

This section provides

a conceptual overview of the future SSR, as envisioned by CDE. The
2

proposed solution presented in this section does not constitute a definition of system
3

requirements.

4

The
SSR, which will be hosted at OTech under the Applicat
ion Hosting environment,

will replace
5

the existing four, separate components that constitute the current SACS System: SACS
6

Software, eTransfer, Workflow, and SACS Maintenance. The
SSR will
integrate the functions of
7

the four components into a single, Web
-
b
ased system and will add functionality that streamlines
8

the LEA reporting process for both LEAs and CDE FAIS staff.

The
SSR

will
ensure that CDE
9

collect
s
, review
s
, and disseminate
s

LEA financial data
efficiently and accurately

for years to
10

come.

The
SSR
solution
will
allow CDE to continue reporting financial data to many divisions
11

within the Department
, to the state and federal government, and to the public. It
will enable

CDE

12

to meet it
s
present
objectives and requirements, yet
will be

scalable and flexi
ble enough to
13

accommodate future

workload

increases
and

legislative changes
. Finally, t
he
SSR will
automate
14

charter school financial data

collection and will facilitate analysis and oversight of LEA fiscal
15

solvency
.

16

Business
Outcomes


17

FAIS'
s

core mission
will
continue to focus on timely and accurate collection, review, and
18

reporting of LEA financial data and
on
LEA fiscal oversight.

CDE anticipates the following
19

business outcomes from the proposed solution. The SSR will:

20



Allow all LEA financial data repor
ting and review activities to be completed using a
21

single, Web
-
based system.

22



E
liminate all
SACS S
oftware downloads, installations
,

and upgrades by LEA and CDE
23

users, as CDE
will
perform updates to the centrally located multi
-
user
W
eb
-
based
24

solution. Once u
pdates are applied to the production Web
-
based system they
will be

25

instantly available to all
user
s.


26



A
llow
multiple users, both within a single
LEA

and across all LEA
s
,

concurrent access

to
27

LEA financial data
.

28



Provide

LEAs online access to their historical financial data and the business rules
29

applied to the data at that point in time
.

30



Allow
CDE
to

update business rules,
workflow

configuration
,

application code, and
31

reports in
a single

system.

In many cases updates
wi
ll

not require programmers due to
32

the configurable nature of the proposed solution.

33



Support charter school reporting in both the SACS
F
ormat and the
Charter School
34

A
lternative
F
ormat
.

35



Further automate th
e LEA budget and interim reporting processes
,

reduci
ng or
36

eliminating the need for LEAs to mail printed paper copies or e
-
mail electronic media to
37

their reviewing agencies.

38



Route
information between
reporting entities, reviewing agencies,
and CDE to
support
39

conducting and tracking

a variety of tasks includi
ng data submission, certification,
40

review, and approval

via a single workflow component
.

41

RFI CDE 6110
-
99

California Department of Education

SACS RFI








Appendix 3



Page
3



Leverage existing enterprise services, software, hardware, and network
s

to the extent
1

possible
.

2



Comply

with CDE standards including software, hardware, security, Int
ernet, software
3

development, enterprise architecture, and other applicable standards.

4



Maintain
target 98.5
%
(or the most current target rate published by OTech) system
5

availability
for at least 18 hours per day (hours determined by CDE)
seven days per
6

week
.

7



Allow the software to be configured and maintained
100% by CDE staff
.

8



Include

documentation
with
sufficient detail that new or backup support staff could
9

completely support the solution in accordance with CDE Data Management policies.

10



Manage with maximu
m workload of potential concurrent users while maintaining
11

minimum performance objectives.

12



Enable CDE staff to provide comprehensive and timely responses to financial data
13

inquiries from stakeholders.

14

Conceptual Design

15

The
Web
-
based SSR
solution
will
allow

all stakeholders to
perform their fiscal oversight and
16

financial data reporting and reviewing activities using a single, integrated system

that is
17

accessible
from their existing environments
using standard Web browsers
.

The
SSR will
provide
18

a
Web
-
based workspace for
:

19



California reporting entities

to perform all activities related to
statutory
budget
,

interim
,
20

and year
-
end financial

reporting,
including
financial data upload, preparation, validation,
21

review,
and submission

to reviewing agencies.

22



California reviewing agencies to perform all activities related to LEA and charter school
23

statutory budget, interim, and year
-
end financial report review and submission to CDE.

24



CDE to perform all activities related to providing the statutory format used
by California
25

LEAs and charter schools for budget, interim, and year
-
end statutory reporting; to
26

conduct its own fiscal oversight activities; and to maintain and manage the SSR system
27

software, business rules, database, and administrative functions.

28

Figure

1

-

SSR Conceptual Design

provides a conceptual overview
of
the
SSR design
. This
29

solution
will be

robust enough to manage the day
-
to
-
day
CDE FAIS bus
iness
functions and
to
30

store
and allow access
to
up to
10 years of
published

financial data

and each year’s associated
31

business rules
.

32

RFI CDE 6110
-
99

California Department of Education

SACS RFI








Appendix 3



Page
4

Figure
1

-

SSR Conceptual Design

1


2

Business Components of the Proposed Solution

3

This secti
on presents CDE’s vision for how the SSR will satisfy major business functions. It is
4

important to emphasize that this is not an exhaustive list of all business functions or details and
5

that

the solution presented in this section does not constitute a defi
nition of system
6

requirements.

7

System Administration

8

System administration encompasses functions such as
adding users, removing users, and
9

managing user permission, access, and passwords.
“Super users” will manage

system
10

administration locally. For example, one CDE super user
may
manage the other CDE users

and
11

RFI CDE 6110
-
99

California Department of Education

SACS RFI








Appendix 3



Page
5

LEA super users
.
E
ach
COE may have

one or more
super users who manage

the COE

users
1

as well as those of its reporting entities.

2

System administration duties

also include maintaining underlying business data to support other
3

system business functions. For example, from year to year, charter schools and districts may
4

merge, lapse, or reorganize, which impacts how their data should be reported. The SSR will
5

acco
mmodate these changes while retaining historical accuracy for reporting purposes (e.g.,
6

merged districts are only merged from that point
-
in
-
time forward; their past data remains
7

separate.)

8

Maintain the System and Infrastructure

9

In coordination with CDE, OT
ech staff will maintain the SSR system hardware, software, and
10

infrastructure, which include such activities as applying patches and performing system backups
11

and server maintenance. All application software will be maintained by CDE.

12

Maintain the Applicat
ion Software

13

CDE FAIS technical staff will maintain and enhance the application software. Software
14

maintenance activities include fixing defects and enhancing application capabilities as well as
15

testing and releasing the updated software. FAIS program staf
f and LEA end users may submit
16

change orders, outside of the SSR, to request fixes and/or enhancements. Additional activities
17

will include using a GUI to update and maintain the User Guide and to tie specific sections of
18

text from the User Guide to the app
ropriate locations in menus, screens, and forms, based on
19

context, so that when the user requests help, the appropriate text from the User Guide is
20

displayed.

21

Manage and Maintain Business Rules

22

Business rules will be a major component of the SSR because
they will embody the criteria
23

used to assess LEA fiscal solvency and prescribe how financial data should be reported.
24

Business rules will be used extensively throughout the system and will take several different
25

forms. Simple business rules may include enf
orcement of valid values in a data entry screen
26

and calculations using a combination of user
-
entered and stored data values. More involved
27

business rules may address such things as user
-
maintained validation tables that define valid
28

SACS code combinations
or submission data set formal acceptance criteria. Complex business
29

rules may include the various IFCs, TRCs, and event
-
triggered system recalculations, which are
30

a combination of user
-
configurable data elements and code that performs complex calculations
31

and defines and enforces criteria for meeting specific business conditions. Sample business
32

rules may be found in
Appendix X

(TBD)
. The proposed solution will provide a GUI giving CDE
33

the ability to establish, configure, test, maintain, and apply all of th
e necessary business rules,
34

which may differ for each fiscal year, reporting period, data type, and entity type/subtype.

35

Prior to the start of a new fiscal year, CDE FAIS staff will use the current year business rules to
36

establish a starting point for the

calculations, forms, TRCs, IFCs, and validations in the
37

upcoming year. CDE staff will add/remove fields, add/edit/remove forms, and update the
38

business rules and validations for the upcoming year. After the rules have been thoroughly
39

tested in a test envi
ronment, CDE staff will deploy, or release, the new year’s version to the
40

production environment for use by LEAs in preparing their budgets for the upcoming year.

41

RFI CDE 6110
-
99

California Department of Education

SACS RFI








Appendix 3



Page
6

Business rules may change after a release deploys, for a variety of reasons, including when a

1

business rule is erroneous or when new legislation passes that impacts financial reporting rules.
2

Rules may also change as a result of a change in FAIS business procedures, such as a
3

decision to modify the severity associated with a specific check or a ch
ange in the criteria that
4

must be met for a formal submission to be accepted by CDE for review. As part of maintaining
5

the business rules throughout the fiscal year, CDE staff will be able to modify existing business
6

rules or add new business rules in a te
st environment, re
-
validate production data based on the
7

new business rules, and then release the updated business rules to the LEAs. When the
8

updated business rules are ready to be deployed into production the system will notify all LEAs
9

of the business r
ule change(s), and provide information to the LEAs regarding how the change
10

will impact their fiscal data. There may be a formal release that updates business rules prior to
11

each new reporting period within each year, with minor fixes and updates applied u
ntil the
12

formal release for the next reporting period within that year.

13

CDE will have the ability to “snapshot” the business rules prior to the issue of a formal release to
14

ensure that, regardless of future business rule changes, CDE can view how the data

“looked” at
15

that point in time and be assured that when looking at data for that particular reporting period,
16

the correct rules in effect for that reporting period, that year, for that release, have been applied
17

to that data. When troubleshooting data iss
ues for LEAs, FAIS staff will have the ability to view
18

the LEA’s data through the filter of past business rules in a test environment. In other words,
19

FAIS staff will be able to view what selected current period data would look like if the
20

corresponding ru
les from a
prior

year were applied to it. When looking at or applying past
21

business rules to data, validation table values will be used based on the defined start and end
22

dates for each code combination. The more complex business rules will be applied base
d on
23

the applicable formal release for the selected reporting period.

24

Each year, the data submission relies on data values from the first and second prior year UA
25

data for some calculations. Occasionally, those values change outside of the system, after th
e
26

prior year data has been published. Published data may not be changed, but the new year UA
27

report must use the new values rather than what was published. So prior to releasing the
28

business rule updates each year, CDE FAIS staff will “pre
-
load” such data
by making a copy of
29

selected prior year data, manually modifying the copy, if necessary, and using the resulting data
30

in selected fields for year
-
end reporting functions, rather than the values stored in the system
31

from the prior year.

32

Configure Workflow
Engine

33

The Web
-
based SSR will employ a sophisticated workflow engine in order to moderate the flow
34

of data within and between reporting entities, reviewing agencies, and CDE, and to be able to
35

track the history of data submissions throughout the submission

and review process. CDE FAIS
36

program and technical staff will configure the workflow engine to ensure submissions are routed
37

correctly, queues are managed, and notifications are sent, when applicable. The business
38

processes discussed in the following subs
ections also elaborate on the expected function of the
39

workflow engine.

40

Prepare, Validate and Report UA Data to the Reviewing Agency

41

Near the end of the fiscal year, CDE will deploy any updated business rules applicable to the
42

UA reporting period and notif
y the LEAs that the system is ready for users to begin entering and
43

working with their year
-
end UA data, for submission to their reviewing agencies.

44

RFI CDE 6110
-
99

California Department of Education

SACS RFI








Appendix 3



Page
7

The process for LEAs to enter and work with their data will remain the same as with the current
1

system: th
e reporting entity will extract GL financial data from its local accounting system and
2

either import or key enter the data into the SSR. The LEA user will add supplemental data,
3

validate and test their data, troubleshoot issues, and make modifications and
re
-
import as
4

needed, depending on how the data was initially created in the system. The LEA user will
5

validate the data by running the data through the current set of TRCs and IFCs to identify which
6

data fail the business rules and why.

7

Unlike the current

system, the SSR will
allow multiple users from a single LEA to access the
8

same system and set of data, simultaneously, from individual workstations
, while maintaining
9

the integrity of interdependent data. Additionally, users from any level of the review p
rocess
10

(reporting entity, reviewing agency, or CDE) will be able to make one or multiple copies of a
11

data set to which they have read access for troubleshooting purposes, to run “what if” scenarios,
12

and to modify the data for other uses, without impacting
the submission dataset or copies made
13

by other users. Users will be able to re
-
import the data or copy portions of one data set into
14

another data set. This capability will allow multiple users to work on different sections of the data
15

and later consolidate

them into a single submission data set.

16

At any time during this process, if the reporting entity user is unable to “pass” all of the required
17

business rules and checks or to meet the criteria for submission to CDE, the user will be able to
18

seek assistance

from its reviewing agency and/or CDE by allowing them access to view or copy
19

the LEA submission data set outside of the formal “review” process. This will allow the reviewing
20

agency or CDE user to then run what
-
if scenarios and troubleshoot issues and pos
sible
21

modifications to the data without impacting the original submission data set or copies made by
22

others. To support these capabilities the system will allow users to enter and save data that
23

does not yet meet all business rules, but will not allow them

to make a formal submission until
24

all formal submission criteria are met.

25

The review process is iterative and may require several cycles of change and review, causing
26

the data set to pass back and forth between the reporting entity and the reviewing agenc
y
27

multiple times, using the workflow process, before it may be submitted to the reviewing agency
28

as the “submission data set.” Being “submitted” in the SSR will mean simply that it passes to the
29

next step in the workflow, allowing the reviewing agency to a
ccess the reporting entity data set
30

for statutory review purposes. Once the reporting entity indicates the readiness of the
31

submission data set, the SSR will notify the reviewing agency that the submission is in queue
32

for review. The reviewing agency will
be able to approve the submission, return the submission
33

for revisions (which may require the reporting entity to modify or reimport data), or, in some
34

cases, add additional data to complete the submission data set.

35

Certify and Submit UA Data to CDE

36

Sever
al levels of “certification” of the data will occur in the SSR throughout the reporting
37

process. The reporting entity will certify to its reviewing agency that its governing authority has
38

approved the submission data set. There are also some specific porti
ons of the submission data
39

set that will require separate specific written signature certification from the reporting entity.
40

Finally, the reviewing agency will certify to CDE that it is in receipt of all of the reporting entity’s
41

hard
-
copy signed certific
ations for the submission, if applicable.

42

Before a submission data set will be accepted by CDE for its formal review, the data set must
43

either pass all CDE acceptance criteria or receive prior CDE approval to be submitted without
44

meeting one or more speci
fic acceptance criteria. Once these conditions are met the reviewing
45

RFI CDE 6110
-
99

California Department of Education

SACS RFI








Appendix 3



Page
8

agency user will be allowed to “submit” the formal submission to CDE, the next step in the
1

workflow process. The system will notify CDE that the formal submission is in the CDE queue
2

for
review and is available to CDE users to access, review, and validate.

3

Once a formal submission is made, reporting entities will continue to be able to make copies of
4

the data set and make updates and changes for other purposes unrelated to the CDE financia
l
5

data review process.

6

Review and Validate UA Data

7

When the formal submission becomes available in the CDE queue it will enter CDE’s internal
8

workflow steps, accessible to CDE FAIS staff. While the submission is in CDE review the LEA
9

users will know only
that it is in CDE review, but not where it is within the internal CDE workflow
10

process.

11

When CDE FAIS reviewers log into the SSR to access formal submissions, the SSR will present
12

them with a dashboard that includes an overview of the submission queue as
well as relevant
13

information such as the status of formal submissions they are currently reviewing. CDE users
14

will review the submission in terms of both the objective system TRCs, and environmental
15

factors unique to the LEA. It is important to note that m
ore than one CDE user will have the
16

ability to review and comment on a submission, either in parallel or in serial workflow steps.
17

CDE reviewer comments, including the CDE reviewer’s username, will be viewable only by CDE
18

FAIS staff and not the LEA. Once t
he submission (or portion of a submission) is accepted by
19

CDE it will move to the next step in the workflow. At any stage of the review process a CDE
20

reviewer may send the submission back to a prior CDE reviewer or return the submission to the
21

reporting en
tity or the reviewing agency.

22

The proposed solution will accommodate the following two processing exceptions:

23



CDE Edits to Submission Data



Most of the time, when a CDE reviewer identifies an
24

error or issue with the data the reviewer will return the subm
ission to the reviewing
25

agency for modification and resubmission. However, there are occasions when time
26

does not permit a resubmission. In those instances, the CDE reviewers will have the
27

ability to make a copy of the submission, make the needed edits and

comments to
28

explain the revision, and then replace the original with the updated copy to become the
29

new formal submission. This process may happen several times. In each case, the prior
30

formal submission will be saved in case it needs to be reverted back,

until such time that
31

CDE chooses to purge all prior submissions. Unlike LEA users, certain CDE users will
32

have the ability to make manual updates to copies of submission data that was originally
33

imported. The updated copy of the submission will not go thr
ough all workflow steps
34

again, but before the data is finalized the reporting entity must acknowledge that CDE
35

had permission to make the edits and that it has seen and agrees with the edits made.

36



Data Resubmission



There are times when a reporting entit
y or reviewing agency
37

identifies an issue after it submits the LEA’s formal submission. In these situations, the
38

LEA will have the ability to modify and resubmit its data through the SSR. The system
39

will flag the submission so CDE users are aware that a re
submission is in process.
40

When the updated data set is formally submitted, it will replace the prior submission. The
41

system will maintain the history and retain the original submission in case CDE and the
42

LEA must revert to the original submission.

43

RFI CDE 6110
-
99

California Department of Education

SACS RFI








Appendix 3



Page
9

As with

the current system, all formal submissions will be considered “draft” until the processing
1

period ends and CDE has completed its review of all reporting entity submissions. At that time,
2

the data will be considered “final,” may not be modified, and will b
e published.

3

Publish LEA UA Data

4

When the submission period closes, the CDE database administrator will export from the SSR
5

the statewide unaudited actual data into an Access database format. CDE will post the
6

database to the Internet for stakeholders to
download. In addition, the CDE users will publish
7

the data in a report form for public use.

8

Budgets and Interim Reporting

9

CDE and other reviewing agencies use b
udget and interim
report
data
submissions for

10

monitor
ing

LEA fiscal solvency and
providing

fisca
l oversight, rather than for statewide annual
11

reporting purposes.


12

Beginning around January of each year, LEAs will develop their budgets for the upcoming year.
13

Around May or June, they will upload their budget data into the SSR, enter supplemental data,
14

a
nd perform additional analyses. They will use the SSR workflow process to submit their
15

budgets to their reviewing agencies. The reviewing agency will conduct its review and will
16

approve or disapprove the budget, all within the SSR.

17

LEAs will use the SSR t
o input, validate, and submit to their reviewing agencies up to three
18

“interim” reports that further refine the LEA financial picture as the year progresses. Interim
19

reports, which include updated budgets and the LEA’s self
-
certification of fiscal solvency
, will be
20

submitted twice each year (December 15 and March 15), except for LEAs in fiscal distress, who
21

will also submit a "third interim" report (June 1) to their reviewing agency. The reviewing agency
22

will make an independent assessment and certification

of the LEA’s fiscal solvency. The
23

certification will be tracked and may be changed by the reviewing agency at any point
24

throughout the year. A copy of the interim report for LEAs experiencing fiscal distress will also
25

be sent to the State Controller.

26

Sep
arate business rules apply to budgets and interim reports. LEAs will use the SSR to run
27

TRCs and other validations, such as the Criteria & Standards for fiscal solvency, prior to
28

submitting their data to their reviewing agency. Approved budget and interim
reports are subject
29

to public review, by request, but the data will not be formally published by CDE.

30


Technical Components of the Proposed Solution

31

Hardware

32

The proposed hardware components in
Table
1

-

SSR Hardware

identify what CDE sees as the
33

minimum

installation environment needed to house the
SSR solution, which will be hosted at
34

OTech under the Application Hosting environment
.


35

The proposed solution
must
compl
y

with
all
CDE
and OTech
technical standards that are in
36

existence at the time of project
development and
execution.
OTech will host and maintain the
37

required hardware and server operating systems
.


38

RFI CDE 6110
-
99

California Department of Education

SACS RFI








Appendix 3



Page
10

Table
1

-

SSR Hardware

1

Solution Category

Hardware Component

Production

3

Servers



1

Database Server



1

Web Server



1 Application Server

Staging Environment

3

Servers



1

Database Server



1

Web Server



1 Application Server

Development/
Testing
Environment
s

3

Servers



1

Database Server



1

Web Server



1 Application Server

Software

2

The software selected
will
compl
y

with CDE technology standards to the extent possible.

3

Exceptions will have to be approved by CDE.
The

proposed solution will include software and
4

tools to accommodate the

following need
s:

5



Forms
management
to provide the ability to define, build, test, implement
, manage, and
6

store

forms

and form templates

in a
centrally located
collaborative software envir
onment.


7



Automated workflow management to provide
the
ability to define, build, test, and
8

implement automated workflow to support FAIS
and LEA
business processes.

9



Business
r
ule
m
anagement to define, deploy, execute, monitor, and maintain business
10

rules of

the proposed solution.

Allows decision logic (business rules) to be externalized
11

from core application code.

12



C
ustom data reporting and analysis.

13



S
erver operating systems
, which

may be "virtualized" so that multiple server operating
14

systems are housed on
a single server hardware installation at
OTech

to reduce
15

software and hardware costs and infrastructure impact.

16



S
tor
age of
all data and information for the proposed solution.

17



Software development tools to perform software customization, Web application des
ign,
18

database connectivity, and
automated
workflow
management
design.

19



Complex calculations that integrate with forms, reports, and business rules.

20

OTech will provide support only for the infrastructure software and not the application software.

21

Technical I
nterfaces

22

The
proposed

solution
will
include
limited
interfaces with
the following other

systems:

23

RFI CDE 6110
-
99

California Department of Education

SACS RFI








Appendix 3



Page
11



Fiscal and Administrative Services Division (FASD) Program Cost Account Schedule
1

System (PCASCH) database



Will o
btain PCA data
that

populate a field in the
SSR

2

database where SACS resource codes are tied to PCA items in the state budget.

3



California School Directory County
-
District
-
School (CDS) Code System
database


Will
4

o
btain changes to LEA information that are used to update LEA records in the
SSR
.

5



Charter

School Division Charter School database



Will o
btain changes to charter school
6

information that are used to update charter school records in the
SSR
.

7



CDE Data Resource Guide

-

Will
export the system's data dictionary to be used to assist
8

CDE's Data Manag
ement Division in the standardization of data elements across the
9

department.

10

No other interfaces are immediately planned within the proposed solution, however the
11

proposed solution
will
be flexible and scalable to allow for additional interfaces in the fu
ture
12

should the need arise.

13

Information Security

14

This new system
will
meet all current State requirements as outlined in the State Administrative
15

Manual (SAM), as well as CDE Information Security policies and standards. The proposed
16

solution

will

require users to log in with a user identification and password. The system
will
17

utilize role
-
based access control to limit access to functions, screens
,

data

and workflow steps

18

to authorized users. LEA

and CDE user
s
will
access the proposed solution thro
ugh a Web
19

browser on a public
-
facing Web site over the Internet.

Role
-
based security
will be

granted to the
20

different types of users based on their business need to access the system.

21

The
OTech
hosting environment
will
maintain a perimeter firewall to prot
ect systems from
22

inappropriate access. Appropriate software virus detection and Intrusion Detection (network and
23

host) software
will be

installed on the system's servers to protect against unauthorized access
24

and provide an additional level of information
security.

The proposed solution

will

include
25

security levels implemented using n
-
tier architecture with additional protections to adhere to the
26

security
requirements
.

27

Classes of users
will be

established, and the user login and authentication process
will
manage
28

access levels. These access levels

will

include
, at the minimum
:

29



Inquiry.

30



Additions.

31



Deletions.

32



Modifications.

33



Security maintenance (
e.g.,
creation or update of security profiles).

34



System maintenance (
e.g.,
table
-
driven system parameters).

35

CDE and O
Tech will maintain a security infrastructure that adheres to the requirements of the
36

State Administrative Manual and industry best practices. Because CDE and OTech maintain an
37

integrated LAN/WAN infrastructure, a high level of security will be enforced on
all IT systems
38

and data. CDE/OTech’s security infrastructure is rigorously maintained, tested, patched, and
39

kept current. The proposed solution must adhere to OTech’s security standards.

40

RFI CDE 6110
-
99

California Department of Education

SACS RFI








Appendix 3



Page
12

Confidentiality

1

The
finalized financial
data within the proposed solu
tion
will not be

confidential and
will

not
2

contain personall
y identifiable information
. However, the system
will
compl
y

with all applicable
3

statutes, regulations, and CDE policies with regard to privacy and confidentiality of the
4

information processed and maintained by and within the proposed solution.

5

Data Center Consolidation

6

This solution will comply with the State Adm
inistrative Manual Section 4982.1, which requires
7

CDE to use the OTech Data Center when consolidated data center services are needed. Using
8

the OTech Data Center services is also consistent with the California Performance Review
9

recommendation to encourage

the expansion of server hosting and management services at the
10

OTech Data Center.

11

The proposed solution will be installed and maintained at the OTech Data Center, which houses
12

all of CDE’s consolidated data services. OTech will be responsible for maintain
ing the hardware
13

and infrastructure, only.
The
SSR

will be

available for at least 18 hours per day (
hours to be
14

determined by CDE
) seven days per week, with a system availability target of 98.5% (or
the
15

most current
target
rate established by OTech), with
user support available during normal
16

business hours (such as 8 a.m. to 5 p.m. Monday through Friday).
If the system
fails because of
17

an infrastructure or hardware problem

during non
-
business hours, the system may

remain
18

offline until
OTech

staff can analyz
e and resolve the problem during normal business hours.

19

During the contract period the Contractor will be responsible for maintaining the application in
20

accordance with the service level objectives identified in the requirements. CDE will assume
21

responsibi
lity for maintaining the application following system acceptance or any contracted
22

maintenance periods.

23

Backup and Recovery

24

OTech

has standard backup and operational recovery procedures associated with all of its
25

online systems.
Additional backup and reco
very services are available as an add
-
on component
26

under the Managed Service.
The proposed solution
will be

consistent with the
OTech

backup
27

and operational recovery processes, practices, and policies associated with the implementation
28

of the production We
b
-
based solution.

The
Bidde
r
’s proposal

will
outline the appropriate
29

operational recovery and backup needs for the proposed solution.

The purchase of a disaster
30

recovery service from OTech will not be necessary for the SSR.

31

System Maintenance

32

Following CD
E system acceptance,

CDE
FAIS
technical
and program
staff
are expecting to

33

assume

responsib
ility

for the ongoi
ng maintenance of the SSR,

including updates to the
34

application software due to new or changed financial reporting requirements, updates to
35

busine
ss rules and forms,
and updates to
application coding
.
CDE
will
re
tain

sole
ownership of
36

the application source code in order to modify the code and maintain the system without
37

dependence on the development vendor
.

However, to accommodate for unforeseen
38

circumstances, the Bidder is expected to include in its Cost Proposal estimated costs to provide
39

ongoing system maintenance for up to four (4) years, each year at the sole option of CDE.

40