United States Department of Commerce
Enterprise Architecture
Program Support
Enterprise Architecture Capability Maturity Model
December 10, 2007
Document Revision History
Version |
Date |
Description |
1.0 |
06/12/2001 |
Initial Draft |
1.1 |
07/01/2003 |
Revised to even scoring across the various areas |
1.2 |
12/10/2007 |
Updated to conform to newer OMB requirements |
|
|
|
Introduction - Enterprise Architecture Capability Maturity Model
The Operating Units of the Department of Commerce (DOC) have made a heavy investment in the development of enterprise-wide Enterprise Architectures. We need to ensure that the Department continues to build on previous efforts and fully realize the benefits of Enterprise Architecture.
Assessments of business processes within an organization are needed to evaluate where we are and where we should be headed, and what role IT should play in getting there. The Department has developed an Enterprise Architecture Capability Maturity Model (CMM) to aid in conducting such assessments. The goal is to enhance the overall odds for success of the Enterprise Architecture by identifying weak areas and providing a defined path towards improvement. As an Architecture matures, it should increase the benefits it offers the organization.
Over the past few years, many disciplines have developed capability maturity models designed to support process improvement. These include the areas of software development, systems engineering, integrated product and process development, and security. The process maturity model most IT organizations use or base their models on is the Software Engineering Institute's (SEI) Capability Maturity Model for describing the evolution of software development processes. An evolving/emerging best practice indicates that Enterprise Architecture organizations should similarly manage their Enterprise Architecture efforts according to capability maturity models.
The Enterprise Architecture CMM developed by the Department provides a framework that represents the key components of a productive Enterprise Architecture process. The CMM delineates an evolutionary way to improve the overall process that starts out in an ad hoc state, transforms into an immature process, and then finally becomes a well defined, disciplined, and mature process.
The CMM is to be used annually by each Operating Unit to conduct an assessment of the Operating Unit's Enterprise Architecture capability and progress.
The ACMM is comprised of three sections as shown below:
1. The DOC Enterprise Architecture Maturity Model
2. DOC Enterprise Architecture Characteristics at Different Maturity Levels
3. DOC Enterprise Architecture Capability Maturity Model Scorecard
The first two sections explain the Architecture Capability Maturity levels and the corresponding Enterprise Architecture characteristics for each maturity level to be used as measures in the assessment process. The third section is used to derive the Architecture Capability Maturity level that is to be reported to the DOC Chief Information Officer.
The DOC Enterprise Architecture Capability Maturity Model consists of six maturity levels and nine architecture elements. The six maturity levels are shown below:
1. None
2. Initial
3. Under Development
4. Defined
5. Managed
6. Measured
The nine Enterprise Architecture Elements are as follows:
1. Architecture Process
2. Architecture Development
3. Business Linkage
4. Senior Management Involvement
5. Operating Unit Participation
6. Architecture Communication
7. IT Security
8. Governance
9. IT Investment and Acquisition Strategy
Two complementary methods are used in Section 3 of the ACMM to calculate an Operating Unit’s maturity rating. The first method obtains an Operating Unit’s weighted mean Enterprise Architecture Maturity Level. The second method shows the percent achieved at each maturity level for the nine architecture elements. The Enterprise Architecture Maturity Level Scorecard and the instructions for the two methodologies are found on pages 15 and 16 of the Scorecard
The table below defines the characteristics for each element that validate the score for each level of the Maturity Model.
Focus |
Architecture Element | |
0 |
No Enterprise Architecture Program |
No Enterprise Architecture to speak of. |
1 |
Initial - Informal Enterprise Architecture Process Underway |
1. Processes are ad hoc and localized. Some Enterprise Architecture processes are defined. There is no unified architecture process across technologies or business processes. Success depends on individual efforts. 2. Enterprise Architecture processes, documentation, and standards are established by a variety of ad hoc means and are localized or informal. 3. Minimal, or implicit linkage to business strategies or business drivers. 4. Limited management team awareness or involvement in the architecture process. 5. Limited Operating Unit acceptance of the Enterprise Architecture process. 6. The latest version of the Operating Unit's Enterprise Architecture documentation is on the Web. Little communication exists about the Enterprise Architecture process and possible process improvements 7. IT Security considerations are ad hoc and localized. 8. No explicit governance of architectural standards. 9. Little or no involvement of strategic planning and acquisition personnel in enterprise architecture process. Little or no adherence to existing Standards Profile |
2 |
Enterprise Architecture Process Is Under Development |
1. Basic Enterprise Architecture Process program is documented based on OMB Circular A - 130 and Department of Commerce Enterprise Architecture Guidance. The architecture process has developed clear roles and responsibilities. 2. IT Vision, Principles, Business Linkages, Baseline, and Target Architecture are identified. Architecture standards exist, but not necessarily linked to Target Architecture. Technical Reference Model and Standards Profile framework established. 3. Explicit linkage to business strategies. 4. Management awareness of Architecture effort. 5. Responsibilities are assigned and work is underway. 6. The DOC and Operating Unit Enterprise Architecture Web Pages are updated periodically and is used to document architecture deliverables. 7. IT Security Architecture has defined clear roles and responsibilities. 8. Governance of a few architectural standards and some adherence to existing Standards Profile. 9. Little or no formal governance of IT Investment and Acquisition Strategy. Operating Unit demonstrates some adherence to existing Standards Profile. |
3 |
Defined Enterprise Architecture Including Detailed Written Procedures and Technical Reference Model |
1. The architecture is well defined and communicated to IT staff and business management with Operating Unit IT responsibilities. The process is largely followed. 2. Gap Analysis and Migration Plan are completed. Fully developed Technical Reference Model and Standards Profile. IT goals and methods are identified. The architecture aligns with the DOC and Federal Enterprise Architectures. 3. Enterprise Architecture is integrated with capital planning & investment control and supports e-government. 4. Senior-management team aware of and supportive of the enterprise-wide architecture process. Management actively supports architectural standards. 5. Most elements of Operating Unit show acceptance of or are actively participating in the Enterprise Architecture process. 6. Architecture documents updated regularly on DOC Enterprise Architecture Web Page. 7. IT Security Architecture Standards Profile is fully developed and is integrated with Enterprise Architecture. 8. Explicit documented governance of majority IT investments. 9. IT acquisition strategy exists and includes compliance measures to IT Enterprise Architecture. Cost-benefits are considered in identifying projects. |
4 |
Managed and Measured Enterprise Architecture Process |
1. Enterprise Architecture process is part of the culture. Quality metrics associated with the architecture process are captured. 2. Enterprise Architecture documentation is updated on a regular cycle to reflect the updated Enterprise Architecture. Business, Information, Application and Technical Architectures defined by appropriate de-jure and de-facto standards. The architecture continues alignment with the DOC and Federal Enterprise Architectures. An automated tool is used to improve the usability of the architecture. 3. Capital planning and investment control are adjusted based on the feedback received and lessons learned from updated Enterprise Architecture. Periodic re-examination of business drivers. 4. Senior-management team directly involved in the architecture review process. 5. The entire Operating Unit accepts and actively participates in the Enterprise Architecture process. 6. Architecture documents are updated regularly, and frequently reviewed for latest architecture developments/standards. 7. Performance metrics associated with IT Security Architecture are captured. 8. Explicit governance of all IT investments. Formal processes for managing variances feed back into Enterprise Architecture. 9. All planned IT acquisitions and purchases are guided and governed by the Enterprise Architecture. |
5 |
Optimizing - Continuous Improvement of Enterprise Architecture Process |
1. Concerted efforts to optimize and continuously improve architecture process. 2. A standards and waivers process are used to improve architecture development process improvements. 3. Architecture process metrics are used to optimize and drive business linkages. Business involved in the continuous process improvements of Enterprise Architecture. 4. Senior management involvement in optimizing process improvements in Architecture development and governance. 5. Feedback on architecture process from all Operating Unit elements is used to drive architecture process improvements. 6. Architecture documents are used by every decision maker in the organization for every IT-related business decision. 7. Feedback from IT Security Architecture metrics are used to drive architecture process improvements. 8. Explicit governance of all IT investments. A standards and waivers process is used to improve governance-process improvements. 9. No unplanned IT investment or acquisition activity. |
The table below shows the scoring criteria for each of the nine Architecture Elements.
Not established or does not exist. |
|
Exists in ad-hoc or localized form or early draft form may exist. Some Enterprise Architecture processes are defined. There is no unified architecture process across technologies or business processes. Success depends on individual efforts. |
|
Being actively developed. Basic Enterprise Architecture Process program is documented based on OMB Circular A-130 and Department of Commerce Enterprise Architecture Guidance. The architecture process has developed clear roles and responsibilities. |
|
The architecture is well defined and communicated to IT staff and business management with Operating Unit IT responsibilities. The process is largely followed. |
|
Enterprise Architecture process is part of the culture, with strong linkages to other core IT and business processes. Quality metrics associated with the architecture process are captured. These metrics include the cycle times necessary to generate Enterprise Architecture revisions, technical environment stability, and time to implement a new or upgraded application or system. |
|
Concerted efforts to optimize and continuously improve architecture process. |
No Enterprise Architecture documentation to speak of. |
|
Enterprise Architecture processes, documentation, and standards are established by a variety of ad hoc means and are localized or informal. |
|
IT Vision, Principles, Business Linkages, Baseline, and Target Architecture are identified. Architecture standards exist, but not necessarily linked to Target Architecture. Technical Reference Model and Standards Profile framework established. |
|
Gap Analysis and Migration Plan are completed. Architecture standards linked to Business Drivers via Best Practices, IT Principles, and Target Architecture. Fully developed Technical Reference Model and Standards Profile. The architecture aligns with the DOC and Federal Enterprise Architectures. |
|
Enterprise Architecture documentation is updated on a regular cycle to reflect the updated Enterprise Architecture. Business, Information, Application and Technical Architectures defined by appropriate de-jure and de-facto standards. The architecture continues alignment with the DOC and Federal Enterprise Architectures. An automated tool is used to improve the usability of the architecture. |
|
Defined and documented Enterprise Architecture metrics are used to drive continuous process improvements. A standards and waivers process is used to improve architecture development process improvements. |
|
No linkage to business strategies or business drivers. |
|
Minimal, or implicit linkage to business strategies or business drivers. |
|
Explicit linkage to business strategies. |
|
Enterprise Architecture is integrated with capital planning and investment control and supports e-government. Explicit linkage to business drivers and information requirements. |
|
Capital planning and investment control are adjusted based on the feedback received and lessons learned from updated Enterprise Architecture. Periodic re-examination of business drivers. |
|
Architecture process metrics are used to optimize and drive business linkages. Business involved in the continuous process improvements of Enterprise Architecture. |
|
No support from senior executives. Status quo is actively defended |
|
Limited management team awareness or involvement in the architecture process.
|
|
Management awareness of Architecture effort. Occasional, selective management team involvement in the architecture process with various degrees of commitment/ resistance. |
|
Senior-management team aware of and supportive of the enterprise-wide architecture process. Management actively supports architectural standards. |
|
Senior management reviews architecture and variances. |
|
Senior-management team directly involved in the optimization of the enterprise-wide architecture development process and governance. |
| ||
No part of Operating Unit participates or is involved with Enterprise Architecture process. |
||
Limited Operating Unit acceptance of the Enterprise Architecture process. Support exists only to the extent that the architecture process maintains the status quo. |
||
Enterprise Architecture responsibilities are assigned and work is underway. There is a clear understanding of where the organizations architecture is at present time. Recognition that it is costly supporting too many kinds of technologies. |
||
Most elements of Operating Unit show acceptance of or are actively participate in the Enterprise Architecture process. Recognition that architectural standards can reduce integration complexity and enhance overall ability to Operating Unit IT to achieve business goals. |
||
The entire Operating Unit accepts and actively participates in the Enterprise Architecture process. |
||
Feedback on architecture process from all Operating Unit elements is used to drive architecture process improvements. |
||
| ||
None. |
||
Little communication exists about the Enterprise Architecture process and possible process improvements. The DOC Enterprise Architecture Web Page contains the latest version of the Operating Units Enterprise Architecture documentation. |
||
The Operating Unit Architecture Home Page, which can be accessed from the DOC Enterprise Architecture Web Page, is updated periodically and is used to document architecture deliverables. Few tools (e.g., office suite, graphics packages) are used to document architecture. Communication about architecture process via meetings, etc., may happen, but sporadic. |
||
Architecture documents updated and expanded regularly on DOC Enterprise Architecture Web Page. Tools are used to support maintaining architecture documentation. Periodic presentations to IT staff on Architecture content. |
||
Architecture documents are updated regularly, and frequently reviewed for latest architecture developments/ standards. Regular presentations to IT staff on Architecture content. Organizational personnel understand the architecture and its uses. |
||
Architecture documents are used by every decision maker in the organization for every IT-related business decision. |
||
| ||
No IT Security considerations in Enterprise Architecture. |
||
IT Security considerations are ad hoc and localized. |
||
IT Security Architecture has defined clear roles and responsibilities. |
||
IT Security Architecture Standards Profile is fully developed and is integrated with Enterprise Architecture. |
||
Performance metrics associated with IT Security Architecture are captured. |
||
Feedback from IT Security Architecture metrics are used to drive architecture process improvements. |
| ||
None. Funding is the sole decision point for projects. |
||
No explicit governance of architectural standards. Limited agreement with governance structure. |
||
Governance of a few architectural standards (e.g. desktops, database management systems) and some adherence to existing Standards Profile. Variances may go undetected in the design and implementation phases. Various degrees of understanding of the proposed governance structure. |
||
Explicit documented governance of majority IT investments. Formal processes for managing variances. Senior management team is supportive of enterprise-wide architecture standards and subsequent required compliance. |
||
Explicit governance of all IT investments. Formal processes for managing variances feed back into Enterprise Architecture. Senior-management team takes ownership of enterprise-wide architecture standards and governance structure. |
||
Explicit governance of all IT investments. A standards and waivers process is used to improve architecture development and governance - process improvements. |
||
| ||
No regard for Enterprise Architecture in formulation of strategic IT acquisition strategy by Operating Unit. |
||
Little involvement of strategic planning and acquisition personnel in enterprise architecture process. Little or no adherence to existing Standards Profile. |
||
Little or no formal governance of IT Investment and Acquisition Strategy. Operating Unit demonstrates some adherence to existing Standards Profile. |
||
IT acquisition strategy exists and includes compliance measures to IT Enterprise Architecture. Operating Unit adheres to existing Standards Profile. RFQ, RFI and RFP content is influenced by the Enterprise Architecture. Acquisition personnel are actively involved in Enterprise Architecture governance structure. Cost-benefits are considered in identifying projects. |
||
All planned IT acquisitions are guided and governed by the Enterprise Architecture. RFI and RFP evaluations are integrated into the Enterprise Architecture planning activities. |
||
Operating Unit has no unplanned IT investment or acquisition activity. |
The table below is the evaluation matrix. For each of the nine characteristics, score your organization according to the definitions below. This score is an evaluation of where your organization is now. Appropriate artifacts that demonstrate the attainment of the maturity level should be available to substantiate your score.
1. Architecture Process: Is there an established Enterprise Architecture process? |
|
Level 0: Architecture process not established. 1: Ad-hoc and localized architecture process defined. 2: Basic Enterprise Architecture Process program is documented based on OMB Circular A-130 and Department of Commerce Enterprise Architecture Guidance. The architecture process has developed clear roles and responsibilities. 3: The architecture is well defined and communicated to IT staff and business management with Operating Unit IT responsibilities. The process is largely followed. 4: Enterprise Architecture process is part of the culture, with strong linkages to other core IT and business processes. Quality metrics associated with the architecture process are captured. These metrics include the cycle times necessary to generate Enterprise Architecture revisions, technical environment stability, and time to implement a new or upgraded application or system. 5: Concerted efforts to optimize and continuously improve architecture process.
|
|
2. Architecture Development: To what extent is the development and progression of the Operating Units' Enterprise Architecture documented? |
|
Level 0: No Enterprise Architecture documentation to speak of. 1: Enterprise Architecture processes, documentation and standards are established by a variety of ad hoc means, and are localized or informal. 2: IT Vision, Principles, Business Linkages, Baseline, and Target Architecture are documented. Architecture standards exist, but not necessarily linked to Target Architecture. Technical Reference Model and Standards Profile framework established. 3: Gap Analysis and Migration Plan are completed. Architecture standards linked to Business Drivers via Best Practices, IT Principles and Target Architecture. Fully developed Technical Reference Model and Standards Profile. 4: Enterprise Architecture documentation is updated on a regular cycle to reflect the updated Enterprise Architecture. Business, Information, Application and Technical Architectures defined by appropriate de-jure and de-facto standards. 5: Defined and documented Enterprise Architecture metrics are used to drive continuous process improvements. A standards and waivers process are used to improve architecture development process improvements.
|
|
3. Business Linkage: To what extent is the Enterprise Architecture linked to business strategies or drivers. |
|
Level 0: No linkage to business strategies or business drivers. 1: Minimal, or implicit linkage to business strategies or business drivers. 2: Explicit linkage to business strategies or drivers. 3: Enterprise Architecture is integrated with capital planning and investment control. Explicit linkage to business drivers and information requirements. 4: Capital planning and investment control are adjusted based on the feedback received and lessons learned from updated Enterprise Architecture. Periodic re-examination of business drivers. 5: Architecture metrics are used to optimize and drive business linkages. Business involved in the continuous process improvements of IT Architecture.
|
|
4. Senior Management Involvement: To what extent are the senior managers of the Operating Unit involved in the establishment and ongoing development of an IT Architecture? |
|
Level 0: No management team awareness or involvement in the architecture process. 1: Limited management team awareness or involvement in the architecture process. 2: Occasional/selective management team involvement in the architecture process with various degrees of commitment. 3: Senior-management team aware of and supportive of the enterprise-wide architecture process. Management actively supports architectural standards. 4: Senior-management team directly involved in the architecture review process. 5: Senior-management team directly involved in the optimization of the enterprise-wide architecture development process and governance. |
|
5A. Operating Unit Participation: To what extent is the Enterprise Architecture process accepted by the Operating Unit? |
|
Level 0: No Operating Unit acceptance. 1: Limited Operating Unit acceptance of the Enterprise Architecture process. 2: Enterprise Architecture responsibilities are assigned and work is underway. There is a clear understanding of where the organization’s architecture is at present time. 3: Largest elements of Operating Unit show acceptance of the IT Architecture process. 4: The entire Operating Unit accepts and actively participates in the IT Architecture process. 5: Feedback on architecture process from all Operating Unit elements is used to drive architecture process improvements. |
|
5B. Operating Unit Participation: To what extent is the Enterprise Architecture process an effort representative of the whole organization? |
|
Level 0: No enterprise-wide effort. 1: Localized individual support of Enterprise Architecture process. 2: Limited organizational involvement. 3: Majority of organization is involved. 4: Cross-enterprise architecture involvement. 5: Entire organization uses feedback on the architecture process to improve its process.
|
|
6A. Architecture Communication: To what extent are the decisions of Enterprise Architecture practice documented? |
|
Level 0: No documentation is available. 1: Little communication exists about the Enterprise Architecture process and possible process improvements. The DOC Enterprise Architecture Web Page contains the latest version of the Operating Unit’s Enterprise Architecture documentation. 2: The Operating Unit Architecture Home Page, which can be accessed from the DOC Enterprise Architecture Web Page is updated periodically and is used to document architecture deliverables. Communication about architecture process via meetings, etc., may happen, but sporadic. Few tools (e.g., office suite, graphics packages) are used to document architecture. 3: Architecture documents updated and expanded regularly on DOC IT Architecture Web Page. Periodic presentations to IT staff on Architecture process, content. Tools are used to support maintaining architecture documentation. 4: Architecture documents are updated regularly, and frequently reviewed for latest architecture developments/standards. Regular presentations to IT staff on architecture content. 5: Architecture documents are used by every decision maker
|
|
6B. Architecture Communication: To what extent is the content of the Enterprise Architecture made available electronically to everybody in the organization? |
|
Level 0: No electronic means of communication. 1: Limited electronic means of communication. 2: Occasional updates published via e-mail. 3: More widespread electronic publication of Enterprise Architectures. 4: An online Web site is used to make available communications across the organization. 5: All Operating Units are actively involved through electronic updates. |
|
6C. Architecture Communication: To what extent is architecture education done across the business on the Enterprise Architecture process and contents? |
|
Level 0: No education. 1: Limited education. 2: Architecture education done for IT staff. 3: More widespread education done across various Operating Units. 4: Most Operating Units participate actively in Enterprise Architecture education. Ongoing education on the value of an Enterprise Architecture across Operating Units. 5: All Operating Units participate in staff education and understanding of IT Architecture. Various education/communication tools utilized across all Operating Units.
|
|
7. IT Security: To what extent is IT Security integrated with the Enterprise Architecture? |
|
Level 0: No IT Security considerations in Enterprise Architecture. 1: IT Security considerations are ad hoc and localized. 2: IT Security Architecture has defined clear roles and responsibilities. 3: IT Security Architecture is fully developed and is integrated with IT Architecture. 4: Performance metrics associated with IT Security Architecture are captured. 5: Feedback from IT Security Architecture metrics are used to drive architecture process improvements. |
|
8. Governance: To what extent is an Enterprise Architecture governance (governing body) process in place and accepted by senior management ? |
|
Level 0: None. Everyone does their own thing. 1: No explicit governance of architectural standards. Limited agreement with governance structure. 2: Governance of a few architectural standards (e. g. desktops, database management systems) and some adherence to existing Standards Profile. Various degrees of understanding of the proposed governance structure. 3: Explicit documented governance of majority IT investments. Formal processes for managing variances. Senior management team is supportive of enterprise-wide architecture standards and subsequent required compliance. 4: Explicit governance of all IT investments. Formal processes for managing variances feed back into Enterprise Architecture. Senior-management team takes ownership of enterprise-wide architecture standards and governance structure. 5: Explicit governance of all IT investments. A standards and waivers process is used to improve governance process improvements.
|
|
9. IT Investment and Acquisition Strategy: To what extent does the Enterprise Architecture influence the IT Investment and Acquisition Strategy? |
|
Level 0: No regard for Enterprise Architecture in formulation of strategic IT Acquisition strategy by Operating Unit. 1: Little or no involvement of strategic planning and acquisition personnel in enterprise architecture process. Little or no adherence to existing Standards Profile. 2: Little or no form al governance of IT Investment and Acquisition Strategy. Operating Unit demonstrates some adherence to existing Standards Profile. 3: IT acquisition strategy exists and includes compliance measures to IT Enterprise Architecture. Operating Unit adheres to existing Standards Profile. RFQ, RFI and RFP content is influenced by the Enterprise Architecture. Acquisition personnel are actively involved in Enterprise Architecture governance structure. Cost-benefits are considered in identifying projects. 4: All planned IT acquisitions and acquisitions are guided and governed by the Enterprise Architecture. RFI and RFP evaluations are integrated into the IT Architecture planning activities. 5: Operating Unit has no unplanned IT investment or acquisition activity. |
|
Record your scores for each characteristic below. For numbers 5 and 6, total the scores for all subsections and divide by the number of subsections as noted in the table to derive a composite score for the whole section. Round your final score to the nearest tenth (0.1) point.
Architecture Characteristic |
|
1. |
|
2. |
|
3. |
|
4. |
|
5. = (5A+5B)/2 |
|
6. = (6A+6B+6C)/3 |
|
7. |
|
8. |
|
9. |
|
Score = (1…9)/9 |
The Enterprise Architecture Capability Maturity Model measures two parameters: Enterprise Architecture Characteristics and Maturity Level. Calculate and report the Enterprise Architecture Capability Maturity Score using Methods One and Two. The two methods complement each other and can be used as a cross plot for the scorecard calculation.
METHOD #1 EXAMPLE
This method calculates an Operating Unit's mean Architecture Capability Maturity Level. 1. First: map the Enterprise Architecture Characteristic with each of the six Maturity Levels 2. Second: sum the occurrences of each Maturity Level 3. Third: divide the sum by nine Enterprise Architecture Characteristics The example below indicates that the Operating Unit achieves a Maturity Level of 2.66
Architecture Level Characteristic Accomplished 1 3 2 2 3 4 4 3 5 1 6 3 7 5 8 2 9 1 Total Score / Number of Characteristics 24/9 = 2.7 |
METHOD #2. EXAMPLE
This method shows the percent achieved at each maturity level for the nine architecture characteristics. This method complements method #1 by allowing an Operating Unit to clearly assess and identify the target improvement they need at each level. · Count the number of elements that have achieved each level of maturity. It is cumulative, so if an element has achieved level 4 rating, it is counted in levels 1, 2, & 3 also. · Divide the number at each level by 9 and multiply by 100 to get the percentage Maturity Level Occurrences at Each Level Percent (out of 9) 5 1 11.11% 4 2 22.22% 3 5 55.55% 2 7 77.77% 1 9 100.00% 0 9 100.00% |
Method 1 - Complete table below
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
Total Score / Number of Characteristics |
|
Method 2 - Complete table below
5 |
|
|
4 |
|
|
3 |
|
|
2 |
|
|
1 |
|
|
0 |
|
|
- Last Updated:
- December 13, 2007
- Questions regarding this section may be directed to the Enterprise Architecture Administrator