Final Enterprise Architecture Modeling New[1]

E-GOVERNMENT SERVICE MANAGEMENT PRACTITIONER'S NOTE:

ENTERPRISE ARCHITECTURE

www.onecitizen.net

Version 1.2 2009

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

INTRODUCTION:The practitioner's note presents lesson learned from various public documents that provide the framework, methods, and templates in doing enterprise architecture modeling. It demonstrates the principle of not-to-reinvent the wheel by improving from existing practices, guidance and standards.

The knowledge items of the practitioner's note are logically structured to support the learning needs of those who attend the e-government management training. It guides the government leaders and workers to build their knowledge, decision points, and action items in communicating and doing enterprise architecture modeling in their organization. The aggregated information provides the empowering content to benchmark current practices, and to make improvement to the knowledge resources of the organization on the disciplines of enterprise architecture.

The practitioner's note provides essential concepts, procedures, templates and software that are used by the note-taker in assisting some government and non-government organizations to define the enterprise architecture. It includes evaluated content considered by the e-government management training participants to be usable to communicate and implement enterprise architecture in their organizations.

Enterprise architectures provides the living documents called reference models to make the organization to effectively and efficiently managed recordings, expectations, processes, configurations, metrics, work around, changes, relationships, collaborations, interchanges, requirement tracing, control, and marketing of the business operation. It provides a 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 ContentsINTRODUCTION:........................................................................................2Part 1: Enterprise Architecture Framework........................................................4

1.0 Health Check on the Practice of Enterprise Architecture.........................................41.1 Enterprise Architecture..................................................................................41.3 Importance of Enterprise Architecture...............................................................51.4. Enterprise Architecture Principles....................................................................61.5 Questions of Enterprise Architecture.................................................................7

Part 2: Doing Enterprise Architecture..............................................................92.1 Enterprise Architecture Components .................................................................92.2 Enterprise Architecture Development Model.......................................................112.3 Enterprise Business Process Analysis.................................................................132.4 Business Process Mapping Worksheet................................................................152.6 Enterprise Information Maturity Model..............................................................202.7 Enterprise Information Data Analysis................................................................212.8 Enterprise Software Readiness Assessment.........................................................272.9 Enterprise Technology Configuration................................................................272.10 Information Security Model..........................................................................282.11. Enterprise Architect..................................................................................292.12 Enterprise Architecture Capability Maturity Model..............................................302.13 Modeling Software.....................................................................................312.14 Project Definition and Workplan for Enterprise Architecture Project........................32

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


Part 1: Enterprise Architecture Framework

1.0 Health Check on the Practice of Enterprise Architecture

Does your agency maintains a blueprint or matrix of all running systems, showing how they inter-operate, and which technology they are using?

YES NO NOT SURE

Can your agency readily presents the professional and business user matrix dovetailed to their requirements, and to the technology services that address those requirements?

YES NO NOT SURE

Does your agency have a documented map of enterprise-wide data, how data is being grouped, how data are related, how data is being accessed, how data is shared, and how data is secured, and how data is store?

YES NO NOT SURE

Are there silos of data and application in the different units of the agency? YES NO NOT SURE

When your agency start a project do you have an enterprise architecture blueprint, which is used to align the type of application to be designed and developed?

YES NO NOT SURE

Is there a formal stage in the project life cycle where system architecture is being checked against the enterprise architecture?

YES NO NOT SURE

If you have any question or problem regarding architecture do you know who to seek for guidance, decision and documentation?

YES NO NOT SURE

Is there an official guidance and listing of all business standards, methods and and tools, technical references that both IT and Business have to use, or you can use whatever technology you want?

YES NO NOT SURE

1.1 Enterprise Architecture

Enterprise architecture provides the fundamental framework to document, and to understand the aligned management of the business processes and information technology in the operation of the organization. It offers the thinking and modeling methods to constitute both the baseline and directive for integrative change in the performance of the organization through information and communications technology.

Enterprise architecture makes the organization ask the proper questions, categorize baseline knowledge, analyze information on gaps and possibilities, and draw integrative models that comprehensively define the business improvement requirements and solution strategy of the organization.

