1. introduction

The State of Arizona’s Enterprise Architecture (EA) describes a comprehensive framework for information technology that supports the Arizona State government strategic plan. Information Technology (IT) is not an independent science having a set of doctrines of its own. Rather, it applies the principles established in the various physical sciences, along with methodologies and human activities to business processes. EA facilitates the application of information technology 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. 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.

Arizona's IT Conceptual Architecture document explains the overall strategic alignment of Arizona’s EA with the State's goals and objectives, the principles behind the architecture, the domains to be addressed, the plans for addressing domains, and the technology trends to be taken into consideration. The conceptual plan was presented to the Information Technology Authorization Committee (ITAC), Chief Information Officer (CIO) Council, and other stakeholders. It is available for review at the Government Information Technology Agency (GITA) website, http://azgita.gov/enterprise_architecture.

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, and applicable recommended best practices.

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 individual roles and responsibilities, funding sources, and timeframes for the implementation of the target architectures are the responsibility of the agency.

Arizona’s EWTA Domains
Infrastructure	Application
Platform	Data/Information
Network	Software
Security

Data/Information Architecture was the fifth major EWTA domain developed by GITA and its architectural task teams. The EWTA was developed in phases and is updated periodically. The domain architectures are driven by the business and program priorities of Arizona State government. They are aligned with, and facilitate the strategic goals of the State and agency IT plans.

2. Data/Information Architecture Vision

The State of Arizona’s Data/Information Architecture suggests a strategy to collectively and collaboratively seek out, embrace, and facilitate the implementation of e-government solutions and strategic business initiatives that potentially cross over traditional agency boundaries through a community-of-interest-based approach. Because government, at all levels, provides a variety of disparate and distinct services, its environment for conducting business is inherently decentralized and distributed. Data/Information Architecture proposes a desired outcome within which communities of interest prudently transcend individual agency operations to mutually address new and changing business opportunities and legislation to more cost-effectively and efficiently deliver services, and interact with other governmental entities, and the private business sector.

3. Data/Information Architecture Definition

Data/Information Architecture focuses on the process of modeling the information that is needed to support the business processes and functions of agencies, and more strategically, of communities of interest. Where applicable, it spans traditional agency organizational boundaries to address interoperability, integration, consolidation, and sharing of resources by correlating agency business processes to common government services through the identification and definition of data/information relationships and dependencies.

Data/Information Architecture outcomes are expressed in the form of data models, information flows, and analysis of inputs/outputs and decision-making criteria for the activities of State government. Analyzing these outcomes within the desired context of collectively improving the efficiency and effectiveness of State government provides a common framework to potentially converge certain individual agency business processes into community-of-interest-based, realistic, attainable e-government solutions and strategic business initiatives that eliminate unnecessary redundant and overlapping individual agency activities. While certain unique agency data and processes may be required and necessary, they should not deter or impede the State’s strategic efforts to maximize opportunities to share information and integrate resources among agencies within communities of interest as well as to improve interoperability with other governmental entities and the private business sector.

4. target data/information architecture

Arizona’s Data/Information Architecture suggests a strategy for e-government. e-Government benefits citizens, business partners, other levels of government, and employees. e-Government has been defined as the use of:

Ø Internet-based technology to improve government services, reduce operational costs, enhance citizen participation, and rethink government processes; and

Ø Digital technologies to transform government operations in order to improve effectiveness, efficiency, and service delivery.

Technology, incorporated into business and aligned with EA, has the potential to transform government by improving service delivery, reducing costs, simplifying and streamlining requirements and services, and increasing efficiency and effectiveness. AZ State Government, other state governments, the federal government, the private sector, and citizens currently embrace e-government as an essential strategy to achieve market-based, citizen- and result-oriented government services. e-Government and strategic business initiatives and programs should be designed to:

Ø Make it easy for citizens and businesses to obtain service and interact with government;

Ø Improve government efficiency and effectiveness; and

Ø Improve government’s responsiveness to citizens, businesses, political sub-divisions, and the federal government.

Utilizing these themes to align e-government and strategic business initiatives with their primary beneficiaries allows service programs to be classified into four major strategic portfolios:

Ø Government-to-Citizen initiatives to fulfill a vision of one-stop online access to government services.

Ø Government-to-Business initiatives to reduce government burden on businesses, reduce redundant data collection and reporting, and enable digital communication with businesses.

Ø Government-to-Government initiatives to enable sharing and integration of information with all levels of government, and integrate key government operations such as disaster response.

Ø Internal Efficiency and Effectiveness initiatives that use technology to reduce costs and improve internal operations by adopting commercial best practices.

Numerous communities of interest exist within state government that affords opportunities to develop realistic and attainable e-government solutions that support strategic initiatives and align with Statewide Policy P100, Information Technology. Many communities of interest such as Health, Human/Social Services, Criminal Justice, Education, Environmental Quality, Transportation, and others extend beyond State government. Recognizing this reality, Data/Information Architecture continues the ongoing strategic theme of Arizona’s EWTA to emphasize and focus on technologies that are aligned with open, pervasive industry-wide standards, interoperability, portability, and adaptability to foster a common, compatible environment conducive to extending the State’s communities of interest to all levels of government and the private business sector.

Arizona’s EWTA provides the strategic technical guidance and definitions to create a comprehensive, interoperable, adaptive IT framework that facilitates and supports the economical and efficient development and implementation of e-government and strategic business solutions that improve government services, eliminate redundancies, and reduce costs. The Network and Platform domains of Arizona’s EWTA address the infrastructure requirements of business projects, while the Security domain focuses on the underlying security of the IT infrastructure. The Software domain concentrates on the secure software technologies, development strategies, and techniques necessary to automate agency, or community of interest, business functions. Data/Information Architecture correlates disparate agency business functions, modeling the desired outcomes into potential e-government and strategic business initiatives.

The purpose of data modeling is to develop an accurate model, or graphical representation, of the agency's information needs and business processes. The data model acts as a framework for business re-engineering and the development of new or enhanced applications to fulfill business requirements and processes. Data modeling aids in describing the types of interactions and information exchanges that occur within and between agencies and their various customers, constituencies, and business partners. The functional perspective of Target Data/Information Architecture data modeling facilitates identification of common business processes, information requirements, and opportunities for business process improvements not only with agencies, but as well across agencies boundaries within communities of interest. Data modeling is a tool that provides a detailed data/information process map to help agencies identify functional processes and programs that can be more effective and efficient through community of interest collaboration and partnerships.

