QnA


Category: General Questions

Yes. Enterprise Architecture is a management and technology practice that is devoted to improving the performance of enterprises by enabling them to see themselves in terms of a holistic and integrated view of their strategic direction, business practices, information flows, and technology resources. By developing current and future versions of this integrated view, an enterprise can manage the transition from current to future operating states. The strategic use of resources is increasingly important to the success of public, private, and non-profit sector enterprises, including extended enterprises involving multiple internal and external participants (i.e., supply chains). How to get the most from business, technology, and human resources requires an enterprise to think in terms of enterprise-wide solutions, rather than individual systems and programs. Doing this requires a new approach to planning and systems development, an approach that has come to be known as Enterprise Architecture. The word ‘enterprise’ implies a high-level, strategic view of the entire entity, while the word ‘architecture’ implies a structured framework for the analysis, planning, and development of all resources in that entity.

Category: Methodology

Yes. The EA 3 methodology is generalized so it can be used in a wide variety of public and private sector enterprises, and can support many types of EA frameworks, tools, and repositories. Depending on the type of enterprise, some parts of the EA methodology may need to be changed.

In the area of physical security, determine and describe the facilities and other direct access protection that will be required to achieve an acceptable level of risk to prevent unauthorized access to these EA components. In the area of information security, determine how the information created/used by the EA component will be protected and authenticated. In the area of personnel security, determine how access control will be provided for system administrators, database administrators, webmasters, security personnel, and end-users. In the area of operational security, determine and document (via a SOP) the procedures for handling end-user agreements, login and access control, incident response (i.e. virus attacks, denial of service attacks, hackers), password issuance and control, and employee termination. For testing and accreditation, determine and describe the method that will be used to test certify that the delivered EA components(s) meet the risk adjusted-goals in the areas of physical, information, personnel, and operational security. For data privacy, determine the sensitivity and classification of information on delivered EA component(s). Determine the issues related to data privacy and describe how they will be handled (e.g., access to employee’s personal information). For records management, determine the issues related to records management and describe how they will be handled. Determine if information exchange and records management issues exist with other IT resources and describe how they will be handled.

One of the purposes of the EA Management Plan is to show an overview of the linkage between current EA components and products at each level of the EA \n3 Cube Framework. In this way, the present role of IT within the enterprise is better understood and can be further analyzed from either a top-down, or bottomup perspective. The objective of this part of the EA Management Plan is not to duplicate the extensive documentation, but to provide an integrated view of how the components and artifacts work in support of each other. This also sets the stage for Part 3 of the EA Management Plan, which discusses future changes in EA components and artifacts to achieve improved performance and/or efficiency.

Tag: EAM
Category: Framework

There are four general types of changes to business services that occur: (1) the introduction of a completely new process, (2) elimination of an existing process, (3) major reengineering of an existing process, and (4) minor improvement of an existing process. Effective management at the Business Level requires that these changes be coordinated so that the performance of the enterprise does not decline. \nTherefore, reviews of existing business services should be performed periodically by line-of business managers to identify those which may be obsolete, duplicative, or not adding sufficient value to the achievement of strategic goals. Resulting decisions to eliminate or change existing processes, or add new processes, are what get documented in the future view of Business Level EA components and artifacts.

Category: Framework

The Systems/Services level of the EA 3 Cube Framework is organized around integrated plug-and-play components that are based on open standards, and reusable objects of code that underlie and enable a component-based and service-oriented approach to EA, as is promoted in the EA \n3 Cube Framework. \nVarious EA artifacts are used to document the future components at the Systems/Services level, including program code and technical documentation on releases and upgrades; interface diagrams; and standards.

Tag: Framework
Category: Framework

Future views of EA components and artifacts at the Information Level of the EA3 framework reflect changes that are anticipated in the collection and flows of information that are needed to support changes in business services (upward alignment) or changes that are anticipated at the Systems/Services Level or the Technology Infrastructure level of the EA3 Cube Framework.

Tag: Framework
Category: Framework

The Technology Infrastructure level of the EA 3 Cube Framework documents components such as the enterprise’s voice, data, and video networks, as well as the security solution that protects them. In that one of the goals of EA is to promote the integration of these networks into one seamless technology backbone, the future view of EA artifacts at this level documents changes to this infrastructure. \nDevelop a future scenario for an enterprise that describes changes in processes, human factors, and technology. Identify the planning assumptions that underlie these changes. \nIn answering this question, students should follow the directions for developing a future scenario.

Tag: Framework

Capital Planning and Investment Control (CPIC) process supports EA by planning, selecting, controlling, and evaluating investments in new or upgraded EA components. This cyclic process promotes the attainment of the following: Identification of operational performance gaps in the enterprise, Identification of new or upgraded EA components to close performance gaps, Development of business cases that consider alternatives, alignment, and value, Development and management of an overall portfolio of investments in the EA, Maximizing the value of individual investments in EA components, Encouraging a culture of learning by evaluating each completed Investment. The CPIC process operates in four distinct phases that serve to (1) standardize how requirements for technology are identified within a strategic and business context; (2) associate the technology requirement with an EA component; (3) make an investment decision; and (4) implement a solution through standardized project management practices and the EA program. The Project Management Plan (PMP) serves as the common documentation source for all phases of the CPIC process.

Tag: CPIC

The Security and Privacy Program is intended to provide expertise, processes, and solutions for the protection of IT resources active in the business and technology operating environment. The Security and Privacy Program supports the EA by providing requirements for standards and procedures that are used in the planning and implementation of EA components and artifacts. Each EA component and artifact should be assessed to determine if the proper level of protection is provided, and if not, that solutions are identified on a risk-adjusted basis. Risk-adjustment refers to the trade-off between sharing and protection, as well as how much security is desired versus the cost and effort required to implement it.

