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 that is 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, 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 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

Software Architecture was the fourth 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. The technical components of the Software Architecture Domain build upon the Network, Security, and Platform Architecture Domains and are presented relative to the upper layers of the Open Systems Interconnection (OSI) Reference Model for strategic alignment with the EWTA and to furnish a common ground for analysis, discussion, and standards development.

2. Software Architecture Vision

The State of Arizona’s Software Architecture describes the criteria and techniques associated with the design, selection, development, and integration of business-specific, interoperable, software applications supported by common, open, programming software, an adaptive database environment promoting interoperability and sharing, and collaborative productivity software to automate and support the State’s heterogeneous and distributed business functions in an efficient and effective manner. Software Architecture provides a structure within which agencies can respond quickly to changing business needs and legislation, as well as embrace evolving technology to enable new business opportunities and provide new e-government solutions for delivering services.

3. Software Architecture Definition

Software Architecture delineates common, industry-wide, open-standards-based technologies (methodologies, tools, principles, etc.) facilitating the design, development, and purchase of software to automate and maintain State and agency business processes, and provides a foundation for interoperability, integration, collaboration, and communication. It defines various methodologies to promote increased sharing of resources and information among agencies as well as interoperability with other governmental entities and the private business sector.

Arizona’s Software Architecture consists of:

1. Software Applications -- systems comprised of programming, productivity, and database software, designed to automate and perform specific business functions such as payroll, accounts payable, MVD vehicle registration, etc.

2. Programming Software -- enabling technologies and products used to develop and maintain Software Applications, including programming languages (COBOL, C++, Java^TM, HTML, etc.), middleware technologies to facilitate inter-application communication and interchange of information, report writers, etc.

3. Database Software -- primarily database management systems to organize and manage data storage, facilitate access to and provide security for, and assure the integrity of the data in database storage.

4. Productivity Software -- office automation and collaborative software products and tools, such as collaborative groupware, email, calendaring and scheduling, word processing, spreadsheet, presentation, graphic applications, report writers, personal databases, etc. and productivity software components.

5. Utility Software -- typically an extension of a device’s operating system. Target Utility Software is classified as those necessary and appropriate software tools used to maintain and enhance Target Network and Platform Architectures, and more specifically, applicable device operating systems.

All software utilized by each State agency shall conform to requirements in Statewide Policy P252, Intellectual Property, to fully comply with all legal provisions governing copyright laws and authorial integrity.

Software Architecture allows the State and individual agencies to deploy and support effective and efficient business software applications, associated databases of information, and productivity software, while increasing the use of e-government solutions.

4. target Software architecture

Target Software Architecture addresses software applications, programming, database, productivity, and utility software relative to: functionality, adaptability, interoperability, and scalability. Software automates business functions and enhances productivity; therefore, the selection or development focuses primarily on its functionality and adaptability driven by business requirements and rules. Interoperability, critical to bridging disparate agency business functions and operations, is instituted through platform independence and use of non-proprietary technologies, capability to exchange information and integrate with other software applications, and the ability to maximize the principles, recommended standards, and best practices delineated in the other EWTA domains. This overall approach aligns with Statewide Policy P100, Information Technology, by focusing on technologies utilized by the software processes that automate and support agency business functions and requirements. These technologies allow for the development or purchase of portable, scalable, interoperable software applications, programming, database, productivity, and utility software that enhance agency services and operational capacities, improve productivity, performance, and the delivery and availability of services to the public and embrace Internet/Intranet and Extranet functionality.

Arizona’s EWTA provides the strategic technical guidance to correlate disparate agency business functions within a comprehensive, interoperable, adaptive framework for IT. The Network and Platform domains of Arizona’s EWTA address the infrastructure requirements of IT projects, while the Security domain focuses on the underlying security of the IT infrastructure. The Software domain concentrates on the software technologies, development strategies, and techniques along with the programming, database, and utility software utilized by the software applications and productivity software necessary to automate agency, or community of interest, business functions. Proposed IT projects, driven by the Arizona State Government and agency strategic plans and aligned with Arizona’s EA, are developed, reviewed, and evaluated based on Statewide Policy P340, Project 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 document as specified in Statewide Standard P340-S340, Project Investment Justification (PIJ).

Arizona’s Software Architecture establishes a framework to assess the alignment of the software applications and the associated programming, database, and productivity software proposed in a PIJ with Enterprise Architecture. Appendix A, Software Architecture Assessment Form, summarized below, describes major attributes and characteristics derived from Statewide Policy P100, Information Technology, as well as the principles, recommended standards and best practices contained in the Target Software Architectures. It provides an architectural tool to determine the “readiness” level of interoperability, functionality, scalability, and adaptability of existing or new software relative to enabling new business opportunities and providing new e-government solutions for delivering service in the future.

Appendix B, State of Arizona Target Software Application Assessment, categorizes agency software applications by community of interest. The intent of the community of interest categorization is to group software applications that may share common interests, information, communication, and interactions as a precursor to potential relationships and dependencies that will be addressed in the Data/Information Architecture. Appendix C captures the programming, database, and productivity software utilized by agencies to support agency business functions. Appendix B and C clearly demonstrate the diversity and breadth of software application solutions and products currently in use by state agencies.

Software Architecture Assessment Form Summary

Attributes/Characteristics	Description
A. Functionality, scalability, and adaptability, emphasizing client interaction	Designed to fulfill business requirements and maximize the efficiency and effectiveness of business functions: able to scale and adapt as business requirements change and expand. Software that is interoperable, modular, and deployable across the State enterprise. Software that supports e-government and client self-sufficiency through browser-based access, regardless of location.
B. Platform independence and use of non-proprietary technologies	Addresses interoperability, portability, and integration across platforms utilizing open and/or de-facto standard protocols, programming languages, middleware, development tools, databases, utilities, etc.
C. Exchange of Information, integration with other software	Utilizes common standard interfaces and/or middleware having the ability to interoperate and integrate with other software without custom programming and intermediate interface-specific applications.
D. Ability to maximize Target Network, Security, and Platform Architectures	Has the capability to conform to, and adhere to, the standards and best practices delineated in the other domain architectures without requiring substantial modifications.

Data and access to data and information are focal points of EWTA in general, and Software Architecture in specific. Software is the medium within which data is entered and updated through the various business software applications and productivity software tools. Data/Information Architecture focuses on the process of modeling the information that is needed to support the business processes and functions of agencies within the State enterprise. Where applicable, it spans agency organizational boundaries to address interoperability and e-government initiatives and opportunities 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. While Data/Information is being addressed as a separate domain of Arizona’s EWTA, it is introduced in this document to correlate the attributes and characteristics of the Software Architecture Assessment Form with the overall strategic goals of interoperability and e-government.

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, 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 the strategy to achieve market-based, citizen- and result-oriented government services. E-government 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, other local governments, and the federal government.

Aligning e-government initiatives with their primary beneficiaries classifies programs into four major portfolios:

E1 - Citizens:

Government-to-Citizens initiatives to fulfill a vision of one-stop, online access to government services.

E2 - Businesses:

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

E3 - Governmental:

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.

E4 - Intra-Governmental:

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

These portfolio classifications are included in Appendix B, State of Arizona Target Software Applications Assessment.

Target Software Architecture is vendor/manufacturer neutral and strategic by design. As such, it does not attempt to identify or address specific software products or software manufacturers / distributors. It does describe desirable attributes and characteristics of software (applications, programming, database, productivity, and utility) products used to automate and maintain State and agency business applications.

