enterprise architecture practitioner's note -draft release

of 44 /44
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

Upload: onecitizen-network

Post on 18-Nov-2014




2 download

Embed Size (px)


Practitioner's note to understand the body of knowledge, reference framework, requirements, process, and results of doing enterprise architecture. It brings together lessons learned, third-party methods, re-usable templates and open software to properly compose the enterprise architecture blueprint for business process improvement and ICT services alignment to the strategic intents of the organization



www.onecitizen.net Version 1.2 2009

Open Practitioner's Note on Enterprise Architecture


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

Open Practitioner's Note on Enterprise Architecture


Table of ContentsINTRODUCTION:........................................................................................2 Part 1: Enterprise Architecture Framework........................................................41.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..............................................................92.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

Open Practitioner's Note on Enterprise Architecture


Part 1: Enterprise Architecture Framework1.0 Health Check on the Practice of Enterprise ArchitectureDoes your agency maintains a blueprint or matrix of all running systems, showing how they inter-operate, and which technology they are using? Can your agency readily presents the professional and business user matrix dovetailed to their requirements, and to the technology services that address those requirements? 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? Are there silos of data and application in the different units of the agency? 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? Is there a formal stage in the project life cycle where system architecture is being checked against the enterprise architecture? If you have any question or problem regarding architecture do you know who to seek for guidance, decision and documentation? Is there an official guidance and listing of all business standards, methods and tools, technical references that both IT and Business have to use, or you can use whatever technology you want?YES YES NO NO NOT SURE NOT SURE













1.1 Enterprise ArchitectureEnterprise 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, Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

accountability, interoperability, security and quality goals of the organization.

CLINGER-COHENEnterprise 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 ArchitectureSchekkerman, J. (2005). Trends in Enterprise Architecture, Institute for Enterprise Architecture Development, white paper. VALUE INDICATORS AlignmentDESCRIPTIONS 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. Enterprise architecture establishes the infrastructure that enables business rules to be consistently applied across the organization, documents data flows, uses and interfaces. 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 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 Enterprise architecture provides the artifacts necessary to ensure legal and regulatory compliance for the technical infrastructure and environment.


Value Creation

Change Management


Open Practitioner's Note on Enterprise Architecture


1.4. Enterprise Architecture PrinciplesThe 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.


DESCRIPTION Decision is aligned with the organizations strategic direction, furthering measurable improvement in performance, achievement of business needs, and citizen/customer satisfaction. Decision reflects the best interests of key stakeholders, and complies with applicable legal mandates and federal directives. Decision eliminates a gap in capability required by the organization to achieve its strategic goals. Decision reduces costs and burden while maintaining and/or improving quality and security. Decision eliminates or prevents non-value added activities. Decision prevents or removes unnecessary redundancy, resulting in consolidation of best-in-class standards and components that are consistent, reused and shared. Decision expands availability of assets, making them easier to use and understand and more readily accessible to a broader set of stakeholders. Decision reduces friction or resistance to change, thereby expediting the organizations ability to rapidly and completely scale and respond to forces of change. Decision enhances integration and connectedness. Decision enhances stability, quality, and confidence that the result is available and correct. Decision enhances security and privacy. Changes are managed and controlled to expedite development, minimize disruption and risk, and are sequenced to maintain order.









Open Practitioner's Note on Enterprise Architecture


1.5 Questions of Enterprise ArchitectureZachman 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.






WHY Strategist Executive Architects Engineers Technician Worker






Open Practitioner's Note on Enterprise Architecture


Enterprise Architecture Components Grid Derived from Zachman Framework

WHATSCOPE List of things and Inventory types important to the enterprise domains.

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

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

WHOIdentification of scope organization experessed in terms of organization and stakeholders important to the business. Identificaiton of the organization model which relates business role to business work, and to other peer business roles.

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

WHYIdentification of scope motivation expressed in terms of motivation types like mandate, policy directives, business goals and strategies. Identification of the business ends and business means that motivates the organization


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. List of systems process that transforms systems input

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

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


List of system entity and relationship

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


List of technology List of List of technology List of technology entity and specification location and role and work relationship technology connection process and technology input Inventory Configuration Proess Configuration Network Configuration Operation location and connection Organization Configuration Organization role and work

