E-GOVERNMENT SERVICE MANAGEMENT PRACTITIONER'S NOTE:

ENTERPRISE ARCHITECTURE

www.onecitizen.net
Version 1.2 2009

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

INTRODUCTION:
The practitioner's note presents lesson learned from various public documents that provide the
framework, methods, and templates in doing enterprise architecture modeling. It demonstrates
the principle of not-to-reinvent the wheel by improving from existing practices, guidance and
standards.
The knowledge items of the practitioner's note are logically structured to support the learning
needs of those who attend the e-government management training. It guides the government
leaders and workers to build their knowledge, decision points, and action items in communicating
and doing enterprise architecture modeling in their organization. The aggregated information
provides the empowering content to benchmark current practices, and to make improvement to
the knowledge resources of the organization on the disciplines of enterprise architecture.
The practitioner's note provides essential concepts, procedures, templates and software that are
used by the note-taker in assisting some government and non-government organizations to define
the enterprise architecture. It includes evaluated content considered by the e-government
management training participants to be usable to communicate and implement enterprise
architecture in their organizations.
Enterprise architectures provides the living documents called reference models to make the
organization to effectively and efficiently managed recordings, expectations, processes,
configurations, metrics, work around, changes, relationships, collaborations, interchanges,
requirement tracing, control, and marketing of the business operation. It provides a singlereference-of-truth to properly lead the business process improvement and the optimal valueadded integration of technology in the business operation of the organization.
The enterprise architecture tools provide the principles, methods, vocabulary, conventions,
presentation objects, procedures, software, repositories, and artifacts in order to draw the
reference models of the enterprise that speaks of its business, information, technology, and
people.
The drawn models are kept in the digital repository and made accessible anytime when business
strategic planning, performance evaluation, and IC solution development are initiated by the
organization. It is reconfigured when new understanding about the business, information,
technology, and people are brought in by the improved enterprise strategy, new program and
projects, and enterprise metrics.
The Doing the Enterprise Architecture process requires the collaborative engagement between
the minds and practitioners running the business processes and those delivering the technology
services. It is to properly compose the reference models of the organization that will make the
business functional units and ICT service providers to realize the performance objectives through
information and communication technology.
The practitioner note is an open content project. The note-taker DOES NOT REPRESENT the
aggregated framework and brand names mentioned in this open content project.
The cited documents, products and services are presented to freely promote discovery and
informed decision on the use of information and communications technology standards,
methodology and software to realize the goals of effectively deliver the e-government services to
all.
The users must exercise DUE DILIGENCE in appraising the applicable use of the concepts,
framework, methodology, template and software in their organizational setting.
The users are FREE TO USE the digital copy of this open document as long as proper attribution, no
modification is done and respect of the copyrights limitations and acceptable use policy of the
cited materials are observed.

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

Table of Contents
INTRODUCTION:........................................................................................2
Part 1: Enterprise Architecture Framework........................................................4
1.0 Health Check on the Practice of Enterprise Architecture.........................................4
1.1 Enterprise Architecture..................................................................................4
1.3 Importance of Enterprise Architecture...............................................................5
1.4. Enterprise Architecture Principles....................................................................6
1.5 Questions of Enterprise Architecture.................................................................7

Part 2: Doing Enterprise Architecture..............................................................9

2.1 Enterprise Architecture Components .................................................................9
2.2 Enterprise Architecture Development Model.......................................................11
2.3 Enterprise Business Process Analysis.................................................................13
2.4 Business Process Mapping Worksheet................................................................15
2.6 Enterprise Information Maturity Model..............................................................20
2.7 Enterprise Information Data Analysis................................................................21
2.8 Enterprise Software Readiness Assessment.........................................................27
2.9 Enterprise Technology Configuration................................................................27
2.10 Information Security Model..........................................................................28
2.11. Enterprise Architect..................................................................................29
2.12 Enterprise Architecture Capability Maturity Model..............................................30
2.13 Modeling Software.....................................................................................31
2.14 Project Definition and Workplan for Enterprise Architecture Project........................32

ABOUT THE NOTETAKER:............................................................................39

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

Part 1: Enterprise Architecture Framework

1.0 Health Check on the Practice of Enterprise Architecture
Does your agency maintains a blueprint or matrix of all running systems, showing how
they inter-operate, and which technology they are using?

YES

NO

NOT
SURE

Can your agency readily presents the professional and business user matrix
dovetailed to their requirements, and to 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, and how data is store?

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 start a project do you have an enterprise architecture blueprint,
which is used 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 and
tools, technical references that both IT and Business have to use, or you can use
whatever technology you want?

YES

NO

NOT
SURE

1.1 Enterprise Architecture

Enterprise architecture provides the fundamental framework to document, and to understand the
aligned management of the business processes and information technology in the operation of the
organization. It offers the thinking and modeling methods to constitute both the baseline and
directive for integrative change in the performance of the organization through information and
communications technology.
Enterprise architecture makes the organization ask the proper questions, categorize baseline
knowledge, analyze information on gaps and possibilities, and draw integrative models that
comprehensively define the business improvement requirements and solution strategy of the
organization.
The enterprise architecture provides the logically structured activities to make the organization
realize the reference models that contextualize the proper integration of ICT solutions and
services in the delivery of the business results intended by the stakeholders.
Enterprise architecture provides the re-usable reference models to ensure integral and managed
change in the performance, business, information and technology domains of the organization
-a.k.a. Enterprise. It brings about the integrative standards to align the silos of process, data,
application, and technology to the efficiency, reliability, effectivity, immediacy, transparency,
accountability, interoperability, security and quality goals of the organization.

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

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.
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.3 Importance of Enterprise Architecture

Schekkerman, J. (2005). Trends in Enterprise Architecture, Institute for Enterprise Architecture
Development, white paper.
DESCRIPTIONS

VALUE INDICATORS
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.

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

1.4. Enterprise Architecture Principles

The process definition of composing the enterprise architecture confronts the organization to
make critical decisions . The options that emerge from the drawn enterprise architecture must be
guided by shared principles in the organization.
Here are some sample of enterprise architecture principles derived from various sources. They
are meant to initiate the thinking process of defining the principles to be embodied in the
formulation of the enterprise architecture.

PRINCIPLES

DESCRIPTION

STRATEGIC DIRECTION

Decision is aligned with the organizations strategic direction,

furthering measurable improvement in performance, achievement of
business needs, and citizen/customer satisfaction.

STAKEHOLDER ALIGNMENT

Decision reflects the best interests of key stakeholders, and complies

with applicable legal mandates and federal directives.

ELIMINATE GAPS

Decision eliminates a gap in capability required by the organization to

achieve its strategic goals.

MINIMIZE COST

Decision reduces costs and burden while maintaining and/or improving

quality and security.

STREAMLINE

Decision eliminates or prevents non-value added activities.

ELIMINATE DUPLICATION

Decision prevents or removes unnecessary redundancy, resulting in

consolidation of best-in-class standards and components that are
consistent, reused and shared.