Software is generally procured in one of two ways, specific software applications designed to satisfy business functions, supported by a business case and qualified through the PIJ process are purchased through an individual, competitive Request for Proposal (RFP) cycle. Programming, database, productivity, and utility software products and distribution channels are competitively qualified for term contracts or transactional agreements through the Arizona Department of Administration (ADOA) State Procurement Office (SPO) State IT procurement processes. It is highly desirable that both procurement processes align with the recommended standards and best practices of Target Software Architecture. An individual agency’s purchase of specific software products utilizing the ADOA SPO contracts is based on the requirements of a given project as described in a PIJ and alignment with the overall collaborative business requirements of the agency.

Since recommendations and decisions made during the ADOA SPO State IT procurement process are based on the principles, recommended standards, and best practices of Target Software Architecture as well as prevailing industry and market conditions, certain options for some software products may be limited or eliminated from future purchase. Agencies should assess the impact of these recommendations and decisions relative to existing software products; interoperability with other software applications and entities; portability; scalability; and their overall business requirements. The Target Software Architecture development, individual agency, or community of interest RFP procurement cycle, and ADOA SPO State IT procurement process are interrelated and collaborative in nature. This allows agencies to participate in the process to maximize their current investment in software products and services, and to develop a transition plan to allow obsolete or non-conforming software products to be phased out. Maximizing the investment benefits and transitioning the software products are not mutually exclusive activities, and are in the best interest of agencies and the State enterprise.

In the case where a specific software application must be implemented to satisfy agency or community of interest business functions and requirements, GITA will work jointly with that individual agency, or applicable community of interest to ensure that the recommended standards and best practices of all five EA domains are appropriately addressed during the PIJ process and any subsequent RFP procurement cycle. GITA and ADOA SPO will also jointly ensure that the recommended standards, and best practices of Target Software Architecture are incorporated into all applicable State IT procurement solicitations that culminate in State IT procurement contracts. It is critical to align the procurement documents and processes with the Target Software Architecture to provide agencies with a streamlined vehicle to purchase products and services that proactively support the Target Software Architecture and overall agency business requirements.

The development and implementation of Target Software Architecture is an ongoing process that encourages the continual refinement of the architecture to ensure sustained alignment with evolving business strategies and requirements of the State as well as changing technology. These processes are extremely important regardless of whether implementation funding is available.

The recommended implementation approach for the Target Software Architecture is as follows:

1. State of Arizona Target Software Application Assessment: Agencies complete the Appendix A. Software Architecture Assessment Form for each of their specific software applications within a stated community of interest. The assessment is intended to determine the “readiness” level of interoperability, functionality, scalability, and adaptability of existing software relative to enabling new business opportunities and providing new e-government solutions for delivering service in the future.

2. Gap Analysis:

a. At the completion of the Target Data/Information Architecture, and based upon e-government initiatives in the Governor’s strategic plan, affected agencies within a community of interest will perform a software gap analysis relative to their “as-is” software, platform, and data/information technologies in the planning stage of a project, to establish a benchmark for agency operations and the development of a PIJ. In some cases an agency may perform a software gap analysis independent of either platform or data/information technologies, at the discretion of the CIO.

b. Agencies are responsible for the execution of any gap analysis as well as for submitting a standard PIJ for project approval and implementation. State IT procurement contracts and procedures should be used to purchase any necessary Software Architecture software products and services, unless otherwise directed by ADOA SPO.

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.

Target Software Architecture Table
OSI Layers 1 – Physical, 2 – Data, 3 – Network, 4 – Transport
Proprietary protocols, gateways	TCP/IP (P100-S101)	IPv6
OSI Layers 5 – Session, 6 – Presentation, 7 – Application
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.) Client/server software applications deployed with “fat” client requirements	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. Three-tier distributed software applications with access to n-tier architecture services	Open, industry standard Web services, .NET, WSDL, XML, UDDI initiatives Software applications hosted via Application Service Providers
Manufacturer-specific programming languages Platform-specific programming languages such as assembler, etc	Business programming languages such as ANSI-standard COBOL that are used in a majority of legacy software applications. C++, Java™, Visual Basic^®, etc.	C#
Proprietary gateways, interfaces Vendor/database-specific middleware with proprietary extensions	COM™, DCOM™ CORBA, ORB (P100-S102), ISO/IEC 11179 Open API (P100-S102) Middleware: TPM, RPC, RMI, JMS, MOM HTML, XHTML, XML (P100-S102)	COM+, Object-oriented software IIOP J2EE™ EJB™ server-side deployment EbXML secure exchange of information, UML, SAML, XSL, CSS3, XSLT, DSML, SOAP, TLS
3270 terminal access to software Unmanaged software applications 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	Custom 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) RDBMS Open database connectivity: SQL, ODBC, OLE DB, NDMP, NFS, CIFS (P100-S102) Database middleware that uses open database connectivity Email services: SMTP, S/MIME, IMAP4, POP3 Productivity software with open APIs	Portal-based universal browser access to all services Enterprise federated management tools Enterprise LDAP directory services OODBMS, ORDBMS JDBC LDAP accessibility for email Productivity software conforming to IETF standards such as ICalendar, CAP, IPP,etc.

Target Software Architecture Table

Obsolete, Transitional

Target (Strategic)

Emerging

OSI Layers 1 – Physical, 2 – Data, 3 – Network, 4 – Transport

Proprietary protocols, gateways

TCP/IP (P100-S101)

IPv6

OSI Layers 5 – Session, 6 – Presentation, 7 – Application

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.)

Client/server software applications deployed with “fat” client requirements

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.

Three-tier distributed software applications with access to n-tier architecture services

Open, industry standard Web services, .NET, WSDL, XML, UDDI initiatives

Software applications hosted via Application Service Providers

Manufacturer-specific programming languages

Platform-specific programming languages such as assembler, etc

Business programming languages such as ANSI-standard COBOL that are used in a majority of legacy software applications.

C++, Java™, Visual Basic^®, etc.

Proprietary gateways, interfaces

Vendor/database-specific middleware with proprietary extensions

COM™, DCOM™

CORBA, ORB (P100-S102), ISO/IEC 11179

Open API (P100-S102)

Middleware: TPM, RPC, RMI, JMS, MOM

HTML, XHTML, XML (P100-S102)

COM+, Object-oriented software

IIOP

J2EE™ EJB™ server-side deployment

EbXML secure exchange of information, UML, SAML, XSL, CSS3, XSLT, DSML, SOAP, TLS

3270 terminal access to software

Unmanaged software applications

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

Custom 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)

RDBMS

Open database connectivity: SQL, ODBC, OLE DB, NDMP, NFS, CIFS (P100-S102)

Database middleware that uses open database connectivity

Email services: SMTP, S/MIME, IMAP4, POP3

Productivity software with open APIs

Portal-based universal browser access to all services

Enterprise federated management tools

Enterprise LDAP directory services

OODBMS, ORDBMS

JDBC

LDAP accessibility for email

Productivity software conforming to IETF standards such as ICalendar, CAP, IPP,etc.

A composite, integrated domain table, consolidated from the individual EWTA domains, is referred to as the Target Technology Table and is available at http://azgita.gov/enterprise_architecture.

5. recommended Software Architecture Standards

