Enterprise Architecture Principles

1.   Primacy of Principles

Description

These principles of software system architecture apply to all organizations within the enterprise.

Rationale

The only way we can provide a consistent and measurable level of architecture quality and technology investments is if all organizations abide by the principles.

Implications

Without this principle, exclusions, favoritism, and inconsistency would rapidly undermine the management of software systems.

A conflict with a principle will be resolved by changing the framework of the initiative.

2.   Maximize Benefit to the Enterprise

Description

Software system development decisions are always made under the business alignment perspective in order to generate maximum benefits for the company as a whole.

Rationale

A better alignment between IT strategy and the IT development teams must generate a competitive edge for the institution.

Decisions based on the corporate perspective have greater long-term value than decisions based on a certain perspective of a group with a specific interest. An optimal ROI requires management decisions to be aligned with the company's priorities and positioning.

Without adhering to the needs of a business domain, and the implications of the other architecture principles, providing architecture recommendations based on resource availability creates a less coherent enterprise architecture.  Resultant increases in complexity, and maintenance burden are commensurate with a reduction in cohesive architectures and productivity organization wide.

This principle, however, must not prevent anyone from performing tasks and activities.

Implications

Aligning IT strategy with the IT development teams and promoting optimal corporate benefits requires changes in how system development efforts are planned and managed. Technology Architecture alone is not enough to promote such changes.

IT must focus on IT services directed toward establishing a competitive edge.

IT must implement a complete IT vision that is focused on business.

Some areas might need to waive their specific preferences to benefit the company as a whole.

Application development priorities must be established by and for the entire company.

Application components must be shared among all areas of the financial institution.

Information management initiatives must be conducted based on a corporate plan. Individual areas must follow IT strategy and management initiatives in accordance with corporate plans and priorities. Planning is modified whenever necessary.

When different team resources are available, we do not recommended changing architectures to match the resource constraints.  Technical architectures should be aligned to the technology strategy of the company.

As new needs arise, priorities must be adjusted proportionally.

3.   Maximum benefits at the lowest costs and risks

Description

Strategic decisions for solutions must always strive to maximize benefits generated for the business at the lowest long-term risks and costs.

Rationale

Decisions must not be made based solely on reaching lower solution costs. Every strategic decision must be assessed based on cost, risk, and benefit perspectives. Lower costs often represent greater risks and, perhaps, fewer benefits.

Implications

A solution must be selected based on a qualitative or quantitative cost, risk, and benefit assessment

Most times, quantitative assessments are simpler based on cost perspective but more complex for risks and even more intricate for benefits. The quantitative assessment must always be conducted whenever possible and sufficient.

A qualitative assessment of one or two perspectives is sufficient when a quantitative assessment of other perspectives (for example, cost) is properly conducted and already leads to a decision.

Operating risks must be quantified whenever possible.

IT infrastructure must also be optimized based on business requirements and technological capacity to generate lower costs and risks, thus benefiting the focus of the company.

4.   Shared information

Description

Users have access to information that is necessary for performance of their respective tasks. Therefore, information is shared between different corporate areas and positions, depending on the security levels established for that particular set of information.

Rationale

Necessary access to accurate information is essential to improve the quality and efficiency of the decision-making process of the financial institution. It is less expensive to maintain integral information in a single application and share that than to maintain duplicate information in multiple applications.

The company has plenty of information, but it is stored in hundreds of incompatible databases. The speed in which information is obtained, created, transferred, and absorbed is driven by the organization's capacity to effectively share these information islands throughout the company.

Shared information promotes better decisions because they are less dependent of less-reliable sources and information managed in the decision-making process.

Implications

To enable information sharing, a common set of policies, procedures, and standards must be developed and followed to regulate information management and both short-term and long-term access.

In the short term, to preserve a significant investment in existing systems, investments in software capable of retrieving and integrating information from existing systems into a shared information environment are required.

Normalized data models and metadata that define such shared environments must be developed, in addition to a repository to store the metadata and make it accessible.

As existing systems are replaced, common information access and developer guidelines must be adopted and implemented to ensure that all information in new applications remains available in the shared environment.

