Training notes to guide discussion on the framework, methodology, process, tools and software of doing Enterprise Architecture to strategically plan e-services in government.

1. Course Name: Enterprise Architecture Framework and Information Systems Planning Essentials
Day 1:
MORNING AFTERNOON
08:00-08:30 01:00-03:00
Registration Enterprise Architecture:
TOGAF FRAMEWORK
08:30-09:00 03:00-03:30
Course Orientation Coffee Break
09:00-10:00 03:30-5:00
Enterprise Architecture: Enterprise Architecture:
DEFINITIONS AND STANDARDS NASCIO TOOLKIT
10:00-10:30 05:00
Coffee Break Home
10:30-12:00
Enterprise Architecture:
COMPETENCY AND MATURITY
12:00
Lunch Break
DAY 2
MORNING AFTERNOON
08:00-08:30 01:00-03:00
Lessons Learned Enterprise Architecture:
BUSINESS ANALYSIS FRAMEWORK
08:30-10:00 03:00-03:30
Enterprise Architecture: Coffee Break
ZACHMAN INTERROGATIVES
10:00-10:30 03:30-05:00
Coffee Break Enterprise Architecture:
PERFORMANCE MODEL & PROCESS MAPPING
10:30-12:00
Enterprise Architecture:
ARCHITECTURE COMPONENTS ELABORATION
12:00-01:00
Lunch Break
DAY 3
MORNING AFTERNOON
08:00-08:30 01:00-03:00
Lessons Learned Enterprise Architecture:
TECHNOLOGY REFERENCE MODEL
08:30-10:00 03:00-03:30
Enterprise Architecture: Coffee Break
INFORMATION MATURITY MODEL
10:00-10:30 03:30-05:00
Coffee Break Enterprise Architecture:
INFORMATION SYSTEM SECURITY MATURITY MODEL
10:30-12:00
Enterprise Architecture:
DATA AND APPLICATION CONCEPTUAL MODEL
12:00-01:00
Lunch Break

2. Day 4:
MORNING AFTERNOON
08:00-08:30 01:00-03:00
Lessons Learned Information Systems Strategic Planning:
STRATEGIC PLAN INPUT AND THINKING TOOLS
08:30-10:00 03:00-03:30
Information Systems Strategic Planning: Coffee Break
MODELS OF STRATEGIC PLANNING
10:00-10:30 03:30-05:00
Coffee Break Information Systems Strategic Planning:
STRATEGIC PLAN AUTHORING TEMPLATE
10:30-12:00 05:00
Information Systems Strategic Planning: Home
STRATEGIC PLAN INTERROGATIVES AND WORKPLAN
12:00
Lunch Break
Day 5:
MORNING AFTERNOON
08:00-08:30 01:00-03:00
Lessons Learned Open Standard Software and Templates:
ENTERPRISE ARCHITECTURE BUSINESS CASE AND
TERMS OF REFERENCE
08:30-10:00 03:00-03:30
Open Standard Software and Templates: Coffee Break
DOCUMENTATION SOFTWARE
10:00-10:30 03:30-05:00
Coffee Break Open Standard Software and Template
ENTERPRISE ARCHITECTURE AND STRATEGIC
PLANNING PROJECT PLAN
10:30-12:00 05:00
Open Standard Software and Templates: Home
PROCESS AND DATA MODELER SOFTWARE
12:00
Lunch Break

3. Training Notes
Introduction:
Enterprise architectures provides the “living documents” called reference models to make the
organization to effectively and efficiently managed recordings, expectations, processes,
configurations, metrics, work arounds, changes, relationships, collaborations, interchanges,
requirement tracing, control, and marketing of the business operation. It provides a “single-
reference-of-truth” to properly lead the business process improvement and the optimal value-
added integration of technology in the business operation of the organization.
The enterprise architecture tools provide the principles, methods, vocabulary, conventions,
presentation objects, procedures, software, repositories, and artifacts in order to draw the
reference models of the enterprise that speaks of its business, information, technology, and
people.
The drawn models are kept in digital repository and made accessible anytime when business
strategic planning, enterprise performance evaluation, and program and ICT project
development are initiated by the organization. It is reconfigured when new understanding about
the business, information, technology, and people are brought in by the improved enterprise
strategy, new program and projects, and enterprise metrics.
The “Doing the Enterprise Architecture” process requires the collaborative engagement between
the “minds and practitioners” running the business processes and those delivering the
technology services. It is to properly compose the reference models of the organization that will
make the business functional units and ICT service providers to realize the performance
objectives through information and communication technology.
ENTERPRISE ARCHITECTURE PRACTICE IN THE AGENCY: CHECK LIST
Does your agency maintains a blueprint or matrix of all running systems, showing how YES NO NOT
they interoperate, and which technology they are using? SURE
Can your agency readily presents the professional and business user matrix with with YES NO NOT
their requirements, and the technology services that address those requirements? SURE
Does your agency have a documented map of enterprise-wide data, how data is being YES NO NOT
grouped, how data are related, how data is being accessed, how data is shared, and SURE
how data is secured?
Are there silos of data and application in the different units of the agency? YES NO NOT
SURE
When your agency start a project do you have an enterprise architecture blueprint, YES NO NOT
which you have to align the type of application to be designed and developed? SURE
Is there a formal stage in the project life cycle where system architecture is being YES NO NOT
checked against the enterprise architecture? SURE
If you have any question or problem regarding architecture do you know who to seek YES NO NOT
for guidance, decision and documentation? SURE
Is there an official guidance and listing of all business standards, methods and and YES NO NOT
tools, technical references that both IT and Business have to use, or you can use SURE
whatever technology you want?

4. Part 01: DEFINITIONS AND STANDARDS
Enterprise Architecture Description (from various references)
FEA definition:
"The FEA (Federal Enterprise Architecture) consists of a set of interrelated "reference
models" designed to facilitate cross-agency analysis and the identification of duplicative
investments, gaps and opportunities for collaboration within and across agencies.
Collectively, the reference models comprise a framework for describing important elements
of the FEA in a common and consistent way. Through the use of this common framework and
vocabulary, IT portfolios can be better managed and leveraged across the federal
government."
CIO Definitions from SearchCIO.com, posted October, 2006:
"An enterprise architecture (EA) is a conceptual blueprint that defines the structure and
operation of an organization. The intent of an enterprise architecture is to determine how
an organization can most effectively achieve its current and future objectives. Purported
advantages of having an enterprise architecture include improved decision making, improved
adaptability to changing demands or market conditions, elimination of inefficient and
redundant processes, optimization of the use of organizational assets, and minimization of
employee turnover."
NASCIO Enterprise Architecture Development Toolkit v.3.0
“Enterprise architecture defines an enterprise-wide, integrated set of components that
incorporates strategic business thinking, information assets, and the technical infrastructure of
an enterprise to promote information sharing across agency and organizational boundaries. The
Enterprise Architecture is supported by Architecture Governance and the allied architectures of,
Business, Information, Technology and Solution Architectures.”
"enterprise" as any collection of organizations that has a common set of goals. For example, an
enterprise could be a government agency, a whole corporation, a division of a corporation, a
single department, or a chain of geographically distant organizations linked together by common
ownership.
TOGAF version 9.0
The term "enterprise" in the context of "enterprise architecture" can be used to denote both an
entire enterprise - encompassing all of its information and technology services, processes, and
infrastructure - and a specific domain within the enterprise. In both cases, the architecture
crosses multiple systems, and multiple functional groups within the enterprise.
CLINGER-COHEN
Enterprise Architecture (EA) links the business mission, strategy, and processes of an organization
to its IT strategy. It is documented using multiple architectural models or views that show how
the current and future needs of an organization will be met. By focusing on strategic
differentiators and working across the enterprise, there is a unique opportunity to create
leverage and synergies and avoid duplication and inconsistencies across the enterprise. The key
components of the EA are:
• Accurate representation of the business environment, strategy and critical success factors
• Comprehensive documentation of business units and key processes
• Views of the systems and data that support these processes
• A set of technology standards that define what technologies and products are approved to
be used within an organization, complemented by prescriptive enterprise-wide guidelines
on how to best apply these technology standards in creating business applications.