Recognizing the benefits of direct involvement and widespread collaboration, GITA and the CIO Council propose to establish a Technology Government Working Group (TGOV.) TGOV will support the Governor’s strategic plan for e-government and the implementation of strategic business initiatives by assisting agencies to achieve success in areas of EA implementation, technology selection, and the adoption of recommended standards and best practices that can be leveraged on a statewide scale. TGOV leverages the knowledge and expertise of existing IT personnel to provide agencies with architectural guidance, technology recommendations and approaches that support the adoption and implementation of Arizona’s EA. Agencies having representation on the CIO Council are encouraged to participate and provide appropriate technical staff representation in the working group. See Appendix A. Technology Government Working Group (TGOV) for further information.

Using a structured, well-defined, architectural-process-based approach to implement strategic business initiatives and e-government solutions dramatically improves the potential for success. Enterprise Architecture helps to avoid problem areas such as duplicate efforts, failure to consider infrastructure and security requirements, and implementing proprietary technologies that are not interoperable, flexible, and scalable. A process-based approach increases the possibility for collaborative efforts by clearly identifying opportunities where community of interest partnerships can take place.

AZ Architectural Process-Based Approach

The recommended implementation approach for the Target Data/Information Architecture is as follows:

1. The EWTA Principles, Recommended Standards, and Best Practices, are being developed by GITA and its architectural task teams in conjunction with the CIO Council and ITAC, and with agency technical staff input and review. The EA domains provide the technical framework for the application of information technology and subsequent change in an orderly, efficient manner by describing a direction for current and future community of interest and agency business activities that is supported by underlying principles, standards, and best practices.

The development and implementation of EWTA is an ongoing process that encourages the continual refinement of the architecture to ensure sustained alignment with evolving business strategies, communities of interest, and requirements of the State as well as changing technology.

2. GITA is undertaking the Initial Agency Conceptual Data Modeling component to define the individual agency and statewide “As-Is” business and application processes and their respective data/information flows. These high-level conceptual models are contained in Appendix B. Statewide Context Diagram and Appendix C. Agency Conceptual Model.

Conceptual data modeling is a high-level graphical representation of the data needed to operate an organization or a business activity that is unbiased toward any single application and independent of its access and physical storage. It describes the information used by an organization in a business manner, not governed, by implementation-level issues and details.

Specific agency data models are confidential and are only available with consent and approval of the agency per A.R.S. § 41-3504(A (9)) “maintain all otherwise confidential information received from a budget unit pursuant to this section as confidential.”

3. The second, more detailed modeling component, Agency Logical Data Modeling, is a participative effort with GITA and State agencies by what will become known as “architectural task teams.”

Logical data modeling describes the business data requirements in a format where business users can understand them. The logical data modeling process discovers, analyzes, defines, standardizes, and normalizes the relationships between business and application processes, the flow of information, and the related data elements required by the agency as established by the conceptual data model. Processes, data flows and their data elements are the logical facts an agency must maintain to conduct business. Logical data modeling interprets business information requirements, forming data elements, which will satisfy those information requirements, but also forming data elements, which are sharable across organizational/process boundaries, and eliminating overlaps and conflicts in those data elements.

4. Target Tactical Planning is based upon strategic e-government and business initiatives as identified in the Governor’s strategic plan. Target Tactical Planning sets the desired “to be” business and technology as a result of “as-is” modeling efforts. Using the conceptual and logical data models, targeted agencies, and communities of interest will align the Governor’s e-government and strategic business initiatives goals and objectives with their Agency IT Plan. GITA will incorporate the strategic e-government business goals and objectives of the Governor’s strategic plan, and proposed Agency IT Plans into the State IT Plan.

5. Targeted State agencies involved in a specific e-government or business initiative will perform a Gap Analysis relative to their “as-is” technologies in the planning stage of the project, to establish a benchmark for agency operations and the development of a Project and Investment Justification (PIJ).

6. Agencies are responsible for the execution of any gap analysis/implementation plan as well as for submitting a standard PIJ for project approval and implementation based on Statewide Policy P340, Project, and Investment Justification (PIJ). The specific business functions and processes, along with the proposed technological solutions, aligned with Arizona’s EWTA, and supported by a positive Business Case are detailed in the PIJ as specified in Statewide Standard P340-S340, Project and Investment Justification (PIJ).

Arizona’s EWTA is vendor/manufacturer neutral and strategic by design. As such, it does not attempt to identify or address specific IT products or IT manufacturers/distributors. The procurement of proposed solutions to fulfill e-government and strategic business initiatives is generally conducted through an individual, competitive Request for Proposal (RFP) process. Unless the proposed solution is developed by internal staff, an individual, competitive RFP process should be used to procure the solution. State IT procurement contracts should be used to purchase any supporting IT products and services, unless otherwise directed by ADOA SPO.

7. Business Process Improvements, as identified in the Governor’s Strategic Plan, the State IT Plan, and individual Agency IT Plans are enacted within a community of interest or individual agency. These represent the executable strategies for restructuring and reshaping business processes into successful, attainable, and measurable solutions.

Organizing the above architectural-process-based approach for implementing strategic business initiatives and e-government solutions within the context of a desired, common target environment for the State aligned with, and supported by the principles, standards, and best practices of Arizona’s EWTA, will enable the State to improve service delivery, reduce costs, simplify, and streamline requirements and services, and increase efficiency and effectiveness.

The proposed Technical Reference Model depicted below provides a common depiction of the desired, common target environment and is intended to support the State’s business functions. It captures the fundamental components of the network, security, platform, software, and data/information domains and presents the aggregate relative to an e-government framework. The intent is to present a consistent, industry-aligned framework with the ability to accommodate a variety of viable e-government and other strategic business solutions that is flexible and capable of adapting to new and improved technologies as they become available.

This Model provides the foundation for agencies to analyze and identify interoperability and integration opportunities. This interoperable, scalable target environment fully embraces open- and de-facto-industry standards and best practices. The practical application of this target environment should minimize point or proprietary approaches and maximize the interoperability of future e-government and other strategic business solutions.

