The governance approach
EA is not only about architecture excellence and optimization, the EA community must take the human aspect of political consideration. Architecture and engineering design alone can not achieve the goal EA goal to bridge strategy and execution.Communicate with stakeholders using comprehensible Architecture products
Communicate the EA information to stakeholders are essential to achieve architecture buy-in. It is very difficult to comply with the architecture design without knowing the enterprise architecture. The EA group must communicate throughout all processes steps and phases, using any and all forms of outreach media possible (including e-mail, brown-bag lunches, formal presentation, and, of course, a comprehensive and customer –friendly web site). Communication must be both internal and external at appropriate intervals. [12]
John Zachman suggests [18] that EA artifacts must be graphically presented . He writes that :
“I would further suggest that ultimately, the Enterprise will require that these artifacts must necessarily be graphically presented because at the point in time when you will need the artifacts, you won’t have the time to read through a thousand pages of text to attempt to discern their implications “
The author have developed the classical hand-drawn architecture drawing in addition to mechanically generate drawings. A hand-drawn sketch today can often be far more valuable then a fully documented and validated document several months from now [2]. Hand-drawings capture the architecture thinking on the paper which facilitate the thinking process.
The author also developed the e-PEA approach which deliver comprehensive architectural products using web technology. e-PEA is not only a web publishing tool to disseminate to post the picture and document on the web for down load but also a web application which automate the integrate EA process and manage the EA information.
EA governance is an integral part of EA
Architecture governance consist of architecture buy-in and compliance as show in the following figure. (figure 1) Scott W. Ambler, one of the authors in the Practical Guide to Enterprise Architecture[10], says that Enterprise architecture is all about people, so it is futile to put together an EA governance program based on a “command and control” approach without the participation of stakeholders [2]. The PEA governance process places the political process for making and enforcing IT-related business policies into the business realm of the enterprise.[3] It is similar to the legislative process in a government., the legislative process empowers the legitimacy of enforcement of the standards and regulations.
Figure 1 : The approach framework
Based on stakeholder needs through change request and management
The EA architects are the facilitators to bring the needs of the stakeholders and the goal of EA together rather than as the owner to command and control the governance process. The design of governance processes between investment management, project management, procurement management, system development life cycle must consistent to the EA goal of sharing and reuse.
The standards and regulations is not limited to architecture technology standards as perceived by many organizations. The EA governance process must be integrated to suit the best for the enterprise culture and protect the investment. In a EA environment, the stakeholders follow the standards and regulation on investment management , project management, procurement management , system life cycle development, application design, data design and technology design as shown in the following governance framework. (figure 2)
Figure 2 : The governance framework
The standard and regulation are maintained based on what the stakeholder needs which is the key to achieve architecture buy-in. The problem is how to find out what the stakeholder want in EA. In application development under the same owner, the system architect can develop a requirement document based on what the owner want. However, in enterprise architecture there are many stakeholders, it is impossible to develop a requirement to satisfy every one. The enterprise establish robust change request processes for the stakeholders to input their needs on establishing the EA standards and regulations.
Leverage on existing environment
Documenting the existing environment is the fundamental of EA. A managed chaos is better than an out of control chaos. Why the effort of documenting existing environment? Starting from a clean sheets for optimization is not a realistic option for most of exiting enterprise, there are many reasons for an enterprise to become the way it is. EA can not bring the business and technology together without knowing the reasons behind the way it is.
Many people have thought that documenting existing environment is trivial because it is exiting and it is all there. It is easy to see a tree but it is not trivial to see the forest. Documenting the existing environment to map out the enterprise is a major effort in EA. It required systematic engineering approach to document the existing environment for the enterprise similar to the national geographical survey to the country.
Documenting existing environment offer a solution to architecture buy-in. It establish a sense of community to the stakeholders toward architecture compliance. The best architecture compliance enforcement is among the stakeholders rather than totally relies on the government. In urban planning, the sense of community and culture have been a major driver for architecture compliance. For example, neighbors in a subdivision keep up with each other to follow the standards and regulation. Existing environment support
Pattern recognition from documenting existing environment offer a solution to the EA “paralysis by analysis”. The effort of Enterprise Resources Planning approach with the concept of generic model have encountered different bottle because of every enterprise has it own culture and one size does not fit all. Documenting the existing environment tells the most of what the stakeholders need. Pattern recognition from the existing environment establish building blocks to best suit the agency’s particular organization, culture, and internal management practices.
Rediscover the business driver of enterprise workload analysis and performance requirements (WAPR)
WAPR has been overlooked in the traditional EA approach, it is merely considered as the operation characteristics for the application systems. PEA rediscovers that WAPR is equally a important business driver as the enterprise function requirements. It is not possible for the engineering of sharing and reuse without knowing who are the stakeholders, where are they and when is the peak demand. The business architecture (figure 3) is composed of function requirements and performance requirements rather than as a business process centric model. The function requirement consists of the information (what) and the business process (how). The performance requirement consists of the organization (who), the location (where) and the peak hour of business activities (when) as shown in the following figure.
WAPR is a major business driver whether it is industrial age or information age. The tangible information about the enterprise organization, the enterprise location and when is the peak hour does not require exhaustive analysis effort.
Figure 3 : Business Architecture Model
Target on the Common IT resources instead of designing the entire enterprise
EA to target on the common IT resources instead of designing the entire enterprise blueprints. This approach has fundamentally modified the traditional EA approach which calls for designing the enterprise wide blueprint with a good reason. It is difficult to get every one to agree every thing in the enterprise but there is always a common denominator on which they can all agree upon. The city planners do not design every building in the city either, instead, they only design the city infrastructure for the same reason.
The traditional EA target to design the entire enterprise blueprint have been a major cause for the EA “paralysis by analysis”. First all, it is a overwhelming effort for most agencies to design the all the application system. Second, the enterprise wide business process reengineering is more art than science [6] , The enterprise wide business process reengineering effort frequently resulted EA “paralysis by analysis”.
From the perception of maturity, optimization must be established on an managed environment. Business process reengineering is an optimization effort which can only be successful on a managed enterprise IT environment. Target on the common IT resources to establish a managed environment is essential for the success of taking advantage of technology evolution.
John Zachman’s stated [17] in “ the Enterprise Architecture Artifacts Vs Application Development Artifacts ,” :
“ Based on the Framework for Enterprise Architecture, I would suggest that Enterprise Architecture is the set of primitive, descriptive artifacts that constitute the knowledge infrastructure of the Enterprise. …Reuse or interoperabitliy does not happen by accident. It is the result of engineering “ .
The definition of IT resources is adopted from the definition of IT infrastructure by Simon Liu who is the architecture/standards subject area editor in the IEEE IT Professional Editorial Board. He state in [9]:
“IT infrastructure as a set of IT resources and organizational capability that employees share across the organization. Infrastructure provides on which to develop business application and support business processes … IT infrastructure provides standardized services offering and leverage a uniform delivery mechanism across application. Although users might select from many options, customization of infrastructure services is minimal or non-existent. . Rather than develop customized services and solutions that map to the requirement of individual applications, an infrastructure service provider seeks to provide a standard service to multiple application “
The following common IT resources framework (figure 4) is evolved from the Zachman framework in a explicit expression. The EA stakeholders can comprehend the enterprise big picture to see the forest from the business architecture. Not knowing what is available resources is a major problem in EA. This framework clearly render the available common IT resources and the stakeholder can leverage on the available common IT resources from the application service architecture, data service architecture and the technology services architecture.
Figure 4 : Common IT resources framework
Design enterprise technology architecture direct from enterprise workload and performance analysis
This is the other fundamental modification on the traditional EA approach to establish enterprise technology architecture direct from the enterprise workload analysis and performance requirements instead of waiting for the enterprise wide application system design. Deliver proven value to the stakeholder is the most persuasive measure to earn buy-in from the stakeholders. In the traditional EA approach, the stakeholder will not see the technology architecture until all application systems are designed. It takes too long and too late for the immediate need .
The PEA model to establish enterprise architecture from workload and performance requirements is based on the concept that function requirements drive the logical architecture, and performance requirements drive the physical architecture as described by Mary Konx, an analyst in the Gartner group, she stated that [7]
“Logical architecture are the principles that guide the design of an enterprise data and application logic assets and the messages that pass among them, regardless of whether these assets are based on current systems, purchased application packages, outsourced services or in-house development. Logical architecture transcend immediate application functionality future states of its IT design. Logical architectures differ from physical architectures, “
Technology architecture is independent of business logic; it is a function of enterprise workload and performance requirements. For example: a complicated application system can run on a PC to support a person, or runs on a mainframe to support the enterprise. This is shown by the evolution of platform-independent languages such as XML, JAVA, J2EE, .NET, Message brokers and Web services.
The PEA model in the following figure (figure 5) indicate that an enterprise can establish enterprise common IT services based on enterprise workload analysis for the engineering of sharing and establish the building blocks based on pattern analysis for the engineering of reuse.
Figure 4: The PEA Model
Figure 5 : The PEA Model
Adopt service oriented architecture
In the same principle of proving the values to earn architecture buy-in, it is suggested to adopt services oriented architecture approach which provides building blocks for agile application system development. It allows the business manager to concentrate their effort on the business rather than worry about application system development.
Pattern analysis technique is essential to establish service oriented architecture approach. The book of “ patterns for e-business” [1} says that patterns are like Lego blocks which help us to assemble solutions rapidly and achieve high levels of best and component reuse within an enterprise. The service oriented architecture avoid the EA “paralysis by analysis” by encapsulating reusable business objects in the building blocks .
The Federal Enterprise Architecture Program Management Office have adopted the services oriented approach to define the following reference models (figure 6) which lay out the basic building blocks for enterprise architecture effort.
Figure 6 : FEAPMO service architecture framework
The following table summarize how the solutions works.
Solutions Overcome the challenge of architecture buy-in from stakeholders. Avoiding EA “paralysis by analysis”
Thinking EA as urban planning rather building a house Model EA after urban planning which has historically resolve the challenge of buy-in from the stakeholders. Clarify that EA is not enterprise wide business process reengineering and application system design to avoid EA “paralysis by analysis”.
Communicate with stakeholders with comprehensible architecture products The first step toward architecture by-in from stakeholders is to communicate stakeholders with comprehensible architecture products. It is difficult to buy-in without knowing what it is.
EA governance is an integral part of EA. EA consist of the EA governance and EA design. The value of EA design is delivered through the mechanism of EA governance.
Based on stakeholder need through change requests and management Architecture governance is achieved based on consensus. Rules and guidelines are established with the participation of stakeholders similar to legislative process.
Leverage on existing environment Sense of community has been a major driver for architecture buy-in. Well maintained exiting environment provide the stakeholders a sense of community. Pattern recognition from the exiting environment to establish building blocks and avoid redundant detail analysis.
Rediscover the business driver of enterprise WAPR. To achieve architecture buy-in, It is important to know the stakeholder organization, location and workload. Enterprise workload analysis and performance analysis are established practices which do not lead to the paralysis by analysis.
Target on Common IT resources rather than on the entire enterprise blueprint It is difficult to get people agree on every thing in a community. But there is always a common interest on which they can agree upon. Concentrating on common IT resources provide a focus on EA design and avoid EA “paralysis by analysis”.
Establish enterprise technology architecture from enterprise workload and performance requirements. PEA deliver the value of EA by establishing enterprise technology architecture in time for practical use. Establish enterprise technology architecture based on enterprise performance requirement without exhaustive business logic analysis.
Adopt service oriented architecture Services oriented architecture provide the building blocks for rapid application development to prove the value of EA. Service oriented architecture using pattern analysis provide the building blocks to avoid the “paralysis by analysis”
^ TOP
Change Control
Change control within Quality management systems (QMS) and Information Technology (IT) systems is a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner. It reduces the possibility that unnecessary changes will be introduced to a system without forethought, introducing faults into the system or undoing changes made by other users of software. The goals of a change control procedure usually include minimal disruption to services, reduction in back-out activities, and cost-effective utilization of resources involved in implementing change.Change control is currently used in a wide variety of products and systems. For Information Technology (IT) systems it is a major aspect of the broader discipline of change management. Typical examples from the computer and network environments are patches to software products, installation of new operating systems, upgrades to network routing tables, or changes to the electrical power systems supporting such infrastructure.
There is considerable overlap and confusion between change management, configuration management and change control. The definition below is not yet integrated with definitions of the others.
Certain experts describe change control as a set of six steps[who?]:
Record / Classify
Assess
Plan
Build / Test
Implement
Close / Gain Acceptance
Record/classify
The client initiates change by making a formal request for something to be changed. The change control team then records and categorizes that request. This categorization would include estimates of importance, impact, and complexity.
Assess
The impact assessor or assessors then make their risk analysis typically by answering a set of questions concerning risk, both to the business and to the process, and follow this by making a judgment on who should carry out the change. If the change requires more than one type of assessment, the head of the change control team will consolidate these. Everyone with a stake in the change then must meet to determine whether there is a business or technical justification for the change. The change is then sent to the delivery team for planning.
Plan
Management will assign the change to a specific delivery team, usually one with the specific role of carrying out this particular type of change. The team's first job is to plan the change in detail as well as construct a regression plan in case the change needs to be backed out.
Build/test
If all stakeholders agree with the plan, the delivery team will build the solution, which will then be tested. They will then seek approval and request a time and date to carry out the implementation phase.
^ TOP
Configuration managment
3. Configuration management model
Configuration management (CM) is a field of management that focuses on establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life.[1] For information assurance, CM can be defined as the management of security features and assurances through control of changes made to hardware, software, firmware, documentation, test, test fixtures, and test documentation throughout the life cycle of an information system
Configuration Management consists of the following four parts:
Configuration Identification
Configuration Control
Status Accounting
Configuration Auditing
Configuration Identification
This is the process of identifying all of the individual items that will be subject to version control within the project. Details such as version and status may be recorded.
3. Configuration Control
This activity ensures that any changes are controlled and monitored. A master copy should be kept in order for people to be able to check out the latest version of the document to avoid two people working on the same document version. Items such as ‘dates’, ‘version numbers’ and ‘updated by’ are details that may be recorded. Once the item has been updated, the item can be checked back in, resulting in it becoming the master copy. A history will be displayed when multiple versions exist.
Status Accounting
This is the process of recording and reporting on the current status of the item. It is in effect the ability to be able to view the current state of the item.
Configuration Auditing
Configuration Auditing is used to ensure that the control process that is used is being correctly adhered to
One aspect of Enterprise Architecture is to serve as Business configuration management. It apply the engineering configuration managment discipline to business environment.
Documenting and manage "As-is" via configuration management
Documenting "As-is" is first thing in EA paradigm
What do EA require Configuration Managment
We usually think of Configuration Management in the context of a Software Development Project, but CM also exists in the context of an Enterprise, having many projects and existing applications within IT and the Enterprise.
EA configuration management
According to Inside Knowledge, Snowden's early work in the field of decision support systems informed his principles of organic knowledge management, using "the natural contours of [an] organisation to allow knowledge to self-organise and self-manage." [4] He describes his three basic rules or principles of knowledge exchange: [9][10]
"Knowledge can only be volunteered; it can't be conscripted."
"People always know more than they can tell, and can tell more than they can write."
"People only know what they need to know when they need to know it."
^ TOP
The introduction
LEA suggest to manage change via goverance. Cheryl Yaeger from BenchMark Consulting International ingovernance and change management said:
"Financial institutions are operating in a very dynamic marketplace today; this requires the ability to choose the right change opportunities while demonstrating the necessary degree of flexibility to meet the fluid requirements of the organization over time. The ability to select change initiatives that are aligned with the organization’s strategic direction is fundamental for success. How to create a governance structure that ensures both this alignment and successful execution of the initiative is the challenge.
Organizations that are successful with large-scale change initiatives have several things in common; primary among them is a defined governance structure encompassing the entire change cycle. Successful structures begin with the decision process and continue through final execution of the change initiative. "
This is not only true for Financial organization but also for ever enterprise because the world change constantly and Enterprise is a living thing.
LEA apply the Holistic Enterprise Archtiecture approach to the domain of Enterprse management. Organization have taken a stovepipe oriented management approach in the governance, risk management and Compliance. LEA take a holistic view to analyze enterprise governance, risk management and compliance. management activity. It observe that all management activity consist of the aspect of governance, risk management, performance, change control and configuration management.
The Sarbanes-Oxley Act of 2002 (also called "Sar-Ox" or "SOX") assigns personal responsibility to senior management of public and non-public organizations in the U.S. and is also being applied in various forms by other countries throughout the world. Of particular concern is Section 404 of the Act, which relates to "Management Assessment of Internal Controls." This section requires an internal control report and states "the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting."1
In Using Enterprise Architecture for IT and Business Governance Requirements,, Clive Finkelstein said:
In most enterprises, senior managers have not become involved in enterprise architecture, which has been considered by many to be a computer discipline. While this is true in part, EA is also a business discipline. It enables business experts and IT staff, working together, to establish and define internal controls -- as systems to support key business processes and databases that are needed for internal control reporting. However, when used by senior management, enterprise architecture also provides methods for business transformation using enterprise architecture, as will be discussed in Part 2 of this column.
Organization to establish an integrated management infrastructure via the cross cutting analysis via the holistic GRC framework.
Further, LEA suggest a Coherent GRC approach to balance the burden and the benefit of GRC.
IT Governance and Enterprise Architecture as prerequsite for Assimilation of Service Oriented Architecture
^ TOP
Governance structure
The Architecture governance role base model describe the relation between mangement roles in maintaining architecture standards.For example :
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.
The Engineering Review Board
The Engineering Review process
^ TOP