BROADEN ACCESSIBILITY

Decision expands availability of assets, making them easier to use and

understand and more readily accessible to a broader set of
stakeholders.

PROVIDE FLEXIBILITY

Decision reduces friction or resistance to change, thereby expediting

the organizations ability to rapidly and completely scale and respond
to forces of change.

ENSURE INTEROPERATIBILITY

Decision enhances integration and connectedness.

ENHANCE RELIABILITY

Decision enhances stability, quality, and confidence that the result is

available and correct.

TIGHTEN SECURITY

Decision enhances security and privacy.

CONTROLLED

Changes are managed and controlled to expedite development,

minimize disruption and risk, and are sequenced to maintain order.

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

1.5 Questions of Enterprise Architecture

Zachman Enterprise Framework offers the interrogatives and perspectives to define and model the
enterprise and its components. It is developed by John A Zachman, the former IBM engineer who
originated the framework for enterprise architecture. He is the CEO of ZIPA, the organization
advancing the art of enterprise architecture.
The Zachman Enterprise Architecture Framework provides the thinking matrix to establish the
views, artifacts, and relationship behind the between systems, processes, data, people, rules,
business units, and products of the enterprise.
The outcome of using the Zachman Enteprise Framework is a comprehensive description of the
enterprise components to logically define the performance, people, business, information and
technology requirements of the organization.
The framework presents the logical structure to classify and organize the descriptive
representations of the enterprise that are significant to understand and perform integrative
management and change of business results. It uses the grid model to present the six questions to
describe the enterprise, they are the following:
1. Inventory The What of the Enterprise
2. Process The How of the Enterprise
3. Network The Where of the Enterprise
4. Organization The Who of the Enterprise
5. Timing The When of the Enterprise
6. Motivation - The Why of the Enterprise
The responses to the questions are derived from the perspectives of the following enterprise
architecture stakeholders.
1. Strategist Defines the scope of the enterprise.
2. Executive Defines the business of the enterprise.
3. Architects Describes the systems of the enterprise.
4. Engineers Defines Technology of the enterprise.
5. Technician Identifies the components of the enterprise.
6. Worker Identifies the operation of the enterprise.

WHAT

HOW

WHERE

WHO

WHEN

WHY

SCOPE

Strategist

BUSINESS

Executive

SYSTEM

Architects

TECHNOLOGY

Engineers

COMPONENT

Technician

OPERATION

Worker
Inventory

Process

Network

Open Practitioner's Note on Enterprise Architecture

Organization

Timing

Motivation

www.onecitizen.net

Enterprise Architecture Components Grid Derived from Zachman Framework

WHAT

HOW

SCOPE

List of things and

Inventory types
important to the
enterprise
domains.

Identification of
scope process
-expressed in
terms of process
types in doing
the business.

Identification of
scope network
-expressed in
terms of
locations where
the business
operates.

BUSINESS

List of business
entity and
relationship

Identification of
the process
model that
describes the
transformation
of input to
process, result,
and entry to
other
peerprocess.

SYSTEM

List of system
entity and
relationship

List of systems
process that
transforms
systems input

TECHNOLOGY

List of technology List of

List of technology List of technology
entity and
specification
location and
role and work
relationship
technology
connection
process and
technology input

List of technology List of

cycle and
technology
moment
means and ends

COMPONENT

Inventory
Configuration

OPERATION

Operation entity Operation

and relationships transform
operation input

Proess
Configuration

WHERE

WHO

WHEN

WHY

Identification of
scope
organization
experessed in
terms of
organization and
stakeholders
important to the
business.

Identification of
scope time
expressed in
terms of events
important to the
business.

Identification of
scope motivation
expressed in
terms of
motivation types
like mandate,
policy
directives,
business goals
and strategies.

Identification of
the network
model which
describes the
business location
and its relation
to other peer
business
locations.

Identificaiton of
the organization
model which
relates business
role to business
work, and to
other peer
business roles.

Identification of
the timing model
which relates a
business cycle to
a business
moment and
another peer
business cycles.

Identification of
the business
ends and
business means
that motivates
the organization

List of system
location and
connection.

List of
organizational
representation in
terms of business
role and business
work

List of the
systems life
cycle, timing
triggers and
calendars

List of systems
means and ends
in terms of
systems ules and
policies

Network
Configuration

Organization
Configuration

Timing
Configuration

Motivation
Configuration

Operation
location and
connection

Organization role
and work

Operation cycle
and moments

Operation ends
and means

Find more information about Zachman Enterprise Architecture framework at www.zifa.com.

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

Part 2: Doing Enterprise Architecture

2.1 Enterprise Architecture Components
The organizational enterprise architecture provides the core reference models to align the
use of information and communications technology to the business or service strategy of the
organization. It is to improve productivity and service results, to rationalize investment and
enterprise planning, to streamline enterprise operations, to realize services integration, and to
reduce the time to market of new products and services. It documents the organizational
blueprint to further enhance understanding, innovation, synchronization, metrics, and control of
the business or service delivery operation.
The enterprise architecture captures, draws, analyzes, improves, and implements the
content of the organization's architectural reference models.

PERFORMANCE
-Performance Metrics
-Balance Score Card

BUSINESS
-Business Reference Model
-Business Process Maturity Model

INFORMATION
-Data Reference Model
-Application Reference Model
-Information Maturity Model

TECHNOLOGY
-Technical Reference Model
-Security Maturity Model
-Services Maturity Model

PEOPLE
-Capability Maturity Model
-Governance Model

Open Practitioner's Note on Enterprise Architecture

1.Performance Reference Model standardized

framework to measure the performance of ICT
investment and their contribution to the business or
program performance.
2. Business Architecture speaks of
the business reference model on what
the business is, its customers, mandate, strategy,
funds, returns, competency, partners, functions,
process, products, locations, cycles, risks ...
3. Information Architecture speaks of the
business data reference model and the
application reference model to produce the needed
information of the business
transactions, compliance, intelligence, product
delivery, and third-party interfaces ...
4. Technology Architecture speaks of the
Technical reference model that defines the
development and operationl platforms of business
technology solutions related to OS, application,
database, communication, security, data and file
standards. It includes references and methods on data
interoperatibility, usability, readiness, security, service
maturity etc...
5. People speaks of the people capability
maturity references and governance model to support
the implementation pre-requisites of the enterprise
architecture. It includes competency standards and
capacity building program ...

www.onecitizen.net

Enterprise Architecture Components Elaboration

BUSINESS ARCHITECTURE

Understanding how the business is

Identify Business Model Business
running, what are its needs, what is
Functions and WHO Performs the
missing and what needs to be changed or Function.
improved.
Definition of Business Goals and
It defines the business strategy,
Goals, the supporting processes,
governance, organization, and key
workflow, policies and procedures.
business processes of the organization.
Assessment of the Current State and
Description of the Future State.
How are the goals and objectives
implemented through the ICT
Solutions and the supporting technical
infrastructure.

DATA ARCHITECTURE

It defines how data is stored, 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

APPLICATION ARCHITECTURE