Tags: EAM, Security

At some point the new components and artifacts in the future view of the EA become implemented and therefore should be documented as part of the current view of the EA. These ongoing changes to the EA represent a challenge in terms of how best to show at any given time what is current and what is planned. \nPerhaps the simplest and most effective way to approach this is to ‘freeze’ the current and future views of the EA at regular periods (e.g., twice each year). This promotes clarity and supports EA version control. \nUsing this example, changes to current and future views are collected for four to five months and then are published in the sixth month as a new release of the enterprise’s EA. EA stakeholders come to expect the new releases and know that they can then rely on the information not changing in the EA repository for the next few months. Special releases can be made if a there is an important change in the middle of the normally static period. Without this type of version control, the EA repository becomes a free-for-all whereby no one is sure when and where changes will appear, and this will detract from the perceived value of EA information.

Categories: Artifacts, Components

EA artifacts document EA components in a consistent way across the entire architecture.

An integrated set of security and privacy controls for the enterprise is created by including these considerations security in the planning, design, implementation, and operation of all EA components and artifacts. For information-centric enterprises, including IT security and data privacy as required design elements of EA components, and having leadership support at the strategic and line of business operations levels can provide a strong and meaningful statement about the importance of protecting the business and technology operating environment. Security and privacy controls should also be a consideration in business process reengineering and improvement activities, and should be a requirement for the design of information flows. Security and privacy should also be key checklist items when making acquisition decisions for systems, hardware, software, and support services at the Systems/Services level and the Technology Infrastructure level of an architecture.

Tag: Security
Category: Standards

Standards determine documentation methods and component configurations at all levels of the EA 3 framework.

Tag: Standards
Categories: Methodology, Repository

Providing easy access to EA documentation is essential for use in planning and decision-making. This can be accomplished through the establishment of an on-line EA repository to archive the documentation of EA components in the various areas of the EA framework. The EA repository is essentially a website and database that stores information and provides links to EA tools and other EA program resources.

As is reflected in the design of the EA framework, strategy creates business requirements and technology supports solutions for meeting those requirements. EA documents three primary issues at the business level: Supporting Strategic Goals. Touch points between strategic initiatives and business activities need to be clearly documented. Not all business activities are strategic, and it is important to distinguish in the EA documentation between those that directly link to strategic initiatives and those that provide general support functions for the enterprise. Documentation of Business Activities. Documenting the creation and delivery of business products and services is important in supporting Business Process Improvement (BPI) and Business Process Reengineering (BPR) projects, and in documenting business activities to show inputs, outputs, outcomes, and other elements of influence regarding each business process. It’s also important to identify how business processes are linked to one another. Identifying Supporting Technologies. Analyzing business requirements and activities can reveal critical supporting technologies (e.g. marketing activities require sales trend analysis data, and a manufacturing process requires various types of resources including raw materials, facilities, labor, computers, data, and/or robotics). EA helps to identify and document these supporting technologies.

Linking EA and Technology Planning \nTechnology is a type of resource that enables information and other resource flows to support the creation and delivery of business products and services, which in turn enables the achievement of strategic goals. \nIt is important that technology not drive business and strategy planning, especially in resource-constrained enterprises, where the expense of duplicative non-strategic technologies cannot be afforded. Bottom-up planning (e.g. where technology is the catalyst for change) is a viable use of EA; however it’s not the normal process for resource implementation. It’s more important for the enterprise to understand its primary directions and priorities, plan necessary business activities, and then identify the supporting resources, including IT.

Tags: Artifacts, EAM

The EA framework and methodology organizes EA documentation in a way that allows strategy to influence business and technology planning and decision-making. This is important especially in the documentation of future EA views. By first identifying what changes are anticipated in strategic goals and initiatives, subsequent documentation of business activities and technology resources can be completed in such a way as to promote alignment, efficiency, and effectiveness. Documenting strategy involves the identification of goals, initiatives, and outcome measures.

For EA to support an enterprise holistically, it must link strategy, business and technology. EA is most effective when it simultaneously supports top-down executive planning and decision-making across the enterprise and bottom-up management planning and decision-making within each LOB. In this way, EA helps to ensure that strategy drives business and technology planning. From a business perspective EA provides the context and purpose of business activities by ensuring technology is implemented only after business requirements are identified. From a technology perspective, EA provides the strategy and business context for resource planning. This can be critical when working with multiple organizations to create common resources (i.e., supply chains) or in merging / acquiring organizations into one enterprise.

In that the EA program links to other areas of resource governance (e.g., capital planning, project management, and security), decision-makers can obtain coordinated information on operations, support, and development activities

An integrated set security and privacy controls for the enterprise is created by including these considerations security in the planning, design, implementation, and operation of all EA components and artifacts. For information-centric enterprises, including IT security and data privacy as required design elements of EA components, and having leadership support at the strategic and line of business operations levels can provide a strong and meaningful statement about the importance of protecting the business and technology operating environment. Security and privacy controls should also be a consideration in business process reengineering and improvement activities, and should be a requirement for the design of information flows. Security and privacy should also be key checklist items when making acquisition decisions for systems, hardware, software, and support services at the Systems/Services level and the Technology Infrastructure level of an architecture.

Category: Framework

Spewak states that EAP is a method for developing the top two levels of Zachman’s Framework.

The future architecture should cover planned changes to EA components in the near term (tactical changes in the next 1-2 years), as well as changes to EA components that are a result of the implementation of long-term operating scenarios that look 3-10 years into the future. These scenarios incorporate different internal and external drivers and can help to identify needed changes in processes, resources, or technology that translate to future planning assumptions, which in turn drive the planning for new EA components.

