OCIO Business process
The OCIO business process framework based on the business function diagram.
Plan and Organization processes
Acquire and Implement
Deliver and Support
Monitor and evaluate
^ TOP
OCIO Function Analysis
From the aspect of EA, the OCIO business consist of startegic planning, captital investment, applicaiton development, operation, result mesurement. It is an effort to considered all the IT managment process from a holistic view rather than by individaul processes.Many organization have analyes IT managment functions such as the :
. The OCIO Council
. ITIL
. CobiT
Leverage on COBIT framework
COBIT framework is chosed as the foundation The Control Objectives for Information and related Technology (COBIT) is a set of best practices (framework)
COBIT structure
COBIT covers four domains:
Plan and Organize
Acquire and Implement
Deliver and Support
Monitor and Evaluate
Plan and Organize
The Planning and Organization domain covers the use of information & technology and how best it can be used in a company to help achieve the company’s goals and objectives. It also highlights the organizational and infrastructural form IT is to take in order to achieve the optimal results and to generate the most benefits from the use of IT. The following table lists the high-level IT processes for the Planning and Organization domain.
HIGH LEVEL CONTROL OBJECTIVES
Plan and Organize
PO1 Define a Strategic IT Plan and direction
PO2 Define the Information Architecture
PO3 Determine Technological Direction
PO4 Define the IT Processes, Organization and Relationships
PO5 Manage the IT Investment
PO6 Communicate Management Aims and Direction
PO7 Manage IT Human Resources
PO8 Manage Quality
PO9 Assess and Manage IT Risks
PO10 Manage Projects
Acquire and Implement
The Acquire and Implement domain covers identifying IT requirements, acquiring the technology, and implementing it within the company’s current business processes. This domain also addresses the development of a maintenance plan that a company should adopt in order to prolong the life of an IT system and its components. The following table lists the high level control objectives for the Acquisition and Implementation domain.
HIGH LEVEL CONTROL OBJECTIVES
Acquire and Implement
AI1 Identify Automated Solutions
AI2 Acquire and Maintain Application Software
AI3 Acquire and Maintain Technology Infrastructure
AI4 Enable Operation and Use
AI5 Procure IT Resources
AI6 Manage Changes
AI7 Install and Accredit Solutions and Changes
Delivery and Support
The Delivery and Support domain focuses on the delivery aspects of the information technology. It covers areas such as the execution of the applications within the IT system and its results, as well as, the support processes that enable the effective and efficient execution of these IT systems. These support processes include security issues and training. The following table lists the high level control objectives for the Delivery and Support domain.
HIGH LEVEL CONTROL OBJECTIVES
Deliver and Support
DS1 Define and Manage Service Levels
DS2 Manage Third-party Services
DS3 Manage Performance and Capacity
DS4 Ensure Continuous Service
DS5 Ensure Systems Security
DS6 Identify and Allocate Costs
DS7 Educate and Train Users
DS8 Manage Service Desk and Incidents
DS9 Manage the Configuration
DS10 Manage Problems
DS11 Manage Data
DS12 Manage the Physical Environment
DS13 Manage Operations
Monitor and Evaluate
The Monitoring and Evaluation domain deals with a company’s strategy in assessing the needs of the company and whether or not the current IT system still meets the objectives for which it was designed and the controls necessary to comply with regulatory requirements. Monitoring also covers the issue of an independent assessment of the effectiveness of IT system in its ability to meet business objectives and the company’s control processes by internal and external auditors. The following table lists the high level control objectives for the Monitoring domain.
HIGH LEVEL CONTROL OBJECTIVES
Monitor and Evaluate
ME1 Monitor and Evaluate IT Processes
ME2 Monitor and Evaluate Internal Control
ME3 Ensure Regulatory Compliance
ME4 Provide IT Governance
OCIO suggest to adopt the CobiT framework as the starting point to develop the OCIO function diagram.
^ TOP
Reading instruction
Reading instruction:Pleas use the category colum on your left to navigate the contents.
Read More →
^ TOP
Notional OCIO organization
The Office of CIO should do themselves a big favor for not reinventing CIO architecture over and over by each office. After all the office of CIO is created in the concept of reuse, sharing and interoperability. IT management has been identified as a line of business (LOB) in the Business Reference Model by the Office Management and Budget (OMB). Instead of reinventing the wheel over and over by each office of CIO, it is essential to establish architecture patterns and standards which does not only allow the CIOs to reuse and share IT management resources but also enable the IT management system vendors to invest service oriented IT management system solutions which can be plug in the different CIO infrastructure
3.2.1. Establish a Technical Review Committee
The CIO should charter and appoint a Technical Review Committee to manage the review of candidate projects and assess project alignment with the EA. Once the EA has been developed and approved, the TRC assesses each proposed investment for compliance with the architecture. The TRC reports their conclusions and provides recommendations to a Capital Investment Council (CIC).
In all cases, the TRC determines and documents the results and the accompanying rationale for its actions. The TRC reviews a project and assesses if:
· The project completely aligns with the EA
· The project does not align with the EA and an alternate course of action is needed
· The project does not align with the EA and a waiver is approved.
The TRC approves a waiver only if the impacts of the lack of alignment are understood and acceptable. By approving a waiver, the TRC conveys to the CIC that it does not object to the proposed project.
3.2.2. Establish a Capital Investment Council
The Agency Head establishes a CIC to achieve informed decision making regarding costs, benefits, risks of alternative investment options and architectural alignment. The goal of the CIC is to ensure enterprise and application architecture projects are feasible from a cost-benefit standpoint. The CIC reviews proposed IT investments and makes the final investment funding decision. It accepts program and project proposals that have been assessed by the TRC and determines whether these programs/projects fit within the overall budgetary and funding goals for the enterprise. While a project may be technically aligned with the EA, the CIC may reject funding for a project because of other external constraints or budgetary reasons. CIC decisions may necessitate updates to the sequencing plan.
3.2.3. Establish an EA Executive Steering Committee
The Agency Head establishes an EA Executive Steering Committee to direct, oversee, and approve the EA and EA program. The EAESC is responsible for approving the initial EA, approving significant changes to the EA, and approving the EA Program Plan.
The EAESC should be formally chartered, with a designated chair or co-chairs, and empowered to ensure Agency-wide strategic direction, oversight, and decision-making authority for the EA. The EAESC charter should authorize the chair or co-chairs to appoint the membership. By charter, the EAESC membership should consist of active participants that represent and include all major Agency business and technology areas. To perform effectively as a decision-making body, it is crucial that the EAESC members are senior leaders, with the authority to commit resources and make and enforce decisions within their respective organizations.
3.2.4. Appoint Chief Architect
The CIO should appoint, with the Agency Head’s approval, an Agency executive to serve as Chief Architect and EA Program Manager. The Chief Architect is responsible for leading the development of the EA work products and support environment. The Chief Architect serves as the technology and business leader for the development organization, ensuring the integrity of the architectural development processes and the content of the EA products. The Chief Architect should be friend and liaison to the business line units and ensure that business unit processes are emphasized in the EA. Likewise, the Chief Architect is responsible for ensuring that the EA provides the best possible information and guidance to IT projects and stakeholders, and that systems development efforts are properly aligned with business unit requirements.
In the role of EA Program Manager, the Chief Architect has management responsibility for the EA program, with the authority, responsibility, and accountability for the overall architectural effort. The Program Manager is responsible for the planning, staffing, and ultimate success of the program, including acquisition of sustaining funding, negotiating schedules, timely and accurate delivery of the EA products, and the establishment of an appropriate support environment that ensures proper application of these assets.
The core competencies of the Chief Architect include expertise in strategic and technical planning, policy development, capital planning and investment control, change management, systems engineering and architectural design, business process reengineering, and large-scale program management. In addition, the Chief Architect becomes completely conversant with the Agency’s business and IT environments. As the primary technical leader of this effort, the Chief Architect should be a good communicator who can bridge the cultural differences that often exist between the business and systems organizations, and facilitate interaction and cooperation between these two cultures.
3.2.5. Establish an Enterprise Architecture Program Management Office
The EA effort should be treated as a formal program with full sponsorship through the Agency's CPIC process. An EA Program Management Office should be established to manage, monitor, and control the development and maintenance of the EA. The EAPMO staff includes experienced architects. The EAPMO identifies and performs cost analyses of alternative approaches for developing the EA, and manages in-house or outside contractor EA development work. The EAPMO is also charged with determining needed resources and securing funding and resource commitments.
A primary goal of the EAPMO and the EAESC is to ensure success of the EA program. Each phase of the program (i.e., EA development, use, and maintenance) is subject to the CIC policies and procedures for investment decisions.
3.2.5.1. Appoint Key Personnel
The CIO should make the EA an explicit responsibility for those individuals designated as the organization’s Evaluators, Risk Manager, and Configuration Manager. The Risk Manager identifies, monitors, controls, and mitigates EA program risks in light of environmental factors (e.g., external business constraints, and technical constraints). The Configuration Manager assumes responsibility for configuration management of the EA products in the same way that configuration management is imposed on any other engineering baseline.
The CIO should establish an independent QA organization to perform evaluation of the EA. This team should report to the EAESC and ensure all established program and project standards and processes are met. Potential sources for review include external reference groups, impartial or uninvolved external entities, or by hiring a neutral third party specializing in assessments or validations. Within the Federal government, Agencies can request their Inspector Generals to conduct an IV&V review or enlist the services of a non-profit entity such as a Federally Funded Research and Development Center (FFRDC).
3.2.5.2. Establish Enterprise Architecture Core Team
At the same time the Agency Head and CIO achieve business line ownership of the effort, a core team of IT experts, business line experts, and technologists should be assigned to develop the desired process and procedures used throughout the development effort. Participants should have an understanding of the current business and technical environment and the strategic business objectives envisioned in the EA. The team includes the Chief Architect; senior business, systems, data, infrastructure and security systems architects. This team should be well grounded in the existing environment and prepared to document and develop the EA that will support evolving business needs.
The architecture core team should include IT representatives from the Agency's applications, data, and infrastructure organizations. The specific core teamwork groups should include business analysts, data analysts, systems designers, security specialists, and systems programmers. As the program gets underway, more resources/team members are typically added to the architecture core team. The architecture core team will include program managers proficient in managing Agency-wide programs as well as interagency initiatives.
The EA core team is responsible for all activities involving the development, implementation, maintenance, and management of the architecture. This includes:
· Developing EA processes, procedures, and standards
· Developing baseline and target architectures
· Developing and maintaining an EA repository
· Performing quality assurance, risk management, and configuration management
· Guiding systems development and acquisition efforts
· Defining EA performance measures.
^ TOP
The OCIO Business Architecture
The OCIO business architecture consider the Office of Chief Information Offier as a critical Line of Busines in the information age rather than a supporting organization. E-OCIO ise essencail to enable E-Gov and E-Enterprise.The OCIO Business Architecture analysis is implemented based the Coherent EA approach in Enterprise Map and Business Architecture model. The Enterprise Map is the effort to see the big picture as the traditional map do. The OCIO Business Architecture analyze OCIO from the aspect of Mission (Why), Function (How), Information (What), Oragnization (Who), Location (Where), Performance (When)by analya their elements, structure and relation.
The OCIO Business Architecture also adopt the Coherent EA principle to lean experiences of the others. There is nothing new under the sun, after a decade, there are many long lasting EA efforts such as the A practicle guide to Federal Enterprsie Architecture by US Federal Goverment Chief Information Officers Council.
The OCIO Business Architecture leverage on past EA effort to populate the OCIO mission, function, informaiton, organization, location and performance. The OCIO have to "eat their own dog food" to render their business in architecture stytle. It is a clear advantage to render OCIO business architecture systematically in a architecture approach over the the traditional redition in a documental stytle. Hopefull, this effort will further renders the value of The CIO Council practicle guide to Federal Enterprsie Architecture which was written in 1999, and has been a very useful EA document.
Please navigate the OCIO Business Architecture by clicking on the chapters on the left column.
^ TOP