Data Element
Data Flow Diagram
Entity Relationship
Relational Structure
Data Physical Storage
Data Interoperatibility
Data Standard
Supported Informational Themes

Application architecture consists of

logical systems that manage the data
objects in the data architecture and
support the business functions in the
Business Architecture.

Current inventory of applications and

components.

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

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.

PEOPLE

It describes the roles and responsibilities

to support the business of the
organization. It defines the set of
knowledge and skils to enable the
performance requirements. It provides
the references on the capability building
standards espoused by the organization.

Evolving applications and components

needed to fulfill for the business
units.

Hardware Platform
Operating System
Application System
Database System
Network & Communication System
Security System
Enterprise Systems Management
Development Methods
It describes the hardware, software and Technical Standards
network infrastructure needed to support Interoperatability References
the deployment of core, mission-critical
applications.

Open Practitioner's Note on Enterprise Architecture

Competency Standards
Organizational Chart
Training Program
Instructional Design
Job Performance Evaluation

www.onecitizen.net

2.2 Enterprise Architecture Development Model

The Open Group Architecture Framework (TOGAF) is a framework - a detailed method and a set of
supporting tools - for developing an enterprise architecture. It may be used freely by any
organization wishing to develop an enterprise architecture for use within that organizatio.
Here is TOGAF version 9 developmental model in doing enterprise architecture. It identifies the
phases and the objectives to be achieve in doing each of the defined developmental stage.
PHASES
Preliminary Phase

OBJECTIVES

A.
Architecture
Visioning

To review the organizational context for conducting enterprise architecture

To identify the sponsor stakeholder(s) and other major stakeholders impacted by the
business directive to create an enterprise architecture and determine their requirements
and priorities from the enterprise, their relationships with the enterprise, and required
working behaviors with each other
To ensure that everyone who will be involved in, or benefit from, this approach is
committed to the success of the architectural process
To enable the architecture sponsor to create requirements for work across the affected
business areas
To identify and scope the elements of the enterprise organizations affected by the
business directive and define the constraints and assumptions (particularly in a
federated architecture environment)
To define the "architecture footprint" for the organization - the people responsible for
performing architecture work, where they are located, and their responsibilities
To define the framework and detailed methodologies that are going to be used to
develop enterprise architectures in the organization concerned (typically, an adaptation
of the generic ADM)
To confirm a governance and support framework that will provide business process and
resources for architecture governance through the ADM cycle; these will confirm the
fitness-for-purpose of the Target Architecture and measure its ongoing effectiveness
(normally includes a pilot project)
To select and implement supporting tools and other infrastructure to support the
architecture activity
To define the architecture principles that will form part of the constraints on any
architecture work
To ensure that this evolution of the architecture development cycle has proper
recognition and endorsement from the corporate management of the enterprise, and the
support and commitment of the necessary line management
To define and organize an architecture development cycle within the overall context of
the architecture framework, as established in the Preliminary phase
To validate the business principles, business goals, and strategic business drivers of the
organization and the enterprise architecture Key Performance Indicators (KPIs)
To define the scope of, and to identify and prioritize the components of, the Baseline
Architecture effort
To define the relevant stakeholders, and their concerns and objectives
To define the key business requirements to be addressed in this architecture effort, and
the constraints that must be dealt with
To articulate an Architecture Vision and formalize the value proposition that
demonstrates a response to those requirements and constraints
To create a comprehensive plan that addresses scheduling, resourcing, financing,
communication, risks, constraints, assumptions, and dependencies, in line with the
project management frameworks adopted by the enterprise (such as PRINCE2 or PMBOK)
To secure formal approval to proceed
To understand the impact on, and of, other enterprise architecture development cycles
ongoing in parallel

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

B.
Business
Architecture
Defintion

C:
Information
Systems
Architecture
Definition
Data Architecture
and
Application
Architecture
Modeling

D.
Technology
Architecture
Definition

E.
Opportunities and
Solutions
Identification

F.
Migration Planning

To describe the Baseline Business Architecture

To develop a Target Business Architecture, describing the product and/or service
strategy, and the organizational, functional, process, information, and geographic
aspects of the business environment, based on the business principles, business goals,
and strategic drivers
To analyze the gaps between the Baseline and Target Business Architectures
To select and develop the relevant architecture viewpoints that will enable the architect
to demonstrate how the stakeholder concerns are addressed in the Business Architecture
To select the relevant tools and techniques to be used in association with the selected
viewpoints
The objective here is to define the major types and sources of data necessary to support
the business, in a way that is:
Understandable by stakeholders
Complete and consistent
Stable
The objective here is to define the major kinds of application system necessary to
process the data and support the business.
It is important to note that this effort is not concerned with applications systems design.
The goal is to define what kinds of application systems are relevant to the enterprise,
and what those applications need to do in order to manage data and to present
information to the human and computer actors in the enterprise.
The applications are not described as computer systems, but as logical groups of
capabilities that manage the data objects in the Data Architecture and support the
business functions in the Business Architecture. The applications and their capabilities
are defined without reference to particular technologies. The applications are stable and
relatively unchanging over time, whereas the technology used to implement them will
change over time, based on the technologies currently available and changing business
needs.
The Technology Architecture phase seeks to map application components defined in the
Application Architecture phase into a set of technology components, which represent
software and hardware components, available from the market or configured within the
organization into technology platforms.
As Technology Architecture defines the physical realization of an architectural solution,
it has strong links to implementation and migration planning.
Technology Architecture will define baseline (i.e., current) and target views of the
technology portfolio, detailing the roadmap towards the Target Architecture, and to
identify key work packages in the roadmap. Technology Architecture completes the set
of architectural information and therefore supports cost assessment for particular
migration scenarios.
To review the target business objectives and capabilities, consolidate the gaps from
Phases B to D, and then organize groups of building blocks to address these capabilities
To review and confirm the enterprise's current parameters for and ability to absorb
change
To derive a series of Transition Architectures that deliver continuous business value (e.g.,
capability increments) through the exploitation of opportunities to realize the building
blocks
To generate and gain consensus on an outline Implementation and Migration Strategy
To ensure that the Implementation and Migration Plan is co-ordinated with the various
management frameworks in use within the enterprise
To prioritize all work packages, projects, and building blocks by assigning business value
to each and conducting a cost/business analysis
To finalize the Architecture Vision and Architecture Definition Documents, in line with
the agreed implementation approach
To confirm the Transition Architectures defined in Phase E with relevant stakeholders
To create, evolve, and monitor the detailed Implementation and Migration Plan providing
necessary resources to enable the realization of the Transition Architectures, as defined
in Phase E

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

G.
Implementation
Governance

To formulate recommendations for each implementation project

To govern and manage an Architecture Contract covering the overall implementation and
deployment process
To perform appropriate governance functions while the solution is being implemented
and deployed
To ensure conformance with the defined architecture by implementation projects and
other projects
To ensure that the program of solutions is deployed successfully, as a planned program of
work
To ensure conformance of the deployed solution with the Target Architecture
To mobilize supporting operations that will underpin the future working lifetime of the
deployed solution