Changes to the EA include the addition, upgrade, retirement of EA components or artifacts. CM ensures that (1) a standardized process is used in reviewing proposed changes, (2) technical standards for voice, data, and video are followed or waived, (3) there is a documented waiver process, (4) waivers have specific time limits, so that EA standards are eventually realized, (5) there is enforcement for EA documentation version control. The CM process should be overseen by the Chief Architect, and be supported by an Architecture Working Group that includes stakeholders from throughout the enterprise. \nThe CM process works through the submission, review and approval/rejection of an EA Change Request (EACR) form by any stakeholder

Tag: EAM
Category: General Questions

New types of organizations and enterprises are appearing which are based on cooperative networks of local and remote individual workers and semiautonomous teams who carry out key functions. In these enterprises, greater cost efficiency and more mission flexibility are achieved by removing layers of management that are not needed in a decentralized operating mode. These teams are actually sub-groups that have their own management level and technical level with core processes, and therefore will still exhibit some of the characteristics of the Parsons/Thompson Model. The difference presented here is that the organization/enterprise’s structure is based on these teams and remote workers, whose goals and functions may change depending on internal and external influences.

Categories: Artifacts, Components

Examples of changes to components include a new strategic goal, business process, information flow, IT system, Web service, application network, security solution, standard, or workforce requirement. \nChanges to components may also reflect upgrade, integration, and retirement activities. \nProvide some examples of artifacts at the Goals & Initiatives level of the EA

The information in the EA repository is valuable for planning and decision-making only as long as it is comprehensive and accurate. Therefore, it is important to regularly update the current and future views of EA components in all areas of the framework. Further, it is helpful to users of EA information if the updates are made on a regular schedule, perhaps twice a year. Also, it is important to maintain version control in between updates, so that all of the users of the EA information know that they are conducting planning and decision-making activities based on the same information. Since what is planned in the future EA views will eventually become the current architecture (at least some of it), it should be recognized that EA updates are ongoing activities that do not cease. Future EA plans will continue as an organization grows and changes. Consider a time when the enterprise no longer needs changes in future capabilities and resources. Should this occur, the EA program transitions from focusing on the establishment of the EA to maintaining the EA and seeing that it continually brings value to the enterprise.

Category: Artifacts

Vendor supplied documentation may include data models, system and application interface information, network specifications and standards, and other artifacts that should be retained as part of the documentation of current and future EA views. Using vendor supplied information avoids the cost of recreating that information and maximizes the accuracy of that information.

Categories: Artifacts, Components

EA artifacts are types of documentation that describe components, including reports, diagrams, charts, spreadsheets, video files, and other types of recorded information. High-level EA artifacts are often text documents or diagrams that describe overall strategies, programs, and desired outcomes. Mid-level EA artifacts are documents, diagrams, charts, spreadsheets, and briefings that describe organizational processes, ongoing projects, supply chains, large systems, information flows, networks, and web sites. \nLow-level EA artifacts describe specific applications, data dictionaries, technical standards, interfaces, network components, and cable plants. When these EA artifacts are harmonized through the organizing taxonomy of the EA framework, new and more useful views of the functioning of EA components are generated. This is one of the greatest values of EA as a documentation process creation of the ability to see a hierarchy of views of the enterprise that can be examined from several perspectives.

Categories: Components, Framework

While an EA framework provides an overall structure for modeling the enterprise’s business and technology operating environment, EA components are the working elements of the framework at each level. In other words, EA components are building blocks that create discrete parts of the overall IT operational capability. EA artifacts describe EA components.

Categories: Artifacts, Framework

Current Strategic Scenario, Strategic Goals, Initiatives, Measures.

Category: Framework

System Interface Diagram, System Communication Diagram, System Interface Matrix, System Data Flow Diagram, System/Operations Matrix, Systems Data Exchange Matrix, System Performance Matrix, System Evolution Diagram, and Web Application Diagram.

Category: General Questions

Developing an enterprise-wide architecture involves an evaluation and depiction of people, processes, and resources. Some of the areas of practice and theory that have influenced the EA practices include business administration, public administration, operations research, sociology, organizational theory, management theory, information science, and computer science. Understanding the mission, goals, and culture of an enterprise is as important to implementing an EA as the selection of analytic methods and documentation techniques. The EA \n3 approach is based on theories of how social organizations are structured and how systems and activities function within enterprises. \nDescribe the purpose of each level of the Parsons/Thompson Model of an organization. \nOne of the more mature models of general organizational structure is a three-level view that was originally envisioned by sociologist Talcott Parsons in the 1950’s and further developed by sociologist James Thompson in the 1960’s. Parsons’ research identified three general levels that are common to most social organizations (technical, managerial, and institutional), based on the observation that different types of activities occur at each level. Thompson built on Parsons’ ideas by further identifying the different types of activities that occur at each level

On the value side, EA is unique in its ability to promote enterprise-wide thinking about resource utilization. EA replaces the systems-level approaches to IT resource development that have characterized the last several decades, and has left many enterprises with stovepipe and/or duplicative IT resources. EA promotes the development of more efficient enterprise-wide common operating environments for business and technology, within which more capable and flexible business services and systems can be hosted. This in turn makes an enterprise more agile and able to respond to internal and external drivers of change, which promotes greater levels of competitiveness in the marketplace. Areas that provide value include: Shortening Planning Cycles, More Effective Planning Meetings, Shorter Decision-Making Cycles, Improved Reference Information, Reduction of Duplicative Resources, Reduced Re-work, Improved Resource Integration and Performance, Fewer People in a Process, Improved Communication, Reduction in Cycle Time.

Category: Framework

The EA framework defines what the EA program will document, and the EA methodology defines how that documentation will be developed and used. By defining what parts of the enterprise are included in the EA, the framework defines the scope of the architecture. The design of the framework communicates the relationship of the areas of the EA that are documented.