List of technology List of cycle and technology moment means and ends


Timing Configuration Operation cycle and moments

Motivation Configuration Operation ends and means

Operation entity Operation and relationships transform operation input

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

Open Practitioner's Note on Enterprise Architecture


Part 2: Doing Enterprise Architecture2.1 Enterprise Architecture ComponentsThe 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

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

BUSINESS-Business Reference Model -Business Process Maturity Model

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

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

PEOPLE-Capability Maturity Model -Governance Model

Open Practitioner's Note on Enterprise Architecture


Enterprise Architecture Components Elaboration BUSINESS ARCHITECTUREUnderstanding 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.


It defines how data is stored, managed, and used in a system. It establishes common guidelines for data operations that make it possible to predict, model, and control the flow of data in the system. It describes the structure of an organization's logical and physical data assets and the associated data management resources

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


Application architecture 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

Hardware Platform Operating System Application System Database System Network & Communication System Security System Enterprise Systems Management Development Methods It describes the hardware, software and Technical Standards network infrastructure needed to support Interoperatability References the deployment of core, mission-critical applications. 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 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 Standards Organizational Chart Training Program Instructional Design Job Performance Evaluation


Open Practitioner's Note on Enterprise Architecture


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

A. Architecture Visioning

Open Practitioner's Note on Enterprise Architecture


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

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

D. Technology Architecture Definition

E. Opportunities and Solutions Identification

F. Migration Planning

Open Practitioner's Note on Enterprise Architecture


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

H. Architecture Change Management

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

2.3 Enterprise Business Process AnalysisBusiness 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 referencemodel?

Industry Segment: Business Domain Scope: Business Area:

What industry sector the business is identified? (retail, manufacturing, education, regulatory, etc.) What are the scope category of the business area in terms of the primary functions to fulfill? (ordering, delivery, billing, etc.) What are the collection of business process (tasks) in the defined scope category? (order registration, order review, order reply, order confirmation, etc..) 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.) What are the business organization components and their entity relationships?

Business Outcomes:

Business Organizational Tree

Open Practitioner's Note on Enterprise Architecture


Business area is the category to speak about the group of business processess that fulfills a primary business function. Business Area Name: Function Category: Description: Objective: Opporunity: Scope Boundary ReferencesWhat is the standard name to assign to the business area that associate it properly to the business reference model? What is the primary function of the business organization being served by the business area? What describes briefly the nature and value of the business area in relation to the business function? What are the specific outcomes expected from the business area? What kind of business opportunity being addressed by the business area? What are the included and excluded activities, relationship, and information of the defined business area? What are the parameters of business entity relationship in terms of users, organization, data, location, etc.. that exist in the business area? 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} 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...) Who are the people and organization whose knowledge and interest are important to the definition and activities of the business 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 Area Definition


Stakeholders Process Area

Business Performance AssessmentGoals Question and Metrics (GQM) of Business Tool to measure and report the business efficiency and effectivity.Conceptual/Goal Operational/Question Quantitative/Metrics Set of objectives that represent various viewpoints relative to specific business environment 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 Set of measurement that answer the questions.

GQM ANALYSIS PARTCritical Success Factor Key Performance Indicator Object Purpose Focus Environment Viewpoint

DESCRIPTIONWhat are the attributes of succesful performance? What are the means to measure achievement of success? What is the Object (product, process, service, etc.) under analysis? What is the motivation behind the analysis of the object? Which quality attributes of the object is under analysis Under what context is the analysis to occur Whose perspective does the analysis of the object reflect

Open Practitioner's Note on Enterprise Architecture


Worksheet 01: Business GQM Analysis Worksheet Business Domain:Business Process Critical Success Factor Key Performance Indicators Object

Business Area:Purpose Focus Environment Viewpoint