Arizona Target Environment – EWTA Technical Reference Model

The architectural-process-based approach described above and the following integrated domain table, consolidated from the individual EWTA domains, provides the technical target architectural components to coordinate and deploy strategic e-government initiatives and business solutions within the context of the Technical Reference Model (above). The domain table describes the technical components of AZ EWTA relative to the Open Systems Interconnection (OSI) Reference Model to furnish a common ground for analysis, discussion, and standards development.

Target Technology Table
Obsolete, Transitional	Target (Strategic)	Emerging
OSI Layer 1 – Physical
Network
Coaxial cabling, Category 3 unshielded twisted pair (UTP), shielded twisted pair (STP), and 62.5/125-micron multimode fiber. Bus topology	Category 5e UTP (supersedes Category 5 UTP), 50/125-micron multimode fiber, 8/125-micron single mode fiber. Logical star topology	Category 6 UTP, wireless. Logical meshed star topology
Security
Open-door physical access	Keys, locks, badges, cameras, access logs, controlled access systems	IP-based access control systems, biometrics
Platform
Platforms that employ proprietary protocols, gateways, as opposed to open-standard interfaces	SCSI, iSCSI Single application smart cards	Trusted Platform Multi-function smart cards
OSI Layer 2 – Data Link
Network
Single-segment LANs, separate networks for different services (e.g., voice and data), separate dedicated networks for various user groups, proprietary protocols (e.g., SNA, Token Ring, Appletalk-addressing), FDDI, X.25, time-domain protocols (e.g., SDLC, HDLC)	Open-standards-based, multi-service networks; 100/1000 Ethernet; 802.11 LAN, 802.16 MAN Wireless Ethernet; Frame Relay; ATM	Packet- and cell-based wireless and satellite protocols, dynamic data-link level switching, and prioritization, 10G/40G Ethernet
Hub technology	Switched technology
Security
No Media Access Control Access Control Lists	Media Access Control Access Control Lists
OSI Layer 3 - Network
Network
Proprietary protocols (e.g., IPX, AppleTalk-routing, DECnet) Separate networks for different services (e.g. voice and data), flat designs with unmanaged bridges, hubs, Fixed IP addressing	IP; RIP; BGP; OSPF; IP switching; and DHCP. Converged networks with prioritization for all services; switched, multi-segment design	IPv6 Dynamic, network-level switching and prioritization
Security
Open, non-firewalled access Critical or Confidential data transmitted in clear formats	Integrated firewalls - Packet filtering, ICMP, Boundary Routers, static NAT, IPSec
OSI Layer 4 - Transport
Network
Proprietary protocols (e.g., SPX, AppleTalk-Transport)	TCP, and UDP Converged networks with prioritization for all services	Dynamic transport-level switching and prioritization
Security
Open, non-firewalled access	Integrated firewalls - Stateful Inspection, dynamic NAT
OSI Layer 5 – Session
Network
AppleTalk-session and DEC-dns	DNS	Dynamic, session-level switching and prioritization
OSI Layers 6 – Presentation. 7 – Application
Network
AppleTalk-filing, and DEC-lat	SNMP; RMON; SMTP	Dynamic, content-level switching and prioritization
Security
Open, non-firewalled Web, FTP, and Mail Servers Proprietary security products User selected passwords that do not conform to restrictive standards. Signs-on’s that only work with a single platform or application User-based privileges	Integrated firewalls - Application-proxy gateway, Proxy Servers, Dedicated Proxy Servers. FTP, S/MIME for mail servers, OpenPGP, Role-based administration, permissions, and rights. Smart cards, Kerberos Firewalled DNS, with services placed on DMZ, SSL Standards-based platform sign-on with role-based administration Industry standard and vendor neutral APIs for identification Strong password policy Token-based identification Public Key Certificates	Multi-function smart cards Enterprise directory services - LDAP meta-directory with an OID tree Single sign-on across platforms, domains Human Authentication API (HA-API) Public Key Infrastructure Mobile agents
Platform
	Platforms having open industry-standard operating systems, with imbedded security, and open-standard interfaces and drivers	Platforms having open industry-standard operating systems, with imbedded security, multifactor authentication, and open-standard interfaces and drivers
Platforms having proprietary operating systems without open-standard interfaces and drivers. For example: o Mainframes without TCP/IP o Digital or analog PBXs /Key Systems requiring a separate network infrastructure o Voice mail systems without open APIs o Storage Area Networking with single-use, proprietary, fiber channel o Pagers, used concurrently with PDAs, radios, cell phones o Analog telephony devices	Platforms having industry de facto standard operating systems, with imbedded security, and open-standard interfaces and drivers. For example: o Mainframes with TCP/IP, SIP, Open APIs o Servers with TCP/IP, SIP, Open APIs o IP telephony with TCP/IP, SIP, Open APIs o Hybrid IP telephony (TDM/IP) systems with TCP/IP, SIP, Open APIs o Network Attached Storage o Direct Attached Storage o Storage Area Networking with multi-use access channels o Client devices (PCs, Network Computers, PDAs, etc.) with wired/wireless connectivity, TCP/IP and multi-function applications
Platform and Network Operating Systems that are unable to utilize a converged network infrastructure to access business applications	Platforms having niche proprietary operating systems, with imbedded security, and open-standard interfaces and drivers (requires exceptional business requirements)
	SNMP management of platforms Platforms deployed on target networks, with class of service (CoS) and quality of service (QoS)
