Skip to content

On Enterprise Architecture Principals

As discussed previously, principles are high level statements of the fundamental values that guide business and technology decision-making and activities and are the foundation for architecture, standards, and policy development. Principles are stable enough to withstand technological and process changes but timely enough to maintain a clear relevancy with markets, policy, program, and management changes.

Principles consist of the principle statement, rationale, and implications. Though the wording for principles should remain consistent, the rational and implications will evolve over time, as an organization responds to factors such as the current IT environment, internal initiatives, external forces and markets, and changes in mission, vision, and strategic plan.

In my prior role as an Enterprise architect, I used the following 16 Principles for the foundation of the Enterprise Architecture. Even with the changes that have rocked the industry in the past 3 years - public, private and hybrid cloud computing, dev-ops, etc - these principles have been steadfast.

Principal Principle

The Enterprise Architecture applies to all aspects of the organization's information technology.

  • Rationale - In the organization's environment, a framework for information technology promotes better results.

  • Implications - Enterprise Architecture must be followed by all organization business units to strengthen the ability of the organization's IT to provide a consistent and measurable level of quality to customers. An exception process will be in place to accommodate new technology and specific needs. Standards must be flexible enough to be responsive to address business needs.

Business Priority

Information systems exist to support the needs of the business. Therefore, the Enterprise Architecture must support the enterprise vision, business strategies and plans.

  • Rationale - The architecture has the most value when closely aligned with the organization's strategic plans and other corporate-level direction, concepts, and objectives.

  • Implications - Technology choices must be linked to business needs. Some technologies will not be appropriate at the organization. The organization's Strategic Plan, goals and objectives will be utilized in developing key components of the architecture business vision and architecture components. The architecture must be generated with a specific purpose and for a specific audience to ensure it meets the expectations and needs of its intended stakeholders. The organization must not implement technology simply because it is available.

Business Authority

The Enterprise Architecture will embody the business’s authority and need to create, read and modify data.

  • Rationale - Those with the most knowledge of the data have the best chance of and most interest in getting it right. Integrity is improved and maintenance is simplified.

  • Implications - The authoritative source of information and data must be identified. The authoritative source must provide corporate access to appropriate data. Data may need to be restructured for easy access and management. Data integrity and security must be maintained to ensure reliability of information upon which business decisions are made.

Optimum Enterprise Benefit

Architectural decisions will maximize the overall benefit to the organization by balancing the following criteria: accessibility, consistency, cost, diversity of business needs, flexibility, functionality, manageability, precision, risk, scalability, security, supportability and value.

  • Rationale - Architectures are to provide long term benefits to the enterprise. Therefore decisions must balance multiple criteria based on the business need.

  • Implications - The business owner must prioritize criteria based on funding, governance and knowledge, skills and abilities of staff. Criteria may receive different emphases in different situations.

Appropriate to Purpose

The Enterprise Architecture must be appropriately scoped, planned, and defined based on the intended use of the architecture.

  • Rationale - The architecture development effort needs direction and guidance to meet expectations for specific uses of the architecture end products. Detailed models may not be needed for high-level decision-making; similarly, simple, descriptive architectures may not provide enough information to support engineering choices.

  • Implications - The architecture must be generated with a specific purpose and for a specific audience to ensure it meets the expectations of its intended stakeholders.

Reusability of Components

The Enterprise Architecture will be built on loosely-coupled, reusable modular components that implement services.

  • Rationale - Reusable components provide opportunities to reduce IT development costs and development time. Reusable components leverage investments in existing IT systems. Modular components improve the ability of systems to adapt to changing requirements because the changes will be isolated to affected modules.

  • Implications - The architecture will establish standards and guidelines for developing system components.

Components

The Enterprise Architecture supports technologies to meet needs and requires mature, proven interoperable technologies in support of service environments. Technical diversity that does not tie to business needs is discouraged.

  • Rationale - Cost and risk are limited unless justified by potential value gains.

  • Implications - Introduction of new technologies will be explicitly evaluated as an exception to standards.

Facilitate Technology Change

The Enterprise Architecture must be compliant with the law as expressed in legislative mandates, executive orders, State and Federal regulations, and other State and Federal guidelines.

  • Rationale - In the rapidly changing IT environment, an organiation needs tools to manage and control business and technical growth and change. As the technical development life cycle shortens, with new technologies replacing older ones, organizations require an overarching architecture to capture systems design and operating environments.

  • Implications - The enterprise architects should ensure the coordination between technology investments and business practices. Architectures must be used in the evaluation function of the capital planning and investment control process.

Facilitate Architectural Change