Balanced Scorecard A balanced scorecard uses financial data, operational measures, customer satisfaction, internal processes and the organization's innovation and improvement activities - indicators of future financial performance - to assess business performance. (Source: Management and Technology Dictionary) (2) A scorecard is an evaluation device, usually in the form of a questionnaire, that specifies the criteria customers will use to rate your business's performance in satisfying their requirements. (Source: American Society for Quality - Quality Glossary) The Question of Balanced Score Card: POINT OF VIEWS Financial Perspective Customer Perspective Business Process Perspective Learning and Growth Perspective INTERROGATIVES To succeed financially how should we appear to our stakeholders? To achieve our vision, how should we appear to our customers? To satisfy our stakeholders and customers, what business processes must we excel at? 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 WorksheetBusiness 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



FUNCTIONSCore Functions




Special Functions

Open Practitioner's Note on Enterprise Architecture







Worksheet 02: Information Requirement Mapping Matrix












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.



ACTORActor 1

TASKS LANEStep 1 - Start Step 4



Actor 2 Actor 3

Step 2 Step 3

Step 5

Open Practitioner's Note on Enterprise Architecture


Process Swim Lane Components

Lanes: Actors: Process: Phases:

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. The people, groups, teams, etc, who are performing the steps identified within the process he actual process and flow that is being tracked through its identified progression steps. 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. These are the physical symbols used to graphically represent what is happening in any given step of the process.


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

Open Practitioner's Note on Enterprise Architecture


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 Use Case ID Use Case Name DESCRIPTIONSGive 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. 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. 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 History

Use Case Defintion ActorsAn 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. 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. 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. 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. 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


Description Preconditions


Open Practitioner's Note on Enterprise Architecture


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

Alternative Flows



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. 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. Estimate the number of times this use case will be performed by the actors per some appropriate unit of time. List any business rules that influence this use case. 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 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. 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.


Frequency of Use Business Rules Special Requirements Assumptions Notes and Issues

Sample Use Case Modeling

Find more about UML modeling and notation at www.uml.org. Open Practitioner's Note on Enterprise Architecture www.onecitizen.net

2.6 Enterprise Information Maturity Model

Learn more about information management methodology at www.mike2.openmethodology.org. MATURITY STAGE LEVEL 1 Aware LEVEL 2 Reactive DESCRIPTIONS 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. 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. 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. 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. 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.

LEVEL 3 Proactive

LEVEL 4 Managed

LEVEL 5 Optimized

Open Practitioner's Note on Enterprise Architecture


2.7 Enterprise Information Data Analysis Data DictionaryData 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 Data Element Domain Name

DESCRIPTIONS A data content topic, for example, a named data collection protocol EMAP. Note there may be multiple domains or subdomains within a particular data dictionary. A number associated with the data element name for use in technical documents. Commonly agreed, unique data element name. Note: there are likely to be multiple data element names for a particular domain. 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). Description of the meaning of the data element Scientific or other unit of measure that applies to the data element. The level to which the data will be reported, eg 1 mile plus or minus .001 mile The type of data (e.g. Characters, Numeric, Alpha-numeric, date, list, floating point). 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). 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). A value that is predetermined. It may be fixed or a variable, like current date and time of the day. An example of the actual data layout required, (e.g. yyyy/mm/dd). 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 Element Number (for reference in data model) Data Element Name

Data Element Field Name

Data Element Definition Data Element Unit of Measure (uom) Data Element Precision Data Element Data Type Data Element Size and Decimalization

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

Default Value Edit Mask (e.g. of actual layout) Data Business Rules

Open Practitioner's Note on Enterprise Architecture


Data Flow Diagram

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

Open Practitioner's Note on Enterprise Architecture


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

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

Yourdon and Coad Process Notations

Gane and Sarson Process Notation

Open Practitioner's Note on Enterprise Architecture


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 DiagramExternal Entity The symbol represents sources of data to the system or destinations of data from the system.

Data Flow The symbol represents movement of data.

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

Open Practitioner's Note on Enterprise Architecture


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

ASSESSMENT CATEGORIES Functionality Usability Quality Security Performance Scalability Architecture Support Documentation Adoption Community Professionalism

DESCRIPTION How well will the software meet the average users requirements? 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? Of what quality are the design, the code, and the tests? How complete and error-free are they? How well does the software handle security issues? How secure is it? How well does the software perform? How well does the software scale to a large environment? How well is the software architected? How modular, portable, flexible, extensible, open, and easy to integrate is it? How well is the software component supported? Of what quality is any documentation for the software? How well is the component adopted by community, market, and industry? How active and lively is the community for the software? What is the level of the professionalism of the development process and of the project organization as a whole?

