The managment structure
4.5 EA management structureFigure 4 illustrates a notional program organization to manage, control, and monitor EA activity and progress. The organization shows the desired functional roles, interrelationships, and lines of communication. The organization structure should facilitate and advance the performance of EA roles and responsibilities. The roles of the EAESC, Technical Review Committee (TRC), and the EA Program Management Office are unique to the introduction of the EA process. Other roles, such as Quality Assurance (QA), Configuration Management (CM), Risk Management (RM), Security, and Evaluation are customary IT support roles. These roles are expanded to explicitly include EA-related responsibilities.
EA roles should be evaluated based on the size of the organization, the complexity of the business and architecture, and other factors to effectively determine the correlation of roles assigned to personnel. In a large organization with complex business processes, an individual may be responsible for one specific role. In smaller Agencies or organizations, an individual may be assigned several roles and responsibilities.
Figure 1. Notional EA Organization
4.5.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.
4.5.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.
4.5.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.
4.5.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.
4.5.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.
4.5.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).
4.5.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.
Table 1 provides a listing of functional roles and the associated responsibilities assigned to EA core team members. In smaller agencies, some of these roles and responsibilities may be shared, doubled up, or contracted out.
Table 1. EAPMO Roles and Responsibilities
Role Responsibilities
Chief Architect Heads the EAPMO, organizes and manages the EA core team; directs development of the baseline and target architecture.
Senior Architecture Consultant Provides architecture strategy and planning consultation to the Chief Architect.
Business Architect Analyzes and documents business processes, scenarios, and information flow.
Applications Architect Analyzes and documents systems, internal and external interfaces, control, and data flow.
Information Architect Analyzes and documents business information (logical and physical) and associated relationships.
Infrastructure Architect Analyzes and documents system environments, including network communications, nodes, operating systems, applications, application servers, web and portal servers, and middleware.
Security Systems Architect Oversees, coordinates, and documents IT security aspects of the EA, including design, operations, encryption, vulnerability, access, and the use of authentication processes.
Technical Writer Ensures that policies, guidebooks, and other documentation within the EA repository are clear, concise, usable, and conform to configuration management standards.
Quality Assurance Ensures that all established program and project standards, processes, and practices are met.
Risk Management Identifies, monitors, and controls risks in light of environmental factors and constraints.
Configuration Control Assures that all changes are identified, tracked, monitored, and appropriately documented.
The CEA: management section elaborate the management structure
^ TOP
EA budget planning
The rival of IT budget authority between CIO and CFO has always be a hot spot to talk about. Some OCIO has managed to get budget authority but most OCIO only have minimum budget resources. The introduction on the concept of EA projects can be used to jutify the need of OCIO budget authrity. It also clarify that OCIO budget authority only covers the EA projects.EA is known to have a lot of responsibility with very limited resources because it is initiated in a stovepipe enviroment which tends to have mission oriented budget practice where EA, is more or less considered as overhead expense, is not the best place to show agency spending. As a result, EA has been a paper tiger with very little practicality.
Some EA experts has suggested to implement EA by having the authority to control IT budget. It is only a wish that in a mission orinted budget system, business owners are not about to surrender their IT budget to OCIO with the risk of respond their critical mission need.
The suggestion is that the OCIO to have the budget authority on EA projects while the business owner to control the budget authority on their misssion specific projects. It is analogy to city planning, that the city have the authority on public projects such as road, bridge, water and sewer. The business owners control their own budget authority on their misssion specific need projects similr to a business buidling.
^ TOP
EA Infrastructure
The Topology toolsThe business performance measurement
The business modeling tools
The EA repository for EA knowledge managment
Portal
Dashboard
Search
The Mitre corporation, sponsored by the CIO council, has established the architecture tool framework
The tool assessment
The IT managment systems which are considered as the CIO applicaiton systems can be described in the following framework develope by Mitre corporation sponsored by the CIO Council
Management oversight tools The systems oversight tools include investment management, portfolio management , risk management , security management .project management , procurement management , performance measurement and decision support
EA management tools are used to organize and manage the EA artifacts. It contain the enterprise automation environment, the business architecture, the IT standards, the architecture design and the transition plan. EA artifact repository should not make redundant effort to contain system artifact.
System development management tools are used to manage the enterprise system development artifact which include the requirements, the system documents, the meta data model and software version control and release management.
Design tools are used to generate design artifacts such graphic tool, and business process modeling tools , data modeling tools, and Computer Aid Designing (CAD) application development tools. are used. In application development paradigm, application developers relies on modeling tools. The design tools are used to model business activities, analyze business processes models, perform function decomposition and design data models, create application components and produce software code .
The EA infrastructure
The OCIO infrastructure is suggested to reduce the burden EA governance and compliance on the stakeholders to earn buy-in. Most of stakeholders concerned about the lengthy delay in projects due to the slow progress in governance and compliance review. To reduce the burden of EA, all the governance and compliance process must be engineering to streamline the process. LEA proposes the OCIO infrastructure concept to establish the integrated OCIO automation solution to expedite the governance and compliance process.
Managment concept of Operation :
LEA has prototyped the EA automation :
The liteEA EA portal
The prototype is developed based on the following figure:
^ TOP
Enterprise Architecture lifecycle
The LEA practice guidance, instead of reinventing wheel, leverage on many US goverment effort in particular from theA practicle guide to Federal Enterprsie Architecture by US Federal Goverment Chief Information Officers Council.
2.4. Architecture Principles
Principles establish the basis for a set of rules and behaviors for an organization. There are principles that govern the EA process and principles that govern the implementation of the architecture. Architectural principles for the EA process affect development, maintenance, and use of the EA. Architectural principles for EA implementation establish the first tenets and related decision-making guidance for designing and developing information systems.
The Chief Architect, in conjunction with the CIO and select Agency business managers, defines the architectural principles that map to the organization’s IT vision and strategic plans. As shown in Figure 1, architectural principles should represent fundamental requirements and practices believed to be good for the organization. These principles should be refined to meet Agency business needs. It should be possible to map specific actions, such as EA development, systems acquisitions, and implementation, to the architectural principles. Deliberate and explicit standards-oriented policies and guidelines for the EA development and implementation are generated in compliance with the principles. Each and every phase of the Systems Life Cycle is supported by the actions necessitated by the architecture principles. CPIC actions are governed by the implications within the principles.
2.5. The Enterprise Life Cycle
The enterprise life cycle is the dynamic, iterative process of changing the enterprise over time by incorporating new business processes, new technology, and new capabilities, as well as maintenance and disposition of existing elements of the enterprise.
Although the EA process is the primary topic of this guide, it cannot be discussed without consideration of other closely related processes. These include the enterprise engineering and program management cycle (more commonly known as the system development/acquisition life cycle) that aids in the implementation of an EA, and the CPIC process that selects, controls, and evaluates investments. Overlying these processes are human capital management and information security management. When these processes work together effectively, the enterprise can effectively manage IT as a strategic resource and business process enabler. When these processes are properly synchronized, systems migrate efficiently from legacy technology environments through
^ TOP
The Initial EA phase
Enterprise Architecture is a holistic architecture effort to overcome the challenge of stovepipe system. The initial effort of EA see the true whole of Enterprise, analyze the high level Business Architecture in its totality and conduct master plan to take advantage of technology evolution in the following sections.1. Enterprise Topology.
2. High level business architecture
3. Notional Target Architecture.
1. The Enterprise Topology
The following paragraph's describe Enterprise Topology, High level Business Architecture and Notional Target architecture. For online reading purpose, each article is partially display, pleas click on the read_more for the full article.
2. The high level business architecture
Enterprsie must be analyzed from both functional
and organic relation Enterprise Architects have to realize the it does not serve well to impose traditional architecture approach straight to business practice as have experienced in the Information Engineering or Enterprise Engineering []in the begining of Information age. It is a case in the difference between the right brain and left brain.
Business community model business based on influence diagram rather than ontology. They concern more about business outcome rather than the busisness structure. Business outcome is the end and business structure is the mean. On the other hand, scientist and engineers consider more about ontology to analyze the structure of business.
HACEA suggest to EA from the aspect of influence.
Enterprise Architects have to realize the it does not serve well to impose traditional architecture approach straight to business practice as have experienced in the Information Engineering or Enterprise Engineering []in the beginning of Information age. It is a case in the difference between the right brain and left brain.
Business community model business based on influence diagram rather than ontology. They concern more about business outcome rather than the business structure. Business outcome is the end and business structure is the mean. On the other hand, scientist and engineers consider more about ontology to analyze the structure of business.
An influence diagram (ID) (also called a decision diagram or a decision network) is a compact graphical and mathematical representation of a decision situation. It is a generalization of a Bayesian network, in which not only probabilistic inference problems but also decision making problems (following maximum expected utility criterion) can be modeled and solved.
EA is the effort to establish an explicit coherent model based on this thinking tool based on there line of business. For example: The coherent model for comercial products based on Productivity (Water), Human resources (Wood), Marketing (Fire), Finance (Earth) and Research (Meatal).
For IT strategic planning
The for relation
It describe that Research for new Product, human resources to support marketing, Marketing generate revenue, revenue to fund Research.
The aginst relation
3. Notional Target architecture to align technology to business in a holistic master plan
Notional target architecture establish the holistic enterprise architecture master plan and build the connectivity model to support decision making via impact analysis. It consist of :
The conceptual application architecture
The conceptual data architecture
The conceptual security architecture
The initial EA deliverable:
The Initial EA describe the high level and holistic view of Enterprise Topology, Business Architecture and the Notional Target architecture.
. The Enterprise Topology
. The Business Architecture
. The Notional Application Architecture
. The Notional Data Architecture
Initial EA to be available in the first year of EA effort.
Notional Target Architecture is analogy to a city plan
City manager use city plan to see the holistic city. a city use a city plan to lay out different zone, land use, street and location for public facility bases on planed business vision (The business architecture). For example: The city plan of Washington DC.
^ TOP