Basic guidance on doing e-services planning and enterprise architecture to align the value of information and communications technology to the strategic intent and performance goals of the organization

1. ENTERPRISE ARCHITECTURE
AND E-SERVICES PLANNING
Primer on Framework, Methodology and Tools to Draw Performance, Processes, Information & Technology to
Effectively and Efficiently Align E-Services to Enterprise Transformation

2. INTRODUCTION
Enterprise Architecture is globally recognized management practice to maximize the value of
agency resources, technology investment and system development to the achievement of performance
goals. Agencies of government need to have an Enterprise Architecture to guide the organization in
defining and communicating clearly the relationship between agency strategic goals, investment
requirements, business methodologies, interconnectedness, technology solutions and performance
scorecard.
1
Enterprise Architecture defines the components that compose the enterprise system, their
interrelationship, and the principles and guidance governing the design and evolution.
2
It provides the
thinking tool to understand, validate and verify the relevance, usability and continual improvement of
strategy, systems and technology of the enterprise. The practice of enterprise architecture creates the
living documents that capture and integrate the view of the organization from different perspectives that
compose the performance model, business model, information model and technology model. It provides
the critical input in the e-services structured planning that clearly elaborates the enterprise component
baseline, reference standards, maturity model, technology configuration, changes requirements and
solution roadmap.
Enterprise Architecture connects the service and business mission strategies, and processes of
the government agency to the information and communication technology strategy. The established key
components of Enterprise Architecture bring accurate representation of the business context, strategies
and critical success factor; comprehensive documentation of functions and processes from the business
units; views of the systems and data that supports the input-process-output of managed information and
communication; and the technology standards that define what technological platforms and products are
agreed to be used within the agency or organization, complemented by prescriptive enterprise-wide
guidelines on how to best apply these technology standards in creating business application.
3
The competencies on Enterprise Architecture make the agency baseline, document, draw,
analyze and change the business, information and technology requirements for improving the
performance scorecard. It provides the blueprint on how to view the alignment of information and
communications technology projects to the agency’s transformation goals.
Enterprise Architecture enables the agency to construct the integrative and standardized view
the enables reliability, security, connectedness and interoperability in the different processes, data,
application and infrastructure in both vertical and horizontal levels of agency performance.
The holistic view offered by enterprise architecture brings better reference to successfully meet
strategic goals, respond to changing mission needs, and serve citizen’s expectation, as compared to
limiting the organization to technology or budget driven model. With Enterprise architecture, the agency
is able to do alignment, integration, change and reduce the time to market.
4
Enterprise architecture (EA) is a strategic planning process that integrates business strategy and
IT strategy to improve the performance scorecard, and to grow the level of effectivity and efficiency in the
process, information and technology of services.
1
Source: FEA (Federal Enterprise Architecture) Practice Guidance
2
Source: TOGAF – The Open Group Architecture Framework.
3
Source: Clinger Cohen Competencies for Enterprise Architecture
4
Source: Zachman Enterprise Architecture Framework

3. OBJECTIVES
The primer presents the essential knowledge to appreciate and do enterprise architecture and
planning of e-services. It covers fundamental concepts on governance model, logical framework, open
methodology and re-usable tools to systematically articulate, compose, agree and communicate the
strategic directives, performance metrics, functional views, process improvement, data design,
application model, security management and technology configuration.
It demonstrates how to use Enterprise Architecture as a management tool to plan the continual
improvement of the organization through e-services. The offered template identifies the information
requirement and decision checkpoints to enable value creation in the use of information and
communication technology in service delivery and support.
The primer on Enterprise Architecture and E-Services planning enable the following capabilities
1. Lead the formulation, implementation and continual improvement of enterprise architecture that
align people, process, information, technology and culture in the achievement of organizational
performance goals
2. Create a case for enterprise architecture as a tool to enable alignment and fitness of strategy, plan,
and capabilities in the use of information and communications technologies to effect change in the
performance scorecard of the organization.
3. Connect the silos of information system to the bigger picture of information management that
enables interoperability and optimization of information as enterprise asset.
4. Perform proper elicitation, elaboration, analysis, and design of the performance, business,
information and infrastructure requirements that are strategized, designed, planned, transitioned
and supported to improve the performance scorecard of the agency.
5. Manage the proper documentation and communication of reference models and standards intended
to guide business process improvement, information and communication systems development,
evaluation and monitoring, and performance planning.
6. Formulate the e-service strategic plan that provides the “bigger picture” of connectedness and
interoperability in the process, systems, data, and skills of the organization that optimize the value of
information and communications technology to strategically transform the maturity level of service
delivery and support in the agency.

4. CONTENT
The primer on Enterprise Architecture and E-Services Strategic Planning is composed of four
parts. Each introduces the body of knowledge to build the concept, terminology, definition, process,
methodology and software in composing and managing the enterprise architecture of the agency. The
content is not prescriptive but descriptive of understanding and skills that form the essential competency
in doing enterprise architecture. It utilizes commonly accepted practices and standards for easily
reference of the participants as they pursue the continual learning on Enterprise Architecture.
Enterprise Architecture Competencies
Enterprise architecture competencies provide the benchmark frameworks that outline and
elaborate the competencies required to do enterprise architecture in an organization and government
agencies. It provides guidance in organizing and implementing enterprise architecture. It identifies and
describes the body of knowledge that serves as basis for the discipline called enterprise architecture. The
reference frameworks on enterprise architectures provides baseline on common terminologies, process
definition, benchmark for good practices, and conditions of usability
Enterprise Architecture Reference Model
Enterprise architecture reference model establishes the requirements that compose an
enterprise and the perspective on which they are elicited, elaborated and applied. It identifies the matrix
of enterprise components to draw, define, communicate and agree in order to compose the blueprint of
enterprise architecture. It presents the process and artifacts in composing the core reference models of
the enterprise architecture that documents and guide performance, integration, process, data,
application, technology and security.
Enterprise Architecture Modeling Tools
The enterprise architecture modeling tools provides the methodology and software to compose,
decompose and recompose the drawing of the organization, process, data, application, infrastructure and
performance. It identifies the commonly accepted methodology and software to compose performance
mind map, process mapping, use case model, data flow diagram, entity relationship diagrams, and
infrastructure diagram. The drawings are the key to articulate the concepts and expectation of Enterprise
Architecture. The drawn objects serve as re-usable artifacts to appreciate requirements of continual
improvement of process, data, application and infrastructure of the agency.
E-Services Strategic Planning
E-services strategic planning provides the methodology and thinking tools to elicit, elaborate,
document, and approve the requirements and content of the e-services strategic plan that is aligned to
the enterprise architecture.

