ENTERPRISE ARCHITECTURE PRACTITIONER'S NOTE - Draft Release

ICT SERVICES 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 “single-
reference-of-truth” to properly lead the business process improvement and the optimal value-
added integration of technology in the business operation of the organization.
The enterprise architecture tools provide the principles, methods, vocabulary, conventions,
presentation objects, procedures, software, repositories, and artifacts in order to draw the
reference models of the enterprise that speaks of its business, information, technology, and
people.
The drawn models are kept in 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.

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
2.15 Enterprise Architecture Document Template.....................................................39
ABOUT THE NOTETAKER:............................................................................40

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 YES NO NOT
they inter-operate, and which technology they are using? SURE
Can your agency readily presents the professional and business user matrix YES NO NOT
dovetailed to their requirements, and to the technology services that address those SURE
requirements?
Does your agency have a documented map of enterprise-wide data, how data is being YES NO NOT
grouped, how data are related, how data is being accessed, how data is shared, and SURE
how data is secured, and how data is store?
Are there silos of data and application in the different units of the agency? YES NO NOT
SURE
When your agency start a project do you have an enterprise architecture blueprint, YES NO NOT
which is used to align the type of application to be designed and developed? SURE
Is there a formal stage in the project life cycle where system architecture is being YES NO NOT
checked against the enterprise architecture? SURE
If you have any question or problem regarding architecture do you know who to seek YES NO NOT
for guidance, decision and documentation? SURE
Is there an official guidance and listing of all business standards, methods and tools, YES NO NOT
technical references that both IT and Business have to use, or you can use whatever SURE
technology you want?
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.
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.
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.

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 organization’s 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 organization’s 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.

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 Organization Timing Motivation

Enterprise Architecture Components Grid Derived from Zachman Framework
WHAT HOW WHERE WHO WHEN WHY

SCOPE List of things and Identification of Identification of Identification of Identification of Identification of
Inventory types scope process scope network scope scope time – scope motivation
important to the -expressed in -expressed in organization – expressed in expressed in
enterprise terms of process terms of experessed in terms of events terms of
domains. types in doing locations where terms of important to the motivation types
the business. the business organization and business. like mandate,
operates. stakeholders policy
important to the directives,
business. business goals
and strategies.
BUSINESS List of business Identification of Identification of Identificaiton of Identification of Identification of
entity and the process the network the organization the timing model the business
relationship model that model which model which which relates a ends and
describes the describes the relates business business cycle to business means
transformation business location role to business a business that motivates
of input to and its relation work, and to moment and the organization
process, result, to other peer other peer another peer
and entry to business business roles. business cycles.
other locations.
peerprocess.
SYSTEM List of system List of systems List of system List of List of the List of systems
entity and process that location and organizational systems life means and ends
relationship transforms connection. representation in cycle, timing in terms of
systems input terms of business triggers and systems ules and
role and business calendars policies
work
TECHNOLOGY List of technology List of List of technology List of technology List of technology List of
entity and specification location and role and work cycle and technology
relationship technology connection moment means and ends
process and
technology input
COMPONENT Inventory Proess Network Organization Timing Motivation
Configuration Configuration Configuration Configuration Configuration Configuration
OPERATION Operation entity Operation Operation Organization role Operation cycle Operation ends
and relationships transform location and and work and moments and means
operation input connection
Find more information about Zachman Enterprise Architecture framework at www.zifa.com.

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.
1.Performance Reference Model – standardized

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

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, Data Element
and used in a system. It establishes Data Flow Diagram
common guidelines for data operations Entity Relationship
that make it possible to predict, model, Relational Structure
and control the flow of data in the Data Physical Storage
system. Data Interoperatibility
Data Standard
It describes the structure of an Supported Informational Themes
organization's logical and physical data
assets and the associated data
management resources
APPLICATION ARCHITECTURE Application architecture consists of Current inventory of applications and
logical systems that manage the data components.
objects in the data architecture and
support the business functions in the Evolving applications and components
Business Architecture. needed to fulfill for the business
units.
It provides a blueprint for the individual Migration plans for moving the
application systems to be deployed, the EXISTING portfolio toward the
interactions between the application PLANNED portfolio
systems, and their relationships to the
core business processes of the
organization
TECHNOLOGY ARCHITECTURE It describes current and future technical Hardware Platform
infrastructure and specific hardware and Operating System
software technologies that support the Application System
Agency information systems. It provides Database System
guidance and principles for implementing Network & Communication System
technologies within the application Security System
architecture. 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.
PEOPLE It describes the roles and responsibilities Competency Standards
to support the business of the Organizational Chart
organization. It defines the set of Training Program
knowledge and skils to enable the Instructional Design
performance requirements. It provides Job Performance Evaluation
the references on the capability building
standards espoused by the organization.

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 OBJECTIVES
Preliminary Phase • 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
A. • To ensure that this evolution of the architecture development cycle has proper
Architecture recognition and endorsement from the corporate management of the enterprise, and the
Visioning 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