H.
Architecture
Change
Management

To ensure that baseline architectures continue to be fit-for-purpose

To assess the performance of the architecture and make recommendations for change
To assess changes to the framework and principles set up in previous phases
To establish an architecture change management process for the new enterprise
architecture baseline that is achieved with completion of Phase G
To maximize the business value from the architecture and ongoing operations
To operate the Governance Framework

Find more about The Open Group Architecture Framework in www.togaf.org.

2.3 Enterprise Business Process Analysis

Business Reference Model Definition

Business reference model describes the high level nature and components of the business.
Business Reference Model Name: What is the standard name of the business in relation to its reference
model?

Industry Segment:

What industry sector the business is identified? (retail, manufacturing,

education, regulatory, etc.)

Business Domain Scope:

What are the scope category of the business area in terms of the primary
functions to fulfill? (ordering, delivery, billing, etc.)

Business Area:

What are the collection of business process (tasks) in the defined scope
category? (order registration, order review, order reply, order confirmation,
etc..)

Business Outcomes:

What are the expected outcomes from the collection of business process?
(Efficient transaction to receive, to approve, to communicate, and to
realize customer's order.)

Business Organizational Tree

What are the business organization components and their entity

relationships?

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

Business Area Definition

Business area is the category to speak about the group of business processess that fulfills a primary
business function.
Business Area Name:

What is the standard name to assign to the business area that associate it properly to
the business reference model?

Function Category:

What is the primary function of the business organization being served by the business
area?

Description:

What describes briefly the nature and value of the business area in relation to the
business function?

Objective:

What are the specific outcomes expected from the business area?

Opporunity:

What kind of business opportunity being addressed by the business area?

Scope

What are the included and excluded activities, relationship, and information of the
defined business area?

Boundary

What are the parameters of business entity relationship in terms of users,

organization, data, location, etc.. that exist in the business area?

References

What are internal and external documents that are relevant to the activities of the
business area? (Documents related to standards, regulation, policy references,
agreements, interface requirements}

Constraints

What are the given constraints of the business area that define the way it conducts
the business? (full on-line, external manual reporting, members only, age and income
limits, etc...)

Stakeholders

Who are the people and organization whose knowledge and interest
are important to the definition and activities of the business area?

Process Area

What are the grouping of tasks and activities to be executed by the business area to
realize its business requirements and performance objectives?

Business Performance Assessment

Goals Question and Metrics (GQM) of Business
Tool to measure and report the business efficiency and effectivity.
Conceptual/Goal

Set of objectives that represent various viewpoints relative to specific business

environment

Operational/Question

Set of questions about the goal that focuses characterizing the assessment or achievement
of a specific goal. The answer to these questions determine the goal achievement

Quantitative/Metrics

Set of measurement that answer the questions.

GQM ANALYSIS PART

DESCRIPTION

Critical Success Factor

What are the attributes of succesful performance?

Key Performance Indicator

What are the means to measure achievement of success?

Object

What is the Object (product, process, service, etc.) under analysis?

Purpose

What is the motivation behind the analysis of the object?

Focus

Which quality attributes of the object is under analysis

Environment

Under what context is the analysis to occur

Viewpoint

Whose perspective does the analysis of the object reflect

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

Worksheet 01: Business GQM Analysis Worksheet

Business Domain:
Business
Process

Business Area:

Critical
Success
Factor

Key
Performance
Indicators

Object

Purpose

Focus

Environment

Viewpoint

Balanced Scorecard
A balanced scorecard uses financial data, operational measures, customer satisfaction, internal
processes and the organization's innovation and improvement activities - indicators of future
financial performance - to assess business performance. (Source: Management and Technology
Dictionary) (2) A scorecard is an evaluation device, usually in the form of a questionnaire, that
specifies the criteria customers will use to rate your business's performance in satisfying their
requirements. (Source: American Society for Quality - Quality Glossary)
The Question of Balanced Score Card:
POINT OF VIEWS

INTERROGATIVES

Financial Perspective

To succeed financially how should we appear to our stakeholders?

Customer Perspective

To achieve our vision, how should we appear to our customers?

Business Process Perspective

To satisfy our stakeholders and customers, what business processes must

we excel at?

Learning and Growth

Perspective

To achieve our vision, how will we sustain our ability to change and
improve.

Worksheet 02: Balance Score Card

Download and view a free balance scorecard template to get started: www.exinfm.com

2.4 Business Process Mapping Worksheet

Business mapping and analysis involve he 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.
Worksheet 01: Business Definition Matrix

MANDATE

STAKEHOLDERS

FUNCTIONS

BUSINESS
ENTITY

PRODUCTS

CONTROLS

Core Functions

Special Functions

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

BUSINESS ENTITY

BUSINESS
LOCATIONS

PERFORMANCE
OBJECTIVES

PROCESS NAME

RELATIONSHIPS

Worksheet 02: Information Requirement Mapping Matrix

BUSINESS
ENTITY

PROCESS
NAME

INFORMATION
SOURCE

INFORMATION
CAPTURE
FORM

PROCEDURE

PROCESS NAME:
SOURCE

RULES &
POLICIES

INFORMATION
REPORTING
FORM

INFORMATION
CUSTOMER

BUSINESS ENTITY:
INPUT

ENTRY
REQUIREMENTS

TASKS

EXIT
REQUIREMENTS

OUTPUT

CUSTOMER

VALIDATION AND VERIFICATION REQUIREMENTS

Worksheet 3: Process Mapping Swim Lane Matrix

Swim lane process map is similar to a flow chart, however it shows the process within the context
of the process organization structure. It defines the process and who performs the process steps.
The processes are flowed within a logical lane, and the change of lanes in each process will show
the hands-offs emanating from the next phases of the process. It clears coordination and
communication problems in the execution of the process.

FUNCTION UNIT:

PROCESS NAME:

ACTOR

TASKS LANE

TASK LANE

Actor 1

Step 1 - Start

Step 4

Actor 2

Step 2

Step 5

Actor 3

Step 3

Open Practitioner's Note on Enterprise Architecture

TASKS LANE
Step 6 -End

www.onecitizen.net

Process Swim Lane Components

Lanes:

The drawn boundaries to contain the logical process flow, and to indicate hands-off
of steps and requirements to the next phase of the logical process.

Actors:

The people, groups, teams, etc, who are performing the steps identified within the
process

Process:

he actual process and flow that is being tracked through its identified progression
steps.

Phases:

These might reflect the phases of the project, different areas of the project, or any
secondary set of key elements that the process flow needs to traverse to
successfully complete this process.

Symbols:

These are the physical symbols used to graphically represent what is happening in
any given step of the process.

Find more information on business process management notation at www.omg.org.

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

Business Use Case

-Defintion by TechTarget
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.

Use Case Identification Elements by Karl Weiger - www.processimpact.com.

COMPONENTS

DESCRIPTIONS

Use Case ID

Give each use case a unique integer sequence number identifier. Alternatively, use a
hierarchical form: X.Y. Related use cases can be grouped in the hierarchy.

Use Case Name

State a concise, results-oriented name for the use case. These reflect the tasks the user
needs to be able to accomplish using the system. Include an action verb and a noun. Some
examples:

View part number information.

Manually mark hypertext source and establish link to target.

Place an order for a CD with the updated software version.

Use Case History

Created By:
Supply the name of the person who initially documented this use case.
Date Created:
Enter the date on which the use case was initially documented.
Last Updated By:
Supply the name of the person who performed the most recent update to the use case
description.
Date Last Updated:
Enter the date on which the use case was most recently updated.

Use Case Defintion

Actors

An actor is a person or other entity external to the software system being specified who
interacts with the system and performs use cases to accomplish tasks. Different actors often
correspond to different user classes, or roles, identified from the customer community that
will use the product. Name the actor that will be initiating this use case and any other actors
who will participate in completing the use case.

Trigger

Identify the event that initiates the use case. This could be an external business event or
system event that causes the use case to begin, or it could be the first step in the normal
flow.

Description

Provide a brief description of the reason for and outcome of this use case, or a high-level
description of the sequence of actions and the outcome of executing the use case.

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:

Users identity has been authenticated.

Users computer has sufficient free memory available to launch task.

Postconditions

Describe the state of the system at the conclusion of the use case execution. Number each
postcondition. Examples:
1. Document contains only valid SGML tags.
2. Price of item in database has been updated with new value

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

Normal Flow

Provide a detailed description of the user actions and system responses that will take place
during execution of the use case under normal, expected conditions. This dialog sequence
will ultimately lead to accomplishing the goal stated in the use case name and description.
This description may be written as an answer to the hypothetical question, How do I
<accomplish the task stated in the use case name>? This is best done as a numbered list of
actions performed by the actor, alternating with responses provided by the system. The
normal flow is numbered X.0, where X is the Use Case ID.

Alternative Flows

Document other, legitimate usage scenarios that can take place within this use case
separately in this section. State the alternative flow, and describe any differences in the
sequence of steps that take place. Number each alternative flow in the form X.Y, where
X is the Use Case ID and Y is a sequence number for the alternative flow. For example,
5.3 would indicate the third alternative flow for use case number 5.

Exceptions
Describe any anticipated error conditions that could occur during execution of the use case,
and define how the system is to respond to those conditions. Also, describe how the system
is to respond if the use case execution fails for some unanticipated reason. If the use case
results in a durable state change in a database or the outside world, state whether the
change is rolled back, completed correctly, partially completed with a known state, or left in
an undetermined state as a result of the exception. Number each alternative flow in the
form X.Y.E.Z, where X is the Use Case ID, Y indicates the normal (0) or alternative (>0)
flow during which this exception could take place, E indicates an exception, and Z is a
sequence number for the exceptions. For example 5.0.E.2 would indicate the second
exception for the normal flow for use case number 5.

Includes

List any other use cases that are included (called) by this use case. Common functionality
that appears in multiple use cases can be split out into a separate use case that is included
by the ones that need that common functionality.

Priority

Indicate the relative priority of implementing the functionality required to allow this use
case to be executed. The priority scheme used must be the same as that used in the
software requirements specification.

Frequency of Use

Estimate the number of times this use case will be performed by the actors per some
appropriate unit of time.

Business Rules

List any business rules that influence this use case.

Special
Requirements

Identify any additional requirements, such as nonfunctional requirements, for the use case
that may need to be addressed during design or implementation. These may include
performance requirements or other quality attributes

Assumptions

List any assumptions that were made in the analysis that led to accepting this use case into
the product description and writing the use case description.

Notes and Issues

List any additional comments about this use case or any remaining open issues or TBDs (To Be
Determineds) that must be resolved. Identify who will resolve each issue, the due date, and
what the resolution ultimately is.

Sample Use Case Modeling

Find more about UML modeling and notation at www.uml.org.

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

2.6 Enterprise Information Maturity Model

Learn more about information management methodology at www.mike2.openmethodology.org.

MATURITY STAGE

DESCRIPTIONS

LEVEL 1
Aware

The organisation 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
Reactive

The organisation 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
Proactive

The organisation 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
Managed

The organisation 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
organisation has many mature and best-in-class practices and utilizes audits
to ensure compliance across all projects.

LEVEL 5
Optimized

The organisation considers information to be as much an enterprise asset as

financial and material assets. A level 5 organisation has best-in-class
information management practices that are utilized across all enterprise
projects. The distinguishing characteristic of a level 5 organisation is the
focus on continuous improvement. At level 5, all data management
practices and assets are regularly measured and the results are analysed as
the basis for process improvement.

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

2.7 Enterprise Information Data Analysis

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 subdomains 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 (eg. Cellular Phone Number might be assigned a
field name of Cell_Ph_No).

Data Element Definition

Description of the meaning of the data element

Data Element Unit of Measure (uom)

Scientific or other unit of measure that applies to the data

element.

Data Element Precision

The level to which the data will be reported, eg 1 mile plus or

minus .001 mile

Data Element Data Type

The type of data (e.g. Characters, Numeric, Alpha-numeric,

date, list, floating point).

Data Element Size and Decimalization

The maximum field length that will be accepted by the

database together with any decimal points (e.g. 30(2)) refers
to a field length of 30 with 2 decimal points).