Software
Traditional, monolithic State software applications deployed on proprietary server and client platforms (e.g., mainframe deployment requiring transitional version of OS with terminal access or terminal emulation access only, etc.)	n-tier distributed software applications emphasizing client (State employee, community of interest, public customer) productivity and performance enhancements and enablers (decision-making at the appropriate level) through self-service, self-administration, etc., utilizing browser-based client access deployed on Target Platform Architecture server, storage, and client devices (P100-S102) Traditional, monolithic State software applications with web-enabled, browser-based, client access.	Open, industry standard Web services, .NET, WSDL, XML, UDDI initiatives Software applications hosted via ASPs
Client/server software applications deployed with “fat” client requirements	Three-tier distributed software applications with access to n-tier architecture services
Business programming languages such as COBOL used in legacy software applications Manufacturer-specific programming languages Platform-specific programming languages such as assembler, etc	C++, Java^™, Visual Basic^®, etc.
Proprietary gateways, interfaces DCE H.320, H.323 Vendor/database-specific middleware with proprietary extensions	Java^™ and servlet software, COM^™, DCOM^™ CORBA, ORB (P100-S102), ISO/IEC 11179 SIP, SDP, SAP, RTSP Open API (P100-S102) Middleware: TPM, RPC, RMI, JMS, MOM HTML, XHTML, XML (P100-S102)	Object-oriented software IIOP J2EE^™ EJB^™ server-side deployment, COM+ EbXML secure exchange of information, UML^™, SAML, XSL, CSS3, XSLT, DSML, SOAP, TLS
3270 terminal access to software Unmanaged software applications	GUI presentation layer access to software as a precursor to browser-based access Browser-based access to software Software applications that are manageable with SNMP-based management tools (P100-S101, P100-S102) LDAP directory services (P800-S820, P100-S102) Software application security (P800-S800 series)	Portal-based universal browser access to all services Enterprise federated management tools Enterprise LDAP directory services
Flat file systems, ISAM, VSAM Vendor-specific SQL extensions Vendor-specific database middleware with proprietary extensions Proprietary email systems, non-MIME-compliant email, proprietary, closed email directory services Proprietary, closed productivity software	RDBMS Open database connectivity: SQL, ODBC, OLE DB, NDMP, NFS, CIFS, JDBC (P100-S102) Database middleware that uses open database connectivity Email services: SMTP, S/MIME, IMAP4, POP3 Productivity software with open APIs	OODBMS, ORDBMS Enterprise email directory services Productivity software conforming to IETF standards such as iCalendar, CAP, IPP, etc.

The terms “Obsolete, Transitional, Target (Strategic), and Emerging” as defined herein provide guidance regarding the status of specific architecture technologies.

Ø Obsolete. Arizona’s EA strongly promotes that agencies employ a different technology. Agencies must not plan new deployments of this technology and should develop a plan to replace this technology. This technology is typically outdated, no longer widely supported, and has been superseded by a newer, better technology.

Ø Transitional. Arizona’s EA promotes other standard technologies. Agencies may presently be using this technology as a transitional strategy in movement to a target/strategic technology. This technology may be waning in use or no longer supported.

Ø Target (Strategic). Arizona’s EA promotes use of this technology by agencies. New deployments of this technology are recommended.

Ø Emerging. Arizona’s EA promotes only evaluative deployments of this technology. This technology may be in development or may require further evaluation.

1. Recommended Data/Information Architecture Standards

Data/Information Architecture Standards are established to provide direction and guidance for community of interest and individual agency implementation of interoperable, collaborative e-government solutions and services that are flexible and adaptable to changing technology, business, and information requirements and that utilize common, proven, and pervasive, open, software products and services.

Data/Information Architecture Standards will be identified and developed at the conclusion of data modeling efforts.

2. Data/Information Architecture Purpose

The purpose of Data/Information Architecture is to create an environment in which the State’s current and future e-government business can be transacted: one that facilitates interoperability, sharing of information and resources, and that is highly flexible and adaptable to changing technology, business, and information requirements. Data/Information Architecture must align with and facilitate the strategic goals of the State and agency IT plans. Data/Information Architecture must support the economical and efficient development of e-government solutions that make State information, programs, and services more accessible to the people of Arizona. It must foster an environment of integration, collaboration, and communication, and must enable new e-government solutions to be developed more rapidly and modified more easily as business requirements change.

The key goals of the State IT Plan that impact requirements for Data/Information Architecture are:

A. Increase the use of e-government solutions.

Rationale:

Ø Data/Information Architecture correlates disparate agency business functions, modeling the desired outcomes into potential e-government solutions facilitating common, open, citizen access interfaces and improving access to State resources and information, which results in consistent delivery of services to external business partners and the public through the Internet.

Ø Data/Information Architecture facilitates the acquisition, development, implementation, and support of e-government business solutions through common, proven, industry-wide technologies that focus on interoperability, sharing of information, scalability, portability, and Internet technologies.

B. Effectively share common IT resources to enable State agencies to better serve the people of Arizona.

Rationale:

Ø Data/Information Architecture provides communities of interest and individual agencies with guidance for designing and implementing e-government solutions and services that support the sharing and exchange of information with other governmental entities and the private sector, while economically and effectively supporting agency operations.

Ø Data/Information Architecture provides data modeling outcomes that allow communities of interest and individual agencies to design and implement interoperable e-government solutions and services that expand business continuity and integration opportunities with other agencies.

C. Improve access to broadband infrastructure statewide.

Rationale:

Ø Data/Information Architecture supports an Internet/Intranet e-government environment that, in conjunction with broadband availability and access, allows for enhanced citizen and State employee access to e-government solutions, services, and information, regardless of location.

D. Improve the quality, efficiency, and usefulness of cross-agency applications integration and data sharing.

Rationale:

Ø Data/Information Architecture facilitates a community of interest approach to e-government solutions, which support interoperability and the sharing of information across the State enterprise to support relevant cross-agency e-government solutions.

Ø Data/Information Architecture promotes consistent, common, proven technologies for implementing community of interest and individual agency e-government solutions to allow agencies to improve interoperability and integration, and consequently, opportunities for sharing data.

E. Improve the capability of IT functions in order to deliver quality products and services.

Rationale:

Ø An understanding of current business processes and their environment in conjunction with the principles, recommended standards, and best practices of Data/Information Architecture allows community of interest and individual agency e-government solutions to be implemented in a manner that facilitates the development and delivery of interoperable, integrated solutions to provide a faster response to changing business needs. It also allows decision-making to progress more rapidly and advances an environment that enhances citizen access to information and services.

3. Data/Information Architecture Principles

Data/Information principles are intended to support the design and implementation of e-government solutions and services, and to facilitate increased sharing of information among agencies and communities of interest.

Principle 1

e-Government initiatives require a flexible, comprehensive Enterprise Architecture model.

Rationale:

Ø Arizona’s EWTA and architectural-process-based approach, coupled with the Project Investment Justification (PIJ) process facilitate and support the development of complete requirements when planning, designing, and implementing major solutions.