5. TABLE OF CONTENTS
Introduction...................................................................................................................................................................2
Objectives ......................................................................................................................................................................3
Content..........................................................................................................................................................................4
Part 1: Enterprise Architecture Competencies and Frameworks ..................................................................................8
Enterprise Architecture Definitions...........................................................................................................................9
Basic Definition of Important Concepts...................................................................................................................11
Enterprise Architecture Status ................................................................................................................................12
Importance of Enterprise Architecture....................................................................................................................14
Enterprise Architect Responsibilities.......................................................................................................................15
Enterprise Architecture Governance.......................................................................................................................18
Enterprise Architecture Framework ........................................................................................................................20
The Open Group Architecture Framework – Guidance Content .........................................................................21
Zachman Architecture Interrogatives..................................................................................................................22
Business Case for Enterprise Architecture...............................................................................................................23
Part 2: Enterprise Architecture Reference Model Requirements...............................................................................24
Scope of Enterprise Architecture Development......................................................................................................25
Architecture Development Method Cycle...............................................................................................................26
Identification and Definition of Enterprise Architecture Component and Requirements ......................................28
Architecture Components Elaboration....................................................................................................................29
Performance Modeling............................................................................................................................................31
Balance Scorecard ...................................................................................................................................................32
Business Analysis Body of Knowledge .....................................................................................................................34
Process Maturity Model ..........................................................................................................................................35
Record Management Standard................................................................................................................................37
Data Reference Model.............................................................................................................................................38
Interoperability Framework.....................................................................................................................................39
Information Security Framework.............................................................................................................................40
Technology Reference Model..................................................................................................................................41
Part 3: Process, Data, Application and Technology Modeling Tools ...........................................................................42
Business Transformation Readiness Assessment ....................................................................................................43
Performance Scorecards..........................................................................................................................................44
Process Mapping .................................................................................................................................................45
BUSINESS DEFINITION MATRIX............................................................................................................................45

6. INFORMATION REQUIREMENT MAPPING ...........................................................................................................45
PROCESS MAPPING: SWIM LANE.........................................................................................................................46
DATA AND Application Design.................................................................................................................................48
Data Dictionary....................................................................................................................................................48
Application Design...............................................................................................................................................49
Use Case Identification Elements ........................................................................................................................50
Information Security Risk Assessment.....................................................................................................................52
INFORMATION SECURITY MODEL............................................................................................................................53
Technology Configuration........................................................................................................................................54
Part 4: E-Services Strategic Planning Methodology.....................................................................................................55
Strategic Alignment Model......................................................................................................................................56
The Test of Effective Strategy..................................................................................................................................57
The Type of Organizational Goals............................................................................................................................58
Critical Phases:.........................................................................................................................................................59
ENTERPRISE ARCHITECTURE AND STRATEGIC PLANNING WORK PLAN ..................................................................60
STRATEGIC PLANNING INPUT AND THINKING TOOLS .............................................................................................61
Architecture Baseline...........................................................................................................................................61
Capability Scanning..............................................................................................................................................62
ICT Configuration Baseline...................................................................................................................................63
Strategic Goal Setting: .........................................................................................................................................64
To-Be Architecture:..............................................................................................................................................65
Strategic Actions:.................................................................................................................................................66
Strategic Investments:.........................................................................................................................................67
Strategic ICT Projects:..........................................................................................................................................68
Strategic ICT Configuration Requirements: .........................................................................................................69
Process Checklist and worksheets...........................................................................................................................70
Information Systems Strategic Planning Questions ................................................................................................71
Worksheet 1: Strategic Intent..............................................................................................................................72
Worksheet 2: Strategic Baseline ..........................................................................................................................73
Worksheet 3: Operation S.W.O.T.........................................................................................................................74
Worksheet 4: ICT Services Performance Status ..................................................................................................75
Worksheet 5: Environment Condition ................................................................................................................76
Worksheet 6: Strategic Goals...............................................................................................................................77
Worksheet 7: Strategic Program..........................................................................................................................78

7. Worksheet 8: Strategic ICT Services ....................................................................................................................79
Worksheet 9: Strategic ICT Services Performance Metrics..................................................................................80
Worksheet 10: Strategic ICT Investment (New Requirements) ..........................................................................81
Worksheet 11: Financial Valuation of the Strategic Investments ........................................................................82
Worksheet 12: Strategic Plan Implementation Time line ....................................................................................83
Worksheet 13: Implementation Roles and Responsibilities ................................................................................84
Software for Enterprise Architect............................................................................................................................85

8. PART 1: ENTERPRISE ARCHITECTURE COMPETENCIES AND FRAMEWORKS
At the end of this presentation, the participant is expected:
1. To assess the status of enterprise architecture and establish the gaps and opportunities in doing
enterprise architecture of the agency.
2. To define the motivation, organization, roles, responsibilities, knowledge and skills in order to lead,
manage and implement enterprise architecture.
3. To review best practice references and open framework to establish the terminologies, organization,
process, content and metrics of doing enterprise architecture in the agency.
4. To compose the suitable enterprise architecture framework and implementation plan to match the
agency context and readiness.

9. ENTERPRISE ARCHITECTURE DEFINITIONS
Enterprise Architecture Description (from various references)
1.0.1 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."
1.0.2 CIO Definitions from SearchCIO.com, posted October, 2006:
"Enterprise architecture (EA) is a conceptual blueprint that defines the structure and operation of an
organization. The intent of 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."
1.0.3 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.
1.0.4 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.

10. 1.0.5 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.