Software Quality Characteristics CHARACTERISTICS 1 2 3 4 5 6 FUNCTIONALITY RELIABILITY USABILITY EFFICENCY MAINTAINABILITY PORTABILITY Attributes Accuracy, Suitability, Interoperatatibility, Compliance, Security Maturity, Fault Tolerance, Recoverability Understandability, Learnability, Operability Time Behaviour, Resource Utilization Analysability, Changeability, Stability, Testability Adaptability, Installability, Conformance, Replaceability

Open Practitioner's Note on Enterprise Architecture


Worksheet: Application Functional WorksheetTasks Activities Functional Features Non-Functional Features

Worksheet: Usability Status and Interface Requirements Matrix Use of ProductAttributes Effectiveness Efficiency Satisfaction Understandability Learnability Operability Level 1 Level 2 Level 3 Level 4

User Interface and InteractionMenu Interface Pages Navigation Color Fonts and Styles

Open Practitioner's Note on Enterprise Architecture


2.9 Enterprise Technology ConfigurationViewing the Enterprise Technology Domain

Technology Domain Technology Devices



Hardware and Peripheral Front-End Services Devices Gadgets, and their Back-End Services Devices capability Configurations Network and Communications Devices Software and Licenses, and their Functional and Non-Functional Features Workstation Operating Systems and User's License Servers Operating Systems and Client Access 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 Device Warranty and Maintenance Service Level Agreements Software Maintenance Service Level Agreements Network and Internet Provision Service Level Agreements Help Desk Service Level Agreements Application Developers Network Administration and Support Database Administration and Support Web Services Administration and Support Security Administration and Support Technology Project Management IT Service Management Process ISO Security ISO Business Process Management Notation Project Management Security Management Network Management Data Management

Technology Programs

Technology Supports

Service Levels and Performance Terms of References

Technology Skills

Specialist and Experts, and their specifications of knowledge, skills and experiences

Technology Standards and Compliance Certification

Methods, Systems

Technology Power Management Technology Network and Bandwidth Technology Development

Electricity Generation and Uninterrupted Power Supply Terminal Points and Internet Services Modeling and Authoring

Power Generators Surge and Spikes Protector Network Point of Presence Bandwidth Quantity and Quality of Experience Diagramming and Case Tools www.onecitizen.net

Open Practitioner's Note on Enterprise Architecture

Tools Technology Business Process Models

Tools Process mapping and use case, business organization, policies and rules Data Dictionary and Data Flow Diagrams Safekeeping of technology data and information, and the conventions. Application Use Cases, and Entity Relationships, Functional Elements, Verification and Validation References Safety, integrity and confidentiality protectors

Code Writing Standards and Languages Business Domains and Locations Process Maps Business Organization Functional Charts Business Procedures, Applied Rules and Policies Data Dictionary Data Flow Diagrams Data Physical References Data Logical References Storage systems File Structures and Naming Conventions

Technology Data Models

Technology Program Logic Model

Application Conceptual Model and Functional Elements Application Use Case Model Application Validation and Verification References Application Work flow and Entity Relationships application Usability References Security Policies Acceptable Behaviors Security Work flow Security Solutions Digital Forensics Security Risks Mitigation Service Delivery Processes Service Support Processes Strategy Alignment Process Acquisition Strategy and Process Solution Development Processes Services Life-Cycle

Technology Security Model

Technology Strategic, Tactical and Operational Processes and Metrics

Service Objectives, Tasks, Activities, key performance indicators and critical success factors Management and control of requirements definition, planning, execution, evaluation and continual improvements Security and healthy references of the place of work.

Technology Governance

Organizational Structure Roles and Responsibilities Decision Trees

Technology Services Work Area

Physical Layouts Security Layouts Utility Configurations Physical Plans

Open Practitioner's Note on Enterprise Architecture


Worksheet: Technology Components DefinitionsCOMPONENTS Hardware Platforms Operating System Application System Database System Network & Communication Security System Enterprise System Management Development Methodologies Data and File Standards Interoperatability ASSETS CONFIGURATION METRICS STANDARDS

