Arizona Enterprise Architecture

Guiding Arizona to Ever Improving Citizen Service

Questions and Answers about Arizona’s Platform Architecture Approach

1. Why doesn’t Arizona’s platform target look like those of other states?

Arizona has chosen to emphasize interoperability among platform-related items in an effort to transcend technologies and vendor-specific solutions, where possible. The goal of architecture is to describe a direction for the future, along with the principles, standards, and best practices needed to arrive there. Basing strategic direction on vendor-specific solutions may prove to be shortsighted, given the pace of technological innovation and rapid reversals in the fortunes of even established technology companies. A requirements-based approach to target platform architecture rather than a product-/manufacturer-specific approach tends to overcome the rapid change cycle of products and revisions and allows agencies to focus on the functionality of platform devices to support business requirements.

2. If EA is vendor and product neutral, why do trademarked products appear in the platform target table?

Describing platforms/operating systems the State currently has installed and will continue to maintain for the next 3 to 5 years simply cannot be done any other way. The nature of the computer/software industry at present necessitates use of trademarked terms like Windows, Solaris, or AIX when discussing installed combinations of hardware and operating systems. The platform domain is currently dominated by these vendor-specific, but very prevalent, standards rather than by true open industry standards, like Linux. The trademarked items in the document are not treated as purely proprietary, since their prevalence has spawned a wide variety of utility and application product development by third parties for use with them. The fact that the document contains recognizable items specific to a manufacturer is not an endorsement of the manufacturer as the “State standard.” Rather, statewide procurement processes overseen by the State Procurement Office (SPO) qualify specific device and operating system manufacturers and distribution channels through a competitive, requirements-based process that aligns with the principles, standards, and best practices of Target Platform Architecture.

3. How was the “as-is” matrix created for server, storage, and client devices? What if a combination of hardware and operating system doesn’t appear on the matrix?

GITA examined current ISIS inventory data to determine the most prevalent combinations of server, storage, and client hardware/operating systems in use by the State to create the “as-is” matrix. Other items common to industry or being considered for use by agencies were added to broaden the list and provide a wider perspective.

If a component/operating system combination necessary for achievement of an agency’s business goals was not scored, agency technical representatives should score the item using the assessment tool criteria, Appendix A of the Target Platform Architecture document, and submit the completed assessment to GITA for update of the “as-is” matrix that appears in Appendix B of the document.

4. How does the scoring work in the platform assessment tool?

Target Platform Architecture establishes targets for platform devices relative to:

o Versatility,

o Capability to utilize open- or pervasive industry-standard operating systems,

o Security functionality of the operating system, and

o Adherence to open-system-standard interface specifications and device drivers that utilize standard protocols and formats.

This approach aligns with Statewide Policy P100, Information Technology, by focusing on the functionality of platform technologies needed to support agency business requirements that enhance agency services and operational capacities. The requirements aim to improve productivity, performance, and public services rather than to specify detailed attributes like configurations, devices, and operating system revisions.

The assessment tool provides evaluation criteria for platform items, regardless of manufacturer or vendor. It contains the requirements in question format and awards one point for each affirmative answer – no subjective weighting of categories or questions has been done. The questions were tested by scoring a wide variety of sample platform items, including PCs, servers, mainframes, wireless clients, storage devices, telephone systems, and pagers. Wording was refined to be technology and vendor neutral. To further reduce subjectivity, the requirements were made general enough to prompt a simple yes or no answer rather than a rating on a numeric scale.

The threshold score between target and transitional/obsolete was set to 18 points, a number that provided a fair characterization of maturity regardless of technology. Examples exist of items that exceed 18 points in every general category (server, storage, and client) required to meet business needs.

5. Who approved the categories and questions used in the platform assessment tool?

Categories and questions were developed using already approved Statewide Information Technology Policy P100 as well as related principles set forth in the Target Platform Architecture document and elaborated in proposed Platform Infrastructure Standard P100-S102. The assessment tool is being reviewed by agency CIOs as a part of the platform architecture target document. As with the other technical domain documents, the Target Platform Architecture and assessment tool will be re-evaluated and updated on an ongoing basis to ensure the questions remain appropriate and reinforce the technology policy of the State of Arizona.

6. What if an agency disagrees with the scoring for an item it has in inventory?

The Enterprise Architecture project is an open, collaborative process that provides for discussion and feedback. Agencies that disagree with the scoring of a component are encouraged to provide GITA with justification for changing the score. A low score for a given item does not mean its use must be terminated immediately. The low score merely alerts the agency of the need to consider alternatives to the item. An agency may have a valid business requirement for keeping a low-scoring item for the near term. The forward focus of designating a target promotes planning for change in the appropriate direction, whenever that change can occur, from a business and funding perspective.

7. How will GITA be compiling the platform gap?

As in the previous domains, GITA has included a table in the target architecture document to characterize representative types of servers, storage devices, and clients across the full life cycle (from emerging, through strategic, transitional, and obsolete stages). As a result of taking a requirements-based approach (see Question 1 above), placement on the table has been accomplished by determining an individual item’s overall scoring against an assessment tool that reflects Arizona’s platform standards.

Using the assessment tool, GITA has identified the cutoff score between target and obsolete/transitional categories (scored items appear in Appendix B of the target document). Where an agency utilizes items that score below the cutoff, or that appear in the obsolete/transitional column of the target table, GITA and that agency both need to understand the magnitude of change required and the resulting costs to migrate to platform items that score above the cutoff. GITA is asking agencies to include in their gap report only items for which a business or agency need to replace exists.

8. What ensures alignment of SPO Statewide contracts with the requirements provided in the target platform architecture?

Aligning statewide contracts with the architecture is a vital task included in the project plan of every domain. The statewide procurement processes overseen by the State Procurement Office (SPO) qualify specific device and operating system manufacturers and distribution channels through a competitive process that aligns with the principles, standards, and best practices of Target Platform Architecture. GITA communicates platform-related requirements and best practices directly to SPO following their approval, participating in the mapping of required changes to existing contracts and identification of new contracts.

The overall goal of the process is to place the burden for alignment with EA on the manufacturers during the procurement process, ensuring the targets are being met through the specific purchases being made by agencies. An individual agency’s selection of specific manufacturers, hardware configurations, and operating systems is always based on the business needs of a given project, a positive business case for anticipated savings, or the overall business requirements of that agency. Procurement is completed under the applicable SPO contract(s).

9. Where can I send my staff to get more information about this effort?

The GITA website (http://azgita.gov) displays a button labeled “Enterprise Architecture” on its left side. We certainly want everyone in IT to know about the architecture and the methodology used to create it. Send your staff here to get the most recent versions of specific documents created in the effort, as well as to learn the background to the effort through presentations that reside there. When you mention the site, please make staff aware that you expect new projects to accommodate the architecture.