Field Constraints: Data Element is a

required 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.

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

Data Flow Diagram

A data flow diagram is a logical model of the flow of data through a system that shows how the
systems boundaries, processes, and data entities are logically related.

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

Data Flow Diagram

Data flow diagrams illustrate how data is processed by a system in terms of inputs and outputs.

A data flow diagram

Data Flow Diagram Notations
You can use two different types of notations on your data flow diagrams: Yourdon & Coad or Gane &
Sarson.
Process Notations

Yourdon and Coad

Process Notations

Gane and Sarson

Process Notation

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

Process
A process transforms incoming data flow into outgoing data flow.

Datastore Notations

Yourdon and Coad

Datastore Notations

Gane and Sarson

Datastore Notations
DataStore
Datastores are repositories of data in the system. They are sometimes also referred to as
files.

Dataflow Notations

Dataflow
Dataflows are pipelines through which packets of information flow. Label the arrows with the name
of the data that moves through it.
External Entity Notations

External Entity
External entities are objects outside the system, with which the system communicates. External
entities are sources and destinations of the system's inputs and outputs.

Data Flow Diagram Layers

Draw data flow diagrams in several nested layers. A single process node on a high level diagram can
be expanded to show a more detailed data flow diagram. Draw the context diagram first, followed by
various layers of data flow diagrams.

The nesting of data flow layers

Context Diagrams
A context diagram is a top level (also known as Level 0) data flow diagram. It only contains one
process node (process 0) that generalizes the function of the entire system in relationship to
external entities.

DFD levels
The first level DFD shows the main processes within the system. Each of these processes can be
broken into further processes until you reach pseudocode.

An example first-level data flow diagram