Open Practitioner's Note on Enterprise Architecture


2.10 Information Security ModelThe 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 PHYSICAL SECURITY USER SECURITY DESCRIPTIONS Securing access to hardware, inventory, and disposition of physical equipment and records. 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. ensuring that an application that accesses another application or data is secure; includes the analysis of distributed, proxy, and middleware services. 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. 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. It includes the physical and electical links between the desktop and the host, LAN/WAN, use of internet, dial-up, wireless. 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.) 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. Viruses, Trojans, spyware, and other malicious code. coordinated incident response for miscellaneous incident that may occur across the state.






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

Open Practitioner's Note on Enterprise Architecture


2.11. Enterprise ArchitectTOGAF ENTERPRISE ARCHITECT RESPONSIBILITIES TASKS Understand and interpret requirements DESCRIPTIONSProbe for information, listen to information, influence people, facilitate consensus building, synthesize and translate ideas into actionable requirements, articulate those ideas to others. Identify use or purpose, constraints, risks, etc. The architect participates in the discovery and documentation of the customer's business scenarios that are driving the solution. The architect is responsible for requirements understanding and embodies that requirements understanding in the architecture specification.

Create a useful model

Take the requirements and develop well-formulated models of the components of the solution, augmenting the models as necessary to fit all of the circumstances. Show multiple views through models to communicate the ideas effectively. The architect is responsible for the overall architecture integrity and maintaining the vision of the offering from an architectural perspective. The architect also ensures leverage opportunities are identified, using building blocks, and is a liaison between the functional groups (especially development and marketing) to ensure that the leverage opportunities are realized. The architect provides and maintains these models as a framework for understanding the domain(s) of development work, guiding what should be done within the organization, or outside the organization. The architect must represent the organization view of the architecture by understanding all the necessary business components

Validate, refine, Verify assumptions, bring in subject matter experts, etc. in order to improve the model and to and expand the further define it, adding as necessary new ideas to make the result more flexible and more tightly linked to current and expected requirements. modelThe architect additionally should assess the value of solution-enhancing developments emanating from field work and incorporate these into the architecture models as appropriate.

Manage the architecture

Continuously monitor the models and update them as necessary to show changes, additions, and alterations. Represent architecture and issues during development and decision points of the program. The architect is an "agent of change", representing that need for the implementation of the architecture. Through this development cycle, the architect continuously fosters the sharing of customer, architecture, and technical information between organizations

Open Practitioner's Note on Enterprise Architecture


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 ModelThe 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 LEVEL O

Status NameNo Program

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


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



Well Defined Program


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. Continously Improved Vital Program The processes are mature; targets have been set for effectiveness and efficiency based on business and technical goals. There are ongoing refinements and improvements based on the understanding of the impact changes have to these processes.


Open Practitioner's Note on Enterprise Architecture


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

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

Open Practitioner's Note on Enterprise Architecture


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

Open Practitioner's Note on Enterprise Architecture


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

Open Practitioner's Note on Enterprise Architecture