5. Terminology Definition Source
Architecture The specification that identifies components and their Software
associated functionalities. It describes connectivity of Engineering
components and the mapping of of functionality into Institute
components. Architectures can be of different types and
cover hardware, software, systems, and can be domain
specific to describes business, data, application, technology,
network, security, etc..
Architecture View It is a representation of the set of system elements and the IEEE
relation associated with them. It represents a whole system
from the perspective of related sets of concerns. Views are
representations of the many system structures that are
present simultaneously in software system.
Architecture Framework The combination of structured processes, templates, and NASCIO
governance that facilitate the elicitation and documentation
of the architecture in a systematic manner.
Architecture Domain High level gouping of disciplines, functional or topical OMB, NASCIO
operations that form the main building block of the
architectural framework. It talks of sphere of activity,
interest, or functions.
Architecture Component Level of details contain in specific architectural domain NASCIO
Enterprise An organization supporting a defined business scope and MITRE EABOOK
mission. An enterprise is comprised of interdependent
resources (people, organizations, and technology) who must
coordinate their functions and share information in support
of a common mission
Enterprise Any collection of organizations that has a common set of TOGAF
goals.
Enterprise Architecture Artifacts Artifacts constitute any object, or work product that is NASCIO
developed as a component of the enterprise architecture.
Artifacts includes trends, principles, mission, goals,
objectives, strategies, capabilities, processes, processes
steps, entities, attributes, relationship, subject areas,
application components, application, database, network
infrastructure, and configuration details.
Business Architecture The high level representation of the business strategies, NASCIO
intentions, functions, processess, information, and assets
critical to operating the business of government successfully.
Business Reference Model It is a function driven framework that describes the business OMB
operation independent of the organization performing the
job. It provides an organized and hierarchical construct for
describing the day-to-day business operation.
Data Reference Model It describes the data and information that supports the CIOGOV
government agency operation from an agency and
government-wide perspective.
Performance Reference Model It is the standardized framework to measure the OCIO-DOI
performance of major IT investments and their contribution
to program performance.
Technology Reference Model It is a component-driven, technical framework used to OCIO-DOI
categorize the standards, specifications, and technologies
that support and enable the delivery of service components
and capabilities

6. ENTERPRISE ARCHITECTURE CONTEXT IN GOVERNMENT MODEL
Aligning the information and communications techonology services to the directives, business, information
and technology architecture of the government agency.

7. Part 02: COMPETENCY AND MATURITY
Importance of Enterprise Architecture
Schekkerman, J. (2005). Trends in Enterprise Architecture, Institute for Enterprise Architecture
Development, white paper.
VALUE INDICATORS DESCRIPTIONS
Alignment Enterprise architecture provides the framework to enable better
alignment of business and information technology objectives. The
architecture used can also serve as a communication tool.
Integration Enterprise architecture establishes the infrastructure that enables
business rules to be consistently applied across the organization,
documents data flows, uses and interfaces.
Value Creation Enterprise architecture provides better measurement of information
technology economic value in an environment where there is a higher
potential for reusable hardware and software assets
Change Management Enterprise architecture establishes consistent infrastructure and
formalizing the management of the infrastructure and information
assets better enables an organization-wide change management
process to be established to handle information technology changes
Compliance Enterprise architecture provides the artifacts necessary to ensure
legal and regulatory compliance for the technical infrastructure and
environment.
Maturity Levels of Enterprise Architecture Program
(NASCIO)
Maturity Level Status Name Description
LEVEL O No Program There is not a documented architectural framework in place at this level
of maturity. While solutions are developed and implemented, this is
done with no recognized standards or base practices. The organization is
completely reliant on the knowledge of independent contributors.
LEVEL 1 Informal Program The base architecture framework and standards have been defined and
are typically performed informally. There is general consensus that
these steps should be performed, however they may not be tracked and
followed. Organizations with an Enterprise Architecture framework at
this level are still dependant on the knowledge of individual
contributors.
LEVEL 2 Repeatable Program The base architecture and standards have been identified and are being
tracked and verified. At this point in the program processes are
repeatable and reusable templates are starting to be developed. The
need for product and compliance components to conform to the
standards and requirements has been agreed upon, and metrics are
used to track process area performance.
LEVEL 3 Well Defined The enterprise architecture framework is well defined; using approved
Program standard and/or customized versions of the templates. Processes are
documented across the organization.
Performance metrics are being tracked and monitored in relationship to
other general practices and process areas.
LEVEL 4 Managed Program At this point performance metrics are collected, analyzed and acted
upon. The metrics are used to predict performance and provide better
understanding of the processes and capabilities.
LEVEL 5 Continously The processes are mature; targets have been set for effectiveness and
Improved Vital efficiency based on business and technical goals. There are ongoing
Program refinements and improvements based on the understanding of the
impact changes have to these processes.

8. The Enteprise Architect Responsibilities
(TOGAF)
TASKS DESCRIPTIONS
Understand and Probe for information, listen to information, influence people, facilitate consensus
interpret building, synthesize and translate ideas into actionable requirements, articulate those
requirements ideas to others. Identify use or purpose, constraints, risks, etc.
The architect participates in the discovery and documentation of the customer's business
scenarios that are driving the solution. The architect is responsible for requirements
understanding and embodies that requirements understanding in the architecture
specification.
Create a useful Take the requirements and develop well-formulated models of the components of the
model solution, augmenting the models as necessary to fit all of the circumstances. Show
multiple views through models to communicate the ideas effectively.
The architect is responsible for the overall architecture integrity and maintaining the
vision of the offering from an architectural perspective. The architect also ensures
leverage opportunities are identified, using building blocks, and is a liaison between the
functional groups (especially development and marketing) to ensure that the leverage
opportunities are realized.
The architect provides and maintains these models as a framework for understanding the
domain(s) of development work, guiding what should be done within the organization, or
outside the organization. The architect must represent the organization view of the
architecture by understanding all the necessary business components
Validate, refine, and Verify assumptions, bring in subject matter experts, etc. in order to improve the model
expand the model and to further define it, adding as necessary new ideas to make the result more flexible
and more tightly linked to current and expected requirements.
The architect additionally should assess the value of solution-enhancing developments
emanating from field work and incorporate these into the architecture models as
appropriate.
Manage the Continuously monitor the models and update them as necessary to show changes,
architecture additions, and alterations. Represent architecture and issues during development and
decision points of the program.
The architect is an "agent of change", representing that need for the implementation of
the architecture. Through this development cycle, the architect continuously fosters the
sharing of customer, architecture, and technical information between organizations
CLINGER-COHEN ENTERPRISE ARCHITECT SUMMARY OF COMPETENCIES
• A basic grounding in the agency’s environment, strategy and priorities
• Extensive knowledge of IT capabilities, covering current and emerging technologies
• Good knowledge of how similar agencies use or plan to use technology
• Ability to rationalize technology opportunities and business drivers optimizing return on
investment
• Familiar with agency’s architectural principles and policies, able to interpret and apply
• “Hands on” experience in architecture, able to perform a number of architectural tasks
• Must have a mixture of BPR, business processes, and meeting facility
• Strong in capability modeling
• Can define and understand component capabilities and apply solutions
• Ability to look at technology trends and effectively apply to business/project needs
• Ability to look at and define target architecture for speciality projects
• Ability to manage a repository - repository modeling and analysis
• Competency in several tool sets
• Ability to manage a project portal to identify concepts, work in progress, etc.
• Able to identify redundancies among existing and proposed IT efforts
• Ability to bring together an overall Enterprise Architecture from several individual EA efforts
• Ability to develop the crux functional integration services that can be implemented in patterns