Software Architecture Standards are established to coordinate agency and State implementation of business-specific software applications and productivity software together with their underlying software technologies consisting of programming, database, and utility software. The goal is to acquire or develop interoperable, business-specific, software applications and productivity software that are flexible and adaptable to changing technology, business, and information requirements and that utilize common, proven, and pervasive, open, software products and services. However, technological advances in available business-specific software applications have not necessarily or uniformly kept pace with standards development associated with the other EWTA domains. Therefore, the recommended Target Software Architecture standards and best practices may be challenged by the availability of interoperable, business-specific, software applications, or the cost to modernize “legacy” software applications currently used to provide core business services. Statewide Policy P340, Project Investment Justification (PIJ), along with Statewide Standard P340-S340, Project Investment Justification (PIJ), provide the evaluation process to derive the most optimal and strategic solutions for State and agency software relative to EWTA.

The recommended standards contained in this document, and the Software Architecture Assessment Form are codified in Statewide Standard P100-S103, Applications and Related Software, and Statewide Standard P100-S104, Software Productivity Tools, and are periodically reviewed and refined. Current and future ADOA SPO State IT procurement contracts for software products described in the Software Architecture must be consistent with these recommended standards and the Software Architecture Assessment Form contents.

Recommended Standard 1

Software applications, programming, database, and productivity software must be secure and scalable with adaptability extended to interoperability, platform-independence, and portability to automate and maintain State and agency business processes.[1]

Rationale:

Ø Statewide Policy P100, Information Technology, requires that State agencies develop, acquire, and/or implement software applications, programming, database, and productivity software that support open architecture, interoperability, portability, and scalability.

Ø Software applications, programming, database, and productivity software that are interoperable, scalable, and secure facilitate the sharing of information and resources; software application integration, maintenance and support; and the ever-increasing growth and performance demands for the services provided by the software applications and productivity software.

Ø Software applications, programming, database, productivity, and utility software that utilize open and/or de-facto standard protocols, without proprietary issues and requirements, support interoperability and portability.

Ø Software applications that utilize similar, familiar user interfaces, such as browsers, minimize additional training requirements.

Ø Software applications, programming, database, and productivity software that are platform independent, or are readily available on a variety of pervasive, industry-wide, commonly used platforms, facilitate integration, portability and interoperability.

Ø Software applications, programming, database, and productivity software that utilize common open and/or de-facto industry standards and/or middleware, without custom programming and intermediate interface-specific applications, enable the sharing and exchange of information, integration, and interoperability.

Ø Software applications that utilize Target Platform and Network operating systems provide widespread choice and flexibility for target database productivity, programming software, including middleware.

Ø Software applications and productivity software that utilize Target Platform and Network Architecture operating systems allow for common, open-standards-based, management tools that are deployable across the Target Enterprise Architecture domains and their extension to management of applications and productivity software.

Ø Target Platform and Network operating systems deployed with consistency of version and most current production release increase interoperability and portability of software applications, programming, database, productivity, and utility software, and reduce installation, support, and maintenance costs.

Ø Security services associated with software applications, database and productivity software should align with the Target Security Architecture, and:

o Allow for the security controls for applications, platform, and network levels to be integrated to reduce or eliminate redundancies.

o Support access, authentication, and authorization techniques as defined in the State of Arizona Target Security Architecture and related standards.

o Allow for all security updates to be pushed to, or accepted by, all associated devices.

o Allow for an integrated LDAP directory service.

Recommended Standard 2

Productivity software (email, calendaring and scheduling, office automation software with word processing, spreadsheet, presentation, graphic applications, etc.) must be capable of transparent interoperability with other productivity software across the State.[2]

Rationale:

Ø The State’s heterogeneous environment requires productivity software that is capable of transparently transferring and exchanging information across multiple software products.

Ø Productivity software must allow the transparent exchange of content information and data with the original formatting intact. If proprietary formats are used, the capability must be provided to convert documents (reports, spreadsheets, etc.) to formats acceptable for content exchange with the receiving productivity software.

Ø Email systems must have the capability of supporting multiple email clients.

Ø Email clients should be capable of email-enabling other productivity software through standard APIs such as MAPI, VIM, CMC, etc., to enhance interoperability and productivity.

Ø Email clients and associated productivity software must conform to standards (SMTP, S/MIME, IMAP4, and LDAP) and should allow a browser front-end.

Ø Email message transport and storage should be secure.

Ø Calendaring and scheduling (C&S) software should conform to proposed IETF standards. C&S clients should allow a browser front-end with secure remote and proxy access.

Ø C&S software should provide for attachments to the notification message. Software should allow for the creation of both private and public notification groups and contact lists. Software should enable task and resource management.

6. Software Architecture Purpose

The purpose of Software Architecture is to provide automation of the State’s business functions with widespread, common access into the State’s information resources. The goal is to create an environment in which the State’s current and future business, including e-government, 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.

Software Architecture must align with and facilitate the strategic goals of the State and agency IT plans. The key goals of the State IT Plan that impact requirements for Software Architecture are:

A. Increase the use of e-government solutions.

Rationale:

Ø Software Architecture provides the software implementation of e-government solutions facilitating common, open, citizen access interfaces and improving access to State resources and information, which results in consistent delivery of these software and application services to external business partners and the public through the Internet and Extranet.

Ø Software 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/Intranet and Extranet technologies.

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

Rationale:

Ø Software Architecture provides agencies with guidance for selecting and developing software applications, programming, database, and productivity software that support the sharing and exchange of information with other governmental entities and the private sector, while economically and effectively supporting agency operations.

Ø Software Architecture provides a foundation that allows agencies to select and develop interoperable software applications that will complement the State’s information architecture, as well as expand business continuity and integration opportunities with other agencies.

Ø Software Architecture provides a common framework for sharing of programming software methodologies and management tools as well as documentation strategies.

C. Improve access to broadband infrastructure statewide.

Rationale:

Ø Software Architecture defines an Internet/Intranet and Extranet e-government environment that maximizes Target Network, Security, and Platform Architecture that, in conjunction with broadband availability and access, allows for enhanced citizen and State employee access to business-specific software applications and information, regardless of location.

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

Rationale:

Ø Software Architecture facilitates the selection and development of business-specific software applications, programming, database, productivity, and utility software, which support interoperability and the sharing of information across the State enterprise to support relevant cross-agency business requirements.

Ø Software Architecture promotes consistent, common, proven technologies for implementing agency and potential cross-agency business-specific software applications, database information, and productivity and utility software environments, to allow agencies to improve interoperability and integration, and consequently, opportunities for sharing data.

Ø Software Architecture enables interoperability at multiple levels statewide as well as improved capabilities for sharing documents, graphics, and reports. It improves cross-functionality and interoperability of agency information systems and development methodologies.

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 Software Architecture provides the technical guidance and tools necessary for IT functions to collaborate with the respective, responsible business unit to effectively deliver quality business-specific software applications, programming, database, productivity, and utility software that satisfy agency requirements.

Software Architecture must support the business and program priorities of State government. Technology investments in business-specific software applications, programming database, productivity, and utility software must provide measurable improvements to public service. Improvements to public service and an agency’s approach and methodology to measure improvements should be identified in the agency’s IT plan and supporting PIJ documents. Software Architecture must support the economical and efficient development of open, interoperable software solutions that make State information, programs, and services more accessible to the people of Arizona. Software Architecture must foster an environment of software integration, collaboration, and communication, and must enable new, business-specific, software applications to be developed more rapidly and modified more easily as business requirements change.