Tag: Framework
Category: General Questions

The strategic use of resources is increasingly important to the success of public, private, and non-profit sector enterprises, including extended enterprises involving multiple internal and external participants (i.e., supply chains). How to get the most from business, technology, and human resources requires an enterprise to think in terms of enterprise-wide solutions, rather than individual systems and programs. \nDoing this requires a new approach to planning and systems development, an approach that has come to be known as Enterprise Architecture. The word ‘enterprise’ implies a high-level, strategic view of the entire entity, while the word ‘architecture’ implies a structured framework for the analysis, planning, and development of all resources in that entity. A program or systems-level perspective is not sufficient for the management and planning of technology and other resources across enterprises with significant size and complexity. EA is the one discipline that looks at systems holistically as well as provides a strategy and business context. Other specific differences include scope, level of integration, standards, and the use of EA frameworks for analysis and design. System development lifecycles are replaced by EA implementation methods.

Category: Artifacts

Network Connectivity Diagram, Network Inventory, Capital Equipment Inventory, Building Blueprints, Network Center Diagram, Cable Plant Diagram, Rack Elevation Diagram

Categories: Artifacts, Components

EA components are changeable goals, processes, standards, and resources that may extend enterprisewide or be contained within a specific line of business or segment. Examples of components include strategic goals and initiatives; business products and services; information flows, knowledge warehouses, and data objects; information systems, software applications, enterprise resource programs, and web sites; voice, data, and video networks; and supporting infrastructure including buildings, server rooms, wiring runs/closets, and capital equipment.

On the risk side, creating an EA for an entire enterprise can be time-consuming, costly, and disruptive to business services. Also, developing detailed EA documentation that covers strategy, business, and technology within each area of the enterprise can be time consuming and costly. Hiring and/or training architects and supporting analysts is one element of the cost. Another cost element is the time it takes line of business managers and support staff away from their normal work. Finally, the cost of EA documentation tools and on-line repositories has to be factored in as well. Further, there is the risk that the EA will not be used by stakeholders if they do not buy-in to the concept of EA or its perceived value. \nAreas of risk include: Financial, Lack of Acceptance, Loss of Key Personnel, Schedule Delays, and Documentation Tools.

Tags: EAM, Security

People can be resistant to changes in their environment, whether it is at home or the workplace. If the EA program promotes changes in the enterprise, and if people are often resistant to any type of change when they do not have some level of control, then the EA program may be resisted by stakeholders unless something is done to increase their level of control. Increasing their level of control helps to successfully manage change, and can be accomplished in several ways, including: Involving stakeholders in the EA program’s establishment and management; Regularly and effectively communicating EA activities to stakeholders; Allowing for stakeholder input to EA planning and decision-making; and Managing stakeholder expectations as to what the EA program can do.

Tag: EAM

Security and privacy controls should function to reduce or eliminate external and internal threats – doing so through a combination of perimeter defense and internal configuration control. Controls should also support rapid bounce-back capabilities (called resilience) when incidents occur – from minor to major in scope. When done correctly, controls can serve to detect and deter unauthorized access attempts, denial of service attacks, malware insertion attempts, spoofing, phishing, and virus attacks, and code manipulation attempts.

Tag: Security
Category: Artifacts

Objects are like entities in that they have a name and attributes, and link to other objects according to rules for frequency. One might say that objects know things about themselves. Objects are unlike entities in that the code for objects also contains behaviors (also known as methods), which are triggered by events that are also identified in the code one might say that objects also know how to do things. Beyond knowing things about themselves and knowing how to do things, there are three defining characteristics of an object: polymorphism, inheritance, and encapsulation : polymorphism, inheritance, and encapsulation .

As a management program, EA provides: Strategic Alignment: Connects goals, activities, and resources, ? Standardized Policy: Resource governance and implementation, Decision Support: Financial control and configuration management, Resource Oversight: Lifecycle approach to development/management. \nAs an analysis and design method, EA provides: EA Approach: The framework, analysis/design method, and artifact set, Current Views: Views of as-is strategies, processes, and resources, Future Views: Views of to-be strategies, processes, and resources, EA Management Plan: A plan to move from the current to the future EA.

In the area of information security, the Security and Privacy Program should promote security and privacy-conscious designs, information content assurance, source authentication, and data access control.

Tag: Security

There are four key elements of the Security and Privacy Program: information security, personnel, operations, and physical protection.

Tag: Security

In the area of operational security, the Security and Privacy Program should promote the development of SOPs for EA component security, risk assessment, testing and evaluation, remediation, certification, operation, and disposal. SOPs should also be developed for extreme events such as recovery from major outages or natural disasters, and enabling the continuity of operations if all or part of the enterprise becomes disabled.

Tag: Security

In the area of personnel security, the Security and Privacy Program should promote user authentication, security awareness, and training

Tag: Security

The aspects of physical protection that should be captured in the EA include controls for the facilities that support IT processing, control of access to buildings, equipment, networks, and telecommunications rooms, as well as fire protection, media storage, and disaster recovery systems.

Tag: Security
Category: Repository

The criteria for selecting an EA tool depends on the role it will play in the EA tool set. If it is an overall EA framework modeling tool, then a wide variety of capabilities are needed including the built-in support of various frameworks and modeling techniques, usability, scalability, development of management views, report generation, web interoperability, version control, security, training, licensing, and total cost of ownership.

Tag: Repository