11. BASIC DEFINITION OF IMPORTANT CONCEPTS
Terminology Definition Source
Architecture The specification that identifies components and their associated
functionalities. It describes connectivity of components and the mapping of
functionality into components. Architectures can be of different types and
cover hardware, software, systems, and can be domain specific to describe
business, data, application, technology, network, security, etc.
Software
Engineering
Institute
Architecture View It is a representation of the set of system elements and the 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.
IEEE
Architecture Framework The combination of structured processes, templates, and governance that
facilitate the elicitation and documentation of the architecture in a
systematic manner.
NASCIO
Architecture Domain High level grouping of disciplines, functional or topical operations that form
the main building block of the architectural framework. It talks of sphere of
activity, interest, or functions.
OMB, NASCIO
Architecture Component Level of details contain in specific architectural domain NASCIO
Enterprise An organization supporting a defined business scope and 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
MITRE EABOOK
Enterprise Any collection of organizations that has a common set of goals. TOGAF
Enterprise Architecture Artifacts Artifacts constitute any object, or work product that is 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.
NASCIO
Business Architecture The high level representation of the business strategies, intentions,
functions, processes, information, and assets critical to operating the
business of government successfully.
NASCIO
Business Reference Model It is a function driven framework that describes the business operation
independent of the organization performing the job. It provides an
organized and hierarchical construct for describing the day-to-day business
operation.
OMB
Data Reference Model It describes the data and information that supports the government agency
operation from an agency and government-wide perspective.
CIOGOV
Performance Reference Model It is the standardized framework to measure the performance of major IT
investments and their contribution to program performance.
OCIO-DOI
Technology Reference Model It is a component-driven, technical framework used to categorize the
standards, specifications, and technologies that support and enable the
delivery of service components and capabilities
OCIO-DOI

12. ENTERPRISE ARCHITECTURE STATUS
The enterprise architecture status identifies the kind of question to assess the practice of enterprise
architecture in the organization. It identifies the components that describe the use of enterprise architecture to
manage the integrative improvement and investment for information and communications technology.
1. Practice of Enterprise Architecture Checklist.
Does your agency maintain a blueprint or matrix of all running systems, showing how they
interoperate, and which technology they are using?
YES NO NOT
SURE
Can your agency readily present the professional and business user matrix with their
requirements, and the technology services that address those requirements?
YES NO NOT
SURE
Does your agency have a documented map of enterprise-wide data, how data is being grouped,
how data are related, how data is being accessed, how data is shared, and how data is
secured?
YES NO NOT
SURE
Are there silos of data and application in the different units of the agency? YES NO NOT
SURE
When your agency starts a project do you have an enterprise architecture blueprint, which you
have to align the type of application to be designed and developed?
YES NO NOT
SURE
Is there a formal stage in the project life cycle where system architecture is being checked
against the enterprise architecture?
YES NO NOT
SURE
If you have any question or problem regarding architecture do you know who to seek for
guidance, decision and documentation?
YES NO NOT
SURE
Is there an official guidance and listing of all business standards, methods and tools, technical
references that both IT and Business have to use, or you can use whatever technology you
want?
YES NO NOT
SURE

13. The capability maturity model on enterprise architecture program provides the organization indicators to
speak the growth of enterprise architecture practices that enable the aligned value of information and
communications technology to the strategy and performance requirements of the organization.
2. NASCIO Enterprise Architecture Program Maturity Model
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 Program The enterprise architecture framework is well defined; using approved 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 Continuously Improved
Vital Program
The processes are mature; targets have been set for effectiveness and efficiency
based on business and technical goals. There are ongoing refinements and
improvements based on the understanding of the impact changes have to these
processes.

14. IMPORTANCE OF ENTERPRISE ARCHITECTURE
The motivation to do enterprise architecture depends on the kind of improvement requirements that the
organization demands to improve the value of people, process and technology in achieving the mandate, mission,
goals, functions, tasks and deliverables.
Doing enterprise architecture means alignment, integration, value creation, change management and
compliance. Here are value indicators and the corresponding description.
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.
Source: Schekkerman, J. (2005). Trends in Enterprise Architecture, Institute for Enterprise Architecture
Development, white paper.
Activity 1: Is there a need for enterprise architecture?
Alignment Integration Value Creation Change
Management
Compliance
INTENTION
FUNCTION
PROCESS
INFORMATION
TECHNOLOGY

15. ENTERPRISE ARCHITECT RESPONSIBILITIES
Enterprise architecture demands competencies to understand and interpret requirements; to create useful
model; to do validation and verification, refinement and expansion of drawn model; and manage the architecture
planning, design, implementation and improvement.
1.3.1 The TOGAF (The Open Group Architecture Framework) Enterprise Architect Responsibility Definition:
TASKS DESCRIPTIONS
Understand and
interpret requirements
Probe for information, listen to information, influence people, facilitate consensus building,
synthesize and translate ideas into actionable requirements, articulate those 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 model Take the requirements and develop well-formulated models of the components of the 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
expand the model
Verify assumptions; bring in subject matter experts, etc. in order to improve 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
architecture
Continuously monitor the models and update them as necessary to show changes, 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
Source: The Open Group Enterprise Architecture Framework

16. 1.3.2 The Open Group Architecture Framework Enterprise Architecture Skills Requirement
Generic Skills Business Skills Enterprise
Architecture
Program or
Project
Management
Skills
IT General
Knowledge
Technical IT Skills Legal Environment
Leadership Business Case Business Modeling Program
Management
IT Application
Development
Methodologies and
Tools
Software
Engineering
Contract Law
Teamwork Business Scenario Business Process Design Project Management Programming
Languages
Security Data Protection Law
Inter-personal Organization Role Design Managing Business
Change
Application Systems Systems & Network
Management
Procurement Law
Oral Communication Business Process Organization Design Change
Management
Database Systems Transaction
Processing
Cybercrime law
Written Communication Strategic Planning Data Design Value Management Storage
Management
Location & Directory Commercial Law
Logical Analysis Budget
Management
Application Design Networks User Interfaces
Stakeholder
Management
Visioning Systems Integration Web-based Services International
Operation
Risk Management Business Metrics IT Standards IT Infrastructure Data Interchange
Business Culture Service Design Asset Management Data Management
Legacy Investment Architecture Principle
Design
Service Level
Agreements
Graphics and Images
Business Functions Architecture Views &
Viewpoint Design
COTS Operating Systems
Services
Building Block Design Enterprise
Continuum
Network Services
Solution Modeling Migration Planning Communication
Infrastructure
Benefit Analysis Management
Utilities
Business Interworking Infrastructure
Systems Behavior
Project Management