9. Part 03: ENTEPRISE ARCHITECTURE FRAMEWORK: TOGAF
Guidance Componets
01. Architecture Development Method Cycle Introduction to the ADM
Preliminary Phase
Phase A: Architecture Vision
Phase B: Business Architecture
Phase C: Information Systems Architectures
Phase C: Information Systems Architectures - Data
Architecture
Phase C: Information Systems Architectures -
Applications Architecture
Phase D: Technology Architecture
Phase E: Opportunities and Solutions
Phase F: Migration Planning
Phase G: Implementation Governance
Phase H: Architecture Change Management
ADM Architecture Requirements Management
02. Architecture Development Method Guidelines Applying Iteration to the ADM
and Techniques Applying the ADM at different Enterprise Levels
Security Architecture and the ADM
Using TOGAF to define and Govern SOAs
Architecture Principles
Architecture Stakeholder Management
Architecture Patterns
Business Scenarios
Gap Analysis
Migration Planning Techniques
Interoperability Requirements
Business Transformation Readiness Assessment
Risk Management
Capability-Based Planning
03. Architecture Content Framework Introduction to the Architecture Content
Framework
Content Metamodel
Architectural Artifacts
Architectural Deliverables
Building Blocks
04. Enterprise Continoum Tools Introduction
Enterprise Continuum
Architecture Partitioning
Architecture Repository
Tools for Architecture Development
05. Reference Model Foundation Architecture: TRM
III-RM
06. Architecture Capability Introduction
Establishing an Architecture Capability
Architecture Board
Architecture Compliance
Architecture Contracts
Architecture Governance
Architecture Maturity Models
Architecture Skills Framework

10. Part 04: ENTERPRISE ARCHITECTURE FRAMEWORK: NASCIO DEVELOPMENT TOOLKIT
TOOLKIT COMPONENTS DESCRIPTION
Architecture Governance The processes necessary to direct or guide initiatives, to ensure
that performance aligns with the enterprise, to enable the
enterprise business by exploiting opportunities, and to ensure
resources are used responsibly and architecture-related risks are
managed appropriately.
Business Architecture An architecture within EA that provides the high-level
representation of the business strategies, intentions, functions,
processes, information and assets critical
to providing services to citizens, businesses, governments and the
like.
Business architecture should include an environmental context,
market or need assessment, strategic business intent, traceability
to capabilities and the management initiatives that will deliver or
further leverage those enabling capabilities. Business
architecture is defined by some as constituting the top two rows
of the Zachman Framework.
Information Architecture The compilation of the business requirements of the enterprise,
the information process entities and integration that drive the
business and rules for selecting, building and maintaining that
information. This includes data and process architecture.
Solution Architecture An architecture within EA that guides the solution architect in the
design of a particulate solution set. For each solution set,
Solution Architecture assists in:
• The identification of business requirements,
• ƒThe determination of the design specifications necessary
to deliver the business requirements,
• The development of the solution set design. Integrating
designs based on details with the Business, Information
and Technology blueprints.
Technical Architecture A disciplined approach to describing the current and future
structure and inter-relationships of the enterprise’s technologies
in order to maximize value in those technologies. It examines the
technologies that are required to run the enterprise and develops
a unified vision of the enterprise’s infrastructure and technology
platforms.
Enterprise Architecture Facilitation A guide on building the enterprise architecture team, and the
Guide tasks to be performed in implementing an enteprise architecture
program for the government enterprise.

11. Part 05: ZACHMAN ARCHITECTURE INTERROGATIVES
The focus of an enterprise architects is to elaborate, analyze, and build the relationships among
technology, information and business viewpoints in the acquisition and development of solutions … It
makes sure that the organization can flexibly integrate with changes demanded by market positioning,
innovation, etc. John Zachman provides the detailed components to describe the enteprise
architecture.
PERSPECTIVES WHAT HOW WHERE WHO WHEN WHY
OBJECTIVES/ List of things List of processes List of location List of List of business List of business
SCOPES important to the enterprise the enterprise organizational events or cycles goals and
the enterprise performs operates units stategies
BUSINESS MODEL Entity Business Process Logistic Network Organizational Business Master Business Plan
Relationship Model (physical (Nodes and Links) Charts with Roles Schedule
Diagram data flow and Skills Sets
diagram)
INFORMATION Data Model Application Distributed Human Interfaces Dependency Business rule
SYSTEM MODEL Data Dictionary Model and Data System Model (role, data Diagram, Entity model
Flow Diagram Architecture , access) Life History
TECHNOLOGY Data Systems Design Systems User Interface, Control Structure Business rule
MODEL Architecture Structure Chart, Architecture Usability, -Control Flow design
(Elements, Pseudo Code (Hardware, Security Design Diagram
relational Software,
tables) Network)
DETAILED Data Design, Detailed Program Network User Screen and Timing Defintion Program Logic
REPRESENTATION Physical Storage Design Architecture Security Rules
Design Architecture Specifications
FUNCTIONING Converted Data Executable Communication Trained People Business Events Enforced Rules
SYSTEM Program Facilities

12. Part 06: ARCHITECTURE COMPONENT ELABORATION
BUSINESS ARCHITECTURE Understanding how the business is Identify Business Model  Business
running, what are its needs, what is Functions and WHO Performs the
missing and what needs to be Function.
changed or improved.
Definition of Business Goals and
It defines the business strategy, Goals, the supporting processes,
governance, organization, and key workflow, policies and
business processes of the procedures.
organization.
Assessment of the Current State
and Description of the Future
State.
How are the goals and objectives
implemented through the ICT
Solutions and the supporting
technical infrastructure.
DATA ARCHITECTURE It defines how data is stored, Data Element
managed, and used in a system. It Data Flow Diagram
establishes common guidelines for Entity Relationship
data operations that make it possible Relational Structure
to predict, model, and control the Data Physical Storage
flow of data in the system. Data Interoperatibility
Data Standard
It describes the structure of an Supported Informational Themes
organization's logical and physical
data assets and the associated data
management resources
APPLICATION ARCHITECTURE Application architecture consists of Current inventory of applications
logical systems that manage the data and components.
objects in the data architecture and
support the business functions in the Evolving applications and
Business Architecture. components needed to fulfill for
the business units.
It provides a blueprint for the Migration plans for moving the
individual application systems to be EXISTING portfolio toward the
deployed, the interactions between PLANNED portfolio
the application systems, and their
relationships to the core business
processes of the organization
TECHNOLOGY ARCHITECTURE It describes current and future Hardware Platform
technical infrastructure and specific Operating System
hardware and software technologies Application System
that support the Agency information Database System
systems. It provides guidance and Network & Communication System
principles for implementing Security System
technologies within the application Enterprise Systems Management
architecture. Development Methods
Technical Standards
It describes the hardware, software Interoperatability References
and network infrastructure needed
to support the deployment of core,
mission-critical applications.