A Business Case shows the value and projected results of selecting an investment in a particular IT solution. Within a business case, one performs an Alternatives Analysis to determine if there are several viable alternatives for meeting the stated EA-related requirement(s). Identify how each alternative meets or does not meet the requirement(s). Perform a Cost-Benefit Analysis for each alternative and then determine what the Return on Investment will be (using a Net Present Value discount factor) during the lifecycle. Perform a risk analysis to identify areas of risk and mitigation strategies. Select the best alternative based on (1) strategic alignment, (2) architecture alignment, (3) ROI, (4) security solution, (5) level of risk, (7) total cost of ownership, and (7) available resources. Ensure that the rest of the PMP documentation focuses only on the selected alternative. \nDescribe roles and responsibilities in the capital planning governance process. \nGovernance processes, including CPIC, are those that provide policy and decision-making, and they should be overseen by some form of Executive Steering Committee that is comprised of the enterprise’s top executives. The CPIC process should be managed by the enterprise’s Chief Financial Officer (CFO) in collaboration with the Chief Information Officer (CIO) and LOB managers. Because CPIC is primarily a financial investment decision-making process, the CFO should lead it, but it is very important in information-centric enterprises that the CIO be a partner in the process and that these two executives effectively integrate CPIC and the EA Management process. CPIC decisions in each phase of the process should be made by an executive level Capital Planning Board (CPB) that is supported by a Capital Planning Working Group (CPWG) and an Enterprise Architecture Working Group (EAWG). In this way, CPIC decision-making has senior stakeholder involvement and the documentation and analysis activities are accomplished by subordinate groups of experts in business and technology.

Tag: EAM

Risk mitigation plans and activities reduce the likelihood that sources of risk will emerge and negatively impact a program such as EA. Actions that mitigate risk (lower uncertainty) include strengthening executive support for the EA program, solidifying budgets, not being the first adopter of EA tools and documentation techniques, ensuring there are trained back-ups on the EA team, and using a detailed EA implementation methodology to guide the overall program. Additionally, basic program management skills address potential problems of key personnel turnover, cost and schedule overruns, performance issues, and stakeholder acceptance. Overcoming issues related to technology compatibility among EA products is achieved through the use of commercial tools that are based on open standards, and which are mature and have significant market share. Risk identification and mitigation is not a one-time activity, it is an ongoing management review item that will assist in making an EA program successful.

Tag: Security
Categories: Methodology, Repository

The EA repository is intended to provide a single place for the storage and retrieval of EA artifacts that are created using EA software applications (tools). A repository works best if it is easy to access and use. \nFor this reason, an on-line, web-based EA repository is recommended. This type of web portal for EA should be located on the enterprise’s internal Local Area Network to promote security of the information while still supporting access by executives, managers, and support staff. Providing easy access to EA information and artifacts is essential for their use in planning, management, and decision-making. The EA repository is intended to provide this type of easy access by being a one-stop-shop for all of the documents that populate the various levels of an EA framework.

Category: General Questions