The enterprise architecture provides the logically structured activities to make the organization realize the reference models that contextualize the proper integration of ICT solutions and services in the delivery of the business results intended by the stakeholders.

Enterprise architecture provides the re-usable reference models to ensure integral and managed change in the performance, business, information and technology domains of the organization -a.k.a. Enterprise. It brings about the integrative standards to align the silos of process, data, application, and technology to the efficiency, reliability, effectivity, immediacy, transparency, accountability, interoperability, security and quality goals of the organization.


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 organizations strategic direction, furthering measurable improvement in performance, achievement of business needs, and citizen/customer satisfaction.

STAKEHOLDER ALIGNMENT Decision reflects the best interests of key stakeholders, and complies with applicable legal mandates and federal directives.

ELIMINATE GAPS Decision eliminates a gap in capability required by the organization to achieve its strategic goals.

MINIMIZE COST Decision reduces costs and burden while maintaining and/or improving quality and security.

STREAMLINE Decision eliminates or prevents non-value added activities.

ELIMINATE DUPLICATION Decision prevents or removes unnecessary redundancy, resulting in consolidation of best-in-class standards and components that are consistent, reused and shared.

BROADEN ACCESSIBILITY Decision expands availability of assets, making them easier to use and understand and more readily accessible to a broader set of stakeholders.

PROVIDE FLEXIBILITY Decision reduces friction or resistance to change, thereby expediting the organizations ability to rapidly and completely scale and respond to forces of change.

ENSURE INTEROPERATIBILITY Decision enhances integration and connectedness.

ENHANCE RELIABILITY Decision enhances stability, quality, and confidence that the result is available and correct.

TIGHTEN SECURITY Decision enhances security and privacy.

CONTROLLED Changes are managed and controlled to expedite development, minimize disruption and risk, and are sequenced to maintain order.


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 WHYSCOPE List of things and

Inventory types important to the enterprise domains.

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

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

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

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

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

BUSINESS List of business entity and relationship

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

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

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

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

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

SYSTEM List of system entity and relationship

List of systems process that transforms systems input

List of system location and connection.

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

List of the systems life cycle, timing triggers and calendars

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

TECHNOLOGY List of technology entity and relationship

List of specification technology process and technology input

List of technology location and connection

List of technology role and work

List of technology cycle and moment

List of technology means and ends

COMPONENT Inventory Configuration

Proess Configuration

Network Configuration

Organization Configuration

Timing Configuration

Motivation Configuration

OPERATION Operation entity and relationships

Operation transform operation input

Operation location and connection

Organization role and work

Operation cycle and moments

Operation ends and means

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


Part 2: Doing Enterprise Architecture

2.1 Enterprise Architecture Components

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

The enterprise architecture captures, draws, analyzes, improves, and implements the content of the organization's architectural reference models.


PERFORMANCE-Performance Metrics-Balance Score Card

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

1.Performance Reference Model standardized framework to measure the performance of ICT investment and their contribution to the business or program performance.

2. Business Architecture speaks of the business reference model on whatthe business is, its customers, mandate, strategy, funds, returns, competency, partners, functions, process, products, locations, cycles, risks ...

3. Information Architecture speaks of thebusiness data reference model and the application reference model to produce the needed information of the businesstransactions, compliance, intelligence, product delivery, and third-party interfaces ...

4. Technology Architecture speaks of theTechnical reference model that defines thedevelopment and operationl platforms of business technology solutions related to OS, application, database, communication, security, data and file standards. It includes references and methods on data interoperatibility, usability, readiness, security, service maturity etc...

5. People speaks of the people capabilitymaturity references and governance model to support the implementation pre-requisites of the enterprise architecture. It includes competency standards and capacity building program ...

INFORMATION-Data Reference Model

-Application Reference Model-Information Maturity Model

BUSINESS-Business Reference Model

-Business Process Maturity Model

PEOPLE -Capability Maturity Model

-Governance Model

Enterprise Architecture Components Elaboration

BUSINESS ARCHITECTURE Understanding how the business is running, what are its needs, what is missing and what needs to be changed or improved.

It defines the business strategy, governance, organization, and key business processes of the organization.

Identify Business Model Business Functions and WHO Performs the Function.

