EA Maturity Model
Farook Abbas
Digital Transformation | Strategy | Governance | Enterprise Architecture | Technical Program Management | Data Management
Quick Intro
Referring to my earlier port, lets start with marurity assessment toolkit. This toolkit introduces the concept of Architecture Capability Maturity Models (ACMM), techniques for evaluating and quantifying an organization’s maturity in Enterprise Architecture this can be used by any enterprise to develop their own organization-specific model. This toolkit is derived from TOGAF 9.2 which is the leading industry standard for the architecture practice establishment and management.
Architecture Capability Maturity Model - Maturity Levels
Level 0 Enterprise Architecture program does not exist and no knowledge of it.
Level 1 Informal Enterprise Architecture process underway.
Level 2 Enterprise Architecture process is under development.
Level 3 Defined Enterprise Architecture including detailed written procedures and TRM.
Level 4 Managed and measured Enterprise Architecture process.
Level 5 Continuous improvement of Enterprise Architecture process.
Architecture Elements
1 Enterprise Architecture Framework
2 Enterprise Architecture Development Method
3 Business Scenario & Requirements Process
4 Stakeholder Involvement
5 Architecture Content (Continuum)
6 Architecture Resources
7 Architecture Governance
8 Architecture Project
9 Architecture Change Management
10 Benefit Realization
11 Application Architecture
12 IT Security
This task establishes the base for EA practice. It's critical that helps the architecture team to set boundaries for architecture practice. The Architecture program effectiveness is only maximized when the appropriate information can be found in EA in a right format. Also helps to visualize the big picture of the organization and act as window of entry.
This is understand the knowledge, practice and artifacts definition within the organization.
Level 0 Enterprise Architecture not known / recognized. Success depends on individuals.
Level 1 Processes are localized and ad-hoc. Few Enterprise Architecture processes are defined.
There is no unified architecture process across technologies or business processes. Success depends on individual efforts.
Level 2 Enterprise 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.?
Level 3 The architecture is well defined and communicated to IT staff and business management. The process is largely followed.?
Level 4 Enterprise Architecture process is part of the culture. Quality metrics associated with the architecture process are captured.
Level 5 Enterprise Architecture principles and process optimize and continuously improved
The footprint of architecture defines the coverage across the business units. In some organizations, the coverage of architecture might be enterprise wide especially in small to medium enterprises while in others mainly large organizations, it might be limited to some line of business or be at corporate but restricted to a subset of the business, information, application and infrastructure layers. Some organizations might have a federated approach combining efforts at the corporate level and the LoB level.
Level 0 None of the followings.
Level 1 Architecture is project focused
Level 2 Architecture exists independently in LoB or geographic silos.
Level 3 Architecture is unified or federated with defined corporate and LoB responsibilities. However, LoBs and corporate architecture programs do not have coordinated processes & governance
Level 4 Architecture is unified or federated with standardized corporate and LoB processes and governance structures.
Level 5 Architecture is unified or federated across the enterprise and encompasses interactions with business partners
Successful architecture programs have a set of clearly defined principles with which to anchor their content. In these programs, principles exist for each of the architecture viewpoints and these are driven by the architecture requirements
Level 0 None of the followings
Level 1 Architecture principles have not been defined?
Level 2 Architecture principles have been defined but are not explicitly linked to their architecture requirements
Level 3 Some architecture principles have been defined and are linked to their architecture requirements. However, principles for at least one of the four architecture viewpoints have not been elaborated
Level 4 Architecture principles have been defined for all three architecture viewpoints and are linked to their architecture requirements. However, the solution architecture principles to resolve a series of viewpoint intersections have not been defined
Level 5 Architecture principles have been defined for all three architecture viewpoints and these are linked to their architecture requirements
2. EA Development Method
In order to evaluate the architecture processes maturity, it is important to understand the effectiveness of the architecture development processes and their integration with other key processes, the management of the architecture lifecycle iterations and the planning horizon of each iteration.
For the architecture program to be effective, it has to have well defined and institutionalized processes for the development and refresh of architecture and the artifacts that are produced.
Level 0 None of the following.
Level 1 No formal architecture development process
Level 2 Architecture development process defined but not mandatory
Level 3 Architecture development process mandatory but does not include architecture refresh
Level 4 Architecture development process mandatory and includes regular refreshing of the architecture
Level 5 Architecture development process is mandatory and includes regular refreshing of the architecture. Continuous improvement processes in place
The effectiveness of the enterprise architecture and its ability to add value to the organization are maximized when the architecture development process is integrated with other key processes including business planning, operation management, IT planning, portfolio management and program management.
Level 0 None of the following
Level 1 The enterprise architecture development integration with other processes is not practiced.
Level 2 The enterprise architecture development integration with other processes is practiced but not well defined.
Level 3 The enterprise architecture development integration with other processes is practiced and formally defined but limited to a minority of the key processes
Level 4 The enterprise architecture development integration with other processes is practiced and formally defined for a majority of the key processes.
Level 5 The enterprise architecture development integration with other processes is practiced and formally defined for all key processes.
A well defined enterprise architecture lifecycle is defined and executed pragmatically. Every iteration should be planned based on a well defined scope and objectives linked to the business strategy and executed as a project with the necessary checks and controls to ensure on time, on budget and on expectation delivery of the architecture artifacts. The duration of the iteration should not exceed the planning cycle of the organization.
Level 0 None of the following
Level 1 Architecture is ad hoc or reactive - no planning is done
Level 2 Architecture is proactive and process driven but not planned
Level 3 Architecture is developed in a cyclical fashion with each iteration planned as projects but not tracked
Level 4 "Architecture cycles are planned and tracked for quality, schedule and cost"
Level 5 Architecture cycles are optimized to improve performance with each iteration and to provide a mix of short and long term business benefits
The most successful architecture programs have planning horizons that match the business planning horizon, typically 3 years into the future and updated on an incremental basis. However, in many companies, architecture is 'just in time' or reactive
Level 0 None of the following
Level 1 Architecture is non-existent or reactive
Level 2 Architecture is “just in time” progressing with change projects
Level 3 "The architecture planning horizon is tactical ? 1 year"
Level 4 The architecture planning horizon is strategic 1 to 3 years
Level 5 Architecture planning is incremental with its planning horizon synchronized with the business strategy
3. Business Scenario & Requirements Process?
Mature enterprise architecture programs are explicitly linked to the business strategy and are able to demonstrate that they deliver business value. To achieve this degree of relevance, organizations must ensure that the enterprise architecture is defined within the context of the changing business environment.
The future state architecture must be driven and prioritized by the business strategy and reflect environmental trends including economic, business and technology trends. The architecture requirements should address
Level 0 None of the followings
Level 1 Architecture requirements have not been defined
Level 2 Architecture requirements have been defined but are not linked to the business strategy or environmental trends
Level 3 Some architecture requirements have been defined and linked to the business strategy and the business, information, application and technology viewpoints environmental context. However, requirements for at least one of the four architecture viewpoints have not been elaborated
Level 4 Architecture requirements have been defined for all four architecture viewpoints and are linked to the business strategy and the environmental context. However, the solution architecture requirements to resolve a series of viewpoint intersections, have not been defined
Level 5 Architecture requirements have been defined for all four architecture viewpoints and are linked to the business strategy and the environmental context. Solution architecture requirements that resolve a series of viewpoint intersections has also been defined
Some key business trends have a direct impact on organizations and lead to the initiation of change within them. Effective architecture programs identify and capture critical business trends and how they can impact the organization.
Level 0 None of the following
Level 1 Business trends have not been formally identified by the EA team
Level 2 Business trends have been identified by the EA team, but not agreed upon
Level 3 "Business trends have been identified and agreed upon with the business"
Level 4 "Business trends have been identified, agreed upon and are periodically reviewed and updated"
Level 5 Business trends have been identified, agreed upon and are continuously reviewed and updated
As new technologies are introduced, organizations must identify the impact of those technologies on the business and plan for the appropriate deployment strategy?
Level 0 None of the following
Level 1 Technology trends have not been formally identified
Level 2 Technology trends have been identified by the EA team, but not agreed upon
Level 3 Technology trends have been identified and agreed upon with the business
Level 4 Technology trends have been identified, agreed upon and are periodically reviewed and updated
Level 5 "Technology trends have been identified, agreed upon and are continuously reviewed and updated"
Architecture needs to be the integral part of business operations and planning.
Level 0 Business requirements specific to a problem
Level 1 Minimal, or implicit linkage to business strategies or business drivers.
Level 2 Explicit linkage to business strategies.
Level 3 Enterprise Architecture is underwritten by the business operations
Level 4 Capital planning and investment control are adjusted based on the feedback received and lessons learned from updated Enterprise Architecture. Periodic reexamination of business drivers.
Level 5 Architecture process metrics are used to optimize and drive business linkages. Business involved in the continuous process improvements of Enterprise Architecture.
4. Stakeholder Involvement
This task establishes the base for the execution of the entire EA iteration. As such, it is critical that the architecture team obtains the right sponsorship and achieves alignment with all key involved stakeholders. The key activities include: Architecture program effectiveness is only maximized when the appropriate stakeholders provide the necessary support. In order to evaluate the involvement of the stakeholders in an enterprise architecture practice and be able to evaluate their demonstrated support, it is important to assess the level of sponsorship provided by senior management, the engagement of the business unit managers and their teams, the participation of the IT organization and most importantly the effectiveness level of the architecture program communication to all involved parties.
Enterprise architecture success in aligning business and IT starts with obtaining the right senior management support. This can only be achieved if the EA practice is perceived to be a strategic initiative with business benefits. The senior management sponsorship is best reflected in the support provided to the practice at the steering committee level and effectively demonstrated through the governance and enforcement processes adopted, as those help motivate the appropriate behaviours across all stakeholders.
Level 0????????None of the followings
Level 1????????Most Corporate Managers have no awareness or involvement with the architecture program
Level 2????????Most Corporate Managers are aware of the architecture program but do not see it as relevant to them
Level 3????????Most Corporate Managers are aware of the architecture program and it has the support of a significant minority
Level 4????????Most Corporate Managers understand and support the architecture program
Level 5????????Support of the architecture program by Corporate Managers is embedded into the enterprise culture
?Architecture should engage the support of the business, ensuring that business unit managers understand the value of architecture and support its contribution during projects. Without the active involvement of the business units, enterprise architecture can become an overhead which leads architects to engage in an on-going battle to ensure architecture compliance
Level 0????????None of the followings
Level 1????????Most business unit managers have no awareness or involvement with the architecture program
Level 2????????Most business unit managers are aware of the architecture program but do not see it as relevant to them.
Level 3????????Most business unit managers are aware of the architecture program and it has the support of a significant minority
Level 4????????Most business unit managers understand and support the architecture program.
Level 5????????"Support of the architecture program by business unit managers is embedded into the enterprise culture"
The involvement and contribution of all the IT constituents namely the Infrastructure Managers, Project/Program Managers, Application Managers, or even Developers help make enterprise architecture actionable. Communication and on-going involvement with these key constituents is critical to the success of the EA effort
Level 0????????None of the followings
Level 1????????Most "Key IT Constituents" have no awareness or involvement with the architecture program
Level 2????????Most "Key IT Constituents" are aware of the architecture program but do not see it as relevant to them
Level 3????????Most "Key IT Constituents" are aware of the architecture program and it has the support of a significant minority
Level 4????????Most "Key IT Constituents" understand and support the architecture program
Level 5????????Support of the architecture program by "Key IT Constituents" is embedded into the enterprise culture
In order to obtain the right level of support and compliance, the architecture program should clearly and widely communicate its value proposition, principles and processes to its key stakeholders. This communication effectiveness is maximized when the message and channel of communication are adapted to each specific stakeholder.
Level 0?None of the followings
Level 1?There is no formal communication of the architecture
Level 2?Some aspects of the architecture have been documented and are available. However, it is one-size-fits-all with no recognition of the different needs of various stakeholder groups
Level 3?Most aspects of the architecture have been documented and are available. However, it is one-size-fits-all with no recognition of the different needs of various stakeholder groups
Level 4?All aspects of the architecture have been documented and are available. There is recognition of the different needs of various stakeholder groups to a certain extent
Level 5?The architecture is well documented and accessible to all stakeholders. Views of aspects of the architecture are available to meet the needs of different stakeholder groups
5. Architecture Content
The evaluation of the architecture content depends on the alignment of the requirements with the business priorities and the coverage of the principles and models across all the four architecture viewpoints namely business, information, application and technology. This also represents the structure of reusable architecture building blocks.
Reusable artifacts in the continuum.
Level 0?Product focused
Level 1?Non-existent. Enterprise Architectures under development
Level 2?Foundation architecture defined. Responsibilities are assigned and work is underway on common systems architectures.
Level 3?Architecture Building Blocks are translated into Solution Building Blocks and agreed by the business
Level 4?The Enterprise Continuum defined and re-use of architecture artifacts is best practice.
Level 5?Enterprise Continuum fully operational with compatible Industry Enterprise Products & Solutions.
Architecture models define the current and future state architecture. The current state architecture models serve as a baseline for change.
领英推荐
Models exist for each of the architecture viewpoints and these are consistent with the architecture principles. Models are developed iteratively to optimize support for the business strategy
Level 0?"None of the followings"
Level 1?"Few, if any, future state models have been created. Those that do exist are not linked to architecture principles"
Level 2?Some future state models have been created that are consistent with the relevant architecture principles. Some current state models might also exist but these are not explicitly linked to future state models to serve as baselines for change
Level 3?Future state models have been created that are consistent with the relevant architecture principles. These are accompanied by those current state models that are needed as baselines for change. However, models for at least one of the four architecture viewpoints have not been elaborated
Level 4?"Future state models for all four architecture viewpoints have been created that are consistent with the relevant architecture principles. These are accompanied by those current state models that are needed as baselines for change"
Level 5?Future state models for all four architecture viewpoints have been created and are consistent with the relevant architecture principles. These are accompanied by those current state models that are needed as baselines for change. The models that have been developed have been explicitly selected to optimize alignment with the business strategy
6. Architecture Resources
The talents, skills, tools, repository and training of the enterprise architecture are not only critical to the current level of success of the architecture program, but also vital to the ability of the practice to evolve and mature as part of its continuous evolution and improvement processes.
To be successful, the enterprise architecture team must have the necessary skills and talents. Training, mentoring and certification programs must be in place to ensure a sustainable pool of EA team resources
Level 0?None of the followings
Level 1?The architecture team is new and formal training has not been completed
Level 2?The EA program has been established and is operating, but EA team members generally lack EA training
Level 3?Basic EA training has been completed by EA team members
Level 4?All long term EA team members have been formally trained and a training program has been developed for new team members
Level 5?All long term EA team members have been formally trained and a training program is in place for the wider architecture community
Mature EA programs require EA tools to create and manage the artifacts
Level 0?None of the followings.
Level 1?The EA program is just getting started.
Level 2?The EA program uses basic MS Office tools (Word, Visio, PowerPoint), or similar.
Level 3?An EA tool has been selected is used by the enterprise architects
Level 4?An EA tool has been selected, is used by the enterprise architects, and is used to communicate enterprise architecture to stakeholders
Level 5?An EA tool is integrated within an IT governance suite and other EA-related tools and is used as a communication hub with all EA stakeholders
Rich repository helps the architects to manage change and complexity in a efficient and effective manner.
Level 0?Specifications delivered after the solution!
Level 1?The latest version of the Enterprise Architecture documentation is on the Web. Little communication exists about the Enterprise Architecture process and possible process improvements.
Level 2?The Enterprise Architecture Web Pages are updated periodically and is used to document architecture deliverables. process modeling tools used.
Level 3?Architecture documents updated regularly on Enterprise Architecture Web Page.
Level 4?Enterprise repository set up and Architecture descriptions are updated regularly, and frequently reviewed for latest architecture developments/standards.
Level 5?Architecture documents and descriptions are used by every decision maker in the organization for every IT related business decision.
7. Architecture Governance
Architecture governance is the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level.
Architecture governance typically does not operate in isolation, but within a hierarchy of governance structures, which, particularly in the larger enterprise, can include all of the following as distinct domains with their own disciplines and processes: Technology Governance & Architecture Governance
Architecture governance is the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level. It includes the following:
Implementing a system of controls over the creation and monitoring of all architectural components and activities, to ensure the effective introduction, implementation, and evolution of architectures within the organization.
Implementing a system to ensure compliance with internal and external standards and regulatory obligations.
Establishing processes that support effective management of the above processes within agreed parameters.
Developing practices that ensure accountability to a clearly identified stakeholder community, both inside and outside the organization.
Level 0?Governance seen as bureaucracy.
Level 1?No explicit governance of architectural standards.
Level 2?Governance of a few architectural standards and some adherence to existing Standards Profile.
Level 3?Explicit documented governance of majority Enterprise investments.
Level 4?Explicit governance of all IT investments. Formal processes for managing variances feed back into Enterprise Architecture.
Level 5?Explicit governance of all IT investments. Continuous Improvement of governance-process and related Service delivery.
Technology governance is a key capability, requirement, and resource for most organizations because of the pervasiveness of technology across the organizational spectrum.
Not only are organizations increasingly dependent on IT for their operations and profitability, but also their reputation, brand, and ultimately their value are also dependent on that same information and the supporting technology.
Level 0?Governance seen as bureaucracy.
Level 1?No explicit governance for technology as a whole.
Level 2?Governance of a few technology standards and some adherence to existing technology Profile.
Level 3?Explicit technology governance of majority Enterprise investments.
Level 4?Explicit technology governance of all IT investments. Formal processes for managing variances feed back into Enterprise Architecture.
Level 5?Explicit technology governance of all IT investments. Continuous Improvement of technology governance-process and related Service delivery.
Architecture adherence, compliance, or assurance must be addressed through a well defined set of processes. Leveraging the enterprise program management office to integrate "architecture touch points" into the project management methodology of the enterprise is recommended.
Architecture compliance is evaluated at those touch points. This includes a process for assessment and approval of waivers from architecture standards and guidelines
Level 0?None of the followings
Level 1?The compliance is actively avoided
Level 2?Architecture influences decision making on purely advisory basis
Level 3?Architecture compliance is mandatory and the process to be followed is clearly defined and well communicated
Level 4?Architecture compliance is mandatory and architecture reviews are integrated into program management processes
Level 5?Architecture compliance is mandatory and penalties are applied for non-compliance.
8. Architecture Project
Architecture project is an understanding of demand / need in context with strategy and enterprise architecture standards and guidelines of an entity to identify right technology selection and solution design. Project also considers compliance and building of reference architectures.
Execution of planned and ad-hoc architecture projects.
Level 0?Architecture projects considered to be time wasting – lets get down to that code!!!!
Level 1?No Enterprise Architecture projects
Level 2?Architecture Projects linked with Project Management methodology
Level 3?Critical Architecture Projects under Program and Project management control
Level 4?All Enterprise Architecture Projects prioritized and majority under Programme & Projects management
Level 5?No unplanned IT investment or acquisition activity. Architecture projects integrated with Service portfolio planning.
To be effective, architecture programs must be aware of all planned and ongoing projects with appropriate "touch points" to ensure that those projects are architecturally aligned. If the EA program is properly supported, disclosure of projects to the EA team should be made mandatory through well defined and implemented processes.
Level 0?None of the followings
Level 1?Project disclosure (planned or current) is actively avoided
Level 2?"Disclosure of Projects is purely optional - no disclosure process in place"
Level 3?Disclosure of projects is mandatory but no formal disclosure processes are in place
Level 4?Disclosure of projects is mandatory and disclosure processes are in place
Level 5?Disclosure of projects is mandatory. Penalties for non-disclosure are in place
9. Architecture Change Management
The goal of an architecture change management process is to ensure that changes to the architecture are managed in a cohesive and architected way, and to establish and support the implemented enterprise architecture as a dynamic architecture; that is, one having the flexibility to evolve rapidly in response to changes in the technology and business environment.
The footprint of architecture defines the coverage across the legacy and new business models and technologies.
Level 0?Legacy management is spiraling out of control
Level 1?Legacy architectures not subject to Architecture Change Management
Level 2?Little or no formal governance of existing Legacy architectures.
Level 3?Architecture Governance commences. Architecture Board operational, Compliance reviews started.
Level 4?Asset Management of legacy architecture and related new initiatives managed through the change management process
Level 5?Portfolio Management of Architecture projects and Service delivery
To be successful, the architecture program must cover both current and future state to be able to understand how to lead the organization towards the realization of its strategic objectives. Appropriate initiatives must be identified and prioritized as part of an enterprise-wide project prioritization process that balances the enterprises long and short term needs
Level 0?None of the followings
Level 1?Future state architectures are not defined in anything more than a piecemeal fashion
Level 2?Architecture is reactive with gap analysis performed in response to specific requests. There is no enterprise-wide oversight
Level 3?"Future state business, information, technology and solution architecture gaps have been identified but have not been coordinated"
Level 4?"Future state business, information, technology and solution architecture gaps have been identified in a consistent fashion within enterprise architecture"
Level 5?"Future state business, information, technology and solution architecture gaps have been identified in a consistent fashion within enterprise architecture and the impacts on stakeholders have been considered"
High level migration plans prioritize highest business priority projects and determine which supporting projects must also be initiated to meet the business objectives
Level 0?None of the followings
Level 1?Future state architectures are not defined in anything more than a piecemeal fashion
Level 2?"Architecture is reactive with migration projects initiated in response to specific requests. There is no enterprise-wide coordination"
Level 3?Business change projects have been prioritized
Level 4?Project dependencies have been identified. Project charters feed into the budget allocation process
Level 5?Business priorities drive migration planning and implementation for both business change and supporting projects
10. Benefit Realization
To demonstrate and improve the effectiveness, enterprise architecture programs must be measured on their impact on the business. Organizations are using increasingly sophisticated metrics, including measures of financial efficiency and business effectiveness benefits.
In order to consistently demonstrate its value to the business and ensure its continuity, the EA program should have well defined and communicated goals supported by a set of reports to communicate the realization of those objectives.
Level 0?None of the followings
Level 1?There is no measurement or reporting program in place
Level 2?Ad hoc reporting to EA Team’s manager based upon points of interest or problems and concerns
Level 3?"Some EA metrics delivered formally"
Level 4?A measurement and reporting program in place that delivers one report to all stakeholders
Level 5?A mature, established and planned EA measurement and reporting program that is delivering well crafted messages specific to each key stakeholder, which is continuously reviewed and updated
Business benefits & cost-benefits measurement.
Level 0?Benefits not measured
Level 1?No benefits achieved from the Enterprise Architecture Program
Level 2?Potential Enterprise benefits realised.
Level 3?IT acquisition strategy exists and includes compliance measures to Enterprise Architecture. Cost-benefits are considered in identifying projects.
Level 4?Benefits of Enterprise Architecture realised for initial projects.
Level 5?Investment Management & Value assessment of Enterprise Architecture built into the Profit & Loss
11. Application Architecture
To demonstrate and improve the effectiveness, enterprise architecture programs must be measured on their application architecture models which should include as-is, to-be, transition and integration models..
In order to manage change and complexity application models of the enterprise are vital. These models demonstrates the current application landscape, architecture, integration in addition to to-be models and transition architecture.
Level 0?None of the following
Level 1?Non-existent. Enterprise Application Architectures under development (Product focused)
Level 2?Application architecture models are defined. Responsibilities are assigned and work is underway on core systems.
Level 3?As-is & To-be Application, integration architecture models are defined. Responsibilities are assigned and work is underway on all the systems..
Level 4?As-is & To-be Application, integration and transition architecture models are defined. Responsibilities are assigned and work is underway on all the systems..
Level 5?Application portfolio and the artifacts are available in enterprise Continuum and fully operational with compatible Industry Enterprise Products & Solutions.
Provides a template solution for an architecture for a particular domain.
Level 0?None of the following
Level 1?Reference architecture have not been formally identified by the EA team
Level 2?Reference architecture have been identified by the EA team, but not agreed upon
Level 3?"Reference architecture have been identified and agreed upon with the business"
Level 4?"Reference architecture have been identified, agreed upon and are periodically reviewed and updated"
Level 5?Reference architecture have been identified, agreed upon and are continuously reviewed and updated
12. IT Security
IT Security is a paramount for any organization and it needs to be considered design to deployment. Relevant principles must be defined, control should be established with appropriate monitoring and management capability.
IT Security adherence, compliance, or assurance must be addressed through a well defined set of processes. Leveraging the enterprise program management office to integrate "architecture touch points" into the project management methodology of the enterprise is recommended.
IT Security compliance is evaluated at those touch points. This includes a process for assessment and approval of waivers from architecture standards and guidelines
Level 0?None of the followings
Level 1?The compliance is actively avoided
Level 2?Architecture influences decision making on purely advisory basis
Level 3?Security Architecture compliance is mandatory and the process to be followed is clearly defined and well communicated
Level 4?Security Architecture compliance is mandatory and architecture reviews are integrated into program management processes
Level 5?Security Architecture compliance is mandatory and penalties are applied for non-compliance.
IT Security Architecture Standards Profile is fully developed and is integrated with Enterprise Architecture
Level 0?None of the following
Level 1?Non-existent. IT Security Architectures under development (Product focused)
Level 2?IT Security architecture models are defined. Responsibilities are assigned and work is underway on core systems..
Level 3?IT Security architecture models are defined.?Responsibilities are assigned and work is underway on all the systems..
Level 4?IT Security architecture models are defined.?Responsibilities are assigned and work is underway on all the systems. Relevant metrics are also measured.
Level 5?IT Security architecture models are defined and fully operational with compatible Industry Enterprise Products & Solutions.