Software includes the software applications, programming, database, productivity, and utility software that automate State and agency business processes and provides a foundation for integration, collaboration, and communication. Software Architecture should be independent of any vendor-specific software, platform, network, or security products or set of development tools. Database and programming software and development strategies should allow business rules to be implemented with flexibility, scalability, interoperability, and portability. Productivity and database software, and business-specific software applications should be managed as carefully as any other business-support infrastructure. Management requirements for business-specific, software applications should be documented during the requirements phase of any IT project. SNMP-based, network and system management tools should be used to manage software applications and productivity software as well as infrastructure components.

7. Software Architecture Principles

Software Architecture is the focal point for State and agency business-specific software applications. It defines how software applications should be designed and how they can interoperate and exchange information using programming software and database software. Software Architecture enables integration of productivity software, software applications and application services, efficient reuse of existing application assets, faster deployment of new applications, and a more responsive environment to changing business needs.

Software Architecture Principles provide guidelines for the design or purchase of software applications, programming, database, and productivity software supporting the State’s distributed business application environment.

Principle 1

Software automates State and agency business functions and processes.

Rationale:

Ø Software applications and productivity software are driven by business requirements and events, as well as business re-engineering improvement efforts. Software applications must be acquired or designed to support or improve upon business processes.

Ø Business processes are a series of business events. Business process changes involve the adding, removing, or changing of business events based on business requirements.

Ø Software applications that emulate business processes provide accurate, quality services to citizens and allow decisions to be based on up-to-date information.

Ø Software applications that mirror the actual business environment increase alignment and linkage to the business and are easier to realign when change occurs.

Ø Software applications, database and productivity software distributed across the enterprise or an individual agency should provide services regardless of end-user location.

Ø Software applications, database and productivity software must be adaptive with built-in flexibility and extensibility. Application designs based on Target Software Architecture allow the impact of future change to be minimized and more effectively managed and implemented.

Principle 2

Software applications, including databases, and productivity software must be designed for interoperability, growth, flexibility, and adaptability.

Rationale:

Ø Changing business functions will alter business processes and requirements, which, in turn, drive changes in software applications, databases, and productivity software.

Ø Interoperable software applications, databases, and productivity software promote and facilitate integration opportunities and sharing of information among agencies and the public.

Ø Scalable, extensible, and adaptive software applications, databases, and productivity software facilitate modification and change resulting from new or changing business requirements.

Ø Software applications, programming, database, and productivity software must support new business requirements and make use of new technologies. Extensibility provides functional scalability and facilitates the integration of additional functionality.

Principle 3

Software applications and productivity software must be designed, acquired, developed, or enhanced such that information and processes can be securely shared and integrated across the State enterprise as well as with external communities of interest, the public, and applicable service providers.

Rationale:

Ø Software Architecture provides a foundation that allows agencies to select and develop interoperable, business-specific, software applications, programming, database, and productivity software that will support integration opportunities with other agencies and external communities of interest.

Ø Software applications, programming, database, and productivity software designed to securely utilize Internet/intranets and extranets facilitate interoperability through the sharing of information and resources across the enterprise and with external communities of interest, regardless of end-user location.

Ø Software applications, programming, database, and productivity software that are designed to promote interoperability, integration, and the secure sharing of information increase efficiency while serving the public, improve the accuracy of information, and allow for better decision-making and accountability.

Principle 4

Software must be implemented with confidentiality and security of information as a high priority.

Rationale:

Ø State and agency operations, information, and software applications are valuable assets that support business functions and processes.

Ø Software applications, programming, database, and productivity software automate State and agency business functions and processes.

Ø 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.

Ø Software applications, programming, database, productivity, and utility software 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.

Ø Software applications, programming, database, productivity, and utility software must be implemented with adherence to applicable Statewide Security Standards and Target Security Architecture.

Principle 5

Software applications, programming, database, and productivity software should be interoperable, platform independent, browser-based (where applicable), and n-tier-architecture oriented.

Rationale:

Ø Software architecture allows the development or acquisition of State and agency business-specific software applications, including databases, to focus on business functions and requirements, without proprietary issues.

Ø Specific platform choices or preferences should not dictate or restrict agency business-specific software application solutions. Minimizing platform dependence associated with an application facilitates interoperability, adaptability, and scalability.

Ø Software applications and productivity software designed for industry-standard Web browsers create a common, secure, client interface, regardless of user-type or location.

Ø Software applications designed for n-tier-oriented architecture offer the greatest potential for reuse and sharing of programming code. Utilizing standard Application Programming Interfaces (APIs) insulates applications from the effects of platform, network, and database changes.

Ø Software applications, programming, database, and productivity software designed for n-tier-oriented architecture is highly scalable with the ability to optimize performance across multiple platforms. Software applications designed for n-tier-oriented architecture allow components (application processing, database accesses, etc.) to be deployed on separate physical devices whenever possible. Granularity in devices facilitates the partitioning of application systems and databases as well as the preservation of logical boundaries.

Ø The separation of software application layers facilitates the rapid modification of any layer without affecting the other application layers. This enables flexibility in adding new client devices (e.g., PDA’s, telephony devices, Pocket PCs. etc.), server platforms, or database software as technology or business requirements change.

Principle 6

Software applications should be designed to be granular and loosely coupled.

Rationale:

Ø Granular and loosely coupled software applications provide flexibility in logical and physical implementation.

Ø Software applications that are granular with reusable components facilitate increased productivity and rapid application deployment.

Ø Granular application design allows for the possibility of re-partitioning an application in the future. Business rules and other recurring application logic should be designed in a consistent manner, encapsulated in a granular form that is network based and available across the network to minimize overall application changes.

Ø Software applications should be designed and constructed around groups of reusable components to fully benefit from n-tier design and adaptive architecture. Reuse of components provides extensive cost savings in both development and maintenance programming. Software applications should be built by assembling and integrating existing components, rather than by creating custom code.

Principle 7

Middleware should be used for communication between software applications and services.

Rationale:

Ø Middleware is programming software that facilitates and simplifies communication within and between services; software application systems and components, whether distributed or not; or running on heterogeneous platforms (or not).

Ø Internet/Intranet and Extranet e-government transaction requirements have increased the need for sophisticated, networked software architectures and integration of services with legacy software applications.

Ø Middleware technologies encompass a wide range of capabilities from database access to very sophisticated integration engines known as message brokers.

Ø Middleware products provide interoperability using flexible, open, standards-based format, allowing new ways of accessing legacy databases and delivering data to Web clients.

Ø Middleware enhances software application integration by providing uniform mechanisms to bridge old and new technologies, or by enabling dissimilar functions to work together.

Ø Middleware facilitates interchange of information in a distributed, multi-vendor, and heterogeneous systems environment while providing the same levels of security, reliability, and manageability traditionally associated with a monolithic, mainframe-based architecture where all products are supplied by a single vendor

Principle 8

Software applications should be documented.

Rationale:

Ø Software applications support business processes, and must change when business processes change. Changes occur more frequently in business processes than in the types of data required to support the business.

Ø The application design is an asset of the development process, facilitates extensibility and adaptability, and provides for future reuse.

Ø Documenting an application will facilitate ease of design, testing, and modification. It will also improve and facilitate reengineering of the application, if necessary. Documentation created in the requirements analysis phase provides a consistent framework for development throughout the application life cycle.