Definition of Business Goals and Goals, the supporting processes, workflow, policies and procedures.

Assessment of the Current State and Description of the Future State.

How are the goals and objectives implemented through the ICT Solutions and the supporting technical infrastructure.

DATA ARCHITECTURE It defines how data is stored, managed, and used in a system. It establishes common guidelines for data operations that make it possible to predict, model, and control the flow of data in the system.

It describes the structure of an organization's logical and physical data assets and the associated data management resources

Data Element Data Flow DiagramEntity Relationship Relational StructureData Physical StorageData InteroperatibilityData StandardSupported Informational Themes

APPLICATION ARCHITECTURE Application architecture consists of logical systems that manage the data objects in the data architecture and support the business functions in the Business Architecture.

It provides a blueprint for the individual application systems to be deployed, the interactions between the application systems, and their relationships to the core business processes of the organization

Current inventory of applications and components.

Evolving applications and components needed to fulfill for the business units.

Migration plans for moving the EXISTING portfolio toward the PLANNED portfolio

TECHNOLOGY ARCHITECTURE It describes current and future technical infrastructure and specific hardware and software technologies that support the Agency information systems. It provides guidance and principles for implementing technologies within the application architecture.

It describes the hardware, software and network infrastructure needed to support the deployment of core, mission-critical applications.

Hardware PlatformOperating SystemApplication System Database SystemNetwork & Communication SystemSecurity System Enterprise Systems ManagementDevelopment MethodsTechnical StandardsInteroperatability References

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

Competency StandardsOrganizational ChartTraining ProgramInstructional DesignJob Performance Evaluation


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. Architecture Visioning

To ensure that this evolution of the architecture development cycle has proper recognition and endorsement from the corporate management of the enterprise, and the support and commitment of the necessary line management

To define and organize an architecture development cycle within the overall context of the architecture framework, as established in the Preliminary phase

To validate the business principles, business goals, and strategic business drivers of the organization and the enterprise architecture Key Performance Indicators (KPIs)

To define the scope of, and to identify and prioritize the components of, the Baseline Architecture effort

To define the relevant stakeholders, and their concerns and objectives To define the key business requirements to be addressed in this architecture effort, and

the constraints that must be dealt with To articulate an Architecture Vision and formalize the value proposition that

demonstrates a response to those requirements and constraints To create a comprehensive plan that addresses scheduling, resourcing, financing,

communication, risks, constraints, assumptions, and dependencies, in line with the project management frameworks adopted by the enterprise (such as PRINCE2 or PMBOK)

To secure formal approval to proceed To understand the impact on, and of, other enterprise architecture development cycles

ongoing in parallel


B.Business Architecture Defintion

To describe the Baseline Business Architecture To develop a Target Business Architecture, describing the product and/or service

strategy, and the organizational, functional, process, information, and geographic aspects of the business environment, based on the business principles, business goals, and strategic drivers

To analyze the gaps between the Baseline and Target Business Architectures To select and develop the relevant architecture viewpoints that will enable the architect

to demonstrate how the stakeholder concerns are addressed in the Business Architecture To select the relevant tools and techniques to be used in association with the selected

viewpoints

C:Information Systems Architecture Definition

Data Architecture andApplication Architecture Modeling

The objective here is to define the major types and sources of data necessary to support the business, in a way that is:

Understandable by stakeholders Complete and consistent Stable

The objective here is to define the major kinds of application system necessary to process the data and support the business.

It is important to note that this effort is not concerned with applications systems design. The goal is to define what kinds of application systems are relevant to the enterprise, and what those applications need to do in order to manage data and to present information to the human and computer actors in the enterprise.

The applications are not described as computer systems, but as logical groups of capabilities that manage the data objects in the Data Architecture and support the business functions in the Business Architecture. The applications and their capabilities are defined without reference to particular technologies. The applications are stable and relatively unchanging over time, whereas the technology used to implement them will change over time, based on the technologies currently available and changing business needs.

D.Technology Architecture Definition

The Technology Architecture phase seeks to map application components defined in the Application Architecture phase into a set of technology components, which represent software and hardware components, available from the market or configured within the organization into technology platforms.

