Effective for
Fiscal Years
2001 Through 2003
Signatures
Management Information Services (MIS)
Table of Contents
|
I. Introduction
|
|
|
A. Executive Summary
|
Page #
|
|
B. Scope
and Purpose
|
Page #
|
|
C. Relation
to Other Plans
|
Page #
|
|
D. Planning
Process
|
Page #
|
|
E. Business
Drivers
|
Page #
|
|
F. Information
Technology Trends
|
Page #
|
|
G. Plan
Participants
|
Page #
|
|
|
|
II.
Architectures
|
|
|
A. Architecture Reference Model
|
Page #
|
|
B. Business Architecture
1. Introduction
2. Architecture
Reference Model
3. Principles
4. Architecture
Analysis
a. “As-Is” Architecture
b. “Should-be”
Architecture
c. Gap Analysis
5. Related
Topics of Importance
6. Best
Practices
|
Page #
|
|
C. Desktop Architecture
1. Introduction
2. Architecture
Reference Model
3. Principles
4. Architecture
Analysis
a. “As-Is” Architecture
b. “Should-be”
Architecture
c. Gap Analysis
5. Related
Topics of Importance
6. Best
Practices
|
Page #
|
|
D. Information Architecture
1. Introduction
2. Architecture
Reference Model
3. Principles
4. Architecture
Analysis
a. “As-Is” Architecture
b. “Should-be”
Architecture
c. Gap Analysis
5. Related
Topics of Importance
6. Best
Practices
|
Page #
|
|
E. Applications Architecture
1. Introduction
2. Architecture
Reference Model
3. Principles
4. Architecture
Analysis
a. “As-Is” Architecture
b. “Should-be”
Architecture
c. Gap Analysis
5. Related
Topics of Importance
6. Best
Practices
|
Page #
|
|
F. Data Architecture
1. Introduction
2. Architecture
Reference Model
3. Principles
4. Architecture
Analysis
a. “As-Is” Architecture
b. “Should-be”
Architecture
c. Gap Analysis
5. Related
Topics of Importance
6. Best
Practices
|
Page #
|
|
G. Infrastructure Architecture
1. Introduction
2. Architecture
Reference Model
3. Principles
4. Architecture
Analysis
a. “As-Is” Architecture
b. “Should-be”
Architecture
c. Gap Analysis
5. Related
Topics of Importance
6. Best
Practices
|
Page #
|
|
H. Security Architecture
1. Introduction
2. Architecture
Reference Model
3. Principles
4. Architecture
Analysis
a. “As-Is” Architecture
b. “Should-be”
Architecture
c. Gap Analysis
5. Related
Topics of Importance
6. Best
Practices
|
Page #
|
|
I. Technology Administration
|
Page #
|
|
|
III. Migration
Plan
|
|
|
A. Architecture
Transition Plans
|
Page #
|
|
B. Roles &
Responsibilities
|
Page #
|
|
C. Project
Schedule
|
Page #
|
|
D. Resource
Requirements
|
Page #
|
|
E. Reporting Requirements
|
Page #
|
|
|
|
IV. Appendices
|
|
|
A. Glossary
|
Page #
|
|
B. Architecture
Development Schedule
|
Page #
|
|
C. WSDOT
IT Planning Cube
|
Page #
|
|
D. WSDOT
Planning Relationship Diagram
|
Page #
|
|
E. Architecture
Planning Methodology
|
Page #
|
|
F. Planner’s
& Owner’s View of the “As-Is” Architecture
|
Page #
|
|
G. Architecture
Reference Model
|
Page #
|
|
H. Agency-wide
Business Drivers
|
Page #
|
|
I. Information
Technology Trends
|
Page #
|
|
|
|
|
|
|
I. Introduction
A. Executive Summary
Provide a brief overview of the background,
process, and findings suitable for executive level staff. Use graphics and other forms of
communication that facilitate quick assimilation of information.
B. Scope and Purpose
The purpose of this section is to provide
the reader with a clear understanding of the scope and purpose of the
architecture plan. The scope and
purpose statement can be extracted from the appropriate sections of the
architecture plan project charter. The
role of the Architecture Plan in business and IT Planning and design should be
clearly stated. The business benefits
to be derived from the Architecture Plan should be clearly stated.
C. Relation to
Other Plans
The
purpose of this section is to provide the reader with a clear picture of how
the architecture plan relates to WSDOT’s strategic, business, IT, operational,
and budget plans. References to the
existing WSDOT plans and associated documents that show the relationships
between WSDOT’s many business and IT-related plans should be clearly shown.
D. Planning
Process
This section provides an overview of the
information technology architectural planning and management process and its
relationship to business, information technology, operational, and budget
planning. References should be made to
the “IT Planning Cube,” the IT Planning Relationship Diagram, the Architecture
Planning Methodology Diagram, etc.
E. Business
Drivers
The purpose of this section is to provide
the reader with an overview of the agency-wide and detailed business drivers
that affect how WSDOT does business and/or changes the business that WSDOT
conducts. Business drivers are outside
influences that information technology must be responsive to, be constrained
by, and be flexible enough to handle at some point down the road. Business drivers typically are few in number
and represent a high-level association between the technology used to support
business and business need.
Agency-wide business
drivers are listed in Appendix H. Examples include: Increases in
Population/Traffic, Changes in Customer Expectations, Policy/Regulatory
Changes, etc. Detailed business drivers
are typically identified in the IT Planning process, the decision package
development process, etc. They often
are business influences that are particular to a specific business
organization.
F. Information Technology Trends
Technology trends are outside technological
influences that information technology must be responsive to, be constrained
by, and be flexible enough to handle at some point down the road.
Agency-wide technology drivers can be found
in Appendix I. Examples include: changes in versions of
software used by stakeholders outside WSDOT, opportunities to use emerging
technologies such as GIS/Web, etc.
G. Plan
Participants
List the customers and MIS employees who
participated in developing this portion of the Architecture Plan. This material can be extracted from the
project charter.
|
Name
|
Author
|
Contributor
|
Reviewer
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
II. Architectures
The purpose of this section is to provide a
detailed description of each of the seven architectural layers identified in
the Architecture Reference Model. The
“architecture reference model” will come from Spevak’s “architecture process
model,” the NIST 5-level model, DOC’s reference model, the federal architecture
reference model, etc. The Architecture
Reference Model is defined in Appendix G.
The “Business Architecture” will be based
upon the “business environment” description developed by the IT Planning team
(account execs). The “business
environment” model developed by the account execs must contain a clear
description of the overall WSDOT business environment (services, customers,
stakeholders, locations, application systems/subject data used by each customer
area, etc.).
The “Desktop Architecture” section will come
from the “level playing field” documentation and an inventory of customer uses
of information technology that is not supplied by MIS. Some of this information will come from the
account execs IT Planning document, some will come from the Weston Study, some
from Y2K documentation efforts, etc.
The “Information Architecture and the Data
Architectures” will come from models currently used by the DRM group. The Weston Study may also provide
information on these architectures.
The “Applications Architecture” will come
from the Weston Study, Y2K documentation, current application documentation,
etc. The mapping of application systems
to customers will come from the account execs planning efforts, Y2K
documentation, etc.
The “Infrastructure Architecture” will come
from a wide-variety of sources. The MIS
Operating Plan, the Weston Study, the Ciber Study, etc. will all provide
information for this section.
The “Technology Administration” will be
developed from a variety of documents.
The IT governance work, the “technology coordination” group’s work,
industry best practices, the IT Planning Process, the IT Budgeting Process,
level playing field processes, etc.
A. Architecture Reference Model
The purpose of this section is to define the
seven architectural layer model upon which WSDOT’s architectural models will be
developed. Each of these seven
architectural layers will be broken down into the most important sub-components
which will be the focus of the descriptions of each architectural layer. Appendix G provides a detailed description
of the Architecture Reference Model, its seven component architectural layers,
and also identifies each architectural sub-component.
B. Business Architecture
1. Introduction
2. Architecture Reference
Model
3. Principles
4. Architecture Analysis
a. “As-Is” Architecture
b. “Should-be”
Architecture
c. Gap Analysis
5. Related Topics of
Importance
6. Best Practices
C. Desktop Architecture
1. Introduction
2. Architecture Reference
Model
3. Principles
4. Architecture Analysis
a. “As-Is” Architecture
b. “Should-be”
Architecture
c. Gap Analysis
5. Related Topics of
Importance
6. Best Practices
D. Information Architecture
1. Introduction
2. Architecture Reference
Model
3. Principles
4. Architecture Analysis
a. “As-Is” Architecture
b. “Should-Be”
Architecture
c. Gap Analysis
5. Related Topics of
Importance
6. Best Practices
E. Applications Architecture
1. Introduction
The purpose of this section is to provide an
overview of the “applications architecture section.” This overview should include a description of the purpose for
defining an applications architecture, the major components of the section and
their purposes, and a description of how the “As-Is” and “Should-Be”
applications architectures were developed.
2. Architecture
Reference Model
The purpose of this section is to provide
the reader with a clear understanding of the “position” of the applications
architecture within the Architecture Reference Model and the major sub-components
contained within the applications architectural layer. Each of the sub-components contained on the
Architecture Reference Model for the applications layer should be clearly
defined. This section should also
discuss the relationship of the application architectural layer and the other
six architectural layers (i.e. business, desktop, data, info,etc.).
3. Principles
The purpose of this section is to define
architectural principles related to the applications architecture. References should be made to the overall IT
Principles document and the relationship of these applications architecture
related principles and the principles contained in the IT Principles document
should be described.
4. Architecture Analysis
a. “As-Is”
Architecture
The purpose of this section is to document
the existing “As-Is” applications architecture. The structure of this section should be based upon the
sub-components identified in the Architecture Reference Model (i.e. Enterprise
Applications Systems and Applications Tools).
These two major topics should be the focus of the documentation that is
put together on the “As-Is” applications architecture.
Within these two major topics, the
“Planner’s and Owner’s View of the As-Is Architecture” diagram should be used
to help identify the what, how, who,
where, when, and why “things” related to Enterprise Applications Systems
and Applications Tools. For example,
from the “What” column of Row 1,
“MIS Supported Application Systems,” “Customer supported Application Systems,”
“Development Projects in Progress,” and “Interfaces” are all topics that should
be discussed under the major topic “Enterprise Applications Systems.” From the “How” column of Row1, “Application Support Tools,” “Application
Development Tools,” “QA Tools,” “Policies, Standards, and Procedures,” “IE
Methodologies,” “Applications Principles,” and “Performance Measures” are all
topics that should be included in the discussion related to the major topic
“Application Tools.”
By going across the “applications row” of
Row 1 of the Planner’s & Owner’s View of the “As-Is” Architecture, the
writer can identify those topics that will fall into each of the two major
sub-topics described in the Applications “As-Is” Architecture.
It is important to remember that the purpose
for describing the Applications “As-Is” Architecture is to provide WSDOT with a
baseline for planning, designing, and supporting its applications systems and
related business functions. Much of the
detail for this section can be provided via charts, diagrams, and matrices
which show the structure and relationships of the application related “things”
identified in Row 1 of the Planner’s & Owner’s View of the “As-Is”
Architecture diagram. Volume and detail
is not the goal of this section.
Rather, clarity and brevity are key to this section being both
understandable and usable.
Some of the possible diagrams, matrices, and
charts that have been identified for inclusion in this section include:
·
Applications by
Platform
·
Applications by
Subject Database
·
Applications by
Tools
·
Applications by
Services
·
Applications by
Service Locations
·
Applications by
Business Functions
·
Applications by
Customers Supported
·
Applications by
Timing Cycles
·
Applications by
RCW
·
Applications by
Support Staff
·
Applications by
Functional Groups
·
Applications by
Type (i.e. strategic, operational, etc.)
Sources of material for this section can
include the Weston study, existing applications documentation, existing
policies, standards, procedures, and processes, service level agreements, etc.
It is important to remember that the purpose
of this section is to clearly describe WSDOT’s applications architecture
environment including what systems we support, how they are supported, what
tools are used, what policies, methods, standards are used, who uses the
systems, what business functions are supported, etc. The “what, how, who, where, when, and why” lists that are
provided on the Planner’s & Owner’s View of the “As-Is” Architecture
document (Appendix F) should provide a clear description of the major topics
that need to be discussed in this section.
b. “Should-Be”
Architecture
The purpose
of this section is to document the proposed “Should-Be” applications
architecture. The structure of this
section should be based upon the sub-components identified in the Architecture
Reference Model (i.e. Enterprise Applications Systems and Applications
Tools). These two major topics should
be the focus of the documentation that is put together on the “As-Is”
applications architecture.
c. Gap
Analysis
The purpose of this section
is to document the “gaps” between the “As-Is” and “Should-Be” applications
architectures. These “gaps” should
include the need for new applications systems, tools, processes, procedures,
policies, etc.
5. Related
Topics of Importance
The purpose of this section is to identify
major topics of importance related to the applications architecture. These topics could include items such as the
need for an information engineering methodology, the lack of web development
standards, the need for additional applications development/support tools, IT
Trends affecting applications development, maintenance, operations, and
support, etc.
6. Best
Practices
The purpose of this section is to identify
best practices related to applications development, maintenance, operations,
and support. Recommendations can be
made as to which of these practices should be evaluated for possible
implementation into WSDOT’s applications development, maintenance, operations,
and support environment
F. Data Architecture
1. Introduction
2. Architecture
Reference Model
3. Principles
4. Architecture
Analysis
a. “As-Is” Architecture
b. “Should-Be”
Architecture
c. Gap Analysis
5. Related
Topics of Importance
6. Best
Practices
G. Infrastructure Architecture
1. Introduction
2. Architecture
Reference Model
3. Principles
4. Architecture Analysis
a. “As-Is” Architecture
b. “Should-be”
Architecture
c. Gap Analysis
5. Related Topics of
Importance
6. Best Practices
H. Security Architecture
1. Introduction
2. Architecture
Reference Model
3. Principles
4. Architecture
Analysis
a. “As-Is”
Architecture
b. “Should-Be”
Architecture
c. Gap
Analysis
5. Related
Topics of Importance
6. Best Practices
I. Technology Administration
The purpose of this section is to provide a
detailed description of how technology will be administered and managed within
WSDOT. The “Technology Administration”
section will be developed from a variety of documents. The IT governance work, the “technology
coordination” group’s work, work being done by the IT Quality Focus Group,
industry best practices, the IT Planning Process, the IT Budgeting Process,
level playing field standards, policies, processes, etc.
III. Migration Plan
A. Architecture
Transition Plans
B. Roles &
Responsibilities
C. Project
Schedule
D. Resource
Requirements
E. Reporting
Requirements
IV. Appendices
A. Glossary
B. Architecture Plan Development Schedule
C. WSDOT IT Planning Cube
D. WSDOT Planning Relationship Diagram
E. Architecture Planning Methodology
F. Planner’s & Owner’s view of the “As-Is”
Architecture
G. Architecture Reference Model
H. Agency-Wide Business Drivers
I. Information Technology Trends
Appendix A
Glossary
Two glossaries have been
developed as a result of the IT Planning and IT Architectural Planning
processes. A general glossary of IT
Planning and IT Architectural terms has been developed by MIS staff to clearly
define commonly used terms in the IT and architectural planning efforts. A specialized glossary has also been
developed to define terms that are specific to the many new IT trends that are
emerging on a daily basis. Both of
these glossaries are available from MIS in hardcopy form and are also available
on the MIS IT Planning website.
Appendix B
Architecture Development Schedule
|
|
|
Estimated Start Date
|
Estimated End Date
|
|
PHASE 0
|
PROJECT PLANNING
|
|
|
|
|
· Charter
|
01/2000
|
02/2000
|
|
|
· Workplan
|
01/2000
|
02/2000
|
|
|
|
|
|
|
PHASE 1
|
ARCHITECTURE METHODS PLANNING
|
|
|
|
|
· EAP Research
|
02/2000
|
10/2000
|
|
|
· IT Principles
|
02/2000
|
09/2000
|
|
|
· Architecture Methodology
|
02/2000
|
09/2000
|
|
|
· IT Trends Research
|
04/2000
|
06/2000
|
|
|
· Architecture Reference Model
|
04/2000
|
06/2000
|
|
|
· Zachman Framework Scoping
|
04/2000
|
05/2000
|
|
|
· Planners View “As Is” Architecture
|
04/2000
|
05/2000
|
|
|
· Select Architecture Repository & Modeling Tool
|
05/2000
|
06/2000
|
|
|
· Glossary
|
02/2000
|
10/2000
|
|
|
· Web Presence
|
05/2000
|
12/2000
|
|
|
|
|
|
|
PHASE 2
|
ARCHITECTURE REQUIREMENTS DEFN.
|
|
|
|
|
· Define Agency Business Drivers
|
04/2000
|
05/2000
|
|
|
· Define Detailed Business Drivers
|
05/2000
|
08/2000
|
|
|
· Define IT Trends
|
04/2000
|
06/2000
|
|
|
· Define Business IT Requirements
|
06/2000
|
08/2000
|
|
|
· Define IT Requirements
|
06/2000
|
08/2000
|
|
|
· Define Architecture Requirements
|
08/2000
|
09/2000
|
|
|
|
|
|
|
PHASE 3
|
CONCEPTUAL ARCHITECTURE DEFINITION
|
|
|
|
|
Define “As Is” Architecture
|
|
|
|
|
· Define Business
|
07/2000
|
09/2000
|
|
|
· Define Customer Technologies
|
05/2000
|
07/2000
|
|
|
· Define Information
|
05/2000
|
09/2000
|
|
|
· Define Applications
|
05/2000
|
09/2000
|
|
|
· Define Data
|
05/2000
|
09/2000
|
|
|
· Define Infrastructure
|
05/2000
|
09/2000
|
|
|
· Define Security
|
07/2000
|
09/2000
|
|
|
Define “Should Be” Architecture
|
|
|
|
|
· Define Business
|
09/2000
|
10/2000
|
|
|
· Define Customer Technologies
|
09/2000
|
09/2000
|
|
|
· Define Information
|
09/2000
|
10/2000
|
|
|
· Define Applications
|
09/2000
|
10/2000
|
|
|
· Define Data
|
09/2000
|
10/2000
|
|
|
· Define Infrastructure
|
09/2000
|
10/2000
|
|
|
· Define Security
|
10/2000
|
10/2000
|
|
|
GAP Analysis
|
11/2000
|
12/2000
|
|
|
|
|
|
|
PHASE 4
|
DOCUMENTATION
|
01/2001
|
03/2001
|
|
|
Conceptual Architecture Report
|
|
|
|
|
· “As Is” Architecture
|
|
|
|
|
· “Should Be” Architecture
|
|
|
|
|
· Migration Plan
|
|
|
|
|
· IT Principles
|
|
|
|
|
· Business Drivers
|
|
|
|
|
· IT Trends
|
|
|
|
|
· Best Practices
|
|
|
|
|
· Glossary
|
|
|
|
|
|
|
|
|
PHASE 5
|
IMPLEMENTATION
|
04/2001
|
07/2001
|
|
|
· Business Planning Process Integration
|
|
|
|
|
· IT Planning Process Integration
|
|
|
|
|
· Decision Package Process Integration
|
|
|
|
|
· Budget Process Integration
|
|
|
|
|
· Design & Construction Process Integration
|
|
|
|
|
· QA Process Integration
|
|
|
|
|
· Performance Measure Process Integration
|
|
|
|
|
|
|
|
|
|
|
|
|
Appendix B (Continued)
Architecture Development Schedule
PROPOSED WSDOT “AS-IS” IT ARCHITECTURE
DEVELOPMENT & REVIEW SCHEDULE
|
PRODUCT
|
RESPONSIBLE
PARTY(IES)
|
REVIEW DATE*
|
|
1. Architecture Report
Template
|
Bob
C.
|
07/06/00
|
|
2. Desktop “As-Is”
Architecture
|
Jim
S./Bill P.
|
07/20/00
|
|
3. Application “As-Is”
Architecture
|
Nancy
A./Vonnie R./Bill P.
|
08/03/00
|
|
4. Business “As-Is”
Architecture
|
Bob
C./Acct Execs
|
08/17/00
|
|
5. Information “As-Is”
Architecture
|
Chris
K./Bill P.
|
08/31/00
|
|
6. Data “As-Is”
Architecture
|
Chris
K./Bill P.
|
09/14/00
|
|
7. Infrastructure
“As-Is” Architecture
|
Deea
N./Bob C.
|
09/28/00
|
|
8. Security “As-Is”
Architecture
|
Deea
N./Chris K./Bob C.
|
10/12/00
|
* Note - Each of the seven “as-is” architecture products will be
reviewed as part of the biweekly Strategic Planning Meetings. Wherever possible, the product presenter
will be the MIS Executive Manager most directly responsible for the given “as-is”
architecture (i.e. Chris Kemp will present the information and data “as-is”
architectures, Nancy A. & Vonnie R. will present the application “as-is”
architecture, etc.).
Appendix C
WSDOT “IT Planning Cube”
Appendix D
WSDOT Planning Relationship Diagram
Appendix E
Architecture Planning Methodology
Appendix F
Planner’s & Owner’s View of the
“As-Is” Architecture
Appendix G
Architecture Reference Model
Appendix G
Architecture Reference Model (continued)
Architecture Reference Model
The
Architecture Reference Model is a way of representing the different sets of
related architectural layers that make up the overall architecture. These layers are also referred to as
“domains”. Each layer has one or more
associated components. The components
provide the more detailed breakdown of what each layer is comprised of in the
architecture. The WSDOT domains are divided into, Governance, Business,
Customer Technologies, Information, Applications, Data, Infrastructure and
Security.
The
technical architectures describe the Department's information technology from a
technical perspective The technical
architecture are driven by the requirements articulated in the Business Layer
Architecture and are provided authority, direction, guidance, and control by
the Governance Layer.
Governance Layer
The Governance layer wraps around the other technology layers. The underlying framework is made up of seven
layers: Business, Customer Technologies, Information, Applications, Data,
Infrastructure and Security. Each of
these layers contains one or mare components.
The Conceptual Architecture Framework provides a structure for defining
the complete IT environment and the related Business Drivers IT Principles, and
Trends. This framework drives the
architecture definition and implementation of the component architectures and
provides a basis to ensure logical consistency across these layers and
component architectures.
The five domains and twelve
components, taken together, provide the basis for the enterprise architecture
that supports the business requirements of the Department.
Business Layer
The
Business layer is derived from business driven strategies, requirements, trends
understood and supported by the department executives and the lines of
business. Guides the engineering of
the organization's information systems and technology infrastructure across the
various component architectures as identified in the WSDOT Strategic and IT
Plans. The Business architecture
establishes the requirements for the technical architecture essential to
support the Department’s business drivers.
Customer Technologies
Customer
Technologies consists of those technologies necessary at the desktop for the
business person to perform their essential job functions using information
technology.
Appendix G
Architecture Reference Model (continued)
Information
The set
of standards and rules that govern the programs, commands, and interfaces associated with the generation of
information from data and subsequent
delivery of the generated information.
It defines the overall data architecture. It describes the logical
structure of databases and the methodology used to correlate data in multiple
databases. The information architecture provides a framework for defining
responsibility for data integrity and distribution.
Applications
Applications
define and encompass the purchase, development, enhancement, delivery, location
and support of business application software within the Department. Applications run on computer platforms,
access data and deliver services through communication networks. They use the other architecture components
to accomplish their functions.
Data
A
consistent and universal representation of the "things of
significance" which must be recorded, reported and accounted for in a
business information environment. These "things of significance" are
relevant to the Department's activities and requests (e.g., a Customer, a
Claim, an Employer Account). The Data Architecture promotes an information
environment that:
Encourages
the sharing of information throughout the department, other government agencies
and with citizens.
Maximizes
the information assets available to support the department's knowledge workers
and executive management.
Provides
a blueprint for the development of a departmental information infrastructure
that is inter-operable, extendible, scaleable, accessible, responsible, and
easy to use.
Infrastructure
Infrastructure
defines computing environment and services managed in the Department. It consists of logical elements, physical
elements, carrier services, protocols, hardware platforms, operating systems,
distributed computing services, database environments, networks and the
supporting systems management functionality.
Security
Security defines the
protections that efficiently and effectively manage the Department's security
environment to support confidentiality, integrity, privacy, and recoverability
of physical facilities, networks, applications and data.
Appendix H
Agency-Wide Business Drivers
High-level Agency-Wide
Business Drivers were developed by MIS staff in February/March of 2000. The final “business driver” document was
approved by the IT Strategic Executive Mangement Team in early March 2000. A copy of the document is available from MIS
and is also available on the MIS IT Planning Website.
Appendix I
Information Technology
Trends
Detail IT trends were
identified in March/April of 2000. The
final “IT Trends” documents were approved by the IT Strategic Executive
Mangement Team in early May of 2000. A
copy of the documents are available from MIS and are also available on the MIS
IT Planning Website.