Ø Arizona’s EWTA and architectural-process-based approach are designed to prudently:

o Maximize and leverage IT investments and avoid unnecessary duplication of infrastructure and major components.

o Link business processes through shared, secure systems.

o Leverage disparate business processes, services, and activities within a community of interest.

Ø A comprehensive EWTA allows for a broad, robust range of e-government solutions that will capable of incorporating new technologies as they are developed.

Ø Arizona’s EWTA and architectural-process-based approach augment GITA oversight responsibilities and individual project team implementation through the use of common data models, conceptual processes, and technical framework.

Principle 2

Value and protect the State’s data and information as critical assets of the enterprise.

Rationale:

Ø The successful delivery of government services depends on information and conclusions derived from accurate, timely, secure data.

Ø e-Government business applications, processes, and transactions will continue to increase across the State.

Ø The State and its agencies must be able to conduct business processes that provide access to information and resources electronically, while maintaining confidentiality and integrity.

Ø e-Government solutions must be implemented in adherence with all security, confidentiality, and privacy policies, as well as applicable statutes, to enhance public trust, exert the proper stewardship over public information, and help ensure the integrity of the information.

Ø e-Government solutions must be implemented with adherence to applicable Statewide Security Standards and Target Security Architecture.

Principle 3

Share, and provide secure access to data and information.

Rationale:

Ø The value of data and information is proportional to its availability. Data and information that is inaccessible or hard to interpret and use diminishes its value and hinders the effectiveness and efficiency of service delivery.

Ø Data and information that is securely shared reduces redundancy and enhances and accelerates decision-making.

Ø The secure sharing of data and information facilitates community of interest solutions and reduces cost and complexity of e-government and other business solutions.

Ø The secure sharing of data and information, particularly with respect to e-government solutions has the potential to minimize the direct data collection burden and promote the principle of “enter once, use often.”

Ø Effective data and information access is critical for e-government solutions, which will contain unprecedented levels of direct access by both internal and external users.

Ø e-Government solutions should encourage and provide for a diversity of secure public and private access, including multiple access points and accessibility to individuals with sensory disabilities.

Principle 4

Statewide interoperability standards facilitate and support community of interest e-government initiatives and other business solutions.

Rationale:

Ø Interoperability is essential for securely sharing data, information, and other resources in the successful implementation of effective and efficient community of interest e-government initiatives and other business solutions.

Ø Agencies, citizens, businesses, political subdivisions, and the federal government are all potential stakeholders interacting with community of interest e-government initiatives and other business solutions.

Ø Pervasive, open industry interoperability standards remove traditional interoperability issues of underlying proprietary software and platforms dependencies.

Ø The State should adopt and use voluntary open- or de-facto industry standards, as delineated in Target Software Architecture.

Ø The State should align its standards with Federal interoperability standards as they are developed.

Principle 5

e-Government solutions maximizing Target Architectures will achieve optimal efficiency and effectiveness for the delivery of services.

Rationale:

Ø Software automates the implementation and delivery of e-government solutions.

Ø Platform Architecture provides the end-user, citizen interface to agency and State information and resources. It enables the rapid, effective execution and processing of State and agency business-specific software applications, database and productivity software. 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.

Ø Software requires universal, secure access to integrated network infrastructure services necessary for communication, collaboration, and delivery of agency services. Target Network and Security Architecture define industry-wide, open-standards-based, scalable, flexible, and adaptive secure networks to facilitate the delivery of software.

Ø Networks enable access to a wide spectrum of information and resources, regardless of the method of delivery or the location of the citizen or end user.

4. Data/Information Architecture recommended Best Practices

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 Data/Information Architecture.

Recommended Best Practice 1

Establish the Technology Government Working Group (TGOV) comprised of agency technology experts to recommend technologies, process improvements, and the adoption of recommended standards and best practices.

Rationale:

Ø There is a definite need and business case for the standardization of technologies, requirements, and methodologies used to design, build, and implement solutions to accomplish the Governor’s e-government initiatives and programs.

Ø Information Technology Authorization Committee (ITAC) and Arizona’s CIO Council have reviewed and approved a technical Enterprise Architecture (EA) that defines a set of standards and best practices to utilize to achieve the Governor’s strategic plans for e-government initiates and subsequent business solutions.

Ø To assist with the coordination and adoption of EA, a multi-disciplinary technical working group is necessary and beneficial.

Ø TGOV is designed to:

o Provide technology and process expertise to assist in defining e-government blueprints aligned with EA domains (Network, Security, Platform, Software, and Data/Information) to support e-government implementations.

o Utilize relationships and lines of communication between relevant statewide entities (i.e., ITAC, CIO Council, GITA, ADOA/ISD/ITSD, ADOA/SPO, and affected agencies) to ensure that standards, best practices and lessons learned in the implementation of the e-government solutions are leveraged Statewide.

o Recommend the deployment of e-government technologies, aligned with EA, that are proven, stable, interoperable, portable, secure, and scalable.

o Recommend strategies for transition from legacy and “agency-driven” solutions to e-government technologies.

o Identify and make recommendations to quickly capitalize on opportunities to leverage, share, and reuse technologies to support common business requirements, activities, and operations across State government.

Ø Further information is provided in Appendix A, Technology Government Working Group (TGOV).

Recommended Best Practice 2

Utilize Communities of Interest to implement e-government solutions and strategic business initiatives that cross over traditional agency boundaries.

Rationale:

Ø Data/Information Architecture proposes a desired outcome within which communities of interest prudently transcend individual agency operations to mutually address new and changing business opportunities or legislation to more cost-effectively and efficiently deliver services, and interact with other governmental entities as well as the private business sector.

Ø Communities of Interest initiatives cross traditional organizational boundaries and require the balancing of individual needs, priorities, and policies against the collective vision and goals of the project.

Ø Communities of Interest initiatives require a certain level of consensus management. Communities of Interest initiatives are based on cooperation, collaboration, and mutual agreement of roles and responsibilities. A formal mechanism for developing a shared vision, defining roles, responsibilities, common objectives, and deliverables is required and must be arrived at through consensus.

o Formulation of an agreed upon problem statement and a process improvement model approach focuses the energies of community members on solutions to the problem. Process improvement models may be “bottom up” and informal, “top down” and prescriptive, or a blended combination depending on the project.