As Technology Architecture defines the physical realization of an architectural solution, it has strong links to implementation and migration planning.

Technology Architecture will define baseline (i.e., current) and target views of the technology portfolio, detailing the roadmap towards the Target Architecture, and to identify key work packages in the roadmap. Technology Architecture completes the set of architectural information and therefore supports cost assessment for particular migration scenarios.

E.Opportunities and Solutions Identification

To review the target business objectives and capabilities, consolidate the gaps from Phases B to D, and then organize groups of building blocks to address these capabilities

To review and confirm the enterprise's current parameters for and ability to absorb change

To derive a series of Transition Architectures that deliver continuous business value (e.g., capability increments) through the exploitation of opportunities to realize the building blocks

To generate and gain consensus on an outline Implementation and Migration Strategy

F.Migration Planning

To ensure that the Implementation and Migration Plan is co-ordinated with the various management frameworks in use within the enterprise

To prioritize all work packages, projects, and building blocks by assigning business value to each and conducting a cost/business analysis

To finalize the Architecture Vision and Architecture Definition Documents, in line with the agreed implementation approach

To confirm the Transition Architectures defined in Phase E with relevant stakeholders To create, evolve, and monitor the detailed Implementation and Migration Plan providing

necessary resources to enable the realization of the Transition Architectures, as defined in Phase E


G.Implementation Governance

To formulate recommendations for each implementation project To govern and manage an Architecture Contract covering the overall implementation and

deployment process To perform appropriate governance functions while the solution is being implemented

and deployed To ensure conformance with the defined architecture by implementation projects and

other projects To ensure that the program of solutions is deployed successfully, as a planned program of

work To ensure conformance of the deployed solution with the Target Architecture To mobilize supporting operations that will underpin the future working lifetime of the

deployed solution

H.Architecture Change Management

To ensure that baseline architectures continue to be fit-for-purpose To assess the performance of the architecture and make recommendations for change To assess changes to the framework and principles set up in previous phases To establish an architecture change management process for the new enterprise

architecture baseline that is achieved with completion of Phase G To maximize the business value from the architecture and ongoing operations To operate the Governance Framework

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

2.3 Enterprise Business Process Analysis

Business Reference Model DefinitionBusiness 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 DefinitionBusiness 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 BusinessTool 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 Process

Critical Success Factor

Key Performance

Indicators

Object Purpose Focus Environment Viewpoint

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

The Question of Balanced Score Card:

POINT OF VIEWS INTERROGATIVES

Financial Perspective To succeed financially how should we appear to our stakeholders?

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

Business Process Perspective To satisfy our stakeholders and customers, what business processes must we excel at?

Learning and Growth Perspective

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

Worksheet 02: Balance Score Card

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

2.4 Business Process Mapping Worksheet

Business mapping and analysis involve he set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and recommend solutions that enable the organization to achieve its goals.

Worksheet 01: Business Definition Matrix

MANDATE STAKEHOLDERS FUNCTIONS BUSINESS ENTITY

PRODUCTS CONTROLS

Core Functions

Special Functions


BUSINESS ENTITY BUSINESS LOCATIONS

PERFORMANCE OBJECTIVES

PROCESS NAME RELATIONSHIPS

Worksheet 02: Information Requirement Mapping Matrix

BUSINESS ENTITY

PROCESS NAME

INFORMATION SOURCE

INFORMATION CAPTURE

FORM

PROCEDURE RULES & POLICIES

INFORMATIONREPORTING

FORM

INFORMATION CUSTOMER

PROCESS NAME: BUSINESS ENTITY:

SOURCE INPUT ENTRY REQUIREMENTS

TASKS EXIT REQUIREMENTS

OUTPUT CUSTOMER

VALIDATION AND VERIFICATION REQUIREMENTS

Worksheet 3: Process Mapping Swim Lane Matrix

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

FUNCTION UNIT: PROCESS NAME:

ACTOR TASKS LANE TASK LANE 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:

Users identity has been authenticated. Users computer has sufficient free memory available to launch task.

Postconditions Describe the state of the system at the conclusion of the use case execution. Number each postcondition. Examples:

1. Document contains only valid SGML tags.2. Price of item in database has been updated with new value


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

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

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

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

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