The team member is required to attend project meeting, focus group discussion, and consultation workshops. He/she is tasked to gather expected data, and to articulate on behalf of the represented agency entity the necessary knowledge input to compose the deliverables of the enterprise architecture. He/she shall assist the project research assistant in the conduct of assessment and data gathering in his/her represented business or learning management entity of the govt_agency . 5.2 EA4govt_agency Project Manager The EA4govt_agency Work Group will be managed by an EA4govt_agency Project Manager, who will insure the delivery of the Enterprise Architecture for govt_agency, and he will work directly with the IT Services Director of the Agency who in turn is responsible in communicating project requirements, decision needs, and deliverable status to the Office of the Secretary. The EA4Egovt_agency Project Manager has the following responsilities: Lead the project team through each stage of the project, and insure resources provision. Identify organization politics and work well within those politics. Supervise collection of input from project stakeholders to efficiently compose the enterprise architecture requirements. Establish and manage realistic and committed project schedules; taking into consideration deadlines, dependencies, resources, and costs when making changes and decisions to schedule. Communicate and maintain project progress on meetings and status reports. Ensure that all the project tasks and deliverables remain on track and within cost Identify and manage all issues and risks on the project. Review and approve deliverables before their release to the project stakeholders. 5.3 IT Management Mentoring Consultants The EA4govt_agency Work Group and Project Manager will be assisted by a contacted external Information Technology Management Mentoring Consultants. The mentoring consultant must have designed and implemented the full development cycle of an information and communication management system in an agencyal organization; done researches and conducted mentoring services related to enterprise architecture, systems development project management, and IT governance in government agencies and agency related organization; and who have professional training and implementation experiences in web application services, database systems, and security applications. He must have at least a minimum of ten (10) years of management experience in ICT service delivery and support. The consultative engagement involves the following responsibilities: 1. Develop the training design and learning materials to assist EA4EAGENCY Work Group to understand, evaluate, and design the procedures and requirements of formulating the agencys enterprise architecture 2. Guide the EA4agency Work Group in the formulation, administration, and result analysis of the capability maturity assessment of the agency 3. Facilitate the elicitation, elaboration, documentation, analysis, and modeling of the enterprise architecture components using standard methods and software 4. Assist the EA4agency Project Manager to define and implement the project management methodology. 5. Guide the Project Research Assistants in the assessment and data gathering interviews and authoring of the required documentation. It includes editorial input to ascertain content accuracy and soundness of the drafted agency-wide proceeding, EA results, and agreements

Open Practitioner's Note on Enterprise Architecture


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

OSEC Project Manager

1.3 1.4

5 5

Project Manager Project Manager

Open Practitioner's Note on Enterprise Architecture





EA4govt_agency Work Group focus group discussion on the project goals, project work plan, results expectation, tasks and processes, approaches and methodology, activity schedule, RAEW matrix, resource requirements, and people Work Group capability building workshop and agreements on the EA modeling tools, documentation templates, and deliverable artifacts. Present and submit for Executive Approval the Project Work Plan, Methodology, and Deliverables, and issuance of appropriate agency memo Make available for actual use the EA tools, assessment forms, documentation templates, and on-line collaboration system, and the drafting of the govt_agency Communication to the business units of the Enterprise Architecture work schedule plan, input requirements, deliverables, and the corresponding agency directive memo. Main Task or Sub Task Name


Project Manager

1.1, 1.2, 1.3


Mentoring Consultant



Project Manager




Mentoring Consultant Project RA Project Manager




1.5, 1.6, 1.7

Main Task No. 02

Sub Task No.

Estimated Duration DAYS

Start Date

End Date


Task Precedence






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


Mentoring Consultant Project RA Mentoring Consultant Project RA





Mentoring Consultant Project RA



Mentoring Consultant Project RA

1.8, 1.9


Mentoring Consultant Project RA


Open Practitioner's Note on Enterprise Architecture




Conduct focus group discussion with EA4govt_agency Work Group to validate the as-is state models of the enterprise architecture, and to determine the gaps based on the capability maturity goals of the agency. Conduct focus group discussion with govt_agency Executives, Directors and Chiefs to review and validate the AS-IS-STATE Enterprise Architecture Model of the agency, and the perceived gaps. Main Task or Sub Task Name Compose the reference domain model documents of the To-Be Enterprise Architecture of the agency, and the Information and Learning Management System Strategic Solution Models. Draw and draft the initial narrative documentation of the proposed Enterprise Architecture reference models to represent the desire state and the remedies to close the gaps Conduct consultation workshop with EA4govt_agency Work Group to review, validate and approved the define Enterprise Architecture reference models Formulate the working paper on the functional requirements of the proposed improvement to current applications and/or new solution to be acquired or develop Conduct consultation workshop to elaborate and improve the functional requirement definition of the improve or to be acquired ICT-based solutions Submit the drafted Enterprise Architecture for review and comments of the agencys business and instructional units Response gathering and analysis, and improvement of the drafted Enterprise Architecture document Submit the improved Enterprise Architecture document to the Executive Level for review and comment Drafting of the final version of Enterprise Architecture document Submit the final version of the Enterprise Architecture document to the Executive Level Information dissemination about the Enterprise Architecture to the stakeholders of the agency.


Project Manager Mentoring Consultant



Project Manager Mentori