o Facilitation may be required to establish ground rules for operating as a community. When the nature of a project is particularly sensitive to the parties involved, active facilitation is an effective method to develop consensus and mutual agreement.

Ø The collaboration process is the governance model for Communities of Interest. Critical mass among the stakeholders must be achieved to initially proceed and maintained to ensure collective representation and participation. Collaboration must be a continuous process throughout the lifecycle of the project. All affected stakeholders must be informed during collaboration.

Ø Collaboration is generally based on five major principles that provide a foundation for effective collaboration among participating organizations.

o Collaboration must be organized and efficient for participants to work across jurisdictions and accept tasks that may not have immediate relevancy for their organization.

o Varying levels of participation should be allowed to maximize project exposure to all relevant parties. Participants must be free to chose and support initiatives.

o Equal consideration and participation, regardless of organizational affiliation, must be afforded to all participants.

o Varying levels of technical maturity and understanding among the participants is to be expected.

o Organizational independence and identity must be respected and maintained.

Ø Participating parties should be represented by their business or functional staff to provide the business case, drive the focus and priority of solutions, and market the project; by their technical staff to create deliverables and align the technical solutions with EA; and by their management to provide leadership, coordination and measurement metrics.

Ø Communities of Interest initiatives require an appreciation of the needs and requirements of all participating organizations. Understanding the priorities and challenges of the participating organizations will increase trust and clarify misconceptions.

Recommended Best Practice 3

Implement data and business modeling methodologies and tools that are Unified Modeling Language (UML^™) compliant.

Rationale:

Ø Data and business modeling can ensure that business functionality is complete and correct, end-user needs are met, and program design supports requirements for scalability, robustness, security, extensibility, and other characteristics, before implementation in programming code renders changes difficult and expensive to make.

Ø UML^™ is the industry-standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. It simplifies the complex process of software design, making a "blueprint" for construction. UML^™ standardizes the description of software designs, particularly object-oriented designs.

Ø UML^™ is supported by a broad base of industry-leading companies. UML^™ merges the notations used by the three most popular analysis and design methodologies, Booch, OOSE (use-cases), and OMT, to produce a single, universal modeling language that can be used with any method.

Ø UML^™ is a rigorous modeling language that standardizes the description of software designs, particularly object-oriented designs. It provides nine different diagram types with which to model systems, specifically:

o Use Case diagrams for modeling business processes.

o Sequence diagrams for modeling time dependencies and events.

o Collaboration diagrams for modeling interactions within a system.

o State diagrams for modeling the behavior of system objects.

o Activity diagrams for modeling the behavior of Use Case, objects, and operations.

o Class diagrams for modeling the static structure of classes.

o Object diagrams for modeling the static structure of objects.

o Component diagrams for modeling components.

o Deployment diagrams for modeling productive deployment of a system.

Ø UML^™ is methodology-independent. Regardless of the modeling methodology used to perform analysis and design, UML^™ can be used to express the results. XML Metadata Interchange (XMI) allows translation of a UML^™ model from one tool into a repository, or into another tool for refinement or the next step in the development process.

Ø Agencies should also consider using methodologies and tools that are IDEF0 IEEE 1320.1 (functional modeling) and if relational database technology is utilized, IDEF1X IEEE 1320.2 (conceptual modeling) compliant.

Recommended Best Practice 4

Establish consistent data classifications within an agency and associated communities of interest.

Rationale:

Ø Standards provide methods of uniformly supporting multiple security levels for the classification of data. Lack of standards prevents data from being classified according to its degree of sensitivity in a universally understandable way. This may cause data to lose its security classification as soon as it traverses any physical or logical boundary such as an organization, computer, application, or network. The receiving entity then lacks the knowledge and ability to enforce restrictions on the proliferation of data, opening a threat to organizational security and personal privacy.

Ø Proposed, but not developed, Statewide Standard P800-S840, Data Classification, should identify consistent methods of supporting multiple security levels for the classification of data.

Ø Data contained in e-government solutions must be controlled relative to all applicable security, confidentiality, and privacy policies, as well as applicable statutes, to enhance public trust, exert the proper stewardship over public information, and help ensure the integrity of the information.

Ø e-Government solutions must be implemented with adherence to applicable Statewide Security Standards and Target Security Architecture.

Ø e-Government solutions need to identify privacy-sensitive data elements prior to development and deployment to prevent the misuse of data, ensure confidentiality, and preserve its integrity according to all applicable statutes, mandates, and regulations.

Ø The purpose of a data classification methodology is to selectively protect data and information placed in an agency's custody.

Ø At a minimum, establish baseline statewide standard definitions for data classification types in accordance with confidentiality, privacy policies, and applicable statutes, as well as federal mandates and regulations.

Recommended Best Practice 5

Encourage e-government solutions to classify data elements into metadata registries according to the ISO/IEC 11179 standard to facilitate interoperability and the sharing of information.

Rationale:

Ø e-Government solutions usually involve the automation of certain government forms. Target Software Architecture addresses the structure of software applications that include web-enabled forms and documents. The content (semantics) of a form or document include the type of information, the meaning of terms and phrases, information needed to perform lookup and validation of users responses, and the meaning of data provided by respondents.

Ø Standardized classification of the content to describe data facilitates ease in understanding, sharing, transferring, designing, processing, analyzing, disseminating, and archiving that data.

Ø Metadata is loosely defined as data about data. ISO/IEC 11179 was designed to guide the process of recording metadata. The L8 – Metadata Committee of the Committee for Information Technology Standards (NCITS), developed a framework for describing data elements, called "Specification and standardization of data elements" - ISO/IEC 11179. ISO/IEC 11179 was developed in six parts that describe various aspects of providing metadata for data elements.

Ø ISO/IEC PDTR 20943 - Procedures for Achieving Metadata Registry Content Consistency: Data Elements - This draft report will provide procedures for ensuring that people using a metadata registry as specified in ISO/IEC 11179 will register data element metadata in the same way.

Ø ISO/IEC WD 18022 - IT-Enablement of Data Domains - This draft standard will provide procedures for the developers of international standards specifying code sets to ensure that the codes sets can be described in ISO/IEC 11179 metadata registries.

Recommended Best Practice 6