Basic Symbols to Draw Data Flow Diagram

External Entity
The symbol represents sources of data to the system
or destinations of data from the system.

Data Flow
The symbol represents movement of data.

Data Store
The symbo represents data that is not moving
(delayed data at rest).
Process
The symbol represents an activity that transforms or
manipulates the data (combines, reorders, converts,
etc.)

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

2.8 Enterprise Software Readiness Assessment

Business Readiness Rating (BRR) is being proposed as a new standard model for rating open source
software. It is intended to enable the entire community (enterprise adopters and developers) to rate
software in an open and standardized way. The application readiness assessment framework being
provided by BRR can be used by the organization to value the acquired commercial-of-the-shelfsoftware, and to evaluate the maturity of a developed software. Learn more at www.openbrr.org.

DESCRIPTION

ASSESSMENT CATEGORIES
Functionality

How well will the software meet the average users requirements?

Usability

How good is the UI? How easy to use is the software for end-users?
How easy is the software to install, configure, deploy, and maintain?

Quality

Of what quality are the design, the code, and the tests? How complete and
error-free are they?

Security

How well does the software handle security issues? How secure is it?

Performance

How well does the software perform?

Scalability

How well does the software scale to a large environment?

Architecture

How well is the software architected? How modular, portable, flexible,

extensible, open, and easy to integrate is it?

Support

How well is the software component supported?

Documentation

Of what quality is any documentation for the software?

Adoption

How well is the component adopted by community, market, and industry?

Community

How active and lively is the community for the software?

Professionalism

What is the level of the professionalism of the development process and of the
project organization as a whole?

2.9 Enterprise Technology Configuration

COMPONENTS

ASSETS

CONFIGURATION

METRICS

STANDARDS

Hardware Platforms
Operating System
Application System
Database System
Network & Communication
Security System
Enterprise System
Management
Development Methodologies
Data and File Standards
Interoperatability
Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

2.10 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 NMs information assets. This domain comprises standards for
identification, authentication, authorization, administration, audit, and naming services.
COMPONENTS

DESCRIPTIONS

PHYSICAL SECURITY

Securing access to hardware, inventory, and disposition of physical

equipment and records.

USER SECURITY

Ensuring that users accessing data and systems are in fact who they say
they are and that they have access only to authorized resources. Functions
include the identification, authentication, and authorization of an individual,
as well as audit requirements.

APPLICATION SECURITY

ensuring that an application that accesses another application or data is

secure; includes the analysis of distributed, proxy, and middleware services.

SYSTEMS SECURITY

Overall systems security analysis, including the user, data transmission, and
the host server, as well as remote links and access from other systems, and
encryption.

DATA SECURITY

Both physical and logical data protection, including loss of data through
mechanical failure, electrical failure, or viruses. Includes backup
procedures, off-site storage, access audit.

NETWORK SECURITY

It includes the physical and electical links between the desktop and the host,
LAN/WAN, use of internet, dial-up, wireless.

SECURITY ADMINISTRATION

Periodic reviews of policies, the design and review of systems (proposed or

existing). Includes periodic testing of security plans. Generally, this is
broken up between Administrators (who focus on individual systems) and an
Information Security Officer (larger enterprise focus.)

SOCIAL ENGINEERING AND

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.

Learn more about information security management maturity model in http://www.ism3.com

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

2.11. Enterprise Architect

TOGAF ENTERPRISE ARCHITECT RESPONSIBILITIES
TASKS
Understand and
interpret
requirements

DESCRIPTIONS
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, Verify assumptions, bring in subject matter experts, etc. in order to improve the model and to
and expand the further define it, adding as necessary new ideas to make the result more flexible and more tightly
linked to current and expected requirements.
model
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

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

CLINGER-COHEN ENTERPRISE ARCHITECT SUMMARY OF COMPETENCIES

A basic grounding in the agencys environment, strategy and priorities

Extensive knowledge of IT capabilities, covering current and emerging technologies
Good knowledge of how similar agencies use or plan to use technology
Ability to rationalize technology opportunities and business drivers optimizing return on investment
Familiar with agencys architectural principles and policies, able to interpret and apply
Hands on experience in architecture, able to perform a number of architectural tasks
Must have a mixture of BPR, business processes, and meeting facility
Strong in capability modeling
Can define and understand component capabilities and apply solutions
Ability to look at technology trends and effectively apply to business/project needs
Ability to look at and define target architecture for specialty projects
Ability to manage a repository - repository modeling and analysis
Competency in several tool sets
Ability to manage a project portal to identify concepts, work in progress, etc.
Able to identify redundancies among existing and proposed IT efforts
Ability to bring together an overall Enterprise Architecture from several individual EA efforts
Ability to develop the crux functional integration services that can be implemented in patterns

2.12 Enterprise Architecture Capability Maturity Model

The National Association of State CIO provides the performance metrics to describe the maturity level
of enteprise architecture in an enterprise called government. Find more at www.nascio.org

Maturity

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

Continously
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.

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

2.13 Modeling Software

DIA is a free to use program to draw structured diagrams. It provides the features to compose
business process models, entity relationship diagrams, use case drawings, and data flow diagrams.

The open software to work with Windows and Linux is downloadable at this site, www.dia-installer.de

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

2.14 Project Definition and Workplan for Enterprise Architecture Project

Project Name:

Enterprise Architecture for govt_agency (EA4govt_agency)

0.0 The Needs:

The Enterprise Architecture for govt_agency emerges from the articulated
requirement of the agency stakeholders for the govt_agency to pursue business process
improvement and to rationalize investments on technology projects based on integrative
framework, performance-based, sustainability, and alignment to the objectives of the basic
agency sector reform agenda.
1.0 The Goal:
The goal is an agency-wide roadmap to bring about customer-centric, efficient, and
sustainable integration of information and communications technology in the core functions of
the govt_agency. The expected result is a process-oriented and standard-based enterprise
architecture blueprint to drive the appropriate development and optimization of information
and communications technology environment in the service delivery and business support of
agency for all.
2.0 The Objectives:
3. To institutionalize enterprise architecture as the enabling reference to document and
perform business process improvement and to initialize the documented standardbased requirements in designing ICT based business and learning solutions of the
agency.
4. To conduct and document capability maturity assessment on the following
management areas: process, information, learning, and IT services, and to enable the
agency to formulate its own documented capability maturity metrics to be pursued in
designing the enterprise architecture and systems development.
5. To align current ICT projects of the agency to the goals, principles, and model
requirements specified in the approved enterprise architecture of the agency.
3.0 The Approach:
The project shall develop the govt_agencys enterprise architecture methodology, and
the corresponding core reference models to guide the business process improvement and the
strategic development of the information, learning and business management technologybased services.
The developmental process is user driven and involves participatory consultation
through EA focus group discussion, assessment surveys, process owner modeling interviews,
agency units process and content experts engagement, documented focus group discussion
and feed-backing, and acquisition of experienced mentoring consultants and project-based
research assistants.
It is to use globally accepted best practice references, and to acquire appropriate
documentation tools, process methodology, technology standard references, diagramming or
case tools to draw properly the process, information and technology usage scenarios and
reference models, which the agency will use in the elaboration and designing of the desired
learning delivery and business support systems model.

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