13. NASCIO ENTERPRISE ARCHITECTURE DEVELOPMENT TOOLKIT – EA DOMAINS
BUSINESS REFERENCE It provides an organized, hierarchical construct for describing the day-to-day
MODEL business operations of the Federal government. While many models exist for
describing organizations - org charts, location maps, etc. - this model
presents the business using a functionally driven approach.
The Lines of Business and Sub-functions that comprise the BRM represent a
departure from previous models of the Federal government that use
antiquated, stovepiped, agency-oriented frameworks. The BRM is the first
layer of the Federal Enterprise Architecture and it is the main viewpoint for
the analysis of data, service components and technology.
DATA REFERENCE MODEL It describes, at an aggregate level, the data and information supporting
government program and business line operations. This model enables
agencies to describe the types of interaction and exchanges occurring
between the Federal government and citizens.
The DRM categorizes government information into greater levels of detail. It
also establishes a classification for Federal data and identifies duplicative
data resources. A common data model will streamline information exchange
processes within the Federal government and between government and
external stakeholders.
"Data dictionary" will enable the development of common data identification
"tags" that will facilitate information exchange both within the Federal
government between the government and its external stakeholders
The DRM provides a standard means by which data may be described,
categorized, and shared. These are reflected within each of the DRM’s three
standardization areas:
• Data Description: Provides a means to uniformly describe data,
thereby supporting its discovery and sharing
• Data Context: Facilitates discovery of data through an approach to
the categorization of data according to taxonomies; additionally,
enables the definition of authoritative data assets within a
community of interest (COI)
• Data Sharing: Supports the access and exchange of data where
access consists of ad-hoc requests (such as a query of a data asset),
and exchange consists of fixed, re-occurring transactions between
parties
SERVICE REFERENCE It is a business and performance-driven, functional framework that classifies
MODEL Service Components with respect to how they support business and/or
performance objectives.
The SRM is intended for use to support the discovery of government-wide
business and application Service Components in IT investments and assets.
The SRM is structured across horizontal and vertical service domains that,
independent of the business functions, can provide a leverage-able
foundation to support the reuse of applications, application capabilities,
components, and business services.
TECHNICAL REFERENCE The Technical Reference Model (TRM) provides a foundation to categorize
MODEL the standards, specifications, and technologies to support the construction,
delivery, and exchange of business and application components (Service
Components) that may be used and leveraged in a Component-Based or
Service-Oriented Architecture.
The TRM unifies existing Agency TRMs and E-Gov guidance by providing a
foundation to advance the re-use of technology and component services
from a government-wide perspective.

14. Part 07: BUSINESS ANALYSIS FRAMEWORK
Business Analysis Body of Knowledge
International Institute of Business Analysis
Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order
to understand the structure, policies, and operations of an organization, and recommend solutions that
enable the organization to achieve its goals.
COMPONENTS DESCRIPTION
Business Analysis Planning and Monitoring It describes how to determine which activities are
necessary to perform in order to complete a business
analysis effort. It covers identifcation of stakeholders,
selection of business analysis techniques, the process
we will use to manage our requirements, and how we
assess the progress of the work in order to make
necessary changes in work effort.
Enterprise Analysis It describes how we take a business need, refne and
clarify the defnition of that need, and defne a solution
scope that can feasibly be implemented
by the business. It covers problem defnition and analysis
business case development, feasibility studies, and the
defnition of a solution scope.
Elicitation It describes how we work with stakeholders to fnd out
what their needs are and ensure that we have correctly
and completely understood their needs.
Requirements Analysis It describes how we progressively elaborate the solution
defnition in order to enable the project team to design
and build a solution that will meet the needs of the
business and stakeholders.
Solution Assessment and Validation Solution Assessment and Validation describes how to
assess proposed solutions to determine which solution
best fts the business need, identify gaps and
shortcomings in solutions, and determine necessary
workarounds or changes to the solution
Requirements Management and It describes how we manage conficts, issues and
Communication changes and ensure that stakeholders and the project
team remain in agreement on the solution scope

15. Part 08: PROCESS MAPPING AND PERFORMANCE MODEL
Business and Process Entity Requirements Definition
BUSINESS DEFINITION MATRIX
MANDATE STAKEHOLDERS FUNCTIONS BUSINESS PRODUCTS CONTROLS
ENTITY
Core Functions
Special Functions
BUSINESS ENTITY BUSINESS PERFORMANCE PROCESS NAME RELATIONSHIPS
LOCATIONS OBJECTIVES
INFORMATION REQUIREMENT MAPPING
BUSINESS PROCESS INFORMATION INFORMATION PROCEDURE RULES & INFORMATION INFORMATION
ENTITY NAME SOURCE CAPTURE POLICIES REPORTING CUSTOMER
FORM FORM
PROCESS NAME: BUSINESS ENTITY:
SOURCE INPUT ENTRY TASKS EXIT OUTPUT CUSTOMER
REQUIREMENTS REQUIREMENTS
VALIDATION AND VERIFICATION REQUIREMENTS

16. PROCESS MAPPING: SWIM LANE
FUNCTION UNIT: PROCESS NAME:
ACTOR TASKS LANE TASK LANE TASKS LANE
Actor 1 Step 1 - Start Step 4 Step 6 -End
Actor 2 Step 2 Step 5
Actor 3 Step 3
Actors: The people, groups, teams, etc, who are performing the steps identified within the
process
Process: he actual process and flow that is being tracked through its identified progression
steps.
Phases: These might reflect the phases of the project, different areas of the project, or any
secondary set of key elements that the process flow needs to traverse to
successfully complete this process.
Symbols: These are the physical symbols used to graphically represent what is happening in
any given step of the process.

17. Part 09: INFORMATION MATURITY MODEL
MATURITY STAGE DESCRIPTIONS
LEVEL 1 The organisation has no common information practices. Any pockets of
Aware information management maturity that the organization has are based on
the experience and initiatives of individuals.
LEVEL 2 The organisation has little in the way of enterprise information management
Reactive practices. However, certain departments are aware of the importance of
professionally managing information assets and have developed common
practices used within their projects. At the enterprise level, a level 2
organization reacts to data quality issues as they arise.
LEVEL 3 The organisation has a significant degree of information management
Proactive maturity. Enterprise awareness, policies, procedures, and standards exist
and are generally utilized across all enterprise projects. At level 3, the
information management practices are sponsored by and managed by IT.
LEVEL 4 The organisation manages information as an enterprise asset. The business is
Managed heavily engaged in information management procedures and takes
responsibility for the quality of information that they manage. A level 4
organisation has many mature and best-in-class practices and utilizes audits
to ensure compliance across all projects.
LEVEL 5 The organisation considers information to be as much an enterprise asset as
Optimized financial and material assets. A level 5 organisation has best-in-class
information management practices that are utilized across all enterprise
projects. The distinguishing characteristic of a level 5 organisation is the
focus on continuous improvement. At level 5, all data management
practices and assets are regularly measured and the results are analysed as
the basis for process improvement.