B. • To describe the Baseline Business Architecture
Business • To develop a Target Business Architecture, describing the product and/or service
Architecture strategy, and the organizational, functional, process, information, and geographic
Defintion 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
C: • The objective here is to define the major types and sources of data necessary to support
Information the business, in a way that is:
Systems • Understandable by stakeholders
Architecture • Complete and consistent
Definition • Stable
• The objective here is to define the major kinds of application system necessary to
Data Architecture process the data and support the business.
and • 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,
Application
and what those applications need to do in order to manage data and to present
Architecture information to the human and computer actors in the enterprise.
Modeling • 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.
D. • The Technology Architecture phase seeks to map application components defined in the
Technology Application Architecture phase into a set of technology components, which represent
Architecture software and hardware components, available from the market or configured within the
Definition 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.
E. • To review the target business objectives and capabilities, consolidate the gaps from
Opportunities and Phases B to D, and then organize groups of building blocks to address these capabilities
Solutions • To review and confirm the enterprise's current parameters for and ability to absorb
Identification 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
F. • To ensure that the Implementation and Migration Plan is co-ordinated with the various
Migration Planning 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

G. • To formulate recommendations for each implementation project
Implementation • To govern and manage an Architecture Contract covering the overall implementation and
Governance 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. • To ensure that baseline architectures continue to be fit-for-purpose
Architecture • To assess the performance of the architecture and make recommendations for change
Change • To assess changes to the framework and principles set up in previous phases
Management • 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?

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

Worksheet 01: Business GQM Analysis Worksheet
Business Domain: Business Area:

Business Critical Key Object Purpose Focus Environment Viewpoint
Process Success Performance
Factor Indicators
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 To achieve our vision, how will we sustain our ability to change and
Perspective 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 PRODUCTS CONTROLS

ENTITY
Core Functions
Special Functions

BUSINESS ENTITY BUSINESS PERFORMANCE PROCESS NAME RELATIONSHIPS
LOCATIONS OBJECTIVES
Worksheet 02: Information Requirement Mapping Matrix
BUSINESS PROCESS INFORMATION INFORMATION PROCEDURE RULES & INFORMATION INFORMATION

ENTITY NAME SOURCE CAPTURE POLICIES REPORTING CUSTOMER
FORM FORM
PROCESS NAME: BUSINESS ENTITY:

SOURCE INPUT ENTRY TASKS EXIT OUTPUT CUSTOMER
REQUIREMENTS REQUIREMENTS
VALIDATION AND VERIFICATION REQUIREMENTS
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 TASKS LANE
Actor 1 Step 1 - Start Step 4 Step 6 -End
Actor 2 Step 2 Step 5
Actor 3 Step 3

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.

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:
 User’s identity has been authenticated.
 User’s computer has sufficient free memory available to launch task.
Postconditions Describe the state of the system at the conclusion of the use case execution. Number each
postcondition. Examples:
1. Document contains only valid SGML tags.
2. Price of item in database has been updated with new value