Leverage data warehouse technology to facilitate and accelerate the sharing of existing data and information.

Rationale:

Ø Data warehouses provide an approach for transforming data into useful and reliable information to support the business decision-making process and to achieve greater business intelligence.

Ø Data warehouses allow data to be replicated and combined from existing databases without changing the originating software application or developing new software applications.

Ø Data warehouses and their associated end-user query and reporting tools can reduce the burden on IT staff to generate reports and data queries.

Ø Decision-making is accelerated and improved with secure access to timely, easily accessible, accurate, and reliable information.

Ø Data warehouse solutions should be compliant with open metadata interchange specifications such as the Object Management Group’s OMG Common Warehouse Metamodel (CWM^™), Meta-Object Facility (MOF^™), XML Metadata Interchange Format (XMI), the Meta Data Coalition Metadata Interchange Specification (MDIS), etc. Metadata is used for building, managing, and using a data warehouse.

Ø Data warehouses must be implemented in adherence with all applicable statewide security standards, confidentiality, privacy policies, and applicable statutes to ensure data integrity, public trust, and proper stewardship over public information.

Ø Utilizing data warehouses with secure access simplifies security requirements by consolidating and reducing the number of individual software applications requiring security access.

Ø Users are able to access data and information without having to know where it resides or how it is stored.

Ø Repositories and information models can be incrementally used to build future enterprise-wide federated metadata.

Recommended Best Practice 7

Establish a federated metadata repository across communities of interest, and ideally, the State.

Rationale:

Ø Data and information used by a community of interest must be commonly understood and consistently defined and referenced by all stakeholders.

Ø A federated metadata repository provides a centralized location where agencies can store and maintain metadata. The repository also serves as an administration tool and helps promote data reusability, reliability, and sharing.

Ø Federated metadata facilitates the sharing and exchange of data and information through the development and use of consistent data definitions.

Ø Federated metadata can be implemented even if data is physically located in disparate databases. Logically, if the data is modeled the same in each physical location, the integration of software applications is simplified.

Ø The agreement and adoption of exchange standards for federated metadata simplifies software application integration and interoperability. The federated metadata repository should be compliant with open metadata interchange specifications such as the Object Management Group’s (OMG) Common Warehouse Metamodel (CWM^™), Meta-Object Facility (MOF^™), XML Metadata Interchange Format (XMI), the Meta Data Coalition Metadata Interchange Specification (MDIS), etc.

Ø Federated metadata should be defined collaboratively by all stakeholder business users throughout a community of interest. Authoritative business sources, responsible for the accuracy of the stored data, should be identified, documented, and maintained in the repository.

Ø Quality control techniques should be applied to the contents of the repository to ensure the quality of the data.

Recommended Best Practice 8

Access to State and agency information databases must be secure and accomplished through business rules embedded in software application systems.

Rationale:

Ø Proposed, but not developed, Statewide Standard P800-S835, Database, should identify security methods for database access supporting agency applications.

Ø Relational, object-relational, and object-oriented database technology is adaptive, providing for efficiency of design and use, flexibility, interoperability, and compatibility.

Ø Data should be input and accessed through software applications and business rules that own the data, to protect data from unauthorized or accidental access and to ensure security, data integrity, and accurate interpretation of the data. Free-form data entry and direct database access should be restricted.

Ø Data access routines should be written utilizing database software or database middleware as independent of the platform and underlying data structure as practically possible.

Ø Utilizing ANSI-standard SQL for relational database software access allows choice in database software and accessibility. Proprietary, vendor-specific extensions, while possibly providing some ease of use or performance benefits, may limit flexibility and adaptability.

Ø Database access logic should be separated from the application logic of a software application. This type of design makes databases easy to relocate, restructure, or to re-platform the back end services with minimal disruption to the software applications that use the databases.

Ø Depending upon any given software application, data may be stored and accessed in numerous databases in multiple locations. Data access should be implemented with usability, accessibility, cost, performance, adaptability, and security in mind. Security should be implemented in adherence with AZ Target Security Architecture.

Ø Data should be validated at every practical level to ensure that only valid data is processed and transported across the network.

Ø e-Government transactions require end-to-end integration with suppliers and partners, which necessitates that participants have to expose some of the data in their ERP systems. This presents a major challenge, since data can be defined and processed in very different ways. Middleware, which combines brokering, transaction process management, messaging, adapters, and some development tools, is key to this objective.

Ø Middleware solutions should be consistent with baseline Target Security Architecture. Agencies that require higher levels of security based on mandates that are more stringent should select middleware solutions that adhere to documented, agreed upon extensions of the baseline Target Security Architecture rather than relying upon the security functions defined by any individual middleware product.

Ø Middleware products should utilize identification, authorization, and access controls already provided by Network, Security, and Platform Architectures. Reusing common security and access control mechanisms avoids potential inconsistencies and redundancies and ensures interoperability and compatibility with Network and Platform operating systems.

Ø Compatible middleware ensures interoperability in heterogeneous, distributed software applications. Organizing software applications around compatible middleware that can be integrated and shared simplifies application management and reduces the cost and complexity of implementing changes in infrastructure services.

Ø Middleware components and objects should use a consistent, agreed-upon naming convention and schema to facilitate use, increase productivity, and interoperability.

Recommended Best Practice 9

Adopt the Government Information Locator Service (GILS) standards for describing and indexing the State’s information resources.

Rationale:

Ø The U.S. government created a Government Information Locator Service (GILS) to assist the public in locating information from federal agencies. This service is an electronic "card catalog," which describes and indexes information resources of many types.

Ø Content standards and search and retrieval protocols for US GILS are governed by the Application Profile for GILS, version 2. The GILS profile establishes a set of attributes for describing and indexing information in a standard way.

Ø The GILS profile incorporates portions of the ANSI/NISO Z39.50 Search and Retrieval Protocol (also called ISO 23950). Z39.50 is an open communications protocol for searching and retrieving electronic information over a network. Its use enables uniform access to a large number of diverse information sources over the Internet.

Ø Several states and foreign countries have adopted the GILS standard, making it the foundation of a Global Information Locator Service.

Recommended Best Practice 10

Implement applicable records management regulations, policies, procedures, and standards for both electronic and manual records management systems.

Rationale:

Ø Recordkeeping is a basic function of government. Records are comprised of data and information. Government must maintain, protect, and preserve the data and information entrusted to it, including providing access to the data and information while ensuring confidentiality where required.

Ø A.R.S. § 41-1350.D … records" means all books, papers, maps, photographs or other documentary materials, regardless of physical form, or characteristics, including prints or copies of such items produced or reproduced on film or electronic media pursuant to § 41-1348, made or received by any governmental agency in pursuance of law or in connection with the transaction of public business and preserved or appropriate for preservation by the agency or its legitimate successor as evidence of the organization, functions, policies, decisions, procedures, operations or other activities of the government, or because of the informational and historical value of the data contained therein.

Ø A.R.S. § 41-1346.D ..."records management" means the creation and implementation of systematic controls for records and information activities from the point where they are created or received through final disposition or archival retention, including distribution, use, storage, retrieval, protection and preservation.

Ø A.R.S. § 41-1346 requires all agencies to “Make and maintain records containing adequate and proper documentation of the organization of the organization, functions, policies, decisions, procedures, and essential transactions of the agency to furnish information to protect the rights of the state and of persons directly affected by the agency’s activities.”

Ø Established by statute, A.R.S. § 41-1345, The Records Management Division (RMD) of the Arizona State Library, Archives and Public Records (SLAPR) administers the management of public records throughout state and local government in Arizona.

Ø SLAPR has established the Arizona ‘Lectronic Records Taskforce (ALERT) to coordinate e-records activities in state and local government and to identify best practices for managing those records.

Ø Agency electronic and manual records management systems should conform with, and adhere to:

o Regulations, policies, procedures, guidelines, and standards published by SLAPR that establish acceptable practice for the management of public records for government agencies.

o Arizona Electronic Recordkeeping Systems (ERS) Guidelines, based on the National Electronic Commerce Coordinating Committee’s (NECCC) Electronic Records Management Guidelines for State Governments, describes specifications for recordkeeping functionality that should be incorporated into any electronic recordkeeping system to ensure the records are accepted as evidence, well managed, and preserved, and that benefits are appropriate to the costs.

o Applicable AZ Security Architecture Statewide Standards, as required.

5. Data/Information Technology and governmental Trends

Trends, economic, governmental, and technical, that impact and influence EA are available at http://azgita.gov/enterprise_architecture/.

Appendix A. Technology Government working group (TGOV)

BACKGROUND

There is a definite need and business case for the standardization of technologies, requirements, and methodologies used to design, build, and implement solutions to accomplish the Governor’s e-government initiatives and programs. Without standardization and the recommendation of consistent standards-driven technologies, agencies risk deploying solutions that:

Ø utilize proprietary technologies,

Ø are not aligned with Enterprise Architecture (EA) strategies, and

Ø are isolated from other initiatives and cross-agency business functions.

To mitigate these risks, the Information Technology Authorization Committee (ITAC) and Arizona’s CIO Council have reviewed and approved a technical Enterprise Architecture (EA) that defines a set of standards and best practices to utilize to achieve the Governor’s strategic plans for e-government initiates and subsequent business solutions.

To assist with the coordination and adoption of EA, a multi-disciplinary technical working group is necessary and beneficial.

INTRODUCTION

Under the direction of the Government Information Technology Agency (GITA) and the CIO Council, TGOV has been established to support the Governor’s strategic plan for e-government and to assist agencies to achieve success in areas of Enterprise Architecture implementation, technology selection, and the adoption of recommended standards and best practices that can be leveraged on a statewide scale. TGOV is supported by the State CIO, agency CIO’s and IT architecture personnel statewide.

TGOV leverages the knowledge and expertise of existing agency IT personnel to provide agencies with architectural guidance, technology recommendations and approaches that support the adoption and implementation of Arizona’s EA. Agencies, with representation on the CIO Council, are encouraged to participate and provide applicable technical staff representation.

Specifically, the TGOV:

Ø Provides technology and process expertise to assist in defining e-government blueprints aligned with EA domains (Network, Security, Platform, Software, and Data/Information) to support the e-government implementations.

Ø Utilizes relationships and lines of communication between relevant statewide entities (i.e., ITAC, CIO Council, GITA, ADOA/ISD/ITSD, ADOA/SPO, and affected agencies) to ensure that standards, best practices and lessons learned in the implementation of e-government solutions are leveraged Statewide.

Ø Recommends and assists with the deployment of e-government technologies, aligned with EA, that are proven, stable, interoperable, portable, secure, and scalable.

Ø Recommends strategies for transition from legacy and “agency-driven” solutions to e-government technologies.

Ø Identifies and makes recommendations to capitalize quickly on opportunities to leverage, share, and reuse technologies to support common business requirements, activities, and operations across State government.

KEY OBJECTIVES

The TGOV has defined several key objectives to assist state agencies in leveraging the skills and capabilities of the working group. They are:

1. Governor’s e-government Initiatives. Analyze and review the Governor’s e-government initiatives to develop implementation strategies and goals for direction, expectations, and impact on Arizona’s IT systems and infrastructures.

2. Architecture Assessments. Provide recommendations on existing agency architecture and technology plans and implementations to plan for target EA solutions and strategies focused on interoperability, extensibility, and security.

3. Communication and Outreach: Prepare reports, review findings, technical direction, and proposed recommendations with ITAC, GITA, CIO Council, and other statewide entities as necessary.

Appendix B. Statewide Context Diagram

appendix c. statewide conceptual model

glossary of terms

Terminology used throughout this document is defined in the GITA Policies, Standards, and Procedures (PSP) and Enterprise Architecture (EA) Glossary of Terms available at: http://azgita.gov/policies_standards/glossary.htm.

Revision	Effective Date	Summary of Changes
NC	02/05/2003	Initial release
1.0	05/06/2003	The Enterprise Architecture Technology Trends section has been removed and consolidated into a new EA Technology Trends document. A hyperlink to http://azgita.gov/enterprise_architecture/ was added in place of the description of the economic, governmental, and technical trends that impact and influence EA.
		The Glossary of Terms section has been removed and consolidated into the GITA Policies, Standards, and Procedures (PSP) and Enterprise Architecture (EA) Glossary of Terms. A hyperlink to http://azgita.gov/policies_standards/glossary.htm was added in place of the glossary content.