Business Rules List any business rules that influence this use case.

Special Requirements

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

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

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

Sample Use Case Modeling

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


2.6 Enterprise Information Maturity Model

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

MATURITY STAGE DESCRIPTIONS

LEVEL 1Aware

The organisation has no common information practices. Any pockets of information management maturity that the organization has are based on the experience and initiatives of individuals.

LEVEL 2Reactive

The organisation has little in the way of enterprise information management practices. However, certain departments are aware of the importance of professionally managing information assets and have developed common practices used within their projects. At the enterprise level, a level 2 organization reacts to data quality issues as they arise.

LEVEL 3Proactive

The organisation has a significant degree of information management maturity. Enterprise awareness, policies, procedures, and standards exist and are generally utilized across all enterprise projects. At level 3, the information management practices are sponsored by and managed by IT.

LEVEL 4Managed

The organisation manages information as an enterprise asset. The business is heavily engaged in information management procedures and takes responsibility for the quality of information that they manage. A level 4 organisation has many mature and best-in-class practices and utilizes audits to ensure compliance across all projects.

LEVEL 5Optimized

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


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 in data model)

A number associated with the data element name for use in technical documents.

Data Element Name Commonly agreed, unique data element name. Note: there are likely to be multiple data element names for a particular domain.

Data Element Field Name The name used for this data element in computer programs and database schemas. It is often an abbreviation of the Date Element Name (eg. Cellular Phone Number might be assigned a field name of Cell_Ph_No).

Data Element Definition Description of the meaning of the data element

Data Element Unit of Measure (uom) Scientific or other unit of measure that applies to the data element.

Data Element Precision The level to which the data will be reported, eg 1 mile plus or minus .001 mile

Data Element Data Type The type of data (e.g. Characters, Numeric, Alpha-numeric, date, list, floating point).

Data Element Size and Decimalization The maximum field length that will be accepted by the database together with any decimal points (e.g. 30(2)) refers to a field length of 30 with 2 decimal points).

Field Constraints: Data Element is a required field (Y/N); Conditional Field (C); or a null field

Required fields (Y) must be populated. Conditional fields (C) must be populated when another related field is populated (e.g. if a city name is required a zip code may also be required). Not null also describes fields that must contain data. Null means the data type is undefined (note: a null value is not the same as a blank or zero value).

Default Value A value that is predetermined. It may be fixed or a variable, like current date and time of the day.

Edit Mask (e.g. of actual layout) An example of the actual data layout required, (e.g. yyyy/mm/dd).