17. 1.3.3 Clinger Cohen’s Summary of Enterprise Architect Competencies.
Clinger-Cohen is a legal basis in the United States that defines the CIO Office and Competencies. Among
the role, that is institutionalize for effective governance and management of ICT is the “Enterprise Architect”
1. A basic grounding in the agency’s environment, strategy and priorities
2. Extensive knowledge of IT capabilities, covering current and emerging technologies
3. Good knowledge of how similar agencies use or plan to use technology
4. Ability to rationalize technology opportunities and business drivers optimizing return on investment
5. Familiar with agency’s architectural principles and policies, able to interpret and apply
6. “Hands on” experience in architecture, able to perform a number of architectural tasks
7. Must have a mixture of BPR, business processes, and meeting facility
8. Strong in capability modeling
9. Can define and understand component capabilities and apply solutions
10. Ability to look at technology trends and effectively apply to business/project needs
11. Ability to look at and define target architecture for specialty projects
12. Ability to manage a repository - repository modeling and analysis
13. Competency in several tool sets
14. Ability to manage a project portal to identify concepts, work in progress, etc.
15. Able to identify redundancies among existing and proposed IT efforts
16. Ability to bring together an overall Enterprise Architecture from several individual EA efforts
17. Ability to develop the crux functional integration services that can be implemented in patterns
Activity 2: What enterprise architect competencies are needed by your organization to allow the proper alignment
and integration of ICT in the performance goals?
STRATEGY PROCESS TECHNOLOGY
1
2
3
4
5
6
7
8
9
10

18. ENTERPRISE ARCHITECTURE GOVERNANCE
1.4.1 Governance Definition
Enterprise architecture governance is how the architectures are managed and controlled at the enterprise
level. It describes the structure of leading, monitoring, controlling, implementing and improving the enterprise
architecture of the organization.
Governance is described as ensuring the business is conducted properly. In general terms the following
governance characteristics, namely, discipline transparency, independence, accountability, responsibility, and
fairness.
At the enterprise level, governance can be viewed in the perspective of:
1. Corporate Governance
2. Business Governance
3. IT Governance
4. Architecture Governance
Architecture governance means:
1 Implementing a system of control over the creation and monitoring of architectural components and
activities that ensures the effective introduction, implementation and evolution of architecture within
the organization.
2 Implementing a system to ensure compliance with internal and external standards and regulatory
obligations
3 Establishing processes that support effective management of the above processes within agreed
parameters
4 Developing practices that ensure accountability to a clearly identified stakeholder community, both
inside and outside the organization.
1.4.2 Process and Content of Architecture Governance
The Open Group Enterprise Architecture Framework sets the processes and content of architecture governance,
they are the following
PROCESS CONTENT
Policy Management and Take-on Requirements
Compliance Service Level Agreements and Operation Levels Agreements
Dispensation Authority Structure
Monitoring & Reporting Organization Standards
Business Control Solutions
Environment Management Architectures

19. 1.4.3 Organization Structure of Architecture Governance
The organization structure of architecture governance speaks of the key areas in the management of
architecture, namely, development, implementation and deployment.
Activity 3: Draw the governance structure of IT in your organization, and identity those responsible for the
management of development, implementation and deployment of enterprise architecture.