In both short and long-term, common methods and tools to create, maintain, and access shared information must be adopted throughout the company.

The information-sharing principle is constantly confronted with the information security principle. Information sharing must not compromise the confidentiality of information under any circumstance.

Shared information must be used by all collaborators to perform their respective tasks. This ensures that only the most up-to-date and accurate information is used in the decision-making process. Shared information shall become the only virtual source of corporate information.

5.   Common terminology and data definitions

Description

Data is defined coherently throughout the company, and definitions are comprehensible and accessible by all users.

Rationale

The data employed in the development of applications, and used in messaging systems, must have a common definition so that the data can be shared. A common terminology facilitates communication and promotes efficient dialogs. Additionally, data and interfaces must be shared among different systems.

Implications

This is separate from "data administration" or “data operation” functions and stated responsibilities. Additional significant energy is required, in addition to resources applied in this task. This is essential to develop the information environment.

The company must first establish a common terminology for business activities. Such definitions must be uniformly used throughout the company.

Whenever a new data definition is required, efforts regarding such definition must be coordinated and reconciled with the corporate data description "glossary." The company's data administrator needs to be responsible for such coordination.

Ambiguities arising from multiple data definitions must be replaced by a definition that is accepted and understood by the entire company.

Data normalization initiatives must be coordinated, and canonical models must be adopted.

Functional data administration responsibilities must be assigned.

6.   Technological independence

Description

Applications and services do not depend on specific technological options and, therefore, can function on different technology platforms. The IT architecture must be planned to reduce the impact of technological changes in the business.

Rationale

The independence of technological applications allows them to be developed, adapted, and operated under the best cost-to-benefit ratio. Alternatively, technology (which is subject to supplier dependence and obsolescence) becomes the users' motivation, rather than their requirements.

This principle is based on the concept that each IT decision renders us dependent of such technology. The purpose of this principle is to ensure that the software is not dependent on specific operating system software or particular hardware.

Implications

This principle requires standards that support portability, which are often called open standards.

Application program interfaces (APIs) must be developed to integrate existing applications with operating environments and applications developed based on the enterprise architecture.

Middleware must be employed to disassociate applications from specific software solutions.

7.   Component reusability and simplicity

Description

The enterprise architecture is built over low-coupling, reusable, modular components that implement services.

Systems architecture must be as simple as possible to maintain yet meet all business and corporate requirements. Whenever complexity is required, it must be encapsulated to promote simplicity of solutions built on the architecture.

Rationale

Reusable components represent opportunities to reduce IT development times and costs. Reusable components leverage investments in current systems. Modular components increase the systems' capacities to adapt to different evolution needs, because the change is isolated from affected modules.

Implications

The architecture establishes standards and guidelines to develop system components and services.

8.   Convergence with the enterprise architecture

Description

The convergence with the enterprise architecture is promoted in the right time, and in line with the company's investment strategy.

The convergence with the enterprise architecture takes place as new applications are built, new technologies are implemented, and older systems are updated or decommissioned. Exceptions to the enterprise architecture might be supported for specific cases if there is a consensus that the benefits of using a solution from a specific technology exceed those arising from the adoption of the enterprise architecture.

Rationale

Convergence offers several advantages:

·        It allows the enterprise architecture to evolve and accommodate changes in business and technologies.

·        It avoids conversions of obsolete systems, which are extremely expensive.

·        Over time, it preserves the investment while promoting the benefits of the enterprise architecture.

Implications

Delayed convergence could reduce the benefits of the enterprise architecture.

Convergence requires a realistic and tangible approach to migration to the enterprise architecture.

It requires an explicit transition strategy for current systems after the target technology is identified.

Allows decommissioning a system sooner when that is appropriate.

Convergence does not allow waiting indefinitely. It requires a business case for exceptions, an exception process, and an exit strategy. It must establish temporary or permanent exceptions, as well as exit strategies for temporary exceptions.

Convergence requires sponsorship to replace obsolete technologies.

9.   Low-coupling interfaces

Description

Interfaces have low coupling, are self--described, and offer low impact on the institution in case of changes.

Rationale