Ø Accurate, up-to-date documentation will facilitate modifications and updates, as well as integration with other software applications.

Ø Version control is a valuable methodology of extending and impacting the useful life of a software product. Version control allows for the structured introduction of software product enhancements, extensions.

Ø Documentation of software applications facilitates reuse of the application components.

Ø Documentation should be in accordance with agency IT documentation policies and procedures.

Principle 9

Software applications, programming, database, and productivity software should maximize Target Network, Security, and Platform Architectures to achieve optimal efficiency and effectiveness for the delivery of services to citizens and end-users, regardless of location.

Rationale:

Ø Software applications, programming, database, and productivity software automate the implementation and delivery of State and agency business processes.

Ø 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 applications, programming, database, productivity, and utility software require 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 applications and productivity software tools.

Ø Networks enable access to a wide spectrum of information, software applications, programming, database, productivity, and utility software, and resources, regardless of the method of delivery or the location of the citizen or end user.

8. Software 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 Software Architecture.

Recommended Best Practice 1

Implement software applications, programming, database, productivity, and utility software that are interoperable, scaleable, portable, and platform independent.

Rationale:

Ø Software applications, programming, database, and productivity software that utilize open-standard or pervasive de-facto-industry-standard interfaces, protocols, and middleware allow agencies to respond efficiently and effectively to business growth and expansion requirements.

Ø Platform decisions should be made based on business requirements and Target Platform Architecture. Application portability supports interoperability and allows choice among multiple platform environments, maximizing the use of Target Platform Architecture.

Ø Software applications should be database independent, enabling interoperability and portability.

Ø Software applications should utilize programming software, including middleware, which is open or de-facto-industry-standard to facilitate interoperability, portability, and scalability.

Ø Productivity, database, and utility software should be platform- and operating-system-independent, enabling portability and interoperability.

Ø Version control, relative to programming, database, and productivity software, represents a valuable methodology of extending and impacting the useful life of a software product. Version control allows for the structured introduction of software product enhancements, extensions, and features that may increase a given software product’s adherence to pervasive open-industry-standards, Internet/Intranet and Extranet technologies, etc., which facilitate interoperability, portability, and integration opportunities.

Recommended Best Practice 2

Implement applicable statewide security standards for software applications and associated databases.

Rationale:

Ø The State's data is a very valuable resource, and establishing a secure data environment is a key component of the Enterprise Wide Technical Architecture, particularly with e-government initiatives. It is critical that the State's data be protected against any unauthorized use of the database or software application, accidental modifications and deletions, confidentiality and integrity breeches for data in data transport and physical storage, and disasters.

Ø To assure adequate protection, perform a risk assessment to identify specific security concerns that must be addressed before development and deployment of the software application. Statewide Standard P800-S805, Risk Management, establishes the requirement for agencies to perform risk assessments for IT systems and their environments to determine security vulnerabilities.

Ø Data security for software applications and associated databases must be implemented with adherence to applicable Statewide Security Standards, with attention to:

o Statewide Standard P800-S810, Account Management, to grant and manage access to software applications and associated databases.

o Statewide Standard P800-S820, Authentication.

o Statewide Standard P800-S825, Session Controls.

o Statewide Standard P800-S830, Network Security, with extensions to implement security scanning and intrusion detection at the database level, if possible.

Ø Determine encryption requirements for software applications and associated databases based on business needs and implement any data integrity issues relative to data movement and data transport in accordance with Statewide Standard P800-S850, Encryption Technologies.

Ø Consider using policy or role-based accounts for software application and database access to streamline administration, ensure scalability, and protect against non-application data access. With policy or role-based accounts, each individual user account is not defined to the application or database, therefore, users are unable to gain ad hoc access to the data. Policy or role-based access does not necessarily equate to policy or role-based auditing, which may require the delineation of individual users.

Ø Implement database transaction logging to assist the recovery of original data, if necessary. The transaction log should be protected in accordance with Statewide Standard P800-S810, Account Management, for access control and Statewide Standard P800-S870, Backups.

Ø Depending on business requirements, record information about users and their connections as data is updated and deleted.

Recommended Best Practice 3

Select productivity software that allows for the transparent exchange and sharing of content data and information, and minimize configuration variations across the State enterprise and individual agencies.

Rationale:

Ø Productivity software that allows for the transparent exchange and sharing of content data and information increases effectiveness and efficiency and facilitates collaboration across agencies and among workgroups.

Ø Consider productivity software as enterprise collaboration systems to encourage the exchange and sharing of content data and information. The fostering of collaboration based upon broader, enterprise considerations provides a foundation and environment that will increase the effectiveness and efficiency of government.

Ø Productivity software typically uses proprietary file formats to store information. Standards for storing content information that can be edited and modified do not exist at this time. Therefore, to allow for the exchange and sharing of content data and information, selected productivity software should provide for pervasive, industry-wide, commonly used data formats.

Ø Standardizing on a suite or interoperable set of productivity software that provides for pervasive, industry-wide, commonly used data formats across the State enterprise allows for a level of transparent exchange and sharing of content data and information until industry standards are developed and adopted.

Ø Minimizing configuration variations within deployed productivity software helps to ensure interoperability, as well as content and format consistency of data and information.

Recommended Best Practice 4

Provide a standardized set of basic productivity software and collaboration services to all employees, as required to meet business needs.

Rationale:

Ø A standardized set of basic productivity software and collaboration services:

o Increases employee productivity and the ability to support business processes.

o Reduces costs of maintenance.

o Provides the basis for multi-agency or statewide business initiatives.

o Increases integration and interoperability opportunities.

o Provides for universal employee access to data and information.

o Leverages the investments made in technology.

Recommended Best Practice 5

Adopt a standardized set of file (document) formats to reduce content exchange conflicts.

Rationale:

Ø Content exchange is a critical interoperability component of a productivity software collaboration framework, enabling the exchange of electronic information and data between individual users and groups.

Ø It includes the interchange of editable and non-editable documents between software and individuals.

Ø Establishing content exchange standards provides flexibility and independence when exchanging documents. Pervasive-industry-standard and de-facto-standard file formats include RTF, PDF, PNG, TIFF, GIF, JPEG, MPEG, etc.

Ø These standards enable a variety of tools to be used to view documents stored in standard formats.

Recommended Best Practice 6

Design or acquire software applications to utilize n-tier-oriented architecture.

Rationale:

Ø Software applications should be functionally partitioned to mirror business processes. The boundaries between application component functionality should reflect the work processes in a business unit. Interfaces between components reflect business interfaces to provide linkage between the business and IT solutions. The logical boundaries for applications should be drawn around units of work. Each unit of work is implemented with a collection of related business rules. Applications should respond to business events by invoking business rules.

Ø The interfaces between components and layers should be designed for maximum flexibility and openness. This encourages code reuse and the ability to add/modify business rules, data access methods, and presentation layers while limiting interactions between other layers and components.

Ø The logical separation of the software application tiers for presentation (user interface(s)), business rules, and data access code facilitates additions or modifications to each of the three tiers without unnecessarily impacting the other tiers. The logical separation of the tiers allows for changing the platforms where the tiers are deployed, resulting in a high degree of scalability.

Ø Programming, database, and productivity software utilized in conjunction with or to develop software applications should compliment and maximize the use of n-tier architecture.

Ø n-tier software applications are easily modified to support changes in business rules.