18. Part 10: DATA AND APPLICATION MODEL
Data Dictionary
Data dictionary is an organized collection of data elements names and definitions arranged in a table. It
provides the reference for accurate, reliable, controllable, and verifiable data to be recorded in
databases. It makes both the users and owners to have correct and proper use and interpretation of data.
It makes them share common understanding of the meaning and descriptive characteristics of the data
that will serve the information to be generated.
ELEMENTS DESCRIPTIONS
Data Element Domain Name A data content topic, for example, a named data collection
protocol – EMAP. Note there may be multiple domains or sub-
domains within a particular data dictionary.
Data Element Number (for reference A number associated with the data element name for use in
in data model) technical documents.
Data Element Name Commonly agreed, unique data element name. Note: there are
likely to be multiple data element names for a particular
domain.
Data Element Field Name The name used for this data element in computer programs
and database schemas. It is often an abbreviation of the Date
Element Name (eg. Cellular Phone Number might be assigned a
field name of Cell_Ph_No).
Data Element Definition Description of the meaning of the data element
Data Element Unit of Measure (uom) Scientific or other unit of measure that applies to the data
element.
Data Element Precision The level to which the data will be reported, eg 1 mile plus or
minus .001 mile
Data Element Data Type The type of data (e.g. Characters, Numeric, Alpha-numeric,
date, list, floating point).
Data Element Size and Decimalization The maximum field length that will be accepted by the
database together with any decimal points (e.g. 30(2)) refers
to a field length of 30 with 2 decimal points).
Field Constraints: Data Element is a Required fields (Y) must be populated. Conditional fields (C)
required field (Y/N); Conditional Field must be populated when another related field is populated
(C); or a “null” field (e.g. if a city name is required a zip code may also be
required). “Not null” also describes fields that must contain
data. “Null” means the data type is undefined (note: a null
value is not the same as a blank or zero value).
Default Value A value that is predetermined. It may be fixed or a variable,
like current date and time of the day.
Edit Mask (e.g. of actual layout) An example of the actual data layout required, (e.g.
yyyy/mm/dd).
Data Business Rules There are often the rules that define how data would be
managed within an information system (e.g. Fish data could be
coded (1=adult, 2=parr, 3=juveniles) and these codes would
then be included in the data dictionary for use by developers
and users. Other business rules, for example how rights to
create, read, update or delete records are assigned if they are
needed.

19. Application Use Case Identification
A use case is a methodology used in system analysis to identify, clarify, and organize system requirements.
The use case is made up of a set of possible sequences of interactions between systems and users in a
particular environment and related to a particular goal. It consists of a group of elements (for example,
classes and interfaces) that can be used together in a way that will have an effect larger than the sum of
the separate elements combined. The use case should contain all system activities that have significance
to the users. A use case can be thought of as a collection of possible scenarios related to a particular goal,
indeed, the use case and goal are sometimes considered to be synonymous.
A use case (or set of use cases) has these characteristics:
• Organizes functional requirements
• Models the goals of system/actor (user) interactions
• Records paths (called scenarios) from trigger events to goals
• Describes one main flow of events (also called a basic course of action), and possibly other ones,
called exceptional flows of events (also called alternate courses of action)
• Is multi-level, so that one use case can use the functionality of another one.
-Defintion by TechTarget
Use Case Identification Elements
Karl Weiger - www.processimpact.com.
COMPONENTS DESCRIPTIONS
Use Case ID Give each use case a unique integer sequence number identifier. Alternatively,
use a hierarchical form: X.Y. Related use cases can be grouped in the
hierarchy.
Use Case Name State a concise, results-oriented name for the use case. These reflect the
tasks the user needs to be able to accomplish using the system. Include an
action verb and a noun. Some examples:
• View part number information.
• Manually mark hypertext source and establish link to target.
• Place an order for a CD with the updated software version.
Use Case History Created By:
Supply the name of the person who initially documented this use case.
Date Created:
Enter the date on which the use case was initially documented.
Last Updated By:
Supply the name of the person who performed the most recent update to the
use case description.
Date Last Updated:
Enter the date on which the use case was most recently updated.
Use Case Defintion
Actors An actor is a person or other entity external to the software system being
specified who interacts with the system and performs use cases to accomplish
tasks. Different actors often correspond to different user classes, or roles,
identified from the customer community that will use the product. Name the
actor that will be initiating this use case and any other actors who will
participate in completing the use case.
Trigger Identify the event that initiates the use case. This could be an external
business event or system event that causes the use case to begin, or it could
be the first step in the normal flow.
Description Provide a brief description of the reason for and outcome of this use case, or a
high-level description of the sequence of actions and the outcome of
executing the use case.

20. Preconditions List any activities that must take place, or any conditions that must be true,
before the use case can be started. Number each precondition. Examples:
1. User’s identity has been authenticated.
2. User’s computer has sufficient free memory available to launch task.
Postconditions Describe the state of the system at the conclusion of the use case execution.
Number each postcondition. Examples:
1. Document contains only valid SGML tags.
2. Price of item in database has been updated with new value
Normal Flow Provide a detailed description of the user actions and system responses that
will take place during execution of the use case under normal, expected
conditions. This dialog sequence will ultimately lead to accomplishing the goal
stated in the use case name and description. This description may be written
as an answer to the hypothetical question, “How do I <accomplish the task
stated in the use case name>?” This is best done as a numbered list of actions
performed by the actor, alternating with responses provided by the system.
The normal flow is numbered “X.0”, where “X” is the Use Case ID.
Alternative Flows Document other, legitimate usage scenarios that can take place within this use
case separately in this section. State the alternative flow, and describe any
differences in the sequence of steps that take place. Number each alternative
flow in the form “X.Y”, where “X” is the Use Case ID and Y is a sequence
number for the alternative flow. For example, “5.3” would indicate the third
alternative flow for use case number 5.
Exceptions
Describe any anticipated error conditions that could occur during execution of
the use case, and define how the system is to respond to those conditions.
Also, describe how the system is to respond if the use case execution fails for
some unanticipated reason. If the use case results in a durable state change in
a database or the outside world, state whether the change is rolled back,
completed correctly, partially completed with a known state, or left in an
undetermined state as a result of the exception. Number each alternative flow
in the form “X.Y.E.Z”, where “X” is the Use Case ID, Y indicates the normal (0)
or alternative (>0) flow during which this exception could take place, “E”
indicates an exception, and “Z” is a sequence number for the exceptions. For
example “5.0.E.2” would indicate the second exception for the normal flow
for use case number 5.
Includes List any other use cases that are included (“called”) by this use case. Common
functionality that appears in multiple use cases can be split out into a
separate use case that is included by the ones that need that common
functionality.
Priority Indicate the relative priority of implementing the functionality required to
allow this use case to be executed. The priority scheme used must be the
same as that used in the software requirements specification.
Frequency of Use Estimate the number of times this use case will be performed by the actors
per some appropriate unit of time.
Business Rules List any business rules that influence this use case.
Special Requirements Identify any additional requirements, such as nonfunctional requirements, for
the use case that may need to be addressed during design or implementation.
These may include performance requirements or other quality attributes
Assumptions List any assumptions that were made in the analysis that led to accepting this
use case into the product description and writing the use case description.
Notes and Issues List any additional comments about this use case or any remaining open issues
or TBDs (To Be Determineds) that must be resolved. Identify who will resolve
each issue, the due date, and what the resolution ultimately is.

21. Part 11: TECHNOLOGY REFERENCE MODEL
COMPONENTS CONFIGURATION ITEMS SPECIFICATIONS
Hardware Platforms
Operating System
Application System
Database System
Network & Communication
Security System
Enterprise System Management
Development Methodologies
Standards
Interoperatability

22. Part 12: INFORMATION SECURITY MODEL
The Security Domain defines the roles, technologies, standards, and policies necessary to protect the
information assets of the state and citizens from any form of unauthorized access. The Security Domain
defines the security and access management principles that are applied to ensure the appropriate level of
access to NM’s information assets. This domain comprises standards for identification, authentication,
authorization, administration, audit, and naming services.
COMPONENTS DESCRIPTIONS
PHYSICAL SECURITY Securing access to hardware, inventory, and disposition of physical
equipment and records.
USER SECURITY Ensuring that users accessing data and systems are in fact who they say
they are and that they have access only to authorized resources.
Functions include the identification, authentication, and authorization of
an individual, as well as audit requirements.
APPLICATION SECURITY ensuring that an application that accesses another application or data is
secure; includes the analysis of distributed, proxy, and middleware
services.
SYSTEMS SECURITY Overall systems security analysis, including the user, data transmission,
and the host server, as well as remote links and access from other
systems, and encryption.
DATA SECURITY Both physical and logical data protection, including loss of data through
mechanical failure, electrical failure, or viruses. Includes backup
procedures, off-site storage, access audit.
NETWORK SECURITY It includes the physical and electical links between the desktop and the
host, LAN/WAN, use of internet, dial-up, wireless.
SECURITY ADMINISTRATION Periodic reviews of policies, the design and review of systems (proposed
or existing). Includes periodic testing of security plans. Generally, this is
broken up between Administrators (who focus on individual systems) and
an Information Security Officer (larger enterprise focus.)
SOCIAL ENGINEERING AND Many techniques used to compromise systems are based on deceptive
HUMAN FACTORS practices aimed at individual users or employees. Security awareness
must be heightened at all levels of the organization and procedures
developed to positively identify requestors of information and their
legitimate purposes.
MALWARE Viruses, Trojans, spyware, and other malicious code.
INCIDENT RESPONSE TEAM coordinated incident response for miscellaneous incident that may occur
across the state.

23. Part 13: MODEL OF STRATEGIC PLANNING
Strategic Alignment Model
(Venkatraman, Henderson and Oldach)
The difficulty to realize value from IT investments is firstly due to the lack of alignment between the business and IT
strategy of the organizations that are making investments, and secondly due to the lack of a dynamic administrative process
to ensure continuous alignment between the business and IT domains.
Strategy Execution This perspective views the business strategy as the driver of both organization design choices and the logic of IS
infrastructure (the classic, hierarchical view of strategic management). T Management is strategy formulator
op ,
IS Management is strategy implementer [Arrow 1]
.
Technology Potential This perspective also views the business strategy as the driver however involves the articulation of an IT
,
strategy to support the chosen business strategy and the corresponding specification of the required IS
infrastructure and processes.
The top management should provide the technology vision to articulate the logic and choices pertaining to IT
strategy that would best support the chosen business strategy while the role of the IS manager should be that
,
of the technology architect - who efficiently and effectively designs and implements the required IS
infrastructure that is consistent with the external component of IT strategy (scope, competences and
governance). [Arrow 2]
Competitive Potential This alignment perspective is concerned with the exploitation of emerging IT capabilities to impact new
products and services (i.e., business scope), influence the key attributes of strategy (distinctive competences),
as well as develop new forms of relationships (i.e. business governance). Unlike the two previous perspectives
that considered business strategy as given (or a constraint for organizational transformation), this perspective
allows the modification of business strategy via emerging IT capabilities.
The specific role of the top management to make this perspective succeed is that of the business visionary who
,
articulates how the emerging IT competences and functionality as well as changing governance patterns in the
IT marketplace would impact the business strategy The role of the IS manager in contrast, is one of the
. ,
catalyst, who identifies and interprets the trends in the IT environment to assist the business managers to
understand the potential opportunities and threats from an IT perspective. [Arrow 3]
Service Level This alignment perspective focuses on how to build world class IT/IS organization within an organization. In this
perspective, the role of business strategy is indirect. This perspective is often viewed as necessary (but not
sufficient) to ensure the effective use of IT resources and be responsive to the growing and fast-changing
demands of the end-user population.
The specific role of the top management to make this perspective succeed is that of the prioritizer who
,
articulates how best to allocate the scarce resources both within the organization as well as in the IT
marketplace (in terms of joint ventures, licensing, minority equity investments, etc.). The role of the IS
manager in contrast, is one of business leadership, with the specific tasks of making the internai business
,
succeed within the operating guidelines from the top management. [Arrow 4]

24. The Test of Effective Strategy
THE TESTS THE INDICATORS
Goodness of Fit Test
The stategy has to be well matched to industry and
competitive conditions, market opportunities and
threats, and other aspects of the enterprise's external
environment.
It has to be tailored to the company's resource strengths
and weaknesses, competencies, and competitive
capabilities.
Competetive Advantage Test
The effective strategy leads to sustainable competitive
advantage.
The bigger the competitive edge that a strategy helps
build, the more powerful and effective it is.
Performance Test The effective strategy boosts company performance.
Two kinds of performance improvements are the most
telling of a strategy's caliber: gains in profitability and
gains in the company's competitive strength and long-
term market position.
The Type of Organizational Goals
Strategic Goals These are set of directives at the top of an organization and directly support the
mission statement. Strategic goals are related to the entire organization instead of
any one department.
Tactical Goals These are goals and objectives that are directly related to the strategic goals of the
organization. They indicate the levels of achievement necessary in the departments
and divisions of the organization. Tactical goals and objectives must support the
strategic goals of the organization.
Operation Goals These are goals and objectives that are determined at the lowest level of the
organization and apply to specific employees or subdivisions in the organization.
They focus on the individual responsibilities of employees.
Super-ordinate Goals These goals are important to more than one party. They are often used to
resolveconflict between groups.

25. Part 14: STRATEGIC PLAN INTERROGATIVES
• Internal and External Environment Scan.
Internal (evaluation of capabilities) and external (forecast of the environment) research and
analysis in order to identify strategic issues facing the institution.
Driving Forces
Restraining Forces
Risks for Doing and Non-Doing the Strategy
The cost of not mitigating the risks
• Strategic Visioning:
Definition of the desired future state of the organization within the targeted time frame.
(Mandate+Mission+Values -Internal and External Environment Analysis
• Strategic Goals Setting:
Definition of what the organization wants to achieve based on their understanding of the
prioritized gaps and possibilities to be managed by the different units of the organization
It includes identification of the key performance indicators to track the progress of the plan, and
document the achievement of the strategic vision.
• Strategic Approaches and Actions :
Statement of approaches that will be used to advance and achieve the stated goals
• Initiatives:
Identification of specific programs or projects to be elaborated in the planning cycles of the
organization,and to fulfill the chosen strategies. The initiative is assigned to specific units of the
organization for implementation.
• Work Plan :
Specification of tasks to execute the initiatives, it includes the program or project scope that
indicates the who is responsible, when to happen, what are the high level requirements, and how
much are resources to be used.
• Strategic Outcomes:
Tangible results to be realized in pursuing the strategy and actions.
Outcome-Based objectives
Specific and measurable statement of results to be achieved by the strategic plan in relation to its
stakeholders perception, behavior, performance expectations, and competitions.

26. Part 15: ENTERPRISE ARCHITECTURE AND STRATEGIC PLANNING WORK PLAN
ORGANIZE 1. Identify and engage the service of the Mentoring Consultant, Technical Consultants,
Technical Facilitators and Researchers
2. Assist and coordinate with the AGENCY NAME ICT Services Strategic Planning Committee
3. Define and agree on the strategic planning framework, tasks and timetable
DISCOVER 1. Set the organizational assessment framework for the strategic planning
2. Identify the specific issues or decisions that the strategic planning should address
3. Identify the information that must be collected
4. Conduct Focus Group Discussions on the situational assessment
a. The Mandate, Laws and Standards
b. Technical and Business Units and Business Processes
c. Current Organizational Strategies and Limitations
d. Best Practices and International Trends
e. Future Organizational Strategies and Directions
f. The Enterprise Architecture
3. Gather and create summary presentation of the information gathered from the key
technical and business areas of the organization
4. Assess the information needs/requirements of the agency
5. Assess the existing IT infrastructure (i.e., hardware, software, network, special
solutions/devices, etc.) as to its applicability and further use
DEFINE 3. Revisit the mandate, mission, vision and values of the organization
4. Define the aim, goals, and objectives of ICT services aligned to the mission, vision,
values, and business ends of the organization
5. Identity the strategic directions of the agency
6. Define the Enterprise Architecture aligned to the strategic directions
7. Define what it takes to realize the strategic directions
8. Define the ICT service projects or components of the business case
9. Define the metrics of success or key performance indicators
10. Define the best practice references
11. Identify the key areas of the plan requiring specific technical experts
12. Identify the necessary upgrades and replacements that must be made to the IT
infrastructure using lifecycle management practices for infrastructure and technologies
employed
13. Identify the information systems necessary to support the mandate of the AGENCY NAME.
14. Define other ICT projects that need to be included in the AGENCY NAME budget forecasts
and to be prioritized within the next three (3) years.
15. Identify the criteria in the selection of the appropriate systems integration/solutions
provider for the eventual implementation of the ISSP.
DRAFT 1. Consolidate the input derived from the focus discussion and research
2. Design and develop the AGENCY NAME Enterprise Architecture (EA) document
3. Develop a three (3) year Information Systems Strategic Plan (ISSP) that would serve as the
“blueprint” of AGENCY NAME in the various aspects of technology, solutions, IT strategies,
IS strategies, IT manpower support and budgetary requirements, among others.
4. Ensure that the developed ISSP is in conformance to the requirements of the regulatory
bodies in the Philippine Government primarily as it related to monitoring, approval and
implementation of the ICT vision of the agency.
5. Prepare an ISSP that conforms to the NCC format (M.O. 2003-02)
6. Prepare the E-commerce Plan of the agency in support of the E-commerce Law so that the
agency maximizes the use of the Internet in the various aspects of operational and
strategic thrusts.
7. Prepare the ICT Projects Investment Roadmap that considers hardware, software and
network infrastructure, information systems, and other ICT projects that need to be
included in the AGENCY NAME budget forecasts and to be prioritized within the next three
(3) years.
8. Conduct a stakeholders and users review
9. Revise and submit for final approval
IMPLEMENT 1. Define implementation and monitoring process of the project outcomes and
recommendations
2. Facilitate the organizational definition of the Implementation Oversight Committee
3. Define and perform a technology transfer program to ensure that AGENCY NAME
management and the corresponding staff of the agency understand the conceptual and
operational aspects of the deliverables
4. Conduct training on ICT Project Management
5. Conduct training on ICT Subcontract Management

27. Part 16: STRATEGIC PLANNING INPUT AND THINKING TOOLS
Environmental Scanning:
1. Strengths are internal factors that create value.
2. Weakness are internal factors that destroy value.
3. Opportunity are external factors that create value.
4. Threats are external factors that destroy value.
THE S.W.O.T. MATRIX
PERFORMANCE AREAS 1. STRENGTH 2. WEAKNESS 3. OPPORTUNITY 4. THREATS
Mandate
Organization
Culture
People
Services/Products
Process
Data
Application
ICT Configuration
ICT Security
ICT Configuration Baseline:
1. Availability - The condition that the ICT asset is ready for use.
2. Reliability - The conditon that the ICT asset is able to perform its required functions under stated
conditions for a specified period of time
3. End of life – The time when the ICT assets is deemed retire or obsolete.
ICT ASSETS BUSINESS NUMBER AVAILABILITY RELIABILITY END OF LIFE
LOCATION STATUS STATUS
Servers
Workstations
Network Devices
Operating
Software
Server Application
Software
Workstation
Application
Software
Security Software
Bandwidth
Services
ICT Worker
ICT Experts
Service Providers

28. Strategic Goal Setting:
1. What do you want that you don't have? (Achieve)
2. What do you want that you already have? (Preserve)
3. What don't you have that you don't want? (Avoid)
4. What do you have now that you don't want? (Eliminate)
THE STRATEGIC GOALS GRID
PERFORMANCE AREAS ACHIEVE ELIMINATE PRESERVE AVOID
Mandate
Organization
Culture
People
Services/Products
Process
Data
Application
ICT Configuration
ICT Security
Strategic Actions:
PERFORMANCE STRATEGIC GOALS ACTIVITIES KEY PERFORMANCE CRITICAL SUCCESS
AREAS INDICATORS FACTORS
Mandate
Organization
Culture
People
Services/Products
Process
Data
Application
ICT Configuration
ICT Security

29. Strategic Investments:
STRATEGIC GOAL ACTIVITIES TIMELINES SERVICES/GOODS ESTIMATED
REQUIREMENT BUDGET
Goal 1:
Goal 2:
Goal 3:
Goal 4:
Goal 5:
Strategic ICT Projects:
STRATEGIC GOALS ICT PROJECT STAKEHOLDERS BUSINESS DELIVERABLES
NAME REQUIREMENTS
Goal 1:
Goal 2:
Goal 3:
Goal 4:
Goal 5:
Strategic ICT Configuration Requirements:
BUSINESS AREA ICT OBJECTIVES HARDWARE SOFTWARE SERVICES
Business Area 1:
Business Area 1:
Business Area 1:

30. Part 17: STRATEGIC PLAN AUTHORING TEMPLATE
Executive Summary
PART 1: ORGANIZATIONAL PROFILE
DEPARTMENT/AGENCY VISION/MISSION STATEMENT
A.1. Mandate
• Legal Basis
• Functions
A.2. Vision
• End view statement of for the agency
A.3. Mission
• Statements of outcome directives for the agency
A.4. Strategic Thrusts and Program
• Strategic Thrust 1:
o Program Item 1:
o Program Item 2:
o Program Item 3
• Strategic Thrust 2:
o Program Item 4
o Program Item 5
o Program Item 6
DEPARTMENT/AGENCY PROFILE
B.1. Name of Designation Information Systems Planner
• Plantilla Position
• E-mail Address
B.2. CURRENT ANNUAL BUDGET
FUND SOURCES AMOUNTS
GAA
ODA
Others:
B.3. ORGANIZATIONAL STRUCTURE
COMPONENTS COUNTS
Employees
Regional/Extension Offices
Provincial Offices
Other Offices:

31. B.4. ORGANIZATIONAL FUNCTIONAL CHART
• Functional Flow Chart
C. THE DEPARTMENT AND ITS ENVIRONMENT
▪ Functional interface chart
D. PRESENT ICT SITUATION (STRATEGIC CHALLENGE) –AS-IS-STATUS AND GAPS
• What are the mission/critical services –level and status of computerization
• What is the availability and status of office automation
• What is the availability and level of web presence
• What is the state of people capability on ICT use
• What is the availability status of computer resources against the number of
employees and agency sites
• What are the ICT reality against the business operation of the agency
E. STRATEGIC CONCERNS FOR ICT USE
E.1 DESCRIPTION:
• What kinds of strategic gaps that information and communications technology
shall be able to fill-in?
• What kind of changes or improvement requirements that the use of ICT shall be
able to enable?
• What kind of agency risks that the use of ICT shall be able to mitigate?
• In what functions of the agency that the use of ICT shall have high level of impact
in terms of service quality, efficiency, timeliness, accountability and security?
E.2 DETAILS
Major Functions Critical Problems Intended Use
Management/Operating Of ICT
Business Systems
Back Office - Human resource - Issues on personnel - Establish the networked
Administrative Support management system record keeping based communication
- Financial Management - Efficiency issues in system
System the manual - Improved the business
- Assets and Property recording and process through the use of
Management System processing of the automated applications
- Legal Management back office systems - Deploy ICT service
System - Issues on the management applications
- ICT Service Management service delivery and to insure capability and
System support performance of the ICT
Communication management of IT support units.
Management System
PART 2: NFORMATION SYSTEMS STRATEGY

32. CONCEPTUAL FRAMEWORK FOR INFORMATION SYSTEM
input-storage-process-output-sharing model
DETAILED DESCRIPTION OF THE ICT PROJECTS
ICT PROJECT 1:
B.1.1 PROJECT NAME:
Intranet System
B.1.2 DESCRIPTION:
The project entails the design and development of the secured network
infrastructure that will connect physically all the functional units and
responsible personnel into the agency-wide information system. On top of the
secured network run the web-based communication, collaboration, content
publication and file sharing applications.
B.1.3 STATUS:
Proposed
DETAILED DESCRIPTION OF INFORMATION SYSTEMS
NAME OF DESCRIPTION STATUS DEVELOPMENT COMPUTING SCHEME
INFORMATION STRATEGY
SYSTEM /
SUBSYSTEMS
EXISTING PROPOSE
Intranet System Network None Out-source
infrastructure to NONE NETWORKED
run web based
communication,
collaboration,
publication and
file sharing
applications
IMPACT AND LINKAGES OF INFORMATION SYSTEM
NAME OF IMPACTS LINKAGES
INFORMATION
SYSTEM /
SUBSYSTEMS
Strategic Thrusts Benefits Internal Users External
& Programs
Owner(s) User(s) User(s)

33. DATABASE REQUIRED
Name of General Content Status Information Data Archiving, Storage, Media
Database Description Systems Served
Communication -e-mail None
Transaction -attached files Communication -Network data storage system
Database -transaction and
references Collaboration
-voice and video system
Document - textual None
Repository - audio Knowledge -Network data storage system
Database -video Management
-multimedia System
NETWORK LAYOUT
Network diagram of existing configuration and planned requirements
PART 3: INFORMATION AND COMMUNICATIONS TECHNOLOGY SOLUTIONS
ICT SOLUTIONS OF THE INFORMATION SYSTEMS
Name of Information Systems ICT Solutions
Existing Proposed
Communication & Collaboration None - structured cabling and network
System - intranet web server, application
server, security server, database
server, active directory server, web
mail, ftp server, file server, and IP
telephony exchange server
ICT STRATEGY FOR PUBLIC ACCESS
How will the public gains access to the service.
PART 4: INFORMATION AND COMMUNICATIONS TECHNOLOGY SOLUTIONS
ICT RESOURCE REQUIREMENTS
A.1. HARDWARE
ITEMS NUMBER OF UNITS
EXISTING YEAR 1 YEAR 2 YEAR 3 TOTAL
Computer
Servers
Computer
Workstations
A.1.1 NETWORK AND TELECOMMUNICATIONS
ITEMS NUMBER OF UNITS
EXISTING YEAR 1 YEAR 2 YEAR 3 TOTAL
Network Server
Network Hubs

34. A.1.2 DEPLOYMENT OF ICT EQUIPMENT
NAME OF OFFICE/ ITEMS NUMBER OF UNITS
ORGANIZATIONAL UNITS
EXISTING PROPOSED
A.2. SOFTWARE
ITEM VERSION LICENSE NUMBER OF LICENSES
TYPE TYPE
EXISTING YEAR 1 YEAR 2 YEAR 3 TOTAL
Network
Operating
System
Desktop
Operating
System
Office
Productivity
Suite
A.3. ICT SERVICES
TYPE NUMBER OF UNITS
EXISTING YEAR 1 YEAR 2 YEAR 3 TOTAL
A.4. ICT MANPOWER AND ORGANIZATIONAL STRUCTURE
A.4.1 DEPLOYMENT OF ICT EQUIPMENT
TYPE NUMBER OF UNITS
EXISTING YEAR 1 YEAR 2 YEAR 3 TOTAL

35. A.4.2 EXISTING ICT ORGANIZATIONAL STRUCTURE
A.4.3 PROPOSED ICT ORGANIZATIONAL STRUCTURE
A.4.4 .PLACEMENT OF THE PROPOSED ICT ORGANIZATIONAL STRUCTURE IN THE
AGENCY ORGANIZATION CHART
A.4.5 ICT TRAINING NEEDS
ICT COURSES NUMBER OF TARGET PARTICIPANTS
TITLE
CLASSIFICATION DESCRIPTION YEAR 1 YEAR 2 YEAR 3 TOTAL
B.OTHER RESOURCES
ITEMS NUMBER OF UNITS
EXISTING YEAR 1 YEAR 2 YEAR 3 TOTAL
PART 5: DEVELOPMENT AND INVESTMENT PROGRAM
A. ICT PROJECTS IMPLEMENTATION SCHEDULE
NAME OF ICT PROJECTS YEAR 1 YEAR 2 YEAR 3

36. B. INFORMATION SYSTEMS IMPLEMENTATION SCHEDULE
NAME OF INFORMATION / SUBSYSTEM /MODULES YEAR 1 YEAR 2 YEAR 3
SUMMARY OF INVESTMENT
BUDGET / ITEM ACCOUNT FINANCIAL REQUIREMENTS IN PESOS
YEAR 1 YEAR 2 YEAR 3
TOTAL