The Enterprise Architecture facilitates architectural change by developing the developing and enhancing architectural roadmaps and the supporting sequencing plan.

  • Rationale - The organization is constantly evolving towards its future. As today’s architecture transitions to the target architecture, the target becomes the baseline architecture at some point in the future. The baseline architecture continuously moves and transitions toward the target architecture.

  • Implications - The target architecture is a rolling set of products, continually portraying the future environment. As a component of strategic planning and change management, the target architecture captures the future environment including data requirements and systems transitions. A sequencing plan is the roadmap to systems migration.

Facilitate Future Data Collection, Storage, and Access

The Enterprise Architecture facilitates the effective and efficient collection, storage and access to the organization's most critical corporate asset – data.

  • Rationale - Data, as a corporate asset, is key to an organization’s vision, mission, goals, and daily work routine. The more efficiently an organization's gathers data, stores and retrieves that data, and uses the data, the more productive the business.

  • Implications - Business processes are best improved by streamlining the flow and use of data and information. The development of architectural node connectivity descriptions, information exchange matrices, and other information models will aid in the design of improved data management systems.

Develop and Validate Accurate Architectural Information

The Enterprise Architecture will be supported by the knowledge and experience those persons with the knowledge of the business, its processes and associated information.

  • Rationale - The architect is not vested with the organizational information. It is incumbent upon the architect to collect the needed architectural information from the persons who possess the knowledge of the business processes and associated information. These subject matter experts tend to be operational staff, field representatives, systems developers, software designers, etc. The domain owners are the responsible managers of specific business units/areas.

  • Implications - The development of the architecture can be a slow process, dependent on the architect’s access to subject matter experts and domain owners. The validity of the architecture can be limited by the accuracy of the collected data. Development of the architecture is an iterative process of data gathering and interviewing to obtain verification and validity checks of the architectural products.

Control of Incongruous Technology

The Enterprise Architecture will provide the governance controls and oversight that manage technology investments and insertions into the enterprise.

  • Rationale - The unquestioned adoption of new and innovative Information Technology products can easily lead to the introduction of incongruous IT products that result in a lack of interoperability in the existing enterprise infrastructure. To avoid this lack of interoperability, it will be necessary to carefully select and use proven standards based technologies and products.

  • Implications -  Enterprise Architecture must be used in conjunction with the organization's investment review process and technology insertion plans. This reliance upon the Enterprise Architecture as an integral component of IT decision-making will help safeguard against the introduction of incompatible products and support security objectives.

Partnership

Every IT investment will have both a Business Owner and an IT Steward. The Business Owner is responsible for the business domain the investment enables. The IT Steward is responsible for the management and technical infrastructure of the investment.

  • Rationale - Business and IT each provides different and required contributions to the acquisition and management of IT investments. Business brings an understanding of the business processes supported and the desired outcome. IT brings an understanding of the technical options to implement the process support and ensure coherence with other elements. This principle ensures a partnership between the business and IT is established for every IT investment.

  • Implication - Business Owners and IT Stewards must work in partnership to successfully achieve the objectives of the investment.

Comply with Law

The Enterprise Architecture must be compliant with the law as expressed in legislative mandates, executive orders, State and Federal regulations, and other State and Federal guidelines.

  • Rationale - The organization must abide by laws, policies, and regulations. However, this does not preclude business process improvements that lead to changes in policies and regulations.

  • Implications - The organization should be aware of laws, regulations, and external policies regarding the development of architectures and the collection, retention, management, and security of data.

Support the Strategic Plan

The Enterprise Architecture will support the business strategy. As the Enterprise Architecture matures and becomes more closely aligned to business strategy the technology initiatives will more directly increase business value and responsiveness.

  • Rationale - The target architecture has maximum value when it is most closely aligned with the organization’s strategic plan and other corporate-level direction, concepts, and planning.

  • Implications - The target architecture must be developed in concert with strategic planners as well as the operational staff. As the strategic plan changes, so do the future environment and the target architecture.

Support the Planning Horizon

The Enterprise Architecture will support the business planning horizon – the time frame for planning strategic activities and for accomplishing strategic goals.

  • Rationale - Technology life cycles currently are in the neighborhood of 18 months, and new IT products appear almost constantly. The organization's future information needs and technical infrastructure requirements are changing just as rapidly. Consequently, no one can accurately predict what business practices will prevail 10 to 20 years into the future and what type of IT capabilities and resources will be available.

  • Implications - While the business elements of the target architecture will be more stable in general, the technology elements of the target architectures will need to be revised and updated regularly. The sequencing plan, illustrating intermediate points in time, may become more valuable than the target architectures.