Low-coupling interfaces are preferable, because when interfaces between independent applications are highly coupled, they are less generic and more susceptible to causing unwanted, secondary effects when they are changed.

Implications

Low coupling means that the services (APIs, for example) are conceived with no affinity to a certain service consumer.

Therefore, the service is completely uncoupled to a service consumer. However, the service consumer is dependent of the service (that is, contains references for service interfaces).

10.                   Control of technical diversity

Description

Technological diversity is controlled to minimize significant costs related to the maintenance of expertise and connectivity between several different processing environments.

Rationale

There is a real and significant cost related to the infrastructure required to support alternative technologies for processing environments. There are other infrastructure costs to maintain the architecture of multiple interconnected systems.

Limiting the number of supported components simplifies and reduces maintenance and management costs.

A smaller number of software packages represent a greater ease and lower integration costs.

Business advantages of minimum technical diversity include:

·        Standard component packaging

·        Predictable implementation impact

·        Predictable returns and validations

·        Defined tests

·        Greater flexibility to accommodate technological advances

A common technology throughout the entire company generates scalable economic savings for the company. Technical management and support costs are better controlled when limited, and specialized, resources focus exclusively on this shared technology set.

Implications

Policies, standards, and procedures that regulate the acquisition of technology or contracting with new suppliers must be directly bound to this principle.

Technology decisions are guided by a technological blueprint.

Procedures to increase the set of acceptable technologies to meet evolved requirements must be developed and implemented.

This principle does not require freezing the technological baseline. Technological advances are welcome and incorporated into the technological blueprint when they are compatible with current infrastructures, are likely to improve operating efficiency, or there is a need to increase capacity.

In order of preference for selecting a technology for use in a solution must be: Reuse (unless it is a “non-invest” or “deprecate” technology), Buy, Build.

11.                   Uniform Metaphor

Description

Any architecture or architectural component should be designed around a powerful metaphor than can be uniformly applied in all areas.

Rationale

Having a conceptually simple metaphor as a model for architecture decisions is much easier to apply, and provides consistency, than a complex model that is difficult to understand or apply across different areas.

Implications

A straightforward example of designing around a conceptually simple uniform metaphor is a Service Oriented Architecture.  The metaphor is services, and this can be applied in all areas with heterogeneous or homogeneous technologies.

In a SOA focused organization, all decomposable functionality should be architected, designed and developed as a service.

12.                   Interoperability

Description

Software and hardware must follow established standards that promote data, application, and technology interoperability.

Rationale

Standards help ensure coherence, thus improving the ability to manage systems, raise user satisfaction, and protect current IT investments, thus maximizing return on investment and reducing costs.

Interoperability standards also help ensure support from several suppliers to their respective products, thus facilitating integration, such as through Service Oriented Architectures aligned to web standards.

Implications

Interoperability and industry standards must be followed unless there is a mandatory business reason to implement a non-standard solution.

A process to establish standards, periodic revision, and exceptions must be established.

13.                   Conceptual Integrity

Description

There must be a single purpose for which an architectural component is conceived, and introduced into the environment. 

Rationale

Without cohesion of purpose to support the concept for which an architecture component is introduced, unnecessary and unexpected complexity rises, making it more difficult to manage, learn, use, or modify an architecture or an architecture component.

Architecture components can quickly be repurposed for different scenarios, exceeding the intended use or designed limit of the components, which could risk destabilizing the component and the dependencies upon it.

Implications

There should be a single architectural vision to provide the clearest concept for the entire architecture, and this is usually provided by a single individual, or a very small group of highly aligned architects. 

This vision of why we would introduce some architectural component, or an architecture itself, is the concept around which all of our decisions must be made.  Making all decisions with the intent of supporting the same concept is what is called “Conceptual Integrity”.

The system needs to be designed with a strong point of view and a consistent set of principles as to what it should be.  After that, there is a cascading of responsibility, and ultimately it is everybody's responsibility to ensure the conceptual integrity of their piece and its relationship to the whole.

Compositions of architectural components should be conceived of and introduced to provide a specific capability, aligned to a single concept.

The result of conceptual integrity, when aligned to the other principles, is that a system is consistent and coherent across all components collectively, and in individual components.