The State of Arizona’s
Enterprise Architecture (EA) describes a comprehensive framework for
information technology (IT) and business that supports the Arizona State
government strategic plan. EA facilitates the application of information
technology to business initiatives and objectives and subsequent change in an
orderly, efficient manner by describing a direction for current and future
activities, supported by underlying principles, standards, and best practices.
EA effectively supports and enhances the
business of government and improves the ability to deliver responsive,
cost-effective government functions and services. Effective utilization of
technology to achieve business functions and services, increasing citizen
access to those services, sharing information and resources at all levels of
government, and maximizing IT resources investment are major motivating factors
for the development and implementation of EA.
The implementation of EA presents
opportunities for State agencies to interoperate together to deliver a higher
level of courteous, efficient, responsive, and cost-effective service to the
citizen owners and employees of State government. Individually, each State
agency can independently implement EA components that are interoperable,
however, e-government initiatives, economies of scale, consolidation, and
cross-agency savings may best be realized not just through interoperability,
but also by working together in partnership and sharing.
EA
includes important business, governance, and technical components. The
technical components, collectively referred to as Enterprise Wide Technical
Architecture (EWTA), provide technical guidance to State agencies. That
guidance is supported by principles correlated to agency business functions,
recommended standards, applicable recommended best practices, and technology
trends. Each
component, or domain, of the EWTA is a separate but interrelated, architectural
discipline. EA is the glue that integrates each of these technical disciplines
into a cohesive framework having the potential to transform government by
improving service delivery, reducing costs, simplifying and streamlining
requirements and services, and increasing efficiency and effectiveness.
EA applies to all agencies. The agency
director, working in conjunction with the agency CIO, is responsible for
ensuring the implementation of EA within the agency’s “sphere of influence,” as
designated by statute or rule. The EA Target Domain Architecture documents
define an overall strategy and technical framework; however, by design, the
capital planning, process approach and timeframes for transition, project
management, and investment control for the implementation of the target
architectures are the responsibility of the agency.
Implementing EA requires significant capital investments. Arizona,
like most states, does not have unlimited capital to invest in implementing EA,
therefore, migrating to EA within available budgets is the only viable method.
The State of Arizona’s Platform
Architecture describes a reliable, scalable, interoperable set of physical and
logical technology platform devices to implement and support the State’s
business functions in an efficient and effective manner. Platform Architecture
provides the interrelated IT devices necessary to implement, process, and
support agency business functions, enable new business opportunities, and
provide new methods for delivering service.
Platform
Architecture describes common, industry-wide, open-standards-based,
interoperable devices, facilitating the reliable and pervasive availability of,
access interfaces with, and processing for, the State's distributed information
processing environment. It defines various technologies required to facilitate
and deliver individual agencies’ and the State’s business application systems
and services to its citizens. It provides for increased interoperability with
the federal government, counties, local governments, and the private business
sector. Platform Architecture allows the State and individual agencies to
quickly deploy and support effective and efficient end-user access interfaces
to business application systems, as well as providing the processing capability
to execute business application systems, while increasing the use of
e-government solutions and maintaining traditional methods of service delivery
to citizens.
Target Platform
Architecture addresses platform devices relative to their: versatility,
capability to seamlessly interoperate with other platform devices, operating
systems, embedded security, adherence to open or pervasive industry standards,
provision for open system standard interfaces, and utilization of open standard
drivers. This approach aligns with Statewide
Policy P100, Information Technology, by focusing on the functionality
of platform technologies to support agency business requirements that enhance
agency services and operational capacities, improve productivity, performance,
and public services rather than addressing attributes such as specific platform
configurations, explicit devices, and operating system revisions that neither
provide a direction for current and future activities nor directly relate to
the State’s business functions.
Appendix A,
Platform Architecture Assessment Form, codified in Statewide
Standard P720-S720, Platform Infrastructure, expands upon the categories summarized below to establish the
methodology for determining an agency’s platform technology position. The
assessment is designed to demonstrate Statewide
Policy P100, Information Technology, through the incorporation of the
underlying principles, standards, and best practices of Target Platform
Architecture as well as Statewide
Policy P800, IT Security, and applicable Statewide security standards. Current,
representative scoring
of the State’s “as-is” platform assets
demonstrating the application of the Platform Architecture Assessment Form is available
at http:/www.azgita.gov/enterprise_architecture/NEW/platform_assess.htm.
Platform Architecture
Assessment Form Summary
|
Device Category
|
Description
|
|
1. Versatility
|
Provides flexibility, adaptability, and scalability without
substantial modification
|
|
2. Operating Systems
|
Utilizes open- or pervasive-industry-standard operating systems
|
|
3. Operating Systems Security
|
Addresses the security functionality of Operating Systems
|
|
4. Open Standard Interfaces and Drivers
|
Adheres to open-system-standard interface specifications and utilizes
device drivers with IEEE interfacing and industry de facto standard protocols
and formats
|
Target Platform Architecture is
vendor/manufacturer neutral and strategic by design. As such, it does not
attempt to identify or address specific device or operating system
manufacturers or distributors. Statewide
Policy P720, Platform Architecture Policy, and Statewide
Standard P720-S720, Platform Infrastructure, technologies identified in the Target
Technology Table, as well as applicable Statewide IT security standards guide the State
and agencies in selecting platform architecture products and services, and
making informed judgments when specifying and choosing solutions to meet
current and planned requirements. An individual agency’s selection of
specific manufacturers, platform hardware configurations, and operating systems
within these parameters is based on the business needs of a given project, a
positive business case, or the overall business requirements of the agency.
The development of Target Platform
Architecture and related Statewide IT policies and standards are ongoing, collaborative
processes
that encourage the continual refinement of the architecture, IT policies, and
standards to ensure continued alignment with evolving business strategies and
requirements of the State, emerging industry standards, and changing
technology. This allows agencies to participate in the process to maximize
their current investment in certain devices and services, and to develop a
transition plan to
allow obsolete or non-conforming platform elements to be phased out. Maximizing
the investment benefits and transitioning the platform elements are not
mutually exclusive activities, and are in the best interest of agencies and the
State enterprise.
Arizona’s
Target Platform Architecture is supported by principles correlated to agency
business functions, statewide standards, applicable recommended best practices,
and technology trends. The principles and recommended standards contained in this
revision and previous revisions of this document are codified in Statewide Policy P720, Platform Architecture,
and Statewide Standard P720-S720, Platform
Infrastructure, respectively. Policies and standards generated as part of
EA are subject to the review, approval, and refresh/renewal procedures outlined
in Statewide Policy P105, Policies,
Standards, and Procedures (PSP) Policy.
The agency director, working in conjunction
with the agency CIO, is responsible for ensuring the implementation of Target Platform
Architecture within the agency’s “sphere of influence,” as designated by
statute or rule. The Target Platform
Architecture document defines an overall strategy and technical framework
that is codified in Statewide Policy P720,
Platform Architecture, and Statewide
Standard P720-S720, Platform Infrastructure; however, by design, the
capital planning, process approach and timeframes for transition, project
management, and investment control for the implementation of the target
architectures are the responsibility of the agency. Implementation strategies
and conformance of IT investments and projects with EA is described in Statewide Policy P700, Enterprise
Architecture, and Arizona’s Enterprise Architecture Framework and Strategies document.
Individual domain target technology tables presented in previous
revisions of Target Domain Architecture documents have been combined and are summarily
presented relative to the OSI 7498-1 Reference Model in a composite, integrated Arizona Enterprise Architecture Target Technology
Table, available at http://www.azgita.gov/enterprise_architecture.
Platform Architecture Standards are
established to coordinate State and agency implementation of platform
infrastructure. The goal is to utilize platforms based on common, proven, and
pervasive industry-wide, approved, open standards; however, a full complement
of open standards does not exist for all components of platform architecture.
Therefore, combinations of open standards, industry de facto standards,
mutually agreed upon product standards, and best practices are currently
required to support the State's heterogeneous operating environment.
The Platform Architecture Standards contained in previous revisions of
this document have been codified in Statewide
Standard P720-S720, Platform Infrastructure, and related statewide security standards.
Platform Architecture Standards contained in Statewide Standard P720-S720, Platform Infrastructure, are
reviewed, updated, and approved in accordance with Statewide Policy P105, Policies, Standards, and Procedures (PSP) Policy.
Agency compliance with Statewide
Standard P720-S720, Platform Infrastructure, shall be in accordance with Statewide Policy P700, Enterprise
Architecture.
All Statewide Policies, Standards, and Procedures referenced in this
document are available at http://www.azgita.gov/policies_standards.
and supports the business and program priorities of State
government. EA is a strategic initiative of the current State IT Plan and is
interwoven with the Governor’s objectives for the State.
Platform Architecture must support the business and program
priorities of State government. Technology
investments in Platform Architecture must provide measurable improvements to
public service. The Platform Architecture must support the economical and
efficient development of open, interoperable software application systems that
make State information, programs, and services more accessible to the people of
Arizona. Platform
Architecture must enable new software applications to be developed more rapidly
and modified more easily as business requirements and technical environments change.
Platform Architecture suggests end-user (client), server,
and storage platform devices, operating systems, and open system interfaces
that provide for interoperability [the capability for services (applications)
operating on different, diverse devices to exchange information and function
cooperatively using this information], and portability [the capability of
software to operate and perform in the same manner on different types of
devices] of business application systems. Categories of the Platform
Architecture Domain range from enterprise-class mainframe-servers to end-user
workstations and hand-held computing devices along with the operating systems
that control these devices. Platform categories, or tiers, complement each
other and maximize the operation and usefulness of various specialized platform
devices to address agency business requirements.
Platform
Architecture categories include the following:
Ø
Server. The server with its associated
operating system provides services requested by clients (end-user devices).
Types of servers included are: mainframes, midrange, and network servers
(application, file, print, database, etc.). Servers should be positioned to
embrace a variety of applications so that, over time, as open-standard
operating systems and open-standard interfaces are deployed the traditional boundary
lines between voice, data, and video are eliminated. Server-attached or
network-attached output devices such as printers, plotters, etc. should use
IEEE-standard interfaces and industry de facto standard software drivers.
Ø
Storage. Storage is increasingly
recognized as a distinct resource, one that is best thought of separately from
the devices (servers, end-user devices) that are its consumers and
beneficiaries. Such storage is increasingly often shared by multiple platform
devices, and acquired and managed independently from them. Storage solutions
should address the State’s requirements for short term, long term, and
permanent storage of information. Types of storage include:
o
Direct Attached Storage (DAS) is
comprised of interfaces (controllers) and storage devices that attach directly
to a server or an end-user device. DAS, in the form of independent storage
devices, RAID arrays, or tape libraries, is the most common storage
architecture today.
o
Network Attached Storage (NAS) is an
open-industry-standard, file-oriented, storage implementation where storage
devices are connected to a network and provide file access services to server
and end-user (client) devices. A NAS storage element consists of an engine,
which implements the file services, and one or more devices, on which data is
stored. By connecting directly into a network, NAS technologies allow users to
access and share data without impacting application servers.
o
Storage Area Network (SAN) is an
open-industry-standard, data-centric, storage implementation that traditionally
uses a special-purpose network that incorporates high-performance communication
and interface technologies as a means to connect storage devices with servers.
Ø
End-user device (client). The end-user
device, with its associated operating system, provides the end-user interface
to the business application. End-user devices include the personal computer
(PC), thin client, host-controlled devices
(terminals, telephones, etc.), voice interface devices, single- and
multi-function mobile devices (Pocket PC, PDA, PDA-phone, etc.), telephony
devices, smart cards, etc. “Personal” input devices (tablet, keyboard, probe,
etc.) and output devices (monitors, displays, projectors, speakers, printers,
etc.) attached to an end-user device should use IEEE-standard interfaces and
industry de facto standard software drivers.
The principles listed below provide
guidelines for the design and selection of platform technology components that
will support distributed n-tier-architecture-based processing activities across
the State. Platform Architecture promotes the ability of software and hardware
on different devices, from different vendors, to integrate and interoperate in
an efficient and effective exchange and sharing of data and information.
Platform Architecture Principles guide the evaluation, planning, design,
selection, and implementation of platform technology and services.
Principle 1
Platform Architecture provides the device infrastructure to
support State and agency business and administrative processes.
Rationale:
Ø
Platform Architecture
provides the end-user, citizen interface to State and agency information and
resources. It enables the rapid and effective execution and processing of a wide
spectrum of State and agency business applications. Platform Architecture works
in conjunction with Network and Security Architecture to extend resources and
information capabilities and access, regardless of
the location of the citizen or end-user.
Ø
Platforms (servers, storage, and end-user
devices (clients)) must accommodate new and expanding applications; increased
storage, access, and retention requirements for a variety of data (e.g., voice,
data, image, and video), and a variety of concurrent users, regardless of location.
Ø
Specific platform choices or preferences should
not dictate or restrict agency business and administrative application
solutions. The platform decision is dependent on the overall application
solution(s) in accordance with agency business requirements.
Ø
Stored information must be readily accessible
from any point in the network, presented in a consistent framework and timely
manner so that business decisions can be based on up-to-date information.
Principle 2
Servers
and storage that support essential business processes and mission-critical
business operations shall be operational, reliable, and available 24x7x365.
Rationale:
Ø
Server and storage
platforms provide for the execution of State and agency business functions and
processes as well as the electronic storage of associated information.
Ø
Sufficient reliability, redundancy, and fault
tolerance must be built in to ensure that a single point of failure does not
have severe adverse effects on essential business
processes and mission-critical business operations.
Ø
Server and storage platforms that support essential business processes and mission-critical business
operations should be designed to permit continued operations during a
failure that occurs in the course of normal operations, or in the event of a
disaster. Throughput may be impacted during the event; however, information and
services should remain accessible and available to citizens and end-users,
regardless of location in the network.
Ø
Storage solutions should address the State’s
requirements for short term, long term, and permanent storage of information.
Ø
Backup and recovery of information stored on
servers and storage platforms shall adhere to Statewide Standard P800-S870, Backups. Timely, well-documented, and
tested backups of software and information will allow agencies to recover
quickly and effectively from potential interruptions of service, and also the
requirement to restore critical information.
Principle
3
Platforms
shall use industry-proven, mainstream technologies based on pervasive
industry-wide, open interfaces, and open architecture.
Rationale:
Ø
Platforms should
interoperate to improve customer (both end-user and citizen) access, reduce
integration complexity, and facilitate the sharing of business process
information.
Ø
Open, vendor-neutral platforms provide
flexibility and consistency, and facilitate
communications and the sharing of information
across the State enterprise and agency boundaries.
Ø
Platform Architecture that utilizes pervasive industry-wide, open interfaces ensures application
portability and integration across platforms.
Ø
Industry-wide, open
interfaces and architecture provide for consistent deployment, management, and
expansion of agency business functions, while enabling agencies to
respond more quickly in an environment of changing business requirements.
Ø
Open, vendor-neutral systems support economic
choices and implementation flexibility, to better protect the State against
unexpected changes in vendor strategies and capabilities.
Ø
Industry-wide, open
interfaces allow agencies to choose from a variety of sources and select
the most cost-effective and efficient platform solutions without adversely
impacting business applications.
Principle 4
Platform operating system security should be based on
industry-wide, open standards.
Rationale:
Ø
Platform operating
system security that utilizes open standards facilitates application
portability and integration across platforms.
Ø
Security services already exist for many common
operating systems and applications; however, products from different vendors
may be implemented in ways that make it difficult to integrate these products
into an overall security architecture. Existing
application, operating system, or platform security mechanisms should be used
whenever they match Statewide Policy
P100, IT Security and associated Statewide IT security standards.
Application-specific security mechanisms should only be developed where
necessary.
Principle 5
Platform configurations and associated
operating system versions should be minimized.
Rationale:
Ø
Reducing uniqueness in platform and operating
system selection and increasing standardization reduces support and maintenance
costs.
Ø
Standardization of platforms and associated
operating systems can lead to increasing purchasing economies of scale for the
State.
Ø
Standardization of platforms and associated
operating systems reduces future upgrade and migration issues.
Ø
Standardization of platforms and associated
operating systems simplifies training, learning curves, and skills transfer.
Principle 6
Platform
infrastructure should employ open, industry-standard components, using an
n-tier model.
Rationale:
Ø
Open,
industry-standard, component platform architecture allows:
o
Business application development and acquisition
to focus on business requirements, without proprietary issues,
o
Simplification of the environment and
geographical independence of servers,
o
For better use of modular, off-the-shelf
components and solutions, and.
o
For significant changes to a component of a
system without changing the entire system (open interfaces).
Ø
A highly granular, loosely coupled server design
supports modular application-code-sets in an n-tiered application architecture.
Principle 7
Platform infrastructure should be
designed for growth, flexibility, and adaptability.
Rationale:
Ø
Changing business
processes and requirements drive application, network, and platform
architecture.
Ø
Scalable, flexible,
and adaptive platform and
network infrastructure facilitates the
delivery of applications resulting from changing business requirements.
Ø
As new processes are
developed and new information becomes available, platform infrastructure and networks must scale to allow for increased demand.
Principle 8
Platform infrastructure should maximize
the design and availability of Target Network Architecture for delivery of
applications and services to citizens and end-users, regardless of location.
Rationale:
Ø
Platform Architecture
provides the end-user, citizen interface to State and agency information and
resources. It enables the rapid, effective execution and processing of a wide
spectrum of State and agency business
applications. Platform Architecture works in conjunction with Network and
Security Architecture to extend resources and information capabilities and
access, regardless of the location of the citizen or
end user.
Ø
Target Network
Architecture defines industry-wide, open-standards-based, scalable, flexible,
and adaptive networks to facilitate the delivery of applications and services.
Ø
Networks enable access
to a wide spectrum of information, applications, and resources, regardless of
the method of delivery or the location of the citizen or end user.
Best Practices are approaches that
have consistently been demonstrated by diverse organizations to achieve a
similar high-level result, which, in the case of architecture, means
demonstrating the principles. Recommended Best Practices assist agency staff in
the planning, design, implementation and expansion, administration, maintenance,
and support of platforms.
Recommended
Best Practice 1
Configure all server and
storage platforms supporting mission-critical applications to minimize service
interruptions.
Rationale:
Ø
Server and storage platforms that support essential business processes and mission-critical business
operations should be designed to permit continued operations. Continued
operations includes accessibility and availability of information and services
to citizens and end users, regardless of location in the network, albeit at
reduced throughput, during a failure that occurs in the course of normal
operations, or in the event of a disaster.
Ø
Sufficient reliability, redundancy, and fault
tolerance must be built in to ensure that a single point of failure does not
have severe adverse effects on essential business
processes and mission-critical business operations.
Ø
Recommended Best Practices should be used for
security, disaster recovery, and backup to ensure the integrity of the server,
the data storage, and the application.
Ø
Target Network Architecture principles,
standards, and best practices ensure the accessibility and availability of
mission-critical business operations, regardless of location, and minimize
service interruptions.
Recommended Best Practice 2
Consider normal, anticipated
future application growth demands when determining increased processing and
capacity requirements for server and storage platforms.
Rationale:
Ø
Server and storage platforms should be
configured and procured to accommodate the current demand as well as to support
anticipated, normal, practical growth without requiring the purchase of a new
platform.
Ø
The processing and capacity capability for
server and storage platforms continues to increase as initial procurement and
support costs decrease. Agencies should consider useful life cycle cost
analysis for server and storage platforms when purchasing and sizing for future
growth.
Ø
Utilize Target Network Architecture principles,
standards, and best practices to ensure sufficient network access and availability
of applications to citizens and end users, regardless of location.
Recommended Best Practice 3
Design and implement storage networking
solutions for the State’s data centers and agency storage requirements.
Rationale:
Ø
Storage networking enables storage to be
consolidated, shared, accessed, and managed over a networked infrastructure.
Ø
Storage networking is a strategic component of
the Platform Architecture that addresses scalability, sharing, and maximum
utilization of storage and information resources, while streamlining
administration, minimizing the total cost of ownership for storage, and
improving data availability and integrity.
Ø
Storage networking provides the framework for
uniting multiple storage architectures including Fiber Channel Storage Area
Networks (SAN), which provide block-based access to shared disks; IP-connected
Network Attached Storage (NAS), which provides file-based access to shared
storage; and server Direct Attached Storage (DAS) into a single, managed,
scalable, and extensible storage infrastructure.
Ø
Storage networking is based on open architecture
and industry standards, and utilizes IEEE-standard SCSI and Fiber Channel
interfaces.
Ø
The storage and networking industries are
driving to convergence through several IETF standards, including SCSI over IP
(iSCSI) for accessing block-level storage from IP-connected hosts and Fiber
Channel over IP (FCIP) for transparently internetworking Fiber Channel SANs
across IP networks.
Ø
Metropolitan optical infrastructures (SONET,
DWDM, etc.) enable the extension of storage networking over IP, Fiber Channel,
ESCON, etc.
Ø
Target Network Architecture provides for the
design and operation of network infrastructure to deliver and support storage
networking.
Ø
Storage solutions should address the State’s
requirements for short term, long term, and permanent storage of information.
Ø
Backup and recovery of information stored on
storage platforms should support Statewide
Standard P800-S870, Backups. Timely, well-documented, and tested backups of
software and information will allow agencies to recover quickly and effectively
from potential interruptions of service, and also the requirement to restore
critical information.
Recommended Best Practice 4
Implement
n-tier platform architecture.
Rationale:
Ø
N-tier platform architecture entails different
types of devices performing different functions that may exist to maximize the
usefulness of various specialized devices. Suitably designed business
application solutions minimize hardware dependencies and incur little or no
detriment from changes in platform selections.
Ø
Mainstream open and industry de facto operating
systems are scalable through the use of multiple processors or clustering
techniques to address growth.
Ø
Clustering allows additional flexibility and
potential cost reduction because the servers operate standard processors and
software, allowing an agency to choose from multiple suppliers, if desired.
Ø
Platform choices should support, not restrict,
agency business and administrative application solutions. Platform decisions
are dependent on the overall application solution in accordance with agency
business requirements.
Ø
Mainstream operating systems provide greater
flexibility for choice of common, open-industry-standard interfaces, middleware
software, Database Management Systems (DBMS), management software, office
productivity software, software development tools, etc. as well as specific
application software (financial, HRIS, call/contact centers, customer relations
management, etc).
Ø
Using
open-standards-based server platforms whenever possible minimizes issues
with interoperability, maintenance, and support and maximizes the reusability
of devices and services.
Ø
N-tier platform architecture facilitates system
management and support since the application logic resides on servers, not on
every end-user platform device.
Ø
Applications designed for n-tier processing
utilizing a multi-tasking, multi-threaded operating system allow components
(application processing, database accesses, etc.) to be deployed on separate
physical devices whenever possible.
Ø
Granularity in servers facilitates the
partitioning of application systems and databases and the preservation of
logical boundaries.
Ø
Multiple, highly scaleable servers maximize
interoperability, portability, and flexibility.
Recommended
Best Practice 5
Select and implement end-user platforms and associated operating
systems that support personal productivity and connectivity, while adhering to uniform
standard configurations.
Rationale:
Ø
A business application may have a variety of
users with different end-user platform requirements. End-user platform choices
should satisfy both end user ease-of-use and uniform standard configurations
for end-user platforms.
Ø
Uniform, standard configurations of end-user platforms and associated operating
systems minimize problems with interoperability, maintenance, and
support and maximize the reusability of devices and services.
Ø
The end-user platform displays the interface to
an application. Office productivity software is designed to operate with the
major, industry de facto standard, end-user operating systems.
Ø
Agency-specific applications should be designed
to minimize dependency on a particular end-user platform, as much as possible.
Ø
Web browsers are becoming widespread application
interfaces that support multiple platforms.
Ø
N-tier applications, using "thin"
client architectures, reduce dependence on a particular end-user platform
because the user interface is isolated from application code.
This assessment is designed to support the planning
and implementation of Target Platform Architecture recommended standards and
best practices. The assessment applies to IT projects that include business
requirements that propose or require modifications and/or additions to existing
deployments of platform devices.
Score. Questions for the four (4)
platform device categories are scored with one (1) point for a “Yes” answer,
and zero (0) for a “No” answer. Maximum possible is the total number of questions
for each category.
Definitions:
Applicable is defined as pertinent,
related to, relevant, and appropriate.
Capability is the potential and
ability for development or use. It is the capacity to be used or developed for
a purpose.
Device includes logical groupings
or categories of server, storage, and end-user (client) platforms in use
statewide, or within a budget unit.
Maximize is defined as taking full
advantage of the subject attribute(s).
Variety is defined simply as more
than one. Note: the intent of versatility is to maximize flexibility and
usefulness of a device relative to the applicable budget unit business
applications.
Widespread is defined as extensive and prevalent.
Platform Device Name/Description:
|
Category
|
Max.
Possible
|
Score
|
Category Description
|
|
1. Versatility
|
8
|
|
Provides interoperability,
flexibility, adaptability, and scalability without requiring substantial
modification.
|
|
2. Operating Systems
|
6
|
|
Utilizes open- or
pervasive-industry-standard, secure, operating systems.
|
|
3. Operating Systems Security
|
7
|
|
Addresses the security
functionality of Operating Systems.
|
|
4. Open Standard Interfaces & Drivers
|
4
|
|
Adheres to
open-system-standard interface specifications and utilizes device drivers
with IEEE interfacing and industry de facto standard protocols and formats.
|
|
Total
Rating Points
|
25
|
|
|
1. Versatility refers to a
device’s capability (assuming connectivity where applicable) to provide
interoperability, flexibility, adaptability, and scalability without requiring
substantial modification.
|
Score 1 Rating Point for a “Yes” answer
|
Yes
|
|
1. Is the device capable of delivering applicable
EA Target Technologies and Statewide IT standards without major upgrades and
additional costs?
|
|
|
2. Is the device capable of delivering or
providing secure (as defined by Statewide IT Security Policy and Standards)
end-user interface access to a variety of business applications (HRIS, email,
office productivity applications, Internet, telephony, voice mail, etc.)
without substantial modifications, regardless of end-user location?
|
|
|
3. Is the device capable of delivering or
providing end-user interface access to a variety of business applications
maximizing a fully converged network, regardless of end-user location?
|
|
|
4a. Server only – is the device capable of
hosting or delivering multiple, and varied application solutions, with
sufficient reliability, redundancy, and fault tolerance to support essential budget
unit business operations?
|
|
|
4b. Storage only – is the device capable of
hosting or delivering storage for multiple, and varied application solutions,
with sufficient reliability, redundancy, and fault tolerance to support
essential budget unit business operations?
|
|
|
4c. End-user device only – is the device capable
of providing one common point for end-user connectivity access and
productivity for multiple and varied application solutions?
|
|
|
5. Is the device able to maximize the use of the
Statewide Network Infrastructure standards?
|
|
|
6. Is the device capable of accommodating
increased demands for service and new application solutions without
substantial modifications?
|
|
|
7. Are widespread choices for off-the-shelf
application solutions, without modifications, available for this device?
|
|
|
8. Does the versatility of this device directly
improve the quality and timeliness of budget unit business functions?
|
|
|
Total
Rating Points
|
|
2. Operating Systems
refer to a device’s, or networks, capability to utilize open- or
pervasive-industry-standard operating systems.
|
Score 1 Rating Point for a “Yes” answer
|
Yes
|
|
1. Is an open-industry-standard operating system
currently available for this device?
|
|
|
2. Is the operating system currently deployed
with this device an open or industry de facto standard operating system?
|
|
|
3. Does the operating system currently deployed
with this device allow for all updates to be pushed to, or accepted by, all
associated devices?
|
|
|
4. Does the same version of the operating system
currently deployed with this device have mass availability?
|
|
|
5. Is the installed version of the operating
system currently deployed with this device the most current production
version, or undergoing continued development by the manufacturer?
|
|
|
6. Is the operating system currently deployed
with this device scheduled for future production releases?
|
|
|
Total
Rating Points
|
|
3. Operating Systems Security
refers to a security functionality that is available with the Operating System
(must be answered relative to responses in 2. Operating Systems.)
|
Score 1 Rating Point for a “Yes” answer
|
Yes
|
|
1. Do the operating system security services
align with Statewide IT Security Policy and Standards?
|
|
|
2. Does the operating system security allow for
logging and the security controls for applications, platform, and network
levels to be integrated to reduce and eliminate redundancies?
|
|
|
3. Does the operating system support access,
authentication, and authorization techniques as defined in the Statewide IT
Security Policy and Standards?
|
|
|
4. Does the operating system allow for an
integrated LDAP directory service?
|
|
|
5. Does the operating system allow for all
security updates to be pushed to, or accepted by, all associated devices?
|
|
|
6. Does the operating system allow for logging
and the restriction, including preventing end-user override, of particular
functions or services, such as non-essential or redundant services,
communication options that are susceptible or prone to abuse, and
operating-system-level utilities?
|
|
|
7. Can extraneous services, open ports, etc., be
easily removed from “default installations of the operating system” and prevented
from returning when the operating system is upgraded?
|
|
|
Total
Rating Points
|
|
4. Open Standard Interfaces and Drivers
refer to a device’s capability to adhere to open-system-standard interface
specifications and to utilize device drivers that use IEEE and industry de
facto standard protocols and formats.
|
Score 1 Rating Point for a “Yes” answer
|
Yes
|
|
1. Does the device utilize Statewide Network
Infrastructure Standards for communication protocols?
|
|
|
2. Is the device capable of being configured,
managed, and maintained using standard SNMP-based management tools?
|
|
|
3. Is the device capable of utilizing
open-standard drivers that employ IEEE-interfaces and industry de facto
standard software drivers?
|
|
|
4. Are multiple, off-the-shelf, peripheral
devices that conform to open-system-standards and that utilize industry de
facto standard drivers available for this device?
|
|
|
Total
Rating Points
|
|