It is to introduce standard-based capability maturity assessment framework to

describe the status, and to guide the business improvement requirement of the agency. It will
cover capability maturity assessment on the following management performance areas of the
agency: process management, information management, learning management, and IT
services management.
4.0 The Deliverables:
The project resources and activities deliver the procedures, reference standards, and the
enterprise architecture reference models documents. At the end, the project releases:
1. Analyzed results and documentation of the agency capability maturity assessment status on
process management, information management, learning management, and IT services
management.
2. Documented agreement among the agency stakeholders and management executives on the
capability maturity goals, and the corresponding vision, principles and objectives of the
enterprise architecture formulation of the agency.
3. Detailed documentation of the AS-IS requirement reference models of the enterprise
architecture components, namely, business process, data standards, application
specifications, and technology configuration.
4. Deliberation and documented agreement on the detailed composition of the TO-BE reference
models of the agencys enterprise architecture components in order to meet the capability
maturity goals, and to serve as the requirement references in the acquisition and
development of technology-based solutions.
5. Drafted document on the Information and Learning Management System Strategic Investment
Plan
6. Drafted improvement plan for the govt_agency Data Center
5.0 The Responsibilities:
5.1 The EA4govt_agency Work Group
The Agency shall compose the EA4govt_agency Work Group, whose members will come from
the agency business and curricular units to provide expert knowledge and input to deliver the
enterprise architecture blueprint of the govt_agency.
In the commissioned work group, are the selected process and content experts of the main
business and curricular services of the govt_agency. The work group will have at least one
expert representative to cover the following agency wide performance areas:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

Customer Service Provider

Procurement and Assets
Budget, Accounting, Cashiering
Human Resources and Payroll
Central Office Administration
Bureau Level Administration
Regional Office Administration
Provincial Office Administration
Local Government Administration
Central IT Management
Regional, Provincial and LGU ICT Coordinator
Attached Project Representatives
Related Government Agency

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

The team member is required to attend project meeting, focus group discussion, and
consultation workshops. He/she is tasked to gather expected data, and to articulate on
behalf of the represented agency entity the necessary knowledge input to compose the
deliverables of the enterprise architecture. He/she shall assist the project research assistant
in the conduct of assessment and data gathering in his/her represented business or learning
management entity of the govt_agency
.
5.2 EA4govt_agency Project Manager
The EA4govt_agency Work Group will be managed by an EA4govt_agency Project Manager, who
will insure the delivery of the Enterprise Architecture for govt_agency, and he will work
directly with the IT Services Director of the Agency who in turn is responsible in
communicating project requirements, decision needs, and deliverable status to the Office of
the Secretary. The EA4Egovt_agency Project Manager has the following responsilities:

Lead the project team through each stage of the project, and insure resources provision.
Identify organization politics and work well within those politics.
Supervise collection of input from project stakeholders to efficiently compose the enterprise
architecture requirements.
Establish and manage realistic and committed project schedules; taking into consideration
deadlines, dependencies, resources, and costs when making changes and decisions to
schedule.
Communicate and maintain project progress on meetings and status reports.
Ensure that all the project tasks and deliverables remain on track and within cost
Identify and manage all issues and risks on the project.
Review and approve deliverables before their release to the project stakeholders.
5.3 IT Management Mentoring Consultants
The EA4govt_agency Work Group and Project Manager will be assisted by a contacted external
Information Technology Management Mentoring Consultants.
The mentoring consultant must have designed and implemented the full development cycle of
an information and communication management system in an agencyal organization; done
researches and conducted mentoring services related to enterprise architecture, systems
development project management, and IT governance in government agencies and agency
related organization; and who have professional training and implementation experiences in
web application services, database systems, and security applications. He must have at least
a minimum of ten (10) years of management experience in ICT service delivery and support.
The consultative engagement involves the following responsibilities:

1. Develop the training design and learning materials to assist EA4EAGENCY Work Group to
understand, evaluate, and design the procedures and requirements of formulating the
agencys enterprise architecture
2. Guide the EA4agency Work Group in the formulation, administration, and result analysis of
the capability maturity assessment of the agency
3. Facilitate the elicitation, elaboration, documentation, analysis, and modeling of the
enterprise architecture components using standard methods and software
4. Assist the EA4agency Project Manager to define and implement the project management
methodology.
5. Guide the Project Research Assistants in the assessment and data gathering interviews and
authoring of the required documentation. It includes editorial input to ascertain content
accuracy and soundness of the drafted agency-wide proceeding, EA results, and agreements

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

6. Provide best practice guidance in the formulation of the improved reference models of the
business processes, data element standards, application specifications, and technology
configuration of the agencys enterprise architecture
7. Prepare and present technical information in the consultation meetings and focus group
discussion on recent developments and capabilities in web application development, database
building, information systems security management, and intranet and Internet services.
8. Lead EA4agency Work Group to properly engage the IT service vendors by providing business
and technical knowledge in doing the solution readiness assessment of the commercial-out-ofthe-shelf technology solutions already installed at govt_agency, or being proposed by various
branded IT Solution Providers.
5.4 Project Research Assistants
The EA4govt_agency Work Group will be assisted by project-based contractual, called Project
Research Assistants who have at least two (2) years experienced in doing actual agencyal or
business researches.
They must be able to present portfolio of commissioned written products in English from any
organization. They must exhibit advanced technology skills in using basic office productivity
software, drawing tools and Internet applications.
They are charged to do the following:
1. To research and compose the aggregated summary of the applicable Enterprise
Architecture reference standards for govt_agency
2. To administer and to generate the tabulated results of the Agency Capability Maturity
Assessments
3. To document the organized brainstorming and focus group discussion
4. To draft the project proceedings, results and agreements of the EA4govt_agency
under the editorial supervision of the mentoring consultants
6.0 Detailed Work Breakdown:
Main
Task
No.
01

Sub
Task
No.

Main Task or Sub Task Name

Organize EA4govt_agency
project team

1.1
1.2

1.3
1.4

Appointment of the
EA4govt_agency Project Manager
Selection and official
appointment of the process and
content expert representatives
from the agency business units to
compose EA4govt_agency Work
Acquisition of IT Management
Mentoring Consultants and
Project Research Assistants
Setting up of the Project
Management Office, and
Acquisition of Support Materials
and Technology

Estimated
Duration
DAYS
35 Days

Start
Date

End
Date

Responsible

OSEC

Project
Manager

Project
Manager

Project
Manager

Open Practitioner's Note on Enterprise Architecture

Task
Precedence

www.onecitizen.net

1.5

1.6

1.7

1.8

1.9

Main
Task
No.

Sub
Task
No.

02

2.1

2.2

2.3

2.4

2.5

EA4govt_agency Work Group