Data Business Rules There are often the rules that define how data would be managed within an information system (e.g. Fish data could be coded (1=adult, 2=parr, 3=juveniles) and these codes would then be included in the data dictionary for use by developers and users. Other business rules, for example how rights to create, read, update or delete records are assigned if they are needed.


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


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

A data flow diagram

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

Process Notations

Yourdon and CoadProcess Notations

Gane and SarsonProcess Notation


ProcessA process transforms incoming data flow into outgoing data flow.

Datastore Notations

Yourdon and CoadDatastore Notations

Gane and SarsonDatastore Notations

DataStoreDatastores are repositories of data in the system. They are sometimes also referred to as files.

Dataflow Notations

DataflowDataflows 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 EntityExternal 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 LayersDraw 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 DiagramsA 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 levelsThe 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 EntityThe symbol represents sources of data to the system or destinations of data from the system.

Data FlowThe symbol represents movement of data.

Data StoreThe symbo represents data that is not moving (delayed data at rest).

ProcessThe 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 users requirements?

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

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

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

Performance How well does the software perform?

Scalability How well does the software scale to a large environment?

Architecture How well is the software architected? How modular, portable, flexible, extensible, open, and easy to integrate is it?

Support How well is the software component supported?

Documentation Of what quality is any documentation for the software?

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

Community How active and lively is the community for the software?

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

2.9 Enterprise Technology Configuration

COMPONENTS ASSETS CONFIGURATION METRICS STANDARDS

Hardware Platforms

Operating System

Application System

Database System

Network & Communication

Security System

Enterprise System Management

Development Methodologies

Data and File Standards

Interoperatability


2.10 Information Security Model

The Security Domain defines the roles, technologies, standards, and policies necessary to protect the information assets of the state and citizens from any form of unauthorized access. The Security Domain defines the security and access management principles that are applied to ensure the appropriate level of access to NMs information assets. This domain comprises standards for identification, authentication, authorization, administration, audit, and naming services.

COMPONENTS DESCRIPTIONS

PHYSICAL SECURITY Securing access to hardware, inventory, and disposition of physical equipment and records.

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

APPLICATION SECURITY ensuring that an application that accesses another application or data is secure; includes the analysis of distributed, proxy, and middleware services.

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

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

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

SECURITY ADMINISTRATION Periodic reviews of policies, the design and review of systems (proposed or existing). Includes periodic testing of security plans. Generally, this is broken up between Administrators (who focus on individual systems) and an Information Security Officer (larger enterprise focus.)

SOCIAL ENGINEERING AND HUMAN FACTORS

Many techniques used to compromise systems are based on deceptive practices aimed at individual users or employees. Security awareness must be heightened at all levels of the organization and procedures developed to positively identify requestors of information and their legitimate purposes.

MALWARE Viruses, Trojans, spyware, and other malicious code.

INCIDENT RESPONSE TEAM coordinated incident response for miscellaneous incident that may occur across the state.

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


2.11. Enterprise Architect

TOGAF ENTERPRISE ARCHITECT RESPONSIBILITIES

TASKS DESCRIPTIONS

Understand and interpret requirements

Probe for information, listen to information, influence people, facilitate consensus building, synthesize and translate ideas into actionable requirements, articulate those ideas to others. Identify use or purpose, constraints, risks, etc.

The architect participates in the discovery and documentation of the customer's business scenarios that are driving the solution. The architect is responsible for requirements understanding and embodies that requirements understanding in the architecture specification.

Create a useful model

Take the requirements and develop well-formulated models of the components of the solution, augmenting the models as necessary to fit all of the circumstances. Show multiple views through models to communicate the ideas effectively.

The architect is responsible for the overall architecture integrity and maintaining the vision of the offering from an architectural perspective. The architect also ensures leverage opportunities are identified, using building blocks, and is a liaison between the functional groups (especially development and marketing) to ensure that the leverage opportunities are realized.

The architect provides and maintains these models as a framework for understanding the domain(s) of development work, guiding what should be done within the organization, or outside the organization. The architect must represent the organization view of the architecture by understanding all the necessary business components

Validate, refine, and expand the model

Verify assumptions, bring in subject matter experts, etc. in order to improve the model and to further define it, adding as necessary new ideas to make the result more flexible and more tightly linked to current and expected requirements.

The architect additionally should assess the value of solution-enhancing developments emanating from field work and incorporate these into the architecture models as appropriate.

Manage the architecture

Continuously monitor the models and update them as necessary to show changes, additions, and alterations. Represent architecture and issues during development and decision points of the program.

The architect is an "agent of change", representing that need for the implementation of the architecture. Through this development cycle, the architect continuously fosters the sharing of customer, architecture, and technical information between organizations


CLINGER-COHEN ENTERPRISE ARCHITECT SUMMARY OF COMPETENCIES

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

2.12 Enterprise Architecture Capability Maturity Model

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

Maturity Status Name Description

LEVEL O No Program There is not a documented architectural framework in place at this level of maturity. While solutions are developed and implemented, this is done with no recognized standards or base practices. The organization is completely reliant on the knowledge of independent contributors.

LEVEL 1 Informal Program The base architecture framework and standards have been defined and are typically performed informally. There is general consensus that these steps should be performed, however they may not be tracked and followed. Organizations with an Enterprise Architecture framework at this level are still dependant on the knowledge of individual contributors.

LEVEL 2 Repeatable Program

The base architecture and standards have been identified and are being tracked and verified. At this point in the program processes are repeatable and reusable templates are starting to be developed. The need for product and compliance components to conform to the standards and requirements has been agreed upon, and metrics are used to track process area performance.

LEVEL 3 Well Defined Program

The enterprise architecture framework is well defined; using approved standard and/or customized versions of the templates. Processes are documented across the organization. Performance metrics are being tracked and monitored in relationship to other general practices and process areas.

LEVEL 4 Managed Program At this point performance metrics are collected, analyzed and acted upon. The metrics are used to predict performance and provide better understanding of the processes and capabilities.

LEVEL 5 Continously Improved Vital Program

The processes are mature; targets have been set for effectiveness and efficiency based on business and technical goals. There are ongoing refinements and improvements based on the understanding of the impact changes have to these processes.


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_agencys enterprise architecture methodology, and the corresponding core reference models to guide the business process improvement and the strategic development of the information, learning and business management 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 units process and content experts engagement, documented focus group discussion and feed-backing, and acquisition of experienced mentoring consultants and project-based research assistants.

It is to use globally accepted best practice references, and to acquire appropriate documentation tools, process methodology, technology standard references, diagramming or case tools to draw properly the process, information and technology usage scenarios and reference models, which the agency will use in the elaboration and designing of the desired learning delivery and business support systems model.


It is to introduce standard-based capability maturity assessment framework to describe the status, and to guide the business improvement requirement of the agency. It will cover capability maturity assessment on the following management performance areas of the agency: process management, information management, learning management, and IT services management.

4.0 The Deliverables:

The project resources and activities deliver the procedures, reference standards, and the enterprise architecture reference models documents. At the end, the project releases:

1. Analyzed results and documentation of the agency capability maturity assessment status on process management, information management, learning management, and IT services management.

2. Documented agreement among the agency stakeholders and management executives on the capability maturity goals, and the corresponding vision, principles and objectives of the enterprise architecture formulation of the agency.

3. Detailed documentation of the AS-IS requirement reference models of the enterprise architecture components, namely, business process, data standards, application specifications, and technology configuration.

4. Deliberation and documented agreement on the detailed composition of the TO-BE reference models of the agencys enterprise architecture components in order to meet the capability maturity goals, and to serve as the requirement references in the acquisition and development of technology-based solutions.

5. Drafted document on the Information and Learning Management System Strategic Investment Plan

6. Drafted improvement plan for the govt_agency Data Center

5.0 The Responsibilities:

5.1 The EA4govt_agency Work Group

The Agency shall compose the EA4govt_agency Work Group, whose members will come from the agency business and curricular units to provide expert knowledge and input to deliver the enterprise architecture blueprint of the govt_agency.

In the commissioned work group, are the selected process and content experts of the main business and curricular services of the govt_agency. The work group will have at least one expert representative to cover the following agency wide performance areas:

1. Customer Service Provider2. Procurement and Assets3. Budget, Accounting, Cashiering4. Human Resources and Payroll5. Central Office Administration6. Bureau Level Administration7. Regional Office Administration8. Provincial Office Administration9. Local Government Administration10. Central IT Management11. Regional, Provincial and LGU ICT Coordinator12. Attached Project Representatives13. 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 agencys enterprise architecture

2. Guide the EA4agency Work Group in the formulation, administration, and result analysis of the capability maturity assessment of the agency

3. Facilitate the elicitation, elaboration, documentation, analysis, and modeling of the enterprise architecture components using standard methods and software

4. Assist the EA4agency Project Manager to define and implement the project management methodology.

5. Guide the Project Research Assistants in the assessment and data gathering interviews and authoring of the required documentation. It includes editorial input to ascertain content accuracy and soundness of the drafted agency-wide proceeding, EA results, and agreements


6. Provide best practice guidance in the formulation of the improved reference models of the business processes, data element standards, application specifications, and technology configuration of the agencys enterprise architecture

7. Prepare and present technical information in the consultation meetings and focus group discussion on recent developments and capabilities in web application development, database building, information systems security management, and intranet and Internet services.

8. Lead EA4agency Work Group to properly engage the IT service vendors by providing business and technical knowledge in doing the solution readiness assessment of the commercial-out-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 TaskNo.

SubTask No.

Main Task or Sub Task Name EstimatedDuration

DAYS

Start Date

EndDate

Responsible TaskPrecedence

01 Organize EA4govt_agency project team

35 Days

1.1 Appointment of the EA4govt_agency Project Manager

5 OSEC

1.2 Selection and official appointment of the process and content expert representatives from the agency business units to compose EA4govt_agency Work

5 Project Manager

1.3 Acquisition of IT Management Mentoring Consultants and Project Research Assistants

5 Project Manager

1.4 Setting up of the Project Management Office, and Acquisition of Support Materials and Technology

5 Project Manager


1.5 EA4govt_agency Work Group focus group discussion on the project goals, project work plan, results expectation, tasks and processes, approaches and methodology, activity schedule, RAEW matrix, resource requirements, and people

2 Project Manager

1.1, 1.2, 1.3

1.6 Work Group capability building workshop and agreements on the EA modeling tools, documentation templates, and deliverable artifacts.

3 Mentoring Consultant

1.3

1.7 Present and submit for Executive Approval the Project Work Plan, Methodology, and Deliverables, and issuance of appropriate agency memo

5 Project Manager

1.6

1.8 Make available for actual use the EA tools, assessment forms, documentation templates, and on-line collaboration system, and the drafting of the govt_agency

5 Mentoring ConsultantProject RA

1.7

1.9 Communication to the business units of the Enterprise Architecture work schedule plan, input requirements, deliverables, and the corresponding agency directive memo.

1 Project Manager

1.5, 1.6, 1.7

Main TaskNo.

SubTask No.


DAYS

Start Date

EndDate


02 Gather data to identify the AS-IS- STATE of the agency Enterprise Architecture Components

2.1 Conduct Agency-wide survey on the capability maturity level of the agency in managing process, information, learning and IT services


1.9

2.2 Consolidate the assessment results to compose the documented capability maturity profile of the agency in managing process, information, learning and IT services.


2.1

2.3 Conduct focus group discussion with the EA4govt_agency Work Group to define the capability maturity goals to define the Agency Enterprise Architecture Framework


2.2

2.4 Conduct data gathering to build the detailed information to represent the process, data, application, and technology entities of the agency Enterprise Architecture


1.8, 1.9

2.5 Draw and draft the narrative documentation of the as-is state models of the business processes, data entities-flow-and relationship, application functional requirements, and technology configuration


2.4


2.6 Conduct focus group discussion with EA4govt_agency Work Group to validate the as-is state models of the enterprise architecture, and to determine the gaps based on the capability maturity goals of the agency.

3 Project ManagerMentoring Consultant

2.5

2.7 Conduct focus group discussion with govt_agency Executives, Directors and Chiefs to review and validate the AS-IS-STATE Enterprise Architecture Model of the agency, and the perceived gaps.

3 Project ManagerMentoring Consultant

2.6

Main TaskNo.

SubTask No.


DAYS

Start Date

EndDate


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 narrative documentation of the proposed Enterprise Architecture reference models to represent the desire state and the remedies to close the gaps

10 MentoringConsultantProject RA

2.7

3.1 Conduct consultation workshop with EA4govt_agency Work Group to review, validate and approved the define Enterprise Architecture reference models


3.2 Formulate the working paper on the functional requirements of the proposed improvement to current applications and/or new solution to be acquired or develop


3.3 Conduct consultation workshop to elaborate and improve the functional requirement definition of the improve or to be acquired ICT-based solutions


3.4 Submit the drafted Enterprise Architecture for review and comments of the agencys business and instructional units

10 Project Manager

3.5 Response gathering and analysis, and improvement of the drafted Enterprise Architecture document


3.6 Submit the improved Enterprise Architecture document to the Executive Level for review and comment

5 Project Manager

3.7 Drafting of the final version of Enterprise Architecture document


3.8 Submit the final version of the Enterprise Architecture document to the Executive Level

5 Project Manager

3.9 Information dissemination about the Enterprise Architecture to the stakeholders of the agency.

5 Project Manager


7.0 Resource Requirements and Estimated Budget

Items Categories Item Summary of Configuration TotalUnits

TotalCost

AvailabilitySchedule

TechnologySupport

Internet and Access DeviceWeb Hosting ServiceProject Management SystemDocumentation SoftwareDiagramming Software or Case-ToolsEA Templates and Artifacts Repository

Consultancy Services IT Management Mentoring ConsultantProject Research Assistant

Conduct of Assessment, Data Gathering, and Writing of R