EA³ is a comprehensive and open approach to enterprise architecture. The EA3 Cube framework is an architecture framework and is compliant with ISO 42010. EA3 is created by Scott Bernard and John Gøtze. [The EA³ Cube Approach](https://coe.qualiware.com/resources/ea3/) is a management and technology practice that is devoted to improving the performance of enterprises by enabling them to see themselves in terms of a holistic and integrated view of their strategic direction, business practices, information flows, and technology resources.

For EA alignment, discuss and then document the project’s proposed technical approach with the enterprise’s EAWG for design and operational alignment at the various levels of the EA3 Cube Framework: strategy, business, information, applications, and technology infrastructure. Determine the costs associated with documenting the project throughout its lifecycle in the on-line EA repository, including views of EA components at all levels of the EA3 Cube Framework in both the current and future architectures, as well as the EA Management Plan. Include these costs in the total lifecycle cost of the project. For integration, determine if there are data or telecommunication interfaces to other EA components and describe how integration, interface, and information exchange issues will be handled. For standards, determine if approved data, telecommunications, and video technical standards at all levels of the EA3 Cube Framework are being followed. If there are new standards being introduced, explain the effect of adopting those new standards on other IT system(s), application(s), database(s), and/or website(s). Describe the approach to configuration management that will be taken in terms of using EACRs at all levels of the EA3 Cube Framework. Determine and describe the System Development Lifecycle Methodology (SDLC) method that will be used to organize IT system implementation efforts (e.g., waterfall, rapid application development, evolutionary, incremental/phased). For performance measures, determine the performance metrics that will be used to measure proper system design performance, to be evaluated as part of acceptance criteria, and during the operations and maintenance phase of the delivered EA component(s). Determine the Standard Operating Procedures (SOPs) that will have to be written for the operations and maintenance phase of the lifecycle, and utilize draft SOPs as part of acceptance testing.

Tag: EAM

Risk is related to uncertainty, and in applied form is the potential source(s) for the failure or underperformance of a program or project. The management of risk involves lowering or eliminating the uncertainty that desired outcomes will not be realized. There are several types of risk that relate to the implementation and maintenance of an EA program, including: Financial. Implementing an EA involves establishing current and future views of enterprise resources, an EA Management Plan, and updates to this information at regular intervals. Like any implementation project, establishing the initial set of EA information will require start-up funding that is more than what will be required for the periodic updates. \nEven after the EA is established, cuts in an EA maintenance budget can severely affect the program, to the point of making the EA information eventually become of little or no use if it becomes too out of date. \nLack of Acceptance. EA represents a new way of looking at enterprise resources by providing an integrated view of strategy, business, and technology that supports the consolidation or re-engineered of these resources to produce additional value. Former approaches to program management that supported systems level planning will be replaced with EA level planning that is promoted through the EA program. \nThis will most likely create some tensions between program level stakeholders, EA stakeholders, and other affected groups. Loss of Key Personnel. EA is an emerging area of professional practice that requires architects, analysts, developers, and programmers. Each of these skill sets is important to the program and the loss of members of the EA team with those skills can create delays in program implementation, as well as effect implementation costs. Schedule Delays. As with all implementation projects, the documentation of current and future EA views as well as the creation of the initial EA Management Plan is approached as a project that has milestones and a specific schedule for completion. \nDelays to the schedule can come from many sources and depending on the point at which a delay occurs during EA implementation, and how long the delay is, the effect can go from being negligible to being catastrophic for the EA program. Documentation Tools. One of the greatest challenges for a Chief Architect is to develop current and future views of the EA that are rich in detail, easy to access, and which can support modeling and decision-making types of queries. The capabilities of EA tools and supporting applications at present are such that intuitive and informative management views of EA information are difficult to produce with these tools. Further, because more than one software application is normally required in an EA program, tool integration is an issue that must be dealt with. As new commercial tools are introduced a Chief Architect has to consider what the effect will be on overall documentation if that product does not integrate with other tools.

Tag: Security

**Disaster Recovery**: The assessment and recovery procedures for responding to a man-made or natural event that significantly disrupts or eliminates business and technology operations, yet does not threaten the existence of the enterprise. This includes sabotage, theft or corruption of resources, successful large scale hacker/virus attacks, building damage, fire, flood, and electrical outages. Two time-related aspects of disaster recovery need to be immediately and continually evaluated: (1) the method for recovery, and (2) the affect on mission accomplishment. Both of these may change as the amount of time increases from the moment the disaster occurred (e.g., facilities considerations, system and data restore procedures and the affect on business services will probably be different for 2-minute, 2-hour, 2-day, and 2-week outages). Security and privacy issues in this area affect all levels of the architecture. **Continuity of Operations**: This refers to procedures that are invoked if all or part of the enterprise are unexpectedly destroyed or forced to disband. In this scenario, the enterprise is unable to conduct any business or IT operations for a period of time. The recovery response is scripted in a Continuity of Operations Plan (COOP) that identifies where, how, and when business and IT functions would be restored. Security and privacy issues in this area affect all levels of the architecture.

Tag: Security
Category: Components

The current view of the EA is intended to show the IT resources that are presently active in the enterprise’s IT operating environment. This is also known as the as-is view of the EA. Depending on the amount of prior EA planning, these IT resources may or may not be aligned with the enterprise’s strategic goals and business services. If little EA planning has occurred, then a significant amount of duplication in function may be present. The future view of the EA documents the IT resources that will be active in the operating environment several years in the future. This is also known as the to-be view of the EA, as opposed to the as-is view that documents current IT resources.

Tag: Components
Category: General Questions

The EA³ Cube is a comprehensive enterprise architecture framework. The framework is compliant with ISO 42010. The EA³ Cube is created and maintained by Scott Bernard and John Gøtze

Categories: Components, Framework

The Integration Definition for Function, or IDEF technique. Developed in the mid-1970’s for modeling complex military projects, IDEF-0 uses Inputs, Outputs, Controls and Mechanisms (ICOM) to show the parts of an activity within an enterprise. IDEF-0 activity modeling is suitable for business process documentation in that it provides both high level context views, and more detailed views of each step in the activity in a format that can be further decomposed and interrelated with other processes to show linkages. IDEF-0 modeling is useful in showing linkages between steps in a process as well as internal external influences, but does not indicate a particular time sequence for the overall set of activities.

As is reflected in the design of the EA framework, strategy creates business requirements and technology supports solutions for meeting those requirements. EA documents three primary issues at the business level: Supporting Strategic Goals. Touch points between strategic initiatives and business activities need to be clearly documented. Not all business activities are strategic, and it is important to distinguish in the EA documentation between those that directly link to strategic initiatives and those that provide general support functions for the enterprise. Documentation of Business Activities. Documenting the creation and delivery of business products and services is important in supporting Business Process Improvement (BPI) and Business Process Reengineering (BPR) projects, and in documenting business activities to show inputs, outputs, outcomes, and other elements of influence regarding each business process. It’s also important to identify how business processes are linked to one another. Identifying Supporting Technologies. Analyzing business requirements and activities can reveal critical supporting technologies (e.g. marketing activities require sales trend analysis data, and a manufacturing process requires various types of resources including raw materials, facilities, labor, computers, data, and/or robotics). EA helps to identify and document these supporting technologies.

The EA Management Plan documents the enterprise’s performance gaps, resource requirements, planned solutions, a sequencing plan, and a summary of the current and future architecture. The Plan also describes the EA governance process, the implementation methodology, and the documentation framework. It is a living document that is updated at regular intervals (e.g., annually) to provide clear version control for changes in current and future views of EA components and artifacts throughout the framework. The EA Management Plan should be archived in the on-line EA repository to support easy access to the information and to promote the linkage of EA to other IT management processes.

Tag: EAM
Category: Components

The current view of the EA is intended to show the IT resources that are presently active in the enterprise’s IT operating environment. This is also known as the as-is view of the EA. Depending on the amount of prior EA planning, these IT resources may or may not be aligned with the enterprise’s strategic goals and business services. If little EA planning has occurred, then a significant amount of duplication in function may be present.

Tag: Components
Category: General Questions

One of the more mature models of general organizational structure is a three-level view that was originally envisioned by sociologist Talcott Parsons in the 1950’s and further developed by sociologist James Thompson in the 1960’s. Parsons’ research identified three general levels that are common to most social organizations (technical, managerial, and institutional), based on the observation that different types of activities occur at each level. Thompson built on Parsons’ ideas by further identifying the different types of activities that occur at each level.

Category: Methodology

Phase I activities are designed to get the EA program initially started, identify key players, and communicate the EA implementation plan to the executive sponsor and other stakeholders in order to gain buy-in and support. These pre-documentation activities are important to ensuring that the EA program has clear goals, remains focused, and is accepted throughout the enterprise.

The Sequencing Plan section of the EA Management Plan documents the tasks, milestones, and timeframe for implementing new EA components and artifacts. Large and mid-size enterprises often have many new development, upgrade, retirement, or migration projects underway at any given time and these require coordination to establish the optimal sequencing of activities. Sometimes there are dependencies between projects that also require proper sequencing.

The E-Business or E-Government Plan then serves to provide more detailed descriptions of how IT initiatives will support the enterprise’s Strategic Plan, with a focus on strategic goals and key business services. Updated plans should be published every few years to reflect the changes in direction and priorities that the enterprise intends to take. The future view of these plans can serve as draft documents where potential changes that have executive sponsorship are recorded until the official publication of the new plans. The future view of these EA components should link to the future view of all related EA artifacts, such as strategic goals, scenarios, initiatives, and performance measures

Program Management. Responsibilities: Manage the EA program and documentation process. Select and implement the EA framework and documentation methodology. Identify EA standards and manage EA configuration management sub-process.

Executive Leadership and Decision-Making.

The framework should identify the areas of the enterprise that the EA will cover, and how those areas relate. For example, the EA3 framework identifies five functional areas and three ‘thread’ areas to be documented, organizes different types of components, and then orients the components into lines of business. These relationships are important in conveying how the enterprise uses its processes and resources in accomplishing its goals.

IT security related processes, information flows, applications, systems, and network hardware and software.

Those who are affected by the EA program are called EA stakeholders and they are the ones most likely to resist the program and/or changes that are perceived to be the product of the EA program. Therefore, one of the things that the EA program manager needs to ensure is that there is stakeholder involvement in as many aspects of the EA program as is possible. This includes governance and oversight activities, the selection of an EA framework and methodology, participation in and reviews of documentation activities, and participation in the development of and updates to the EA Management Plan.

Tag: EAM
Category: Methodology

The executive sponsor must provide the Chief Architect with enough resources (e.g., budget, personnel, hardware/software, and facilities) and the authority to be able to properly establish the EA program. The Chief Architect should be accountable for EA program resources. The second step in the EA methodology is for the Chief Architect and EA team to identify all of the steps in the methodology that the enterprise needs in order to create an effective EA program. The important thing to remember in starting an EA is to have an actionable methodology that will guide program implementation and subsequent documentation activities, as well as reduce the risk of the EA program losing focus, effectiveness, and value.

Category: General Questions

Dr. Scott Bernard is the Federal Chief Enterprise Architect in the US. He works in the Office of Management and Budget within the Executive Office of the President of the United States. Dr. Bernard created the EA3 Cube framework and the EA3 approach.

The EA Management Plan documents the enterprise’s performance gaps, resource requirements, planned solutions, a sequencing plan, and a summary of the current and future architecture. The Plan also describes the EA governance process, the implementation methodology, and the documentation framework. It is a living document that is updated at regular intervals (e.g., annually) to provide clear version control for changes in current and future views of EA components and artifacts throughout the framework. The EA Management Plan should be archived in the on-line EA repository to support easy access to the information and to promote the linkage of EA to other IT management processes.

Tag: EAM
Category: Framework

The five levels of the EA3 Framework are hierarchical and integrated so that separate sub-architectures are not needed to reflect different levels or functional areas of the enterprise. The architectural areas covered at each level are arranged to position high-level strategic goals at the top, general business services and information flows in the middle, and specific support applications and the network infrastructure at the bottom. In this way alignment can be shown between strategy, information, and technology, which aids planning and decision-making.

EA management views can help various types of users to both understand and share EA artifacts. For example, members of the EA team who are modeling data in several information systems can develop a management view to show how information from those systems is used between various LOBs, and in so doing gain the support of managers in those business areas. In addition, management views can help to translate EA artifacts that are in technical modeling or analytic formats into views that are easier to understand by those who are not trained in that documentation methodology.

Tags: Artifacts, EAM
Categories: Components, Standards

Open standards at the national and international level promote EA component interoperability.

Category: Methodology

Phase III activities are where the actual development of the EA occurs in the form of documentation artifacts. Phase II enables this work. The work involves analyzing and documenting the current strategy, business, information, services, and infrastructure of the enterprise. It also involves the development of artifacts that reflect changes in resources in the short-term and the development of a group of long-term future scenarios to identify possible courses of action and resource changes that would be needed in response to different internal and external influences. The activities in this phase of the EA documentation methodology conclude with the development of an EA Management Plan that summarizes the current and future views of the architecture and provides a transition and sequencing plan for short term and long term changes. \nCompare and contrast the purpose of Phase II and Phase IV activities. \nPhase II activities take place when the initial set of EA documentation is developed. This begins with the selection of an EA documentation framework that will identify the scope of the architecture, guide the techniques for the modeling of current views, develop future scenarios and associated modeling, and establish an on-line EA repository that will archive all of the EA documentation artifacts . Phase IV is an ongoing set of activities that promotes the use of EA information by all stakeholders, and establishes an annual cycle for updates. This is where the value of the EA Program is realized, as planning and decisionmaking throughout the enterprise are supported. This value is maintained through regular updates of the current and future views of the architecture. Value is also gained in the maintenance of the EA repository and the maintenance of all associated software licenses for modeling and archiving.

Because the EA is still an emerging area of professional practice, the Acronym List and Glossary are helpful in creating a common set of terms and definitions for use throughout the enterprise.

Tags: EAM, Standards

The EA Management Plan documents the enterprise’s performance gaps, resource requirements, planned solutions, a sequencing plan, and a summary of the current and future architecture. The Plan also describes the EA governance process, the implementation methodology, and the documentation framework. It is a living document that is updated at regular intervals (e.g., annually) to provide clear version control for changes in current and future views of EA components and artifacts throughout the framework. The EA Management Plan should be archived in the on-line EA repository to support easy access to the information and to promote the linkage of EA to other IT management processes. \n \n

Tag: EAM

One fundamental aspect of security and privacy is the realization that there isn’t a 100% foolproof solution for any enterprise. The reason for this is that the security and privacy program and risk management strategy are created by members of that enterprise or by contracted service providers, The employees and contractors who are in security and system administration positions can decide to disable, evade, or sabotage the security and privacy solutions. This type of insider threat is the Achilles Heel of all IT security and privacy programs, and is what underlies what are referred to as risk-adjusted solutions. This means that a security or privacy solution is selected based on several considerations, including the cost, the level of protection needed, the effect on end-users and system administrators, and the effectiveness of available technologies.

Tag: Security
Category: Components

Because business processes change and/or are replaced over time. An enterprise’s key business and support processes are documented at the Business level of the EA framework. EA components at this level include business process documentation and an IT capital planning portfolio that provides business case documentation on each investment in IT that meets operational and financial thresholds.

Tag: Components
Category: Components

Because information flows and data objects change and/or are replaced over time. How an enterprise uses data and information is documented at the Data and Information level of the EA3 Cube Framework. \nEA components at this level include documentation on the design, function, and management of information systems, databases, knowledge warehouses, and data marts. It also includes detailed documentation on the structure and processing logic of data that the enterprise is interested in.

Tag: Components
Category: Components

Because software applications and networks change and/or are replaced over time. The systems and applications that an enterprise uses to support its business services, product delivery processes, and information flows are documented at the Systems and Applications level of the EA3 Framework. One of the purposes of EA is to improve the integration and efficiency of the support systems and software applications across the enterprise. Duplication of functions and a lack of interoperability can be addressed through the establishment of technical and product standards for software. Components at this level range in size and complexity from large multi-function ERP solutions that extend throughout the enterprise to single-user desktop tools that enhance productivity.

Tag: Components
Categories: Framework, Methodology

Analysis and documentation, as organized through an EA framework, provides standardized, hierarchical views of the enterprise from an integrated strategy, business, and technology perspective

Enterprise architecture is accomplished through a management program and an analysis and design method that is repeatable at various levels of scope. Together the EA program and method provide an ongoing capability and actionable, coordinated views of an enterprise’s strategic direction, business services, information flows, and resource utilization.

Tags: EAM, Methodology

Project (and program) management is a professional discipline that focuses on developing, implementing, operating, improving, and/or retiring enterprise resources. Project and Program Managers (PMs) are responsible for meeting the goals of the project or program. Controlling successful outcomes involves the management of five primary aspects of a project/program: managing scope; controlling costs, maintaining the schedule, achieving desired levels of product performance, and mitigating risk. Projects and Programs are terms that encompass the work that an enterprise does. Projects are different from programs in that projects create new or updated resources/capabilities. Programs include projects as well as the ongoing governance and business services that constitute most of the activities of an enterprise. Programs are oriented toward the management of existing (legacy) resources/capabilities, whereas projects build new or upgrade existing resources/capabilities.

Tag: EAM

The role of security and privacy within an EA program is best described as a comprehensive set of controls that pervade all architectural domains and are a key part of an organization’s risk management strategy. One can think of this as a vertical thread that weaves through all levels of the architecture. The thread metaphor is used (as opposed to a separate dedicated level) because security and privacy are most effective when they are integral to the enterprise’s strategic initiatives, business services, information flows, applications, and technology infrastructure.

Tag: Security

The EA program is only effective if the enterprise’s resources are effectively applied to gaps in operational performance. It takes people, money, facilities, software, hardware, training, and other resources to do this through the investment in an ongoing series of development and improvement projects. If there were no gaps in operational performance, there would be no requirement for new or upgraded EA components. \nDescribe the four basic phases of the capital planning [CPIC] process. \nCPIC Planning Phase: The CPIC Planning Phase is where business and technology requirements that emerge throughout the enterprise are reviewed at a preliminary level for merit, need, and identification of an association with an EA component. \nCPIC Selection Phase: The CPIC Selection Phase is where a funding decision is made for a proposed investment in an EA component. \nCPIC Control Phase: The CPIC Control Phase is where ongoing development and upgrade projects are evaluated for how closely cost, schedule, and EA component performance milestones are being met, and how well areas of risk are being managed. \nCPIC Evaluation Phase: The CPIC Evaluation Phase is where (1) completed IT projects receive a PostImplementation Review (PIR), and (2) where operational systems are periodically reviewed for continuing value.

Tag: EAM
Category: Workforce

Enterprise architecture is as much about people and social interaction as it is about processes and resource utilization. Understanding each of these aspects of an enterprise is essential to the development of accurate views of the current architecture and relevant, meaningful views of the future architecture. \nInsight into the people aspect of enterprises is also important to the development of policy, standards, and an EA Management Plan that will be accepted by the enterprise. Moving from current to future states of the EA involves changes in processes and how people will communicate. Change involves moving from what is familiar to something unfamiliar, which is uncomfortable and/or threatening to many people. \nTherefore, there may be resistance to programs such as EA that cause or support changes in resources and processes throughout the enterprise.

Because an enterprise’s strategic drivers, business requirements, and technology solutions change over time.

Categories: Artifacts, Components

It allows direct comparison of EA artifacts in the current and future views.

Those who are affected by the EA program are called EA stakeholders and they are the ones most likely to resist the program and/or changes that are perceived to be the product of the EA program. Therefore, one of the things that the EA program manager needs to ensure is that there is stakeholder involvement in as many aspects of the EA program as is possible. This includes governance and oversight activities, the selection of an EA framework and methodology, participation in and reviews of documentation activities, and participation in the development of and updates to the EA Management Plan.

Tag: EAM