focus group discussion on the
project goals, project work plan,
results expectation, tasks and
processes, approaches and
methodology, activity schedule,
RAEW matrix, resource
requirements, and people
Work Group capability building
workshop and agreements on the
EA modeling tools,
documentation templates, and
deliverable artifacts.
Present and submit for Executive
Approval the Project Work Plan,
Methodology, and Deliverables,
and issuance of appropriate
agency memo

Project
Manager

1.1, 1.2, 1.3

Mentoring
Consultant

1.3

Project
Manager

1.6

Make available for actual use the

EA tools, assessment forms,
documentation templates, and
on-line collaboration system, and
the drafting of the govt_agency
Communication to the business
units of the Enterprise
Architecture work schedule plan,
input requirements, deliverables,
and the corresponding agency
directive memo.
Main Task or Sub Task Name

Mentoring
Consultant
Project RA

1.7

Project
Manager

1.5, 1.6, 1.7

Gather data to identify the ASIS- STATE of the agency

Enterprise Architecture
Components
Conduct Agency-wide survey on
the capability maturity level of
the agency in managing process,
information, learning and IT
services
Consolidate the assessment
results to compose the
documented capability maturity
profile of the agency in managing
process, information, learning
and IT services.
Conduct focus group discussion
with the EA4govt_agency Work
Group to define the capability
maturity goals to define the
Agency Enterprise Architecture
Framework
Conduct data gathering to build
the detailed information to
represent the process, data,
application, and technology
entities of the agency Enterprise
Architecture
Draw and draft the narrative
documentation of the as-is state
models of the business processes,
data entities-flow-and
relationship, application
functional requirements, and
technology configuration

Estimated
Duration
DAYS

Start
Date

End
Date

Responsible

Task
Precedence

Mentoring
Consultant
Project RA

1.9

Mentoring
Consultant
Project RA

2.1

Mentoring
Consultant
Project RA

2.2

30

Mentoring
Consultant
Project RA

1.8, 1.9

15

Mentoring
Consultant
Project RA

2.4

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

2.6

2.7

Main
Task
No.
03

Sub
Task
No.

3.0

3.1

3.2

3.3

3.4

3.5

3.6

3.7
3.8
3.9

Conduct focus group discussion

with EA4govt_agency Work Group
to validate the as-is state models
of the enterprise architecture,
and to determine the gaps based
on the capability maturity goals
of the agency.
Conduct focus group discussion
with govt_agency Executives,
Directors and Chiefs to review
and validate the AS-IS-STATE
Enterprise Architecture Model of
the agency, and the perceived
gaps.

Project
Manager
Mentoring
Consultant

2.5

Project
Manager
Mentoring
Consultant

2.6

Main Task or Sub Task Name

Estimated
Duration
DAYS

Compose the reference domain

model documents of the To-Be
Enterprise Architecture of the
agency, and the Information and
Learning Management System
Strategic Solution Models.
Draw and draft the initial
narrative documentation of the
proposed Enterprise Architecture
reference models to represent
the desire state and the
remedies to close the gaps
Conduct consultation workshop
with EA4govt_agency Work Group
to review, validate and approved
the define Enterprise
Architecture reference models
Formulate the working paper on
the functional requirements of
the proposed improvement to
current applications and/or new
solution to be acquired or
develop
Conduct consultation workshop
to elaborate and improve the
functional requirement definition
of the improve or to be acquired
ICT-based solutions
Submit the drafted Enterprise
Architecture for review and
comments of the agencys
business and instructional units
Response gathering and analysis,
and improvement of the drafted
Enterprise Architecture
document
Submit the improved Enterprise
Architecture document to the
Executive Level for review and
comment
Drafting of the final version of
Enterprise Architecture
document
Submit the final version of the
Enterprise Architecture
document to the Executive Level
Information dissemination about
the Enterprise Architecture to
the stakeholders of the agency.

Start
Date

End
Date

Responsible

10

Mentoring
Consultant
Project RA

Mentoring
Consultant
Project RA

Mentoring
Consultant
Project RA

Mentoring
Consultant
Project RA

10

Project
Manager

Mentoring
Consultant
Project RA

Project
Manager

Mentoring
Consultant
Project RA
Project
Manager

5
5

Open Practitioner's Note on Enterprise Architecture

Task
Precedence

2.7

Project
Manager

www.onecitizen.net

7.0 Resource Requirements and Estimated Budget

Items Categories

Item Summary of Configuration

Technology
Support

Internet and Access Device

Web Hosting Service
Project Management System
Documentation Software
Diagramming Software or Case-Tools
EA Templates and Artifacts Repository

Consultancy Services

IT Management Mentoring Consultant

Project Research Assistant

Conduct of
Assessment, Data
Gathering, and
Writing of Results

Food & Accommodation

Transportation
Office Supplies
Allowances

Conduct of Focus
Group Discussion and
Consultation
Workshops, and
Writing of Results

Venue
Food
Accommodation
Transportation
Office Supplies

Total
Units

Total
Cost

Availability
Schedule

8.0 Enterprise Architecture Document Details

(Represent the Enterprise AS-IS-STATE and the TO-BE-STATE)

Document Listing of the Enterprise Architecture Scope

Strategic Intent
Organization
Performance Requirements
Business Entity
Process Entity
Data Entity
Application Entity
Technology Entity

Business Process Mapping

Process Entity Identification, procedure and relationship, applied policies and rules definition,
process event triggers and exemption handling
Decomposition Analysis and Business Process Improvement Model Composition

Information Element Mapping

Identification, Harmonization, and Standards Definition of Data Elements
Decomposition Analysis and Improved Data Model Composition
Application Conceptual Model, Data and Process Entity Relationship Model

Technology Configuration Models

Solution Architecture
Network Configuration
Database Configuration
Development Platform Configuration
Security Configuration
Interoperability Configuration

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net

ABOUT THE NOTETAKER:

John Macasio
Mr. Macasio is currently the ICT project consultant of the Department of Education, Office of the Secretary,
and of the Technical Education and Skills Development Authority, e-TESDA PMO. He also serves as the eGovernment Management Training Consultant of the National Computer Institute, Commission on Information
and Communications Technology.
He served as training consultant to some government agency-based trainings on ICT Project Management,
namely Bureau of Internal Revenue, Land Transportation Office, Central Bank, Land Bank, and Intellectual
Property Office.
Mr. Macasio is professionally trained on ITIL Service Management Framework, Oracle Database Administration,
and Microsoft Windows and Linux Network Services. He was the ICT Services Group Head of Far Eastern
University for eleven years.
He co-authors the United Nations APCICT Academy module on the Essentials of ICT Project Management for
Government Leaders. He is the project consultant of CESB in the formulation of the National Competency
Standards for CESO. He is the developer and administrator of the capability building projects on digital
citizenship located at www.aralanet.org and www.onecitizen.net. He has written other practitioner's notes
on Basics of ICT Project Management, ICT Services Management Essentials, and OpenDesk ICT for Teaching and
Learning.

Open Practitioner's Note on Enterprise Architecture

www.onecitizen.net