20. ENTERPRISE ARCHITECTURE FRAMEWORK
Framework is a real or conceptual structure intended to serve as a support or guide for building of
something that expands the structure into something useful. It is a broad overview, outline or skeleton of
interlinked items which supports a particular approach to meet specific objectives, and serves as a guide that can
be modified as required by adding or deleting items.
Framework offers the kind of taxonomies that describe visually, textually and verbally the business,
operations, data, systems and technology of the enterprise. The structured representation clarifies
communication and documentation. The matrix of definition and images draws well defined blueprint. The
hierarchy of components and flow of process improve understanding on the current behavior and change
requirement for improvement. The organized classification gets better the reporting of the current state and
application of performance metrics on expected input, process and outcomes.
The enterprise architecture framework is best practice references on the principles, methods, processes,
artifacts and metrics in doing enterprise architecture. Here are the commonly cited guides to construct the
enterprise architecture of organization and government.
1. TOGAF (The Open Group Architecture Framework) – The framework offers a structured approach
to plan, design and implement the enterprise architecture. It provides the life cycle view of
developing the enterprise architecture. It identifies the modeling methodologies, assessment
requirements and governance framework to manage the planning and implementation of
enterprise architecture.
2. Zachman Framework –The framework presents the logical structure to comprehensive represent
the different views and artifacts to compose the enterprise architecture. It provides the
perspectives to look at the enterprise, and the corresponding questions to be answered to
properly draw the performance, business, process, information and technology that are aligned
and integrated in fulfilling the strategic ends of the organization.
3. FEA (Federal Enterprise Architecture – It provides the reference model to assess and describe the
government enterprise architecture
4. NASCIO (National Association of State Chief Information Officer) – It provides the toolkit to
develop the enterprise architecture of government.

21. THE OPEN GROUP ARCHITECTURE FRAMEWORK – GUIDANCE CONTENT
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 and Techniques
 Applying Iteration to the ADM
 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 Continuum Tools  Introduction
 Enterprise Continuum
 Architecture Partitioning
 Architecture Repository
 Tools for Architecture Development

22. 05. Reference Model Foundation Architecture
06. Architecture Capability  Introduction
 Establishing an Architecture Capability
 Architecture Board
 Architecture Compliance
 Architecture Contracts
 Architecture Governance
 Architecture Maturity Models
 Architecture Skills Framework
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 enterprise architecture.
PERSPECTIVES WHAT HOW WHERE WHO WHEN WHY
OBJECTIVES/
SCOPES
List of things
important to the
enterprise
List of processes
the enterprise
performs
List of location the
enterprise
operates
List of
organizational units
List of business
events or cycles
List of business
goals and
strategies
BUSINESS MODEL Entity
Relationship
Diagram
Business Process
Model (physical
data flow diagram)
Logistic Network
(Nodes and Links)
Organizational
Charts with Roles
and Skills Sets
Business Master
Schedule
Business Plan
INFORMATION
SYSTEM MODEL
Data Model
Data Dictionary
Application Model
and Data Flow
Diagram
Distributed System
Architecture
Human Interfaces
Model (role, data ,
access)
Dependency
Diagram, Entity Life
History
Business rule
model
TECHNOLOGY
MODEL
Data Architecture
(Elements,
relational tables)
Systems Design
Structure Chart,
Pseudo Code
Systems
Architecture
(Hardware,
Software,
Network)
User Interface,
Usability, Security
Design
Control Structure -
Control Flow
Diagram
Business rule
design
DETAILED
REPRESENTATION
Data Design,
Physical Storage
Design
Detailed Program
Design
Network
Architecture
User Screen and
Security
Architecture
Timing Definitions Program Logic
Rules
Specifications
FUNCTIONING
SYSTEM
Converted Data Executable
Program
Communication
Facilities
Trained People Business Events Enforced Rules

23. BUSINESS CASE FOR ENTERPRISE ARCHITECTURE
At the early stage of enterprise architecture, the need for it stems from system complexity and poor
business alignment. Organization were spending more and more building to develop IT system, and the silo of
systems are not getting aligned to the business needs. Robert Session in his whitepaper, entitled A Comparison of
the Top Four Enterprise-Architecture Methodologies, describes some present problem in organization to cause the
case for enterprise architecture. They are the following:
5
1. IT systems that have become unmanageably complex and increasingly costly to maintain.
2. IT systems that are hindering the organization's ability to respond to current, and future, market
conditions in a timely and cost-effective manner.
3. Mission-critical information that is consistently out-of-date and/or just plain wrong.
4. A culture of distrust between the business and technology sides of the organization.
The business case for enterprise architecture offer value proposition to give reason for investing in enterprise
architecture. Anna Mar at simplicable.com wrote good answers to identify and give simple description on the
enterprise architecture value proposition.
1. EA supports revenue generation and cost reduction by enabling faster, smarter projects.
2. EA reduces technology costs and accelerates time to market by facilitating common approaches.
3. EA provides IT transparency for business stakeholders.
4. EA facilitates pragmatic, cost effective approaches to IT projects.
5. EA is the bridge between business strategy and IT execution.
6. EA shifts IT spending from temporary stop-gap projects to strategic initiatives.
7. EA flags redundant, non-strategic and high risk projects before they get funding.
8. EA ensures IT spending is aligned with business strategy and goals.
9. EA breaks down IT silos — finding common solutions that reduce time to market and risk.
10. EA pushes IT silos to think globally and act locally.
11. EA provides the enterprise-wide IT transparency required for IT groups to design solutions that make
sense for the organization as a whole.
12. EA develops competitive advantage by ensuring that IT spending is focused on strategic core
competencies.
13. EA develops opportunities for cross-silo technology initiatives that resolve business pain points.
14. EA develops opportunities — driving leaps forward that dramatically improve IT responsiveness to
business needs.
6
5
Source: http://simplicable.com/new/14-enterprise-architecture-value-propositions
6
Source: http://www.objectwatch.com/whitepapers/4EAComparison.pdf

24. PART 2: ENTERPRISE ARCHITECTURE REFERENCE MODEL REQUIREMENTS
At the end of this module, the participants are expected:
1. To describe the components that structurally defines the architectural views of the agency
as an enterprise.
2. To create the artifacts that represent the enterprise architecture reference models of
performance, business, data, application, integration, and infrastructure.
3. To review commonly accepted standards to define requirements and maturity metrics for
process, information and technology.

25. SCOPE OF ENTERPRISE ARCHITECTURE DEVELOPMENT
 Enterprise Architecture Development Context in Government
The discussion on what represent as the scope of drawing the enterprise architecture of government has
to elaborate the following components, namely, the stakeholders, mandates & business strategy, functions
and service portfolio, business process, information requirement and technology resources.
The conditions provided by those components dictates the value of information and communication
technology service and the manner government defines investment and procurement plan of acquiring
computers, computers, internet, network, database system, application system, security system and
technology skills and standards.

26. ARCHITECTURE DEVELOPMENT METHOD CYCLE
The Open Group Enterprise Architecture (TOGAF) provides a life cycle model to identify the scope of
enterprise architecture development.
1. The Preliminary Phase describes the preparation and initiation activities required to prepare to
meet the business directive for new enterprise architecture, including the definition of an
Organization-Specific Architecture framework and the definition of principles.
2. Phase A: Architecture Vision describes the initial phase of an Architecture Development Cycle. It
includes information about defining the scope, identifying the stakeholders, creating the
Architecture Vision, and obtaining approvals.
Key Activities:
3. Phase B: Business Architecture describes the development of a Business Architecture to support
an agreed Architecture Vision.
4. Phase C: Information Systems Architectures describes the development of Information Systems
Architectures for an architecture project, including the development of Data and Application
Architectures.
 Data Architecture: Define the types and sources of data needed to support the business,
in a way that can be understood by the stakeholders.
 Application Architecture: Define the kind of application systems needed to process the
data and support the business.
5. Phase D: Technology Architecture describes the development of the Technology Architecture for
an architecture project.
6. Phase E: Opportunities and Solutions conducts initial implementation planning and the
identification of delivery vehicles for the architecture defined in the previous phases.
7. Phase F: Migration Planning addresses the formulation of a set of detailed sequence of Transition
Architectures with a supporting Implementation and Migration Plan.
8. Phase G: Implementation Governance provides an architectural oversight of the implementation.
9. Phase H: Architecture Change Management establishes procedures for managing change to the
new architecture.
10. Requirements Management examines the process of managing architecture requirements
throughout the ADM.

27. The development of enterprise architecture shall bring the tasks and deliverables of the following
1. Architecture Principles and Vision
2. Architecture Requirements
3. Architecture Realization

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

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

30. NASCIO ENTERPRISE ARCHITECTURE DEVELOPMENT TOOLKIT – EA DOMAINS
BUSINESS REFERENCE MODEL It provides an organized, hierarchical construct for describing the day-to-day 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, stovepipe, 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 MODEL It is a business and performance-driven, functional framework that classifies 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 MODEL The Technical Reference Model (TRM) provides a foundation to categorize 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.

31. PERFORMANCE MODELING
Performance modeling provides the reference for the expected purpose, behavior, capability and outcomes
the organization is directed to become. It provides the set of tools to classify the performance components and to
define the metrics that describe results to be generated.
 EFQM Excellence Model
The EFQM Excellence Model is the most popular quality tool in Europe, used by more than 30 000
organizations to improve performance. The use of EFQM means:
7
1. Assess your performance, to identify key strengths and improvement areas
2. Integrate existing tools, procedures and processes, to align all and remove duplicates
3. Introduce a way of thinking that encourages reflection and stimulates continuous improvement
4. Identify what actions are really driving your results, which areas need more attention, and which
approaches should be made redundant.
The model provides the nine criteria to understand and analyze the cause and effect relationship between
what the organizations is “doing” and the “outcomes” being achieved. The criteria are grouped as “enabler” and
“results”. The “results” criteria cover what the organization achieves. Enabler is what the organization is doing and
how they are being done.
ENABLER RESULTS
Leadership Customer Results
Strategy People Results
People Society Results
Partnership & Resources Business Results
Process, Products and Services
Definition as provided by EFQM Guidance:
Leadership: Excellent organizations have leaders who shape the future and make it happen, acting as role Models
for its values and ethics and inspiring trust at all times. They are flexible, enabling the organization to anticipate
and react in a timely manner to ensure the on-going success of the organization.
Strategy: Excellent organizations implement their mission and vision by developing and deploying a stakeholder
focused strategy. Policies, plans, objectives and processes are developed and deployed to deliver the strategy.
People: Excellent organizations value their people and create a culture that allows the mutually beneficial
achievement of organizational and personal goals. They develop the capabilities of their people and promote
fairness and equality. They care for, communicate, reward and recognize, in a way that motivates people, builds
commitment and enables them to use their skills and knowledge for the benefit of the organization.
Partnership & Resources: Excellent organizations plan and manage external partnerships, suppliers and internal
resources in order to support strategy and policies and the effective operation of processes.
Processes, Products & Services: Excellent organizations design, manage and improve processes to generate
increasing value for customers and other stakeholders.
Results: Excellent organizations achieve and sustain outstanding results that meet or exceed the needs and
expectations of their customers, people, society stakeholders, and business stakeholders.
7
Resource Link: http://www.efqm.org

32. BALANCE SCORECARD
Balance Scorecard is a perspective and method to describe and analyze the performance of the
organization. It proposes that financial success does not provide a “balance” view of performance for the
organization. Performance has to be comprehensively viewed from the standpoint of financial, customer,
internal business process and learning and growth. The improvement of the vision and strategy get
balance input from the defined objectives, measures, targets and initiatives of the financial, customer,
internal process, and learning and grow sides of performance.
The success of an organization being defined by financial metrics has to be supplemented with
performance measurement coming from the views of customer, internal processes and learning and
grow. They are the drivers for creating long-term shareholder value. Kaplan emphasizes that employee
and process performance are critical for current and future success. Financial metrics, ultimately, will
increase if companies’ performance improves. And to optimize long-term shareholder value, the firm had
to internalize the preferences and expectations of its shareholders, customers, suppliers, employees, and
communities.
8
The balance scorecard provides answers on the following question:
Financial: If we succeed, how will we look to our shareholders?
Customer: To achieve our vision, how must we look to our customers?
Internal Processes: To satisfy our customers, which processes must we excel at?
Learning & Growth: To achieve our vision, how must our organization learn and improve?
8
Robert S. Kaplan, Conceptual Foundations of the Balance Scorecard; A Working Paper, Harvard Business School,
2010

33. The information provided by the balance scorecard enables the organization to clearly compose
the strategic map to guide the definition, assessment and continual improvement of agency performance.
The strategic map provides the smart view of expectation and deliverable for productivity strategy and
growth strategy for the financial quadrant of scorecard. It spells out the value proposition to the
customer in terms of the quality and quality attributes of products and services, relationship and image.
The strategic map draws the requirements to improve the operation management, customer
management, innovation and application of regulatory and social expectation.
Strategic Mapping Process

34. BUSINESS ANALYSIS BODY OF KNOWLEDGE
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. The Business Analysis Body of Knowledge - International Institute of Business
Analysis defines the set of competencies in doing business analysis.
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 identification 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, refine and clarify
the definition of that need, and define a solution scope that
can feasibly be implemented
By the business. It covers problem definition and analysis
business case development, feasibility studies, and the
definition of a solution scope.
Elicitation It describes how we work with stakeholders to find 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
definition 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
fats the business need, identify gaps and shortcomings in
solutions, and determine necessary workarounds or changes
to the solution
Requirements Management and Communication It describes how we manage conflicts, issues and changes and
ensure that stakeholders and the project team remain in
agreement on the solution scope

35. PROCESS MATURITY MODEL
Business process management is aligning people, process, technology and culture of the organization to meet
the customer expectation of quality service.
Standards on business process management present process maturity model, designing tools, quality assessment
framework, and business process standards of effectivity and efficiency.
1. The Business Process Management Notation Standards (BPMN)
2. Capability Maturity Model Integration (CMMI)
3. ISO 9001: Quality Management Systems
2.2 Information Maturity Model
The information maturity model provides the indicators to assess the level attributes of effective and efficient
information management.
Method for an Integrated Knowledge Environment (MIKE 2.0) is an open source methodology that provides a
framework to define the level maturity of information to establish the end states of information development. It
provides the descriptors and indicators of information maturity, information accuracy and organization confidence
to speak of the kind of change in the management of information in the organization.

36. Information Maturity Level (MIKE 2.0)
 Level 1: Organization has no common information practices. Any pockets of information management
maturity that the organization has are based on the experience and initiatives of individuals.
 Level 2: Organization has little in the way of enterprise information management 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: Organization has a significant degree of information management 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: Organization manages information as an enterprise asset. The business is heavily engaged in
information management procedures and takes responsibility for the quality of information that they
manage. A level 4 organization has many mature and best-in-class practices and utilizes audits to ensure
compliance across all projects.
 Level 5: Organization considers information to be as much an enterprise asset as financial and material
assets. A level 5 organization has best-in-class information management practices that are utilized across
all enterprise projects. The distinguishing characteristic of a level 5 organization is the focus on continuous
improvement. At level 5, all data management practices and assets are regularly measured and the results
are analyzed as the basis for process improvement.

37. RECORD MANAGEMENT STANDARD
The information record management standard provides the benchmark for an acceptable record management
system process and systems to baseline the improvement requirement.
ISO 15489-2001 provides the benchmark to examine the change requirement for record management. It
establishes the principles, design, process and control to govern the practice and systems of record management.
Definition of Record
Record is information created, received, and maintained as evidence and information by an
organization or person, in pursuance of legal obligations or in the transaction of business.
Record Characteristics
• AUTHENTICITY
The record must be proven to be what it purports to be, to have been created or sent by the person
purported to have created or sent it, and to have been created or sent at the time purported.
Critical to authenticity of records is the implementation and documentation of policies and procedures
to control the authorized creation, receipt, transmission, maintenance and disposition of records.
• RELIABILITY
The record is one whose contents can be trusted as a full and accurate representation of the
transactions, activities, or facts to which they attest and can be depended upon in the course of subsequent
transactions, or activities.
Critical to record reliability is the time of creation or incident to relate the record.
• INTEGRITY
The record is complete and unaltered.
Critical to record integrity is the protection against unauthorized alteration. It involves policies
and procedures that specifies valid addition and annotation after the record is created, and under what
circumstances and who is authorized to allow annotation, addition or deletion in the received record.
• USEABILITY
The record is located, retrieved, presented and interpreted.
Critical to record usability is connecting it to the business activity or transaction that produced the record.
The link should carry the information to understand the transaction that created the record.

38. DATA REFERENCE MODEL
The Data Reference Model Framework (DRM) provides a standard means by which data may be described,
categorized, and shared. The U.S. Federal Enterprise Architecture provides the components to established
standards on common data reference.
Data Reference Model Standardization Areas
1. Data Description: It provides the means to uniformly describe data to support searching and sharing.
2. Data Context: It facilitates the search of data by establishing the shared approach on data
categorization and taxonomies. It defines the authoritative data assets.
3. Data Sharing: It 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. Enabled by capabilities provided by both the Data Context and Data Description
standardization areas.
The Data Reference Model provides understanding on requirements in composing data architecture; guidance on
implementation framework; presentation on abstract model; and discussion on security and privacy.

39. INTEROPERABILITY FRAMEWORK
Information interoperability begins by common understanding on the core areas of inter-connection and
compatibility.
The four layers of interoperability which is based on European Interoperability Framework (EIF).
Layers of Interoperability Interoperability Concerns
1. Legal Interoperability Alignment to existing laws, mandate, regulation and
policies to enable data exchanges to be legally acceptable
and justified. Areas of concern are availability and
applicability of legal requirements and guidance.
2. Organizational Interoperability Coordination of function and process to realize joint
performance and delivery of outcomes. Areas of concerns
are roles, procedures, rules and methods compatibility.
3. Technical Interoperability Interconnecting information and communication systems.
Areas of concern are basic protocols, digital format,
security and accessibility.
4. Semantic Interoperability Precise sharing of meaning on the methods and tools in the
formulation of standardized data and schema that allows
instantaneous sharing of input-process-output. Areas of
concerns are data elements and representation schema.

40. INFORMATION SECURITY FRAMEWORK
Information security standard connects information management program to the principles, design, process
and implementation of security of information in the organization. ISO 27001 provides reference standards on the
following:
1. Management and control domains for information security
2. Information security classification
3. Information security management processes and deliverables
 Information Security Definition (ISO 27001)
INFORMATION SECURITY refers to the protection of information assets in order to achieve:
1. Confidentiality: It is protecting sensitive information from unauthorized disclosure or interception
2. Integrity: It is safeguarding the accuracy and completeness of information.
3. Availability: It is ensuring that information and vital services are available to users when required.
 Information Security Domains (ISO 27001)
1. Security Policies
2. Information Security Organization
3. Asset Management
4. Human Resources Security
5. Physical and Environmental Security
6. Operations Management
7. Access Control
8. Systems Development and Maintenance
9. Information Security
10. Incident Management
11. Business Continuity Management
12. Compliance

41. TECHNOLOGY REFERENCE MODEL
 Communication Protocol Standards
Communication protocol covers shared format, rules and technologies in communication exchanges
that connect voice and data.
There are technical bodies and organization that manages guidance on communication and network
protocol, namely:
1. International Standards Organization
2. International Telecommunication Union
3. Institute of Electrical and Electronics Engineers
4. Internet Corporation for Assigned Names and Numbers
5. World Wide Web Consortium
6. Internet Engineering Task Force
 Communication Quality of Service/Experience
Connects information management development framework to a reference standard on quality
of service and quality of experience that insure effectivity, efficiency and reliability in information
exchanges in any network and communication platform.
Quality of Service/Experience Parameters
1. Availability
2. Delivery
3. Latency
4. Bandwidth
5. MTBF (Mean Time Between Failure)
6. MTRS (Mean Time to Restore Service)

42. PART 3: PROCESS, DATA, APPLICATION AND TECHNOLOGY MODELING TOOLS
At the end of this, the participants demonstrate the ability:
1. To develop performance scorecards
2. To compose, describe, draw and analyze the performance model, process model, data model,
application model and infrastructure model of the agency’s enterprise architecture.
3. To use modeling notation and basic software to construct performance mind-map, process map,
data flow diagram, entity relationship diagram, use case, process schema, systems and network
configuration.

43. BUSINESS TRANSFORMATION READINESS ASSESSMENT
The migration of the organization to the target architecture that will transform the business depends on
the level of readiness to satisfy the following: (Canadian Government Business Transformation Enablement
Program (BTEP))
1. Vision:
The ability to clearly define and communicate what is to be achieved.
2. Desire, Willingness, and Resolve:
The presence of a desire to achieve the results, willingness to accept the impact of doing the work, and
the resolve to follow through and complete the endeavor.
3. Need:
There is a compelling need to execute the endeavor.
4. Business Case Exists:
Creates a strong focus for the project, identifying benefits that must be achieved and thereby creating an
imperative to succeed.
5. Funding:
In the form of a clear source of fiscal resources, funding exists that meets the endeavor’s potential
expenditures.
6. Sponsorship and Leadership:
Exists and is broadly shared, but not so broadly as to diffuse accountability. Governance: The ability to
engage the involvement and support of all parties with an interest in or responsibility to the endeavor
with the objective of ensuring that the corporate interests are served and the objectives achieved.
7. Accountability:
The assignment of specific and appropriate responsibility, the recognition of measurable expectations by
all concerned parties, and the alignment of decision-making between areas of responsibility and where
the impact of the decisions will be felt.
8. Workable Approach and Execution Model:
An approach that makes sense relative to the task, with a supporting environment modeled after a
proven approach.
9. IT Capacity to Execute:
The ability to perform all the IT tasks required by the project, including the skills, tools, processes, and
management capability.
10. Enterprise Capacity to Execute:
The ability of the enterprise to perform all the tasks required by the endeavor, in areas outside of IT,
including the ability to make decisions within tight time constraints.
11. Enterprise Ability to Implement and Operate:
The transformation elements and their related business processes operationally absorb the changes
arising from implementation.

44. PERFORMANCE SCORECARDS

45. PROCESS MAPPING
BUSINESS DEFINITION MATRIX
MANDATE STAKEHOLDERS FUNCTIONS BUSINESS ENTITY PRODUCTS CONTROLS
Core Functions
Special Functions
BUSINESS ENTITY BUSINESS LOCATIONS PERFORMANCE
OBJECTIVES
PROCESS NAME RELATIONSHIPS
INFORMATION REQUIREMENT MAPPING
BUSINESS
ENTITY
PROCESS NAME INFORMATION
SOURCE
INFORMATION
CAPTURE FORM
PROCEDURE RULES &
POLICIES
INFORMATION
REPORTING
FORM
INFORMATION
CUSTOMER
PROCESS NAME: BUSINESS ENTITY:
SOURCE INPUT ENTRY
REQUIREMENTS
TASKS EXIT
REQUIREMENTS
OUTPUT CUSTOMER
VALIDATION AND VERIFICATION REQUIREMENTS

46. 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: His 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.

48. DATA AND APPLICATION DESIGN
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 in data
model)
A number associated with the data element name for use in 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 (e.g. 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, e.g. 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
field (Y/N); Conditional Field (C); or a “null”
field
Required fields (Y) must be populated. Conditional fields (C) must be
populated when another related field is populated (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.

49. APPLICATION DESIGN
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

50. 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 Definition
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.
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.
Post conditions Describe the state of the system at the conclusion of the use case execution. Number
each post condition. Examples:
1.Document contains only valid SGML tags.
2.Price of item in database has been updated with new value

51. 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 Determined) that must be resolved. Identify who will resolve each issue, the due
date, and what the resolution ultimately is.

52. INFORMATION SECURITY RISK ASSESSMENT
Risk assessment is designed to realize the following
• Exposed the unnoticed Weaknesses
• Exposed the Risks
• Staff are eager to fix the Risks
• Research activities to secure became evident and high
The risk assessment process in compliance to ISO27001
The information security assessment must define the risk assessment factors:
1. Asset Value
2. Threat
3. Vulnerability
4. Control

53. 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, and 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
HUMAN FACTORS
Many techniques used to compromise systems are based on deceptive 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.

54. TECHNOLOGY CONFIGURATION
OMPONENTS CONFIGURATION ITEMS SPECIFICATIONS
Hardware Platforms
Operating System
Application System
Database System
Network & Communication
Security System
Enterprise System Management
Development Methodologies
Standards
Interoperatibility

55. PART 4: E-SERVICES STRATEGIC PLANNING METHODOLOGY
At the end of this module, the participants are able
1. To create the performance baseline to justify the value of e-services to transform the quality of
performance, people, process, information and technology.
2. To define change requirements and roadmap that enables the alignment of e-services to the
strategic vision, mission, and performance goals of the agency.
3. To draft the E-Services Strategic Plan

56. STRATEGIC ALIGNMENT MODEL
(Venkatraman,HendersonandOldach)
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
alignmentbetweenthebusinessandITdomains.
StrategyExecution ThisperspectiveviewsthebusinessstrategyasthedriverofbothorganizationdesignchoicesandthelogicofISinfrastructure
(the classic, hierarchical view of strategicmanagement). Top Management is strategy formulator, IS Management is strategy
implementer.[Arrow1]
TechnologyPotential Thisperspectivealsoviewsthebusinessstrategyasthedriver,howeverinvolvesthearticulationofanITstrategytosupportthe
chosenbusinessstrategyandthecorrespondingspecificationoftherequiredISinfrastructureandprocesses.
The top management should provide the technology vision to articulate the logic and choices pertaining to IT strategy that
wouldbestsupportthechosenbusinessstrategy,whiletheroleoftheISmanagershouldbethatofthetechnologyarchitect-
who efficiently and effectively designs and implements the required IS infrastructure that is consistent with the external
componentofITstrategy(scope,competencesandgovernance).[Arrow2]
CompetitivePotential ThisalignmentperspectiveisconcernedwiththeexploitationofemergingITcapabilitiestoimpactnewproductsandservices
(i.e., business scope), influence the key attributes of strategy (distinctive competences), as well as develop new forms of
relationships(i.e.businessgovernance).Unlikethetwo previousperspectivesthatconsideredbusinessstrategyasgiven(ora
constraint for organizational transformation), this perspective allows the modification of business strategy via emerging IT
capabilities.
Thespecificroleofthetopmanagementtomakethisperspectivesucceedisthatofthebusinessvisionary,whoarticulateshow
theemergingITcompetencesandfunctionalityaswellaschanginggovernancepatternsintheITmarketplacewouldimpact
thebusinessstrategy.TheroleoftheISmanager,incontrast,isoneofthecatalyst,whoidentifiesandinterpretsthetrendsinthe
ITenvironmenttoassistthebusinessmanagerstounderstandthepotentialopportunitiesandthreatsfromanITperspective.
[Arrow3]
ServiceLevel ThisalignmentperspectivefocusesonhowtobuildworldclassIT/ISorganizationwithinanorganization.Inthisperspective,the
roleofbusinessstrategyisindirect.Thisperspectiveisoftenviewedasnecessary(butnotsufficient)toensuretheeffectiveuseof
ITresourcesandberesponsivetothegrowingandfast-changingdemandsoftheend-userpopulation.
Thespecificroleofthetopmanagementtomakethisperspectivesucceedisthatoftheprioritizer,whoarticulateshowbestto
allocatethescarceresourcesbothwithintheorganizationaswellasintheITmarketplace(intermsofjointventures,licensing,
minorityequityinvestments,etc.).TheroleoftheISmanager,incontrast,isoneofbusinessleadership,withthespecifictasksof
makingtheinternalbusinesssucceedwithintheoperatingguidelinesfromthetopmanagement.[Arrow4]