Enterprise Architecture

Architecture development is entirely ad hoc. We have no defined process to speak of.

Our EA development process is defined, documented, and tailored to the needs of our organization.

While we may have a process documented, it is never followed.

Our EA development process is well understood and followed comprehensively.

There is no review or optimization of our architecture development process.

Our EA development process is subject to continuous review and formal optimization.

There is no linkage between the architecture process and others processes.

Our EA development process is integrated into other related organizational processes; and works efficiently in harmony with them.

Execution of our EA development process is non-existent or always poor.

Our EA development process is always well executed by architects and delivery teams.

There is little to no appreciation or knowledge of corporate strategy within EA.

Our corporate strategy (including drivers, goals and objectives) is well known and understood by the EA team. Strategy drives our architecture roadmap.

There is little or no definition of business architecture.

Our business architecture is comprehensively documented at baseline and target states, and is subject to regular refresh.

Few business processes are documented or codified.

Our business processes are well documented, standardized, and subject to regular refresh.

There is no linkage of strategy elements to the underlying architecture.

The elements of our corporate strategy (drivers, goals, objectives, etc.) are well codified, and linked to the underlying architecture. This linkage is subject to regular analysis and refresh.

Our EA is practically irrelevant when it comes to strategic planning.

Our EA serves as a key resource to the business during strategic planning cycles.

Almost no one in the organization knows what EA is or what we do.

The mission and purpose of our EA function is well understood and appreciated across the organization.

Senior management have no understanding of what we do, or see us merely as a cost center.

Senior management and leadership understand our role and contribution to the business, and actively support and promote our work. We are seen as an aid to innovation in the organization.

There is little or no transparency of EA work to stakeholders in the business.

EA work and processes are surfaced regularly and transparently to stakeholders in the organization.

There is little productive engagement between EA and IT operations.

There is constant, productive, bi-directional engagement between EA and IT operations teams.

We put little or no effort towards proactively managing EA stakeholders in the business.

Our EA function practices proactive stakeholder management; carefully tailoring outputs and communications to stakeholder needs. This practice is regularly reviewed and optimized.

The EA team itself is poorly defined, and does not adhere to any clear organizational structure.

Our EA team has clearly defined roles and reporting structures, and combines the optimum levels of experience and organizational model needed to achieve our mission.

Our EA artifacts are stored on disparate platforms. We do not utilize a dedicated EA tool.

We leverage a best in class EA management tool, that provides a governed modeling environment, rich analysis features, and a collaborative repository to house and maintain artifacts.

We have no defined EA framework or metamodel.

Our EA operates around a defined EA framework, that is based on industry best practice and includes an EA metamodel that is optimized to the needs of the organization.

Artifacts are unstructured, do not adhere to a metamodel, and there is no established visual notation in use.

Our EA artifacts are structured according to our defined metamodel, and utilize notational standards that are tailored to stakeholder needs and aid communication.

We have no effective means of socializing the outputs of EA to our stakeholders.

We utilize an easy to use web-based platform that enables us to socialize EA outputs to stakeholders across the organization on a live basis. This platform is well used and entrenched, and fosters transparency and engagement with EA.

EA's impact for mitigating or reducing technology risk on the business is not qualified or quantified.

The value of EA with respect to mitigating or reducing risk from technology on the business is well understood, and part of a structured program of EA performance measurement.

EA makes little or no contribution to standardization of business and technology structures in the organization.

EA effectively oversees the standardization of architectures developed in the organization. Standards management is efficient, optimized and subject to regular review. The exceptions process is well defined and impacts are quantified and tracked.

Roadmaps are static or not utilized. There is little or no visualization of the future state.

EA has mastered the visualization of architectural future states on dynamic roadmaps that optimally communicate the path ahead to stakeholders in the business, across domains.

EA, insofar as it may be practiced, does not deliver strategic insights that are seen as meaningful to senior management.

Our EA delivers powerful strategic insights to senior management that directly speak to their concerns, and link strategy to execution.

We have no structured way to measure or communicate the success of the EA program.

We, and our leadership, know what success looks like for the EA program. We operate to clearly defined performance measurement criteria, that are reviewed regularly.