Ø Any combination of user interfaces (e.g., character, graphical, web browser, and telephone interfaces) may be implemented in an n-tier software application.

Ø The maximum benefits of an n-tier architecture are realized when many n-tier software applications and productivity software tools are deployed across the State, sharing common software services and offering multiple user interfaces.

Recommended Best Practice 7

Select the browser to be the presentation layer environment of software applications.

Rationale:

Ø The browser provides an independent presentation layer, allowing platform selection based on business requirements and target Platform Architecture.

Ø Utilizing a browser maximizes access for external customers and internal users, while presenting a consistent presentation interface. The browser provides a common look and feel through all developed software applications and productivity software tools.

Ø A browser interface allows easy integration of existing browser applications, frequently without additional development, recompilation, or additional software distribution.

Ø New browser-based software applications can be implemented on the desktop without additional software distribution or configuration.

Ø Utilizing a browser and minimizing the presentation layer environment reduces:

o Complexity to the desktop operating environment and simplifies integration, testing, and tuning processes.

o Configuration management and support issues.

o The likelihood of undesirable interactions between environments.

o The use of system resources and potential premature equipment upgrades.

Recommended Best Practice 8

Emulate the “look and feel” of the client device operating system and productivity software for all new software applications.

Rationale:

Ø Software applications that are designed to emulate commonly used office productivity software tools receive a higher degree of acceptance.

Ø Most current client operating systems and office productivity solutions utilize similar conventions for menuing, windows, and dialog boxes, as well as file options such as Open, Close, Save, and Exit, along with editing features that contain Cut, Copy, Paste, and Undo.

Ø Utilizing common functionality simplifies and facilitates the ability to copy and paste from one application into another.

Recommended Best Practice 9

Minimize and isolate customizations to purchased software applications.

Rationale:

Ø Purchased software applications have the potential to represent a significant challenge in the management and implementation of software, network, security, and platform architectures.

Ø Customizations should be isolated into separate modules from the purchased software, improving the ability to upgrade and move to new releases as required over time. As new releases or patches to the purchased software occur, the customization can then be reapplied.

Ø Customizations should be fully documented according to agency IT documentation policies and procedures.

Recommended Best Practice 10

Design or acquire software applications, including databases, and productivity software for manageability.

Rationale:

Ø Proactive application management facilitates the ability to support software applications and productivity software. Proactive management allows software applications to report potential problem conditions at predefined thresholds, before errors occur, providing system administrators the opportunity to take corrective action to prevent an application from failing.

Ø Software applications, including databases, should be managed in their entirety by addressing every component of the application and its dependencies. Application dependencies include infrastructure (e.g., middleware, databases, platforms, and networks, etc.), productivity software, other applications, programming and/or utility software, and shared software components.

Ø Software applications, including databases, and productivity software should be managed using SNMP-based system management tools.

Ø Software applications and their components generally require management functions, such as:

o Software distribution;

o Startup, shutdown, and restart of components;

o Starting multiple instances of a component;

o Configuration of components;

o Logging of component operations;

o Communication of errors, exceptions, and unexpected events;

o Security;

o Installation, removal, and update of application modules; and

o Version control, etc.

Ø Software applications should report status, performance statistics, errors, and conditions as well as provide for run-time tracing to assist in the resolution of operational problems.

Ø Specific management reporting requirements of an application should be determined during the design phase.

Ø Software application configurations should be parameter-driven, in order for applications to be reconfigured without recompiling and redistributing code.

Recommended Best Practice 11

Minimize the number of programming software languages and development tools used for software applications.

Rationale:

Ø When developing software applications, no single programming language is likely to provide all required functionality for the entire business application.

Ø Minimizing the number of languages used in software applications will mitigate the associated risks and costs.

Ø In order to provide an adaptive range in software architecture, avoid the use of proprietary, vendor-specific-versions of programming software to allow greater flexibility in migrating to other products, as new technologies become more mature and stable.

Recommended Best Practice 12

Implement database software that uses relational, object-relational, or object-oriented database technology and access stored data using ANSI-standard SQL and database middleware.

Rationale:

Ø 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 that is as independent of the platform and underlying data structure as practically possible.

Ø Utilizing ANSI-standard SQL for 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.

Ø Minimize the use of vendor- or product-specific stored procedures. While stored procedures offer some advantage to processing time and closeness to the database, and frequently offer some unique access features, their proprietary nature can tie the agency to both a particular platform and DBMS. Stored procedures may present difficult migration problems when the time comes to change database platforms, since the proprietary mechanisms that provide performance enhancements must be recreated under the new DBMS. Routines and business logic that are encapsulated in stored procedures must also be reconstructed when moving databases.

Ø Minimize the use of vendor- or product-specific extensions beyond the standard SQL-compliant commands.

Recommended Best Practice 13

Design databases to be modular, business driven, and aligned with application services.

Rationale:

Ø Modularity provides better performance for transactions, backup, and recovery, as well as higher reliability, availability, and scalability. Database designs that are business driven, n-tier architected, and linked with the functional application services facilitate changes in a business process by only requiring changes to the data affected by the change, not the entire software application.

Ø 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 State of Arizona Target Security Architecture.

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

Recommended Best Practice 14

Consider database replication, when necessary, based on business requirements.

Rationale:

Ø When databases are geographically distributed, they may be kept up to date from a central source database through replication. Replication services propagate data and transactions that occur in a central source database to each participating remote database. Replication may be appropriate when there are users in different locations needing similar data that does not need to be current 24 hours a day and where a central source database is not a possible solution.

Ø When replication is needed, evaluate the replication options and select the implementation that meets the existing business needs. Consider the following:

o Acceptable lag times to determine replication schemes, schedules, and the product features needed.

o Business requirements for any data transformation requirements and for any differences in replication requirements.

o Impact of processing overhead on the source and target databases relative to system and network performance.

o Identify specific requirements for data availability, recoverability, and freshness (near real time, 24 hours old, etc.)

o Design access to replicated data to be “read only.”

o Perform all data updates to the authoritative sources, and then replicate changes to remote databases. An authoritative source for data is the source of record where data is collected and maintained by the application that owns the data. All other data stores must synchronize to the source of record. All data updates must occur against the source of record through the data access rules that own that data.

Recommended Best Practice 15

Establish common, enterprise-wide data dictionary tools across the State to design and maintain new software application databases.

Rationale:

Ø A data dictionary or repository ensures that data is defined accurately and consistently so that it is used in the manner intended.

Ø An enterprise-wide data model, built in a repository, assists in identifying opportunities for data sharing and reuse.

Recommended Best Practice 16

Establish a component reuse and sharing strategy (and program) across the State.

Rationale:

Ø Reusable, shared software components increase the productivity and interoperability opportunities of software application development across the State. Reusable, shared software components simplify the environment and enable integration and sharing of information resources with other agencies. Reuse allows the leveraging and sharing of IT skills across the State. Reuse reduces development and maintenance efforts while facilitating a consistent design and development environment for IT staff. Reuse can eliminate certain potential processing inconsistencies and some of the duplication of development, testing, and maintenance of software applications.

Ø When the State begins to use federated data (data that is available for use within a single agency, between multiple governmental organizations, and across that State), it is important that the software that maintains the data is common, reused, and shared to mitigate risk to the integrity of the data.

Ø A component reuse and sharing program should be defined and implemented incrementally over time through ongoing projects. Elements of a program may include:

o Establishment of reuse methodology for the identification and implementation of components.

o Creation of a central repository of components, accessible to all authorized users.

o A methodology to harvest components from existing software applications.

o A component review board to identify common components and to provide oversight.

o Management of the component repository and common APIs.

Ø A software component should implement a single, common business rule or function, or a small set of related business rules or functions.

Ø Components and services should be callable from any software application or any other component.

Ø Developed components should be written in a portable, platform-independent language, such as C++, Java^TM, etc., and utilize open-standards-based security protocols, such as SSL, TLS, IPSec, S/MIME, GSS-API, CDSA, etc.

Ø Object-oriented components encapsulate both the business logic and the data access by the business logic and should be CORBA and IIOP compliant.

Recommended Best Practice 17

Adopt programming software coding standards and standard test/performance measurement procedures for custom developed software applications and components.

Rationale:

Ø Develop and adopt coding standards for all programming software languages and development tools. Minimize the number of programming languages to reduce development and maintenance complexity. Whenever possible, use non-proprietary programming languages to increase adaptability, flexibility, and portability.

Ø Coding standards make debugging and maintenance easier and should address (but not be limited to):

o Naming conventions for variables, constants, data types, procedures, and functions.

o Code flow and indentation.

o Error and exception detection and handling.

o Source code organization, including the use of libraries.

o Source code documentation.

Ø Develop and use a consistent API format for calling data access routines. This format should be consistent across all environments and be independent from the underlying file structure accessed.

Ø Design interfaces between software applications should be middleware message-based. Messaging supports the logical partitioning and boundaries, enhances interoperability, and simplifies integration efforts. Messaging technology allows for transparency in locations, databases, and data structures. Whenever possible, messages should be asynchronous in their logic and communication.

Ø Design the code providing input and output to the user interface to support as wide a range of interfaces as possible, including other applications as well as other types of user interfaces.

Ø Generalize software application interfaces. Generalizing application interfaces facilitates component reuse, providing more flexible, scalable solutions.

Ø Testing is a critical step in the development of software applications.

Ø Measuring software application performance will quantify the impact on platform and network infrastructure. Load testing will identify network, platform, and application bottlenecks prior to deployment in a production environment. Conduct performance and volume testing prior to deployment.

Recommended Best Practice 18

Adopt consistent software application documentation policies and procedures based on accepted industry best practices.

Rationale:

Ø Accurate, up-to-date documentation will facilitate modifications and updates, as well as integration with other software applications.

Ø Documentation should include, but not be limited to entity relationship diagrams, functional specifications, object models, interaction diagrams, source code, modifications, etc.

Ø Consider applicable elements of ISO/IEC 15910: Software user documentation process (1999) that specifies the minimum process for creating user documentation for software that has a user interface, including printed documentation (e.g. user manuals and quick-reference cards), on-line documentation, help text, and on-line documentation systems.

Ø Consider applicable elements of ISO/IEC TR 9294:1990 that provide guidelines for software documentation. It addresses the policies, standards, procedures, resources, and plans to produce effective software.

Ø Documentation methodology should be based on industry-wide standards such as the Unified Modeling Language™ (UML.)

Recommended Best Practice 19

Adopt a secure, common, consistent “look and feel” for State Internet/Intranet and Extranet web sites, including e-government-enabled software applications that promotes interoperability, and conforms to acceptable use and accessibility policies.

Rationale:

Ø The Webmasters Group, the Arizona Portal Advisory Council (APAC), the CIO Council (CIOC), and the State CIO form the working technical forum, advisory group, and decision-making elements relative to the strategic technical direction, architecture, design, and development of the State’s Internet/Intranet and Extranet web sites.

Ø A secure, consistent presentation format for State Internet/Intranet and Extranet web sites, including e-government enabled applications, establishes widespread, common access into the State’s information resources.

Ø A consistent presentation format provides a common:

o “Look and feel” for end users, regardless of agency specific information and e-government enabled applications.

o Web site framework and improves common, open, citizen access and a consistent delivery of the State’s information, software, and e-government enabled applications.

o Framework for sharing of e-government-enabled software development, management tools, and documentation strategies.

Ø Style Guide for Arizona @ Your Service is designed to provide web site developers with style elements, such as logo usage, color, typography, imagery, graphic elements, layout, content, etc., to build web sites that are consistent and compatible with the overall image of the Arizona @ Your Service web portal.

Ø State Internet/Intranet and Extranet web sites that are designed and constructed to provide interoperability with other State Internet/Intranet and Extranet web sites increase opportunities for the sharing of information and resources to streamline and improve e-government initiatives.

Ø State Internet/Intranet and Extranet web sites that are developed using interoperable, scalable, object-oriented programming software, such as Java^TM, HTML, etc., that provide for interoperability, scalability and integration with agency service-specific software applications.

Ø State Internet/Intranet and Extranet web sites that support major public browsers, including previous versions, in a reasonable manner, ensure widespread, common accessibility.

Ø State Internet/Intranet and Extranet web sites should conform with, and adhere to:

o State of Arizona Target Security Architecture, to ensure identities, authenticity, confidentiality, and reliability of digital information.

o Statewide Policy P125, Web Portal Acceptable Use Policy, to establish and enhance the State’s ability to provide e-Business services and e-government applications as an end-to-end solution.

o Statewide Policy P130, Web Site Accessibility, to establish an accessibility model for the development and implementation of web sites that minimize technical barriers to accessibility for individuals with disabilities.

o Federal Rehabilitation Act of 1998, # Section 508, as applicable, to provide disabled employees and members of the public access to information that is comparable to the access available to others.

o A.R.S. § 41-4152, which defines the obligations of state agencies obtaining information online.

o A.R.S. § 41-4153, which defines the requirement for posting agency annual reports online.

Recommended Best Practice 20

Adopt a common, integrated, development environment for web services and e-government-enabled software applications.

Rationale:

Ø A common, integrated, development environment facilitates and promotes interoperability, cross-agency software application integration, and component reuse.

Ø A common, integrated, development environment provides a framework for leveraging IT skills through common design and development tools, which supports the sharing and exchange of information between agencies.

Ø An integrated development environment supports the design/code/debug/deploy cycle of software development.

Ø An integrated development environment has the potential to enable rapid design, development and deployment of robust Web and e-government software applications, while reducing resource, timeline, and maintenance requirements by allowing software applications to be primarily "configured" rather than written from scratch.

Ø Consider applicable elements of ISO/IEC 12207 that define best practices for developing software. The standard describes the major component processes of a complete software life cycle and the high-level relations that govern their interactions. This standard covers the life cycle of software from conceptualization of ideas through retirement.

Recommended Best Practice 21

Utilize middleware products for enterprise application integration and database access that are interoperable, scalable, based on mainstream technologies, and compatible with State of Arizona Target Network, Security, and Platform Architectures.

Rationale:

Ø Industry-standard protocols and interfaces, combined with open architecture, minimize the dependence between software and platform infrastructure and simplify support in a distributed environment.

Ø 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 should be scalable in size, capacity, and functionality to meet changing business and technical requirements. The use of scalable components and products encourages the reuse of those components and products.

Ø Middleware products and configurations should be standardized or at least minimized to increase portability and interoperability while reducing support and maintenance costs, simplifying training, and increasing IT skills transfer.

Ø 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 solutions should be consistent with baseline Target Security Architecture. Agencies that require higher levels of security based on more stringent mandates 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.

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