Normal Flow Provide a detailed description of the user actions and system responses that will take place
during execution of the use case under normal, expected conditions. This dialog sequence
will ultimately lead to accomplishing the goal stated in the use case name and description.
This description may be written as an answer to the hypothetical question, “How do I
<accomplish the task stated in the use case name>?” This is best done as a numbered list of
actions performed by the actor, alternating with responses provided by the system. The
normal flow is numbered “X.0”, where “X” is the Use Case ID.
Alternative Flows Document other, legitimate usage scenarios that can take place within this use case
separately in this section. State the alternative flow, and describe any differences in the
sequence of steps that take place. Number each alternative flow in the form “X.Y”, where
“X” is the Use Case ID and Y is a sequence number for the alternative flow. For example,
“5.3” would indicate the third alternative flow for use case number 5.
Exceptions
Describe any anticipated error conditions that could occur during execution of the use case,
and define how the system is to respond to those conditions. Also, describe how the system
is to respond if the use case execution fails for some unanticipated reason. If the use case
results in a durable state change in a database or the outside world, state whether the
change is rolled back, completed correctly, partially completed with a known state, or left in
an undetermined state as a result of the exception. Number each alternative flow in the
form “X.Y.E.Z”, where “X” is the Use Case ID, Y indicates the normal (0) or alternative (>0)
flow during which this exception could take place, “E” indicates an exception, and “Z” is a
sequence number for the exceptions. For example “5.0.E.2” would indicate the second
exception for the normal flow for use case number 5.
Includes List any other use cases that are included (“called”) by this use case. Common functionality
that appears in multiple use cases can be split out into a separate use case that is included
by the ones that need that common functionality.
Priority Indicate the relative priority of implementing the functionality required to allow this use
case to be executed. The priority scheme used must be the same as that used in the
software requirements specification.
Frequency of Use Estimate the number of times this use case will be performed by the actors per some
appropriate unit of time.
Business Rules List any business rules that influence this use case.
Special Identify any additional requirements, such as nonfunctional requirements, for the use case
Requirements 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.

