About GITA


IT Coordination and Planning
  Statewide Plan and Applications
  Enterprise Architecture
  Service Oriented Architecture
  Policies, Standards, Procedures


IT Project Review and Monitoring
  Project Investment Justification
  Project Oversight
  Project Management Certification


E-Government


Information Security and Privacy
  Incident Response
 
Encryption Readiness NOI


Public Safety Communications


Strategic Initiatives 


Telecommunications


Councils and Committees

 

Q & A about Arizona’s Enterprise Architecture Effort

1. Why does Arizona need an IT architecture?

2. Is GITA collaborating with agencies on this effort?

3. What is GITA’s role in developing the architecture? What is the agency’s role?

4. How is GITA assisting the agencies?

5. Do I have to comply? Will I be penalized for non-compliance as soon as each document is published?

6. How does the target architecture get implemented?

7. Why gap analysis?

8. When do the standards become effective?

9. Do I have to fill out a PIJ for my target?

10. Where can I send my staff to get educated about this effort?

11. Technology keeps changing, how does the architecture stay current?

 


1. Why does Arizona need an IT architecture?

Architectures facilitate change in an orderly, efficient manner by describing a direction for the future, along with the principles, standards, and best practices needed to arrive there. E-government offers opportunities for State agencies to reconsider operating as a large set of distinct silo operations and begin interoperating to deliver courteous, efficient, responsive, and cost-effective service to the citizen owners and employees of State government (Theme 5, Goal 16 of AZ Strategic Direction). Though each agency has the ability to pursue this goal alone, the amount of progress made will only make a quantum leap when agencies begin thinking beyond their own walls. Citizens view State government as a monolithic entity, whether agencies see themselves that way or not. Anytime multiple people from multiple disciplines of multiple organizations work together to accomplish a goal, both the goal and the plans for achieving it must be clearly defined.

top

2. Is GITA collaborating with agencies on this effort?

Absolutely. The State has a significant need for consistent technical standards. In order to respond quickly and effectively to this need, GITA is pursuing a fast-track approach to documenting the architecture. This does not mean that the effort is being done without regard for the specifics of the State environment. Agencies are being offered ample opportunity to provide feedback on the proposed architectural model, as well as the specific standards. The model we are following posits that IT is really a means used by the business to accomplish specific ends. GITA began the effort by ensuring a governance structure was in place, gathering the State’s business requirements, and reviewing individual agencies’ IT plans.

Some other states have embarked on top-heavy architecture development programs that created a great structure for including everyone in the development of an architecture – however, these efforts have lost steam before ever delivering an actionable, detailed, target architecture for all domains. Our research shows that 80 percent of the effort involves aligning the people, politics, and resources to actually implement the architecture – only 20 percent is spent on arriving at the architecture itself. GITA is dealing with the initial 20 percent itself, freeing agencies to focus on their business requirements.

top

3. What is GITA’s role in developing the architecture? What is the agency’s
role?

The effort falls under GITA’s direction to develop and implement a statewide IT plan (A.R.S. § 41-3501 et seq.). To shorten the development cycle time far below that of other states, as directed by the CIO Council, GITA is providing straw man architecture documents for the revision and approval of CIOs, ADOA/ISD, and ITAC, the IT governance bodies already in place. Arizona does not have the luxuries of time and resources to spend convening large teams by subject area, sending them to training, pairing them with a facilitator, defining the deliverables, and managing a massive project to simply create the target architecture and related standards.

Even so, the effort is a partnership. The documented architecture provides the conceptual framework and principles within which agencies may wisely plan their upcoming projects. Agencies will be asked to adopt collaboratively established principles, standards, and best practices that collectively aim us at the target architecture and express these in the Three-Year IT Plan and in PIJs for the specific projects that enact that plan. GITA uses its coordination and oversight role to evaluate proposed projects against the target architecture and ensure that we, as a collection of independent agencies, continue to approach the target, making best use of the resources we have when we have them.

top

4. How is GITA assisting the agencies?

The State CIO, GITA, ITAC, and the CIO Council are championing the architecture effort. As mentioned, GITA shouldered the responsibility for recommending the development process for architecture, creating the conceptual architecture document that guides the effort, and then producing individual architecture documents that provide very specific targets for technology solutions over a 3- to 5-year timeframe. We are making a concerted effort in communicating the importance of architecture and working to ensure decision makers in the State understand how valuable it is in facilitating change and reaching goals of e-government and cost-efficient inter-operation.

GITA has taken the step of documenting the target architecture across the technology life cycle (from emerging, through strategic, transitional, and obsolete stages). GITA is also leading an effort to compile Gap Analysis Implementation Plans for each domain based on technology gaps that currently exist between the “as-is” condition and the target identified in the published architecture document. Where an agency has hardware or software classified as “Obsolete,” GITA and that agency both need to understand the magnitude of change required and the resulting costs in order to migrate to the strategic standard. By collecting the specific data from agencies, GITA can identify the level of risk and other environmental issues resulting from the magnitude of the gap, helping agencies to decide on using a single, unified approach to closing it (possible in the case of security); a part unified, part agency-by-agency approach; or a fully distributed approach where each agency makes plans on its own.

top

5. Do I have to comply? Will I be penalized for non-compliance as soon as
each document is published?

Once standards are approved, GITA and State agencies must comply with the new technical standards as soon as possible. We say as soon as possible, or reasonably possible, because of agency priorities, budgetary concerns, and the biennial cycle.

Architecture is being developed as part of the due diligence for quality IT infrastructures. Providing statewide IT direction without the efforts of an Enterprise Architecture (EA) creates an arena of confusion and misunderstanding. The risks of not having an EA have grown too great as the pace of technological change continues at a breathtaking clip. The effort was not undertaken to single out an agency and prove it to be deficient in some way. The forward focus of designating a target promotes change in the appropriate direction, not blame for today’s conditions.

Lack of an architecture could well be the root cause for today’s problems! A problem whose existence is denied can never be solved; and that’s the spirit of undertaking the gap analysis effort for each domain. Again, identifying gaps is not a report card effort, but a consolidation of the magnitude of required changes needed to hit the target. It aligns the request for funding to accomplish various projects with the larger statewide roadmap for technology in order to achieve the core business goals of the State as a whole.
The problems we experience today (and, consequently, the problems our customers experience) are the penalty for non-compliance. The release of an architecture target brings with it the responsibility to perform the gap analysis and actively work toward closing the gap. There may be components and technologies that an agency has no choice but to live with. Due diligence requires that those decisions be examined and documented. Again, review of efforts in other states reveals complex waiver and exception programs. Arizona does not have the time and staff to administer such a program.

top

6. How does the target architecture get implemented?

Unfortunately, there is no magic wand to wave at the problem! Individual projects are the building blocks of the solution. The key is ensuring that any given project reinforces the target architecture and the principles behind it (like open solutions, inter-operability, etc.). Fortunately, the PIJ process already established can be used to do just that. In the past, individual agencies made a determination for themselves about whether the project advanced their goals and GITA tried to assess the value to the State as a whole. The presence of a larger roadmap provides an agency with clearer direction about what State goals a project should accomplish or reinforce. It also enables the establishment of Statewide buying contracts to help agencies procure products that fit well in the target architecture.

As described in “How is GITA assisting the agencies?” above, a gap analysis implementation plan will be compiled from agency inputs to assess the magnitude of effort required to close gaps between the target architecture and where we stand today, even if funding is not immediately available. It provides hard data rolled up to a statewide level for use in decision making.

top

7. Why gap analysis?

Performing a gap analysis provides some great benefits to your agency. It identifies IT projects, initiatives, policies, and standards that need to be implemented and identifies a high-level migration plan that relates to the statewide IT direction. As such, it helps in the construction of funding requests.

It results in a road map of targeted IT infrastructure items at the agency and helps IT align with architecture principles and best practices. The gap analysis gives an agency confidence that it is creating the systems and infrastructures that support e-government initiatives, new business processes, and information sharing requirements. It even provides a head start on an eventual PIJ, ensuring that the development effort gets reused.

top

8. When do the standards become effective?

Approval of a domain architecture document is not the same as creating PSPs. Various PSPs still have to be created using the same approach GITA uses today – straw man development, task team review/approval, CIO Council approval, and publication. Individual PSPs will carry the effectivity of the date signed by the State CIO, unless otherwise specified in the document itself. It is anticipated that new projects comply with architectural standards. Agencies are not required to bring their existing systems immediately into compliance, but to do so as soon as possible, or reasonably possible, due to agency priorities, budgetary concerns, and the biennial budget cycle.

top

9. Do I have to fill out a PIJ for my target?

Yes, after the completion of the Gap Analysis Implementation Plan. Once finished, the completed Plan forms a significant portion of the PIJ. Since individual projects remain the vehicle for achieving the target architecture, you do have to eventually complete a PIJ. But, for the purpose of performing the gap analysis, you do not have to complete a separate PIJ. If you already have submitted a PIJ for a project to close an identified gap in the domain architecture, simply refer to that PIJ number and/or the Three-Year Plan goal number on the front of the “Gap Analysis Implementation Plan.” All items in the Gap Analysis Implementation Plan were taken directly from the PIJ, so completing the Plan provides a head start on completing the PIJ for Agency and GITA approvals of the implementation of targeted technologies.

top

10. Where can I send my staff to get educated about this effort?

The GITA website (http://azgita.gov) displays a button on the homepage for Enterprise Architecture. 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. If the architecture is not publicized and used, the entire development effort is for naught. It would be like producing house plans but never building!

top

11. Technology keeps changing, how does the architecture stay current?

The vision, principles, and purposes of the targeted domain are based on business principles and will change much more slowly than technology. The targets, standards, and best practices will change more rapidly. GITA will continue to refresh the documents, making certain they still align with the business plans of the State and the direction of technology across industries. Updates will be published at the GITA Enterprise Architecture page and publicized through the CIO Council. This is not a one-time effort to be put on the shelf, but an iterative process that pays bigger dividends as it becomes internalized into our existing planning processes. GITA has the responsibility to keep the architecture and implementation plan current as part of its Statewide IT Plan effort.
 

top
 

Privacy Policy    Accessibility Policy    Contact GITA |  © Copyright 2009 GITA