Ø Middleware should be deployed on the platform that provides the best combination of cost, functional effectiveness, and compatibility with AZ Target Architecture Standards, interoperability, supportability, and performance.

Recommended Best Practice 22

Assign responsibility for business rules to the applicable business units.

Rationale:

Ø Business rules are the foundation on which systems and software applications are built.

Ø Business units are responsible for the definition and integrity of business rules and for communicating changes in business rules to IT.

Ø Implement business rules in a non-proprietary, cross-platform language to provide platform independence and portability.

Ø Business rules should be implemented as granular components. Business components that are more granular or singular in task provide reuse opportunities. Granular components make business rules easier to find and modify when necessary.

Ø Design software applications so business rules control access to data. Data is created and used by business processes. Data should be created, used by, and managed by the application component that automates the business process. Accessing data in any way other than by business processes bypasses the rules of the module that controls the data.

Ø Federated data, when available, should be used wherever available to assure data accuracy and simplify data management.

9. Software Architecture Technology Trends

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

appendix A. Software Architecture Assessment FORM

This assessment form is an architectural tool intended to determine the “readiness” level of interoperability, functionality, scalability, and adaptability of existing software relative to enabling new business opportunities and providing new e-government solutions for delivering service in the future. It is designed to support the planning and implementation of Target Software Architecture principles, recommended standards, and best practices. It addresses the alignment of the software applications and associated programming, database, productivity, and utility software proposed in a PIJ with Enterprise Architecture. It describes major attributes and characteristics derived from Statewide Policy P100, Information Technology, and the principles and recommended standards and best practices contained in the Target Software Architecture.

Ratings for programming, database, and productivity software are based on the latest production release of the software. Utility software products used in conjunction with target network and platform architectures are considered target.

This assessment form is applicable for all software reported to the Information Services Inventory System (ISIS) as defined by Statewide Standard P800-S815, Configuration Management.

Score. Questions for the four (4) software 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.

Agency/Community of Interest:

Software Application:

Attributes/Characteristics	Maximum Possible	Score	Description
A. Functionality, scalability, and adaptability, emphasizing client interaction (Software Applications only)	5		Software Applications designed to fulfill business requirements and maximize the efficiency and effectiveness of business functions with the ability to scale and adapt as business requirements change and expand; that are interoperable, modular, and deployable across the State enterprise; and that support e-government and client self-sufficiency through browser-based access, regardless of location.
B. Platform independence and use of non-proprietary technologies	5		Addresses interoperability, portability, and integration across platforms utilizing open and/or de-facto standard protocols, programming languages, middleware, development tools, databases, utilities, etc.
C. Exchange of information, integration with other software	5		Utilizes common, standard interfaces and/or middleware having the ability to interoperate and integrate with other software without requiring custom programming or intermediate, interface-specific applications.
D. Ability to maximize (take full advantage of) Target Network, Security, and Platform Architectures	5		Has the capability to conform to, and adhere to, the standards and best practices delineated in the other domain architectures without requiring substantial modifications.
Total Rating Points	20/15

Software when italicized in an assessment form question encompasses all five (5) categories of Software Architecture, including:

1. Software Applications 4. Database Software

2. Programming Software 5. Utility Software

3. Productivity Software

Agency/Community of Interest:

Software Application:

A. Functionality, scalability, and adaptability refer to software applications that maximize the efficiency and effectiveness of business functions and have the ability to scale and adapt as business requirements change and expand; are interoperable, modular, and deployable across the State enterprise; and that emphasize e-government and client self-sufficiency through browser-based access, regardless of location. (Software Applications only)	Yes
1. Is the software application extensible (capable of being expanded or customized), adaptive (the adjustment or modification that makes something more fit given the conditions of its environment), and capable of accommodating increased demands for service without substantial modifications and additional costs?
2. Is the software application developed and deployed utilizing open and/or de-facto standard protocols, languages, development tools, databases, etc.?
3. Is a browser or GUI presentation layer available for the software application?
4. Does the software application emulate the “look and feel” of the client device’s operating system and productivity software?
5. Does the software application support e-government solutions and/or end user self-sufficiency or self-service?
B. Platform independence and use of non-proprietary technologies addresses interoperability and portability across platforms utilizing open and/or de-facto standard protocols, programming languages, middleware, development tools, databases, utilities, etc.
1. Is the software, as configured, portable, and accessible across platforms in use within the subject agencies or community of interest?
2. Is the software, including version levels, consistent with current deployments of like or similar software within the subject agencies or community of interest?
3. Is the software, as configured, platform independent, without proprietary issues and requirements?
4. Is the software designed for, and/or supports, n-tier-oriented architecture deployment and implementation?
5. Does the software allow for, or provide open and/or de-facto standard interfaces for, a variety of end-user client devices, server and storage platforms, and database products?
C. Exchange of information, integration with other software emphasizes common standard interfaces and/or middleware having the ability to interoperate and integrate with other software without requiring custom programming and intermediate interface-specific applications.
1. Does the software, as configured, provide for and/or support (directly or through extensions) the transparent transfer and exchange of information with other software products through open or de-facto industry standards?
2. Does the software utilize target middleware technologies or open or de-facto industry standards for communicating and exchanging information with other software products?
3. Does the software provide for and/or support the integration of, or interfacing with, productivity software currently deployed within the subject agencies or community of interest?
4. Does the software provide the capability for sharing common software services and potential reuse of components?
5. Is the software, as configured, unrestricted by any proprietary or vendor-specific integration requirements?
D. Ability to maximize Target Network, Security, and Platform Architectures addresses the capability to conform to, and adhere to, the standards and best practices delineated in the other domain architectures, without requiring substantial modifications.
1. Is the software capable of providing and/or supporting secure (as defined by the State of Arizona Target Security Architecture) end-user interface access without substantial modifications, regardless of end-user location?
2. Does the software, as configured, utilize target Network and Platform operating systems?
3. Are the versions of the target Network and Platform operating systems utilized by the software consistent with current deployments within the subject agencies or community of interest?
4. Do the security services included with the software align with Target Security Architecture and adhere with all security, confidentiality, and privacy policies as well as applicable statutes? If no security services are included, is the software unrestricted to align with Target Security Architecture?
5. Is the software capable of being managed and maintained with standard SNMP-based management tools?
Total Rating Points

[1] Statewide Standard P100-S103, Applications and Related Software, adopted 12/18/2002.

[2] Statewide Standard P100-S104, Software Productivity Tools, adopted 12/18/2002.

Revision	Effective Date	Summary of Changes
NC	12/03/2002	Initial release
1.0	05/06/2003	Reference to a master Target Technology Table covering all domains and OSI layers at http://azgita.gov/enterprise_architecture/ has been added in Target Software Architecture. The software-specific target table remains.
		The Recommended Software Architecture Standards referred to in the Recommended Standards section have been codified in Statewide Standards P100-S103, Applications and Related Software Standards, and P100-S104, Software Productivity Tools, now available at http://azgita.gov/policies_standards/. References to the published standards documents have been added.
		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 Appendix B. State of Arizona Target Software Applications Assessment and Appendix C. State of Arizona Target Programming, Database, and Productivity Software Assessment contents have been removed and replaced with links to separate documents containing the information at http:/azgita.gov/enterprise_architecture/software_arch/appendix B.pdf and http:/azgita.gov/enterprise_architecture/software_arch/appendix C.pdf, respectively..
		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.