2.6 Enterprise Information Maturity Model
Learn more about information management methodology at www.mike2.openmethodology.org.
MATURITY STAGE DESCRIPTIONS

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

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 sub-
domains within a particular data dictionary.
Data Element Number (for reference A number associated with the data element name for use in
in data model) technical documents.
Data Element Name Commonly agreed, unique data element name. Note: there are
likely to be multiple data element names for a particular
domain.
Data Element Field Name The name used for this data element in computer programs
and database schemas. It is often an abbreviation of the Date
Element Name (eg. Cellular Phone Number might be assigned a
field name of Cell_Ph_No).
Data Element Definition Description of the meaning of the data element
Data Element Unit of Measure (uom) Scientific or other unit of measure that applies to the data
element.
Data Element Precision The level to which the data will be reported, eg 1 mile plus or
minus .001 mile
Data Element Data Type The type of data (e.g. Characters, Numeric, Alpha-numeric,
date, list, floating point).
Data Element Size and Decimalization The maximum field length that will be accepted by the
database together with any decimal points (e.g. 30(2)) refers
to a field length of 30 with 2 decimal points).
Field Constraints: Data Element is a Required fields (Y) must be populated. Conditional fields (C)
required field (Y/N); Conditional Field must be populated when another related field is populated
(C); or a “null” field (e.g. if a city name is required a zip code may also be
required). “Not null” also describes fields that must contain
data. “Null” means the data type is undefined (note: a null
value is not the same as a blank or zero value).
Default Value A value that is predetermined. It may be fixed or a variable,
like current date and time of the day.
Edit Mask (e.g. of actual layout) An example of the actual data layout required, (e.g.
yyyy/mm/dd).
Data Business Rules There are often the rules that define how data would be
managed within an information system (e.g. Fish data could be
coded (1=adult, 2=parr, 3=juveniles) and these codes would
then be included in the data dictionary for use by developers
and users. Other business rules, for example how rights to
create, read, update or delete records are assigned if they are
needed.

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

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

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

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-shelf-
software, and to evaluate the maturity of a developed software. Learn more at www.openbrr.org.
ASSESSMENT CATEGORIES DESCRIPTION
Functionality How well will the software meet the average user’s 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?
Software Quality Characteristics
CHARACTERISTICS Attributes
1 FUNCTIONALITY Accuracy, Suitability, Interoperatatibility, Compliance, Security
2 RELIABILITY Maturity, Fault Tolerance, Recoverability
3 USABILITY Understandability, Learnability, Operability
4 EFFICENCY Time Behaviour, Resource Utilization
5 MAINTAINABILITY Analysability, Changeability, Stability, Testability
6 PORTABILITY Adaptability, Installability, Conformance, Replaceability

Worksheet: Application Functional Worksheet
Tasks Activities Functional Features Non-Functional Features
Worksheet: Usability Status and Interface Requirements Matrix
Use of Product
Attributes Level 1 Level 2 Level 3 Level 4
Effectiveness
Efficiency
Satisfaction
Understandability
Learnability
Operability
User Interface and Interaction
Menu Interface Pages Navigation Color Fonts and Styles

2.9 Enterprise Technology Configuration
Viewing the Enterprise Technology Domain
Technology Domain Descriptions Components

Technology Devices Hardware and Peripheral • Front-End Services Devices
Gadgets, and their • Back-End Services Devices
capability Configurations • Network and Communications Devices
Technology Programs Software and Licenses, • Workstation Operating Systems and User's License
and their Functional and • Servers Operating Systems and Client Access
Non-Functional Features Licenses
• Workstation Application Programs and User's
License (Desktop Based Productivity and Business
Applications)
• Servers Services Programs and User's Licenses
(Network, Security, Web, Database, and
Application Services)
• Intranet and Internet based Business and
Communications Applications
• Patches and Updates
• Devices Drivers and Utilities
Technology Supports Service Levels and • Device Warranty and Maintenance Service Level
Performance Terms of Agreements
References • Software Maintenance Service Level Agreements
• Network and Internet Provision Service Level
Agreements
• Help Desk Service Level Agreements
Technology Skills Specialist and Experts, • Application Developers
and their specifications • Network Administration and Support
of knowledge, skills and • Database Administration and Support
experiences • Web Services Administration and Support
• Security Administration and Support
• Technology Project Management
• IT Service Management
Technology Standards and Methods, Systems • Process ISO
Compliance Certification • Security ISO
• Business Process Management Notation
• Project Management
• Security Management
• Network Management
• Data Management
Technology Power Electricity Generation • Power Generators
Management and Uninterrupted • Surge and Spikes Protector
Power Supply
Technology Network and Terminal Points and • Network Point of Presence
Bandwidth Internet Services • Bandwidth Quantity and Quality of Experience
Technology Development Modeling and Authoring • Diagramming and Case Tools

Tools Tools • Code Writing Standards and Languages
Technology Business Process mapping and use • Business Domains and Locations
Process Models case, business • Process Maps
organization, policies • Business Organization Functional Charts
and rules • Business Procedures, Applied Rules and Policies
Technology Data Models Data Dictionary and • Data Dictionary
Data Flow Diagrams • Data Flow Diagrams
Safekeeping of • Data Physical References
technology data and • Data Logical References
information, and the • Storage systems
conventions.
• File Structures and Naming Conventions
Technology Program Logic Application Use Cases, • Application Conceptual Model and Functional
Model and Entity Relationships, Elements
Functional Elements, • Application Use Case Model
Verification and • Application Validation and Verification References
Validation References • Application Work flow and Entity Relationships
• application Usability References
Technology Security Model Safety, integrity and • Security Policies
confidentiality • Acceptable Behaviors
protectors • Security Work flow
• Security Solutions
• Digital Forensics
• Security Risks Mitigation
Technology Strategic, Service Objectives, • Service Delivery Processes
Tactical and Operational Tasks, Activities, key • Service Support Processes
Processes and Metrics performance indicators • Strategy Alignment Process
and critical success • Acquisition Strategy and Process
factors • Solution Development Processes
• Services Life-Cycle
Technology Governance Management and control • Organizational Structure
of requirements • Roles and Responsibilities
definition, planning, • Decision Trees
execution, evaluation
and continual
improvements
Technology Services Work Security and healthy • Physical Layouts
Area references of the place • Security Layouts
of work. • Utility Configurations
• Physical Plans

Worksheet: Technology Components Definitions
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

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

2.11. Enterprise Architect
TOGAF ENTERPRISE ARCHITECT RESPONSIBILITIES
TASKS DESCRIPTIONS
Understand and Probe for information, listen to information, influence people, facilitate consensus building,
interpret synthesize and translate ideas into actionable requirements, articulate those ideas to others.
requirements Identify use or purpose, constraints, risks, etc.
The architect participates in the discovery and documentation of the customer's business scenarios
that are driving the solution. The architect is responsible for requirements understanding and
embodies that requirements understanding in the architecture specification.
Create a useful Take the requirements and develop well-formulated models of the components of the solution,
model 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
model linked to current and expected requirements.
The architect additionally should assess the value of solution-enhancing developments emanating
from field work and incorporate these into the architecture models as appropriate.
Manage the Continuously monitor the models and update them as necessary to show changes, additions, and
architecture alterations. Represent architecture and issues during development and decision points of the
program.
The architect is an "agent of change", representing that need for the implementation of the
architecture. Through this development cycle, the architect continuously fosters the sharing of
customer, architecture, and technical information between organizations

CLINGER-COHEN ENTERPRISE ARCHITECT SUMMARY OF COMPETENCIES
• A basic grounding in the agency’s environment, strategy and priorities

• Extensive knowledge of IT capabilities, covering current and emerging technologies
• Good knowledge of how similar agencies use or plan to use technology
• Ability to rationalize technology opportunities and business drivers optimizing return on investment
• Familiar with agency’s architectural principles and policies, able to interpret and apply
• “Hands on” experience in architecture, able to perform a number of architectural tasks
• Must have a mixture of BPR, business processes, and meeting facility
• Strong in capability modeling
• Can define and understand component capabilities and apply solutions
• Ability to look at technology trends and effectively apply to business/project needs
• Ability to look at and define target architecture for 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 The base architecture and standards have been identified and are being tracked and
Program verified. At this point in the program processes are repeatable and reusable templates
are starting to be developed. The need for product and compliance components to
conform to the standards and requirements has been agreed upon, and metrics are used
to track process area performance.
LEVEL 3 Well Defined The enterprise architecture framework is well defined; using approved standard and/or
Program customized versions of the templates. Processes are documented across the
organization.
Performance metrics are being tracked and monitored in relationship to other general
practices and process areas.
LEVEL 4 Managed Program At this point performance metrics are collected, analyzed and acted upon. The metrics
are used to predict performance and provide better understanding of the processes and
capabilities.
LEVEL 5 Continously The processes are mature; targets have been set for effectiveness and efficiency based
Improved Vital on business and technical goals. There are ongoing refinements and improvements based
Program on the understanding of the impact changes have to these processes.

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

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 standard-
based 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_agency’s 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 technology-
based services.
The developmental process is user driven and involves participatory consultation

through EA focus group discussion, assessment surveys, process owner modeling interviews,
agency unit’s 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.

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 agency’s 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. Customer Service Provider

2. Procurement and Assets
3. Budget, Accounting, Cashiering
4. Human Resources and Payroll
5. Central Office Administration
6. Bureau Level Administration
7. Regional Office Administration
8. Provincial Office Administration
9. Local Government Administration
10. Central IT Management
11. Regional, Provincial and LGU ICT Coordinator
12. Attached Project Representatives
13. Related Government Agency

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
agency’s 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

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 agency’s 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-of-
the-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 Sub Main Task or Sub Task Name Estimated Start End Responsible Task
Task Task Duration Date Date Precedence
No. No. DAYS
01 Organize EA4govt_agency 35 Days
project team
1.1 Appointment of the 5 OSEC

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

1.5 EA4govt_agency Work Group 2 Project 1.1, 1.2, 1.3
focus group discussion on the Manager
project goals, project work plan,
results expectation, tasks and
processes, approaches and
methodology, activity schedule,
RAEW matrix, resource
requirements, and people
1.6 Work Group capability building 3 Mentoring 1.3
workshop and agreements on the Consultant
EA modeling tools,
documentation templates, and
deliverable artifacts.
1.7 Present and submit for Executive 5 Project 1.6
Approval the Project Work Plan, Manager
Methodology, and Deliverables,
and issuance of appropriate
agency memo
1.8 Make available for actual use the 5 Mentoring 1.7

EA tools, assessment forms, Consultant
documentation templates, and Project RA
on-line collaboration system, and
the drafting of the govt_agency
1.9 Communication to the business 1 Project 1.5, 1.6, 1.7
units of the Enterprise Manager
Architecture work schedule plan,
input requirements, deliverables,
and the corresponding agency
directive memo.
No. No. DAYS
02 Gather data to identify the AS-

IS- STATE of the agency
Enterprise Architecture
Components
2.1 Conduct Agency-wide survey on 5 Mentoring 1.9
the capability maturity level of Consultant
the agency in managing process, Project RA
information, learning and IT
services
2.2 Consolidate the assessment 2 Mentoring 2.1
results to compose the Consultant
documented capability maturity Project RA
profile of the agency in managing
process, information, learning
and IT services.
2.3 Conduct focus group discussion 2 Mentoring 2.2
with the EA4govt_agency Work Consultant
Group to define the capability Project RA
maturity goals to define the
Agency Enterprise Architecture
Framework
2.4 Conduct data gathering to build 30 Mentoring 1.8, 1.9
the detailed information to Consultant
represent the process, data, Project RA
application, and technology
entities of the agency Enterprise
Architecture
2.5 Draw and draft the narrative 15 Mentoring 2.4
documentation of the as-is state Consultant
models of the business processes, Project RA
data entities-flow-and
relationship, application
functional requirements, and
technology configuration

2.6 Conduct focus group discussion 3 Project 2.5
with EA4govt_agency Work Group Manager
to validate the as-is state models Mentoring
of the enterprise architecture, Consultant
and to determine the gaps based
on the capability maturity goals
of the agency.
2.7 Conduct focus group discussion 3 Project 2.6
with govt_agency Executives, Manager
Directors and Chiefs to review Mentoring
and validate the AS-IS-STATE Consultant
Enterprise Architecture Model of
the agency, and the perceived
gaps.
No. No. DAYS
03 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.
3.0 Draw and draft the initial 10 Mentoring 2.7
narrative documentation of the Consultant
proposed Enterprise Architecture Project RA
reference models to represent
the desire state and the
remedies to close the gaps
3.1 Conduct consultation workshop 2 Mentoring
with EA4govt_agency Work Group Consultant
to review, validate and approved Project RA
the define Enterprise
Architecture reference models
3.2 Formulate the working paper on 5 Mentoring
the functional requirements of Consultant
the proposed improvement to Project RA
current applications and/or new
solution to be acquired or
develop
3.3 Conduct consultation workshop 2 Mentoring
to elaborate and improve the Consultant
functional requirement definition Project RA
of the improve or to be acquired
ICT-based solutions
3.4 Submit the drafted Enterprise 10 Project
Architecture for review and Manager
comments of the agency’s
business and instructional units
3.5 Response gathering and analysis, 5 Mentoring
and improvement of the drafted Consultant
Enterprise Architecture Project RA
document
3.6 Submit the improved Enterprise 5 Project
Architecture document to the Manager
Executive Level for review and
comment
3.7 Drafting of the final version of 5 Mentoring
Enterprise Architecture Consultant
document Project RA
3.8 Submit the final version of the 5 Project
Enterprise Architecture Manager
document to the Executive Level
3.9 Information dissemination about 5 Project
the Enterprise Architecture to Manager
the stakeholders of the agency.

7.0 Resource Requirements and Estimated Budget
Items Categories Item Summary of Configuration Total Total Availability

Units Cost Schedule
Technology Internet and Access Device
Support 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 Food & Accommodation

Assessment, Data Transportation
Gathering, and Office Supplies
Writing of Results Allowances
Conduct of Focus Venue

Group Discussion and Food
Consultation Accommodation
Workshops, and Transportation
Writing of Results Office Supplies
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

2.15 Enterprise Architecture Document Template
Table of Content
01. Introduction
1. Purpose of doing the enterprise architecture
2. Goals to achieve in doing the enterprise architecture
3. Activties to perform the initiation, planning, drafting, validation, publication and approval of the
enterprise architecture
4. Approaches to structurally guide the formulation of the enterprise architectur
5. Organization are the business units, roles and responsibilities to manage and compose the drafting of the
enterprise architecture
02. Enterprise Strategic Intent

1. Mandate
2. Functions
3. Location
4. Stakeholders
5. Fund Sources
6. Mission
7. Values
8. Vision
9. Goals
10. Reform Agenda
11. Program
12. Products and Services
13. Metrics
14. Organization
15. Sourcing Strategy
03. Enterprise Performance Reference Model

1. Enterprise Goals, Questions and Metrics
2. Enterprise Balanced ScoreCard
3. Enterprise Industry Specific Performance Metrics References
4. Enterprise Business Process Improvement Principles
04. Enterprise Business Reference Model

1. Enterprise Business Domain and Organization Definition
2. Enterprise Business Area Process Definition
3. Enterprise Business Process Mapping
05. Enterprise Information Reference Model

1. Enterprise Data Dictionary and Standards
2. Enterprise Data Flow Diagram
3. Enterprise Application Conceptual Model
4. Enterprise Application Use Case
06. Enterprise Technology Reference Model

1. Enterprise Technology Configuration Entity (Technology Assets by Category, Location, Users, Status etc.)
2. Enterprise Technology Standards (Network, Database, Application, Operating Systems, File Types, etc)
3. Enterprise Technology Service Levels
4. Enterprise Technology Security Configuration
5. Enterprise Network Entity and Connections
07. Enteprise Architecture Organization and Change Management

1. Organizational Worflow, Roles and Responsibility Matrix to Implement Enterprise Architecture
2. Migration and Change Management -Plan, Process, and Organization
3. Continual Improvement Plan

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 e-
Government 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.

ENTERPRISE ARCHITECTURE PRACTITIONER'S NOTE - Draft Release

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ENTERPRISE ARCHITECTURE PRACTITIONER'S NOTE - Draft Release

Uploaded by

Copyright:

Available Formats

ICT SERVICES MANAGEMENT PRACTITIONER'S NOTE:

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

1.0 Health Check on the Practice of Enterprise Architecture

1.1 Enterprise Architecture

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

NASCIO Enterprise Architecture Development Toolkit v.3.0

“Enterprise architecture defines an enterprise-wide, integrated set of components that

1.3 Importance of Enterprise Architecture

Schekkerman, J. (2005). Trends in Enterprise Architecture, Institute for Enterprise Architecture

VALUE INDICATORS DESCRIPTIONS

Alignment Enterprise architecture provides the framework to enable better alignment of

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

ELIMINATE GAPS Decision eliminates a gap in capability required by the organization to

STREAMLINE Decision eliminates or prevents non-value added activities.

ELIMINATE DUPLICATION Decision prevents or removes unnecessary redundancy, resulting in

PROVIDE FLEXIBILITY Decision reduces friction or resistance to change, thereby expediting

ENSURE INTEROPERATIBILITY Decision enhances integration and connectedness.

TIGHTEN SECURITY Decision enhances security and privacy.

CONTROLLED Changes are managed and controlled to expedite development,

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

1. Strategist – Defines the scope of the enterprise.

WHAT HOW WHERE WHO WHEN WHY

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

WHAT HOW WHERE WHO WHEN WHY

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

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

2.1 Enterprise Architecture Components

1.Performance Reference Model – standardized

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

How are the goals and objectives

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

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

2.3 Enterprise Business Process Analysis

Business Reference Model Definition

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

Business Performance Assessment

Goals Question and Metrics (GQM) of Business

GQM ANALYSIS PART DESCRIPTION

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

Business Domain: Business Area:

The Question of Balanced Score Card:

POINT OF VIEWS INTERROGATIVES

Worksheet 02: Balance Score Card

2.4 Business Process Mapping Worksheet

Worksheet 01: Business Definition Matrix

MANDATE STAKEHOLDERS FUNCTIONS BUSINESS PRODUCTS CONTROLS

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

Worksheet 02: Information Requirement Mapping Matrix

BUSINESS PROCESS INFORMATION INFORMATION PROCEDURE RULES & INFORMATION INFORMATION

PROCESS NAME: BUSINESS ENTITY:

VALIDATION AND VERIFICATION REQUIREMENTS

Worksheet 3: Process Mapping Swim Lane Matrix

FUNCTION UNIT: PROCESS NAME:

Actor 2 Step 2 Step 5

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

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

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

Sample Use Case Modeling