Architecture Principles (2024)

This chapter provides principles for the use and deployment of IT resources across the enterprise.

This chapter builds on work done by the US Air Force in establishing its Headquarters Air Force Principles for InformationManagement (June 29, 1998), with the addition of other input materials.

Introduction

Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way inwhich an organization sets about fulfilling its mission.

In their turn, principles may be just one element in a structured set of ideas that collectively define and guide theorganization, from values through to actions and results.

Depending on the organization, principles may be established at any or all of three levels:

• Enterprise principles provide a basis for decision-making throughout an enterprise, and inform how the organization setsabout fulfilling its mission. Such enterprise-level principles are commonly found in governmental and not-for-profit organizations,but are encountered in commercial organizations also, as a means of harmonizing decision-making across a distributed organization.In particular, they are a key element in a successful architecture governance strategy (see Architecture Governance).
• Information Technology (IT) principles provide guidance on the use and deployment of all IT resources and assets acrossthe enterprise. They are developed in order to make the information environment as productive and cost-effective as possible.
• Architecture principles are a subset of IT principles that relate to architecture work. They reflect a level ofconsensus across the enterprise, and embody the spirit and thinking of the enterprise architecture. Architecture principles can befurther divided into:
  • Principles that govern the architecture process, affecting the development, maintenance, and use of the enterprisearchitecture
  • Principles that govern the implementation of the architecture, establishing the first tenets and related guidance for designingand developing information systems

These sets of principles form a hierarchy, in that IT principles will be informed by, and elaborate on, the principles at theenterprise level; and architecture principles will likewise be informed by the principles at the two higher levels.

The remainder of this section deals exclusively with architecture principles.

Characteristics of Architecture Principles

Architecture principles define the underlying general rules and guidelines for the use and deployment of all IT resources andassets across the enterprise. They reflect a level of consensus among the various elements of the enterprise, and form the basisfor making future IT decisions.

Each architecture principle should be clearly related back to the business objectives and key architecture drivers.

Components of Architecture Principles

It is useful to have a standard way of defining principles. In addition to a definition statement, each principle should haveassociated rationale and implications statements, both to promote understanding and acceptance of the principles themselves, and tosupport the use of the principles in explaining and justifying why specific decisions are made.

A recommended template is given in Recommended Format for Defining Principles .

An example set of architecture principles following this template is given in Example Set of ArchitecturePrinciples .

Developing Architecture Principles

Architecture principles are typically developed by the Lead Architect, in conjunction with the enterprise CIO, ArchitectureBoard, and other key business stakeholders.

Appropriate policies and procedures must be developed to support the implementation of the principles.

Architecture principles will be informed by overall IT principles and principles at the enterprise level, if they exist. Theyare chosen so as to ensure alignment of IT strategies with business strategies and visions. Specifically, the development ofarchitecture principles is typically influenced by the following:

• Enterprise mission and plans: the mission, plans, and organizational infrastructure of the enterprise.
• Enterprise strategic initiatives: the characteristics of the enterprise - its strengths, weaknesses, opportunities, andthreats - and its current enterprise-wide initiatives (such as process improvement and quality management).
• External constraints: market factors (time-to-market imperatives, customer expectations, etc.); existing and potentiallegislation.
• Current systems and technology: the set of information resources deployed within the enterprise, including systemsdocumentation, equipment inventories, network configuration diagrams, policies, and procedures.
• Computer industry trends: predictions about the usage, availability, and cost of computer and communicationtechnologies, referenced from credible sources along with associated best practices presently in use.

Qualities of Principles

Merely having a written statement that is called a principle does not mean that the principle is good, even if everyone agreeswith it.

A good set of principles will be founded in the beliefs and values of the organization and expressed in language that thebusiness understands and uses. Principles should be few in number, future-oriented, and endorsed and championed by seniormanagement. They provide a firm foundation for making architecture and planning decisions, framing policies, procedures, andstandards, and supporting resolution of contradictory situations. A poor set of principles will quickly become disused, and theresultant architectures, policies, and standards will appear arbitrary or self-serving, and thus lack credibility. Essentially,principles drive behavior.

There are five criteria that distinguish a good set of principles:

• Understandable: the underlying tenets can be quickly grasped and understood by individuals throughout the organization.The intention of the principle is clear and unambiguous, so that violations, whether intentional or not, are minimized.
• Robust: enable good quality decisions about architectures and plans to be made, and enforceable policies and standardsto be created. Each principle should be sufficiently definitive and precise to support consistent decision-making in complex,potentially controversial situations.
• Complete: every potentially important principle governing the management of information and technology for theorganization is defined. The principles cover every situation perceived.
• Consistent: strict adherence to one principle may require a loose interpretation of another principle. The set ofprinciples must be expressed in a way that allows a balance of interpretations. Principles should not be contradictory to the pointwhere adhering to one principle would violate the spirit of another. Every word in a principle statement should be carefully chosento allow consistent yet flexible interpretation.
• Stable: principles should be enduring, yet able to accommodate changes. An amendment process should be established foradding, removing, or altering principles after they are ratified initially.

Applying Architecture Principles

Architecture principles are used to capture the fundamental truths about how the enterprise will use and deploy IT resources andassets. The principles are used in a number of different ways:

1. To provide a framework within which the enterprise can start to make conscious decisions about IT
2. As a guide to establishing relevant evaluation criteria, thus exerting strong influence on the selection of products or productarchitectures in the later stages of managing compliance to the IT architecture
3. As drivers for defining the functional requirements of the architecture
4. As an input to assessing both existing IS/IT systems and the future strategic portfolio, for compliance with the definedarchitectures. These assessments will provide valuable insights into the transition activities needed to implement an architecture,in support of business goals and priorities
5. The Rationale statements (see below) highlight the value of the architecture to the enterprise, and therefore provide a basisfor justifying architecture activities
6. The Implications statements (see below) provide an outline of the key tasks, resources, and potential costs to the enterpriseof following the principle; they also provide valuable inputs to future transition initiative and planning activities
7. Support the architecture governance activities in terms of:
   • Providing a "back-stop" for the standard Architecture Compliance assessments where some interpretation is allowed orrequired
   • Supporting the decision to initiate a dispensation request where the implications of a particular architecture amendment cannotbe resolved within local operating procedure

Principles are inter-related, and need to be applied as a set.

Principles will sometimes compete; for example, the principles of "accessibility" and "security" tend towards conflictingdecisions. Each principle must be considered in the context of "all other things being equal".

At times a decision will be required as to which information principle will take precedence on a particular issue. The rationalefor such decisions should always be documented.

A common reaction on first reading of a principle is "this is motherhood", but the fact that a principle seems self-evidentdoes not mean that the principle is actually observed in an organization, even when there are verbal acknowledgements of theprinciple.

Although specific penalties are not prescribed in a declaration of principles, violations of principles generally causeoperational problems and inhibit the ability of the organization to fulfil its mission.

Example Set of Architecture Principles

Too many principles can reduce the flexibility of the architecture. Many organizations prefer to define only high-levelprinciples, and to limit the number to between 10 and 20.

The following example illustrates both the typical content of a set of architecture principles, and the recommended format fordefining them, as explained above.

Another example of architecture principles is contained in the US Government's Federal Enterprise Architecture Framework (FEAF -see FEAF).

Business Principles

Principle 1:

Primacy of Principles

Statement:

These principles of information management apply to all organizations within the enterprise.

Rationale:

The only way we can provide a consistent and measurable level of quality information to decision-makers is if all organizationsabide by the principles.

Implications:

• Without this principle, exclusions, favoritism, and inconsistency would rapidly undermine the management of information.
• Information management initiatives will not begin until they are examined for compliance with the principles.
• A conflict with a principle will be resolved by changing the framework of the initiative.

Principle 2:

Maximize Benefit to the Enterprise

Statement:

Information management decisions are made to provide maximum benefit to the enterprise as a whole.

Rationale:

This principle embodies "service above self". Decisions made from an enterprise-wide perspective have greater long-term valuethan decisions made from any particular organizational perspective. Maximum return on investment requires information managementdecisions to adhere to enterprise-wide drivers and priorities. No minority group will detract from the benefit of the whole.However, this principle will not preclude any minority group from getting its job done.

Implications:

• Achieving maximum enterprise-wide benefit will require changes in the way we plan and manage information. Technology alone willnot bring about this change.
• Some organizations may have to concede their own preferences for the greater benefit of the entire enterprise.
• Application development priorities must be established by the entire enterprise for the entire enterprise.
• Applications components should be shared across organizational boundaries.
• Information management initiatives should be conducted in accordance with the enterprise plan. Individual organizations shouldpursue information management initiatives which conform to the blueprints and priorities established by the enterprise. We willchange the plan as we need to.
• As needs arise, priorities must be adjusted. A forum with comprehensive enterprise representation should make thesedecisions.

Principle 3:

Information Management is Everybody's Business

Statement:

All organizations in the enterprise participate in information management decisions needed to accomplish businessobjectives.

Rationale:

Information users are the key stakeholders, or customers, in the application of technology to address a business need. In orderto ensure information management is aligned with the business, all organizations in the enterprise must be involved in all aspectsof the information environment. The business experts from across the enterprise and the technical staff responsible for developingand sustaining the information environment need to come together as a team to jointly define the goals and objectives of IT.

Implications:

• To operate as a team, every stakeholder, or customer, will need to accept responsibility for developing the informationenvironment.
• Commitment of resources will be required to implement this principle.

Principle 4:

Business Continuity

Statement:

Enterprise operations are maintained in spite of system interruptions.

Rationale:

As system operations become more pervasive, we become more dependent on them; therefore, we must consider the reliability ofsuch systems throughout their design and use. Business premises throughout the enterprise must be provided with the capability tocontinue their business functions regardless of external events. Hardware failure, natural disasters, and data corruption shouldnot be allowed to disrupt or stop enterprise activities. The enterprise business functions must be capable of operating onalternative information delivery mechanisms.

Implications:

• Dependency on shared system applications mandates that the risks of business interruption must be established in advance andmanaged. Management includes but is not limited to periodic reviews, testing for vulnerability and exposure, or designingmission-critical services to assure business function continuity through redundant or alternative capabilities.
• Recoverability, redundancy, and maintainability should be addressed at the time of design.
• Applications must be assessed for criticality and impact on the enterprise mission, in order to determine what level ofcontinuity is required and what corresponding recovery plan is necessary.

Principle 5:

Common Use Applications

Statement:

Development of applications used across the enterprise is preferred over the development of similar or duplicative applicationswhich are only provided to a particular organization.

Rationale:

Duplicative capability is expensive and proliferates conflicting data.

Implications:

• Organizations which depend on a capability which does not serve the entire enterprise must change over to the replacemententerprise-wide capability. This will require establishment of and adherence to a policy requiring this.
• Organizations will not be allowed to develop capabilities for their own use which are similar/duplicative of enterprise-widecapabilities. In this way, expenditures of scarce resources to develop essentially the same capability in marginally different wayswill be reduced.
• Data and information used to support enterprise decision-making will be standardized to a much greater extent than previously.This is because the smaller, organizational capabilities which produced different data (which was not shared among otherorganizations) will be replaced by enterprise-wide capabilities. The impetus for adding to the set of enterprise-wide capabilitiesmay well come from an organization making a convincing case for the value of the data/information previously produced by itsorganizational capability, but the resulting capability will become part of the enterprise-wide system, and the data it produceswill be shared across the enterprise.

Principle 6:

Compliance with Law

Statement:

Enterprise information management processes comply with all relevant laws, policies, and regulations.

Rationale:

Enterprise policy is to abide by laws, policies, and regulations. This will not preclude business process improvements thatlead to changes in policies and regulations.

Implications:

• The enterprise must be mindful to comply with laws, regulations, and external policies regarding the collection, retention, andmanagement of data.
• Education and access to the rules. Efficiency, need, and common sense are not the only drivers. Changes in the law and changesin regulations may drive changes in our processes or applications.

Principle 7:

IT Responsibility

Statement:

The IT organization is responsible for owning and implementing IT processes and infrastructure that enable solutions to meetuser-defined requirements for functionality, service levels, cost, and delivery timing.

Rationale:

Effectively align expectations with capabilities and costs so that all projects are cost-effective. Efficient and effectivesolutions have reasonable costs and clear benefits.

Implications:

• A process must be created to prioritize projects.
• The IT function must define processes to manage business unit expectations.
• Data, application, and technology models must be created to enable integrated quality solutions and to maximize results.

Principle 8:

Protection of Intellectual Property

Statement:

The enterprise's Intellectual Property (IP) must be protected. This protection must be reflected in the IT architecture,implementation, and governance processes.

Rationale:

A major part of an enterprise's IP is hosted in the IT domain.

Implications:

• While protection of IP assets is everybody's business, much of the actual protection is implemented in the IT domain. Eventrust in non-IT processes can be managed by IT processes (email, mandatory notes, etc.).
• A security policy, governing human and IT actors, will be required that can substantially improve protection of IP. This mustbe capable of both avoiding compromises and reducing liabilities.
• Resources on such policies can be found at the SANS Institute (www.sans.org/newlook/home.php).

Data Principles

Principle 9:

Data is an Asset

Statement:

Data is an asset that has value to the enterprise and is managed accordingly.

Rationale:

Data is a valuable corporate resource; it has real, measurable value. In simple terms, the purpose of data is to aiddecision-making. Accurate, timely data is critical to accurate, timely decisions. Most corporate assets are carefully managed, anddata is no exception. Data is the foundation of our decision-making, so we must also carefully manage data to ensure that we knowwhere it is, can rely upon its accuracy, and can obtain it when and where we need it.

Implications:

• This is one of three closely-related principles regarding data: data is an asset; data is shared; and data is easilyaccessible. The implication is that there is an education task to ensure that all organizations within the enterprise understandthe relationship between value of data, sharing of data, and accessibility to data.
• Stewards must have the authority and means to manage the data for which they are accountable.
• We must make the cultural transition from "data ownership" thinking to "data stewardship" thinking.
• The role of data steward is critical because obsolete, incorrect, or inconsistent data could be passed to enterprise personneland adversely affect decisions across the enterprise.
• Part of the role of data steward, who manages the data, is to ensure data quality. Procedures must be developed and used toprevent and correct errors in the information and to improve those processes that produce flawed information. Data quality willneed to be measured and steps taken to improve data quality - it is probable that policy and procedures will need to be developedfor this as well.
• A forum with comprehensive enterprise-wide representation should decide on process changes suggested by the steward.
• Since data is an asset of value to the entire enterprise, data stewards accountable for properly managing the data must beassigned at the enterprise level.

Principle 10:

Data is Shared

Statement:

Users have access to the data necessary to perform their duties; therefore, data is shared across enterprise functions andorganizations.

Rationale:

Timely access to accurate data is essential to improving the quality and efficiency of enterprise decision-making. It is lesscostly to maintain timely, accurate data in a single application, and then share it, than it is to maintain duplicative data inmultiple applications. The enterprise holds a wealth of data, but it is stored in hundreds of incompatible stovepipe databases. Thespeed of data collection, creation, transfer, and assimilation is driven by the ability of the organization to efficiently sharethese islands of data across the organization.

Shared data will result in improved decisions since we will rely on fewer (ultimately one virtual) sources of more accurate andtimely managed data for all of our decision-making. Electronically shared data will result in increased efficiency when existingdata entities can be used, without re-keying, to create new entities.

Implications:

• This is one of three closely-related principles regarding data: data is an asset; data is shared; and data is easilyaccessible. The implication is that there is an education task to ensure that all organizations within the enterprise understandthe relationship between value of data, sharing of data, and accessibility to data.
• To enable data sharing we must develop and abide by a common set of policies, procedures, and standards governing datamanagement and access for both the short and the long term.
• For the short term, to preserve our significant investment in legacy systems, we must invest in software capable of migratinglegacy system data into a shared data environment.
• We will also need to develop standard data models, data elements, and other metadata that defines this shared environment anddevelop a repository system for storing this metadata to make it accessible.
• For the long term, as legacy systems are replaced, we must adopt and enforce common data access policies and guidelines for newapplication developers to ensure that data in new applications remains available to the shared environment and that data in theshared environment can continue to be used by the new applications.
• For both the short term and the long term we must adopt common methods and tools for creating, maintaining, and accessing thedata shared across the enterprise.
• Data sharing will require a significant cultural change.
• This principle of data sharing will continually "bump up against" the principle of data security. Under no circ*mstances willthe data sharing principle cause confidential data to be compromised.
• Data made available for sharing will have to be relied upon by all users to execute their respective tasks. This will ensurethat only the most accurate and timely data is relied upon for decision-making. Shared data will become the enterprise-wide"virtual single source" of data.

Principle 11:

Data is Accessible

Statement:

Data is accessible for users to perform their functions.

Rationale:

Wide access to data leads to efficiency and effectiveness in decision-making, and affords timely response to informationrequests and service delivery. Using information must be considered from an enterprise perspective to allow access by a widevariety of users. Staff time is saved and consistency of data is improved.

Implications:

• This is one of three closely-related principles regarding data: data is an asset; data is shared; and data is easilyaccessible. The implication is that there is an education task to ensure that all organizations within the enterprise understandthe relationship between value of data, sharing of data, and accessibility to data.
• Accessibility involves the ease with which users obtain information.
• The way information is accessed and displayed must be sufficiently adaptable to meet a wide range of enterprise users and theircorresponding methods of access.
• Access to data does not constitute understanding of the data. Personnel should take caution not to misinterpretinformation.
• Access to data does not necessarily grant the user access rights to modify or disclose the data. This will require an educationprocess and a change in the organizational culture, which currently supports a belief in "ownership" of data by functionalunits.

Principle 12:

Data Trustee

Statement:

Each data element has a trustee accountable for data quality.

Rationale:

One of the benefits of an architected environment is the ability to share data (e.g., text, video, sound, etc.) across theenterprise. As the degree of data sharing grows and business units rely upon common information, it becomes essential that only thedata trustee makes decisions about the content of data. Since data can lose its integrity when it is entered multiple times, thedata trustee will have sole responsibility for data entry which eliminates redundant human effort and data storage resources.

Note:

A trustee is different than a steward - a trustee is responsible for accuracy and currency of the data, while responsibilitiesof a steward may be broader and include data standardization and definition tasks.

Implications:

• Real trusteeship dissolves the data "ownership" issues and allows the data to be available to meet all users' needs. Thisimplies that a cultural change from data "ownership" to data "trusteeship" may be required.
• The data trustee will be responsible for meeting quality requirements levied upon the data for which the trustee isaccountable.
• It is essential that the trustee has the ability to provide user confidence in the data based upon attributes such as "datasource".
• It is essential to identify the true source of the data in order that the data authority can be assigned this trusteeresponsibility. This does not mean that classified sources will be revealed nor does it mean the source will be the trustee.
• Information should be captured electronically once and immediately validated as close to the source as possible. Qualitycontrol measures must be implemented to ensure the integrity of the data.
• As a result of sharing data across the enterprise, the trustee is accountable and responsible for the accuracy and currency oftheir designated data element(s) and, subsequently, must then recognize the importance of this trusteeship responsibility.

Principle 13:

Common Vocabulary and Data Definitions

Statement:

Data is defined consistently throughout the enterprise, and the definitions are understandable and available to all users.

Rationale:

The data that will be used in the development of applications must have a common definition throughout the Headquarters toenable sharing of data. A common vocabulary will facilitate communications and enable dialogue to be effective. In addition, it isrequired to interface systems and exchange data.

Implications:

• We are lulled into thinking that this issue is adequately addressed because there are people with "data administration" jobtitles and forums with charters implying responsibility. Significant additional energy and resources must be committed to thistask. It is key to the success of efforts to improve the information environment. This is separate from but related to the issue ofdata element definition, which is addressed by a broad community - this is more like a common vocabulary and definition.
• The enterprise must establish the initial common vocabulary for the business. The definitions will be used uniformly throughoutthe enterprise.
• Whenever a new data definition is required, the definition effort will be co-ordinated and reconciled with the corporate"glossary" of data descriptions. The enterprise data administrator will provide this co-ordination.
• Ambiguities resulting from multiple parochial definitions of data must give way to accepted enterprise-wide definitions andunderstanding.
• Multiple data standardization initiatives need to be co-ordinated.
• Functional data administration responsibilities must be assigned.

Principle 14:

Data Security

Statement:

Data is protected from unauthorized use and disclosure. In addition to the traditional aspects of national securityclassification, this includes, but is not limited to, protection of pre-decisional, sensitive, source selection-sensitive, andproprietary information.

Rationale:

Open sharing of information and the release of information via relevant legislation must be balanced against the need torestrict the availability of classified, proprietary, and sensitive information.

Existing laws and regulations require the safeguarding of national security and the privacy of data, while permitting free andopen access. Pre-decisional (work-in-progress, not yet authorized for release) information must be protected to avoid unwarrantedspeculation, misinterpretation, and inappropriate use.

Implications:

• Aggregation of data, both classified and not, will create a large target requiring review and de-classification procedures tomaintain appropriate control. Data owners and/or functional users must determine whether the aggregation results in an increasedclassification level. We will need appropriate policy and procedures to handle this review and de-classification. Access toinformation based on a need-to-know policy will force regular reviews of the body of information.
• The current practice of having separate systems to contain different classifications needs to be rethought. Is there a softwaresolution to separating classified and unclassified data? The current hardware solution is unwieldy, inefficient, and costly. It ismore expensive to manage unclassified data on a classified system. Currently, the only way to combine the two is to place theunclassified data on the classified system, where it must remain.
• In order to adequately provide access to open information while maintaining secure information, security needs must beidentified and developed at the data level, not the application level.
• Data security safeguards can be put in place to restrict access to "view only", or "never see". Sensitivity labeling foraccess to pre-decisional, decisional, classified, sensitive, or proprietary information must be determined.
• Security must be designed into data elements from the beginning; it cannot be added later. Systems, data, and technologies mustbe protected from unauthorized access and manipulation. Headquarters information must be safeguarded against inadvertent orunauthorized alteration, sabotage, disaster, or disclosure.
• Need new policies on managing duration of protection for pre-decisional information and other works-in-progress, inconsideration of content freshness.

Application Principles

Principle 15:

Technology Independence

Statement:

Applications are independent of specific technology choices and therefore can operate on a variety of technologyplatforms.

Rationale:

Independence of applications from the underlying technology allows applications to be developed, upgraded, and operated in themost cost-effective and timely way. Otherwise technology, which is subject to continual obsolescence and vendor dependence, becomesthe driver rather than the user requirements themselves.

Realizing that every decision made with respect to IT makes us dependent on that technology, the intent of this principle is toensure that Application Software is not dependent on specific hardware and operating systems software.

Implications:

• This principle will require standards which support portability.
• For Commercial Off-The-Shelf (COTS) and Government Off-The-Shelf (GOTS) applications, there may be limited current choices, asmany of these applications are technology and platform-dependent.
• Application Program Interfaces (APIs) will need to be developed to enable legacy applications to interoperate with applicationsand operating environments developed under the enterprise architecture.
• Middleware should be used to decouple applications from specific software solutions.
• As an example, this principle could lead to use of Java, and future Java-like protocols, which give a high degree of priorityto platform-independence.

Principle 16:

Ease-of-Use

Statement:

Applications are easy to use. The underlying technology is transparent to users, so they can concentrate on tasks at hand.

Rationale:

The more a user has to understand the underlying technology, the less productive that user is. Ease-of-use is a positiveincentive for use of applications. It encourages users to work within the integrated information environment instead of developingisolated systems to accomplish the task outside of the enterprise's integrated information environment. Most of the knowledgerequired to operate one system will be similar to others. Training is kept to a minimum, and the risk of using a system improperlyis low.

Using an application should be as intuitive as driving a different car.

Implications:

• Applications will be required to have a common "look and feel" and support ergonomic requirements. Hence, the common look andfeel standard must be designed and usability test criteria must be developed.
• Guidelines for user interfaces should not be constrained by narrow assumptions about user location, language, systems training,or physical capability. Factors such as linguistics, customer physical infirmities (visual acuity, ability to use keyboard/mouse),and proficiency in the use of technology have broad ramifications in determining the ease-of-use of an application.

Technology Principles

Principle 17:

Requirements-Based Change

Statement:

Only in response to business needs are changes to applications and technology made.

Rationale:

This principle will foster an atmosphere where the information environment changes in response to the needs of the business,rather than having the business change in response to IT changes. This is to ensure that the purpose of the information support -the transaction of business - is the basis for any proposed change. Unintended effects on business due to IT changes will beminimized. A change in technology may provide an opportunity to improve the business process and, hence, change businessneeds.

Implications:

• Changes in implementation will follow full examination of the proposed changes using the enterprise architecture.
• We don't fund a technical improvement or system development unless a documented business need exists.
• Change management processes conforming to this principle will be developed and implemented.
• This principle may bump up against the responsive change principle. We must ensure the requirements documentation process doesnot hinder responsive change to meet legitimate business needs. The purpose of this principle is to keep us focused on business,not technology needs - responsive change is also a business need.

Principle 18:

Responsive Change Management

Statement:

Changes to the enterprise information environment are implemented in a timely manner.

Rationale:

If people are to be expected to work within the enterprise information environment, that information environment must beresponsive to their needs.

Implications:

• We have to develop processes for managing and implementing change that do not create delays.
• A user who feels a need for change will need to connect with a "business expert" to facilitate explanation and implementationof that need.
• If we are going to make changes, we must keep the architectures updated.
• Adopting this principle might require additional resources.
• This will conflict with other principles (e.g., maximum enterprise-wide benefit, enterprise-wide applications, etc.).

Principle 19:

Control Technical Diversity

Statement:

Technological diversity is controlled to minimize the non-trivial cost of maintaining expertise in and connectivity betweenmultiple processing environments.

Rationale:

There is a real, non-trivial cost of infrastructure required to support alternative technologies for processing environments.There are further infrastructure costs incurred to keep multiple processor constructs interconnected and maintained.

Limiting the number of supported components will simplify maintainability and reduce costs.

The business advantages of minimum technical diversity include: standard packaging of components; predictable implementationimpact; predictable valuations and returns; redefined testing; utility status; and increased flexibility to accommodatetechnological advancements. Common technology across the enterprise brings the benefits of economies of scale to the enterprise.Technical administration and support costs are better controlled when limited resources can focus on this shared set oftechnology.

Implications:

• Policies, standards, and procedures that govern acquisition of technology must be tied directly to this principle.
• Technology choices will be constrained by the choices available within the technology blueprint. Procedures for augmenting theacceptable technology set to meet evolving requirements will have to be developed and emplaced.
• We are not freezing our technology baseline. We welcome technology advances and will change the technology blueprint whencompatibility with the current infrastructure, improvement in operational efficiency, or a required capability has beendemonstrated.

Principle 20:

Interoperability

Statement:

Software and hardware should conform to defined standards that promote interoperability for data, applications, andtechnology.

Rationale:

Standards help ensure consistency, thus improving the ability to manage systems and improve user satisfaction, and protectexisting IT investments, thus maximizing return on investment and reducing costs. Standards for interoperability additionally helpensure support from multiple vendors for their products, and facilitate supply chain integration.

Implications:

• Interoperability standards and industry standards will be followed unless there is a compelling business reason to implement anon-standard solution.
• A process for setting standards, reviewing and revising them periodically, and granting exceptions must be established.
• The existing IT platforms must be identified and documented.

The TOGAF document set is designed for use with frames. To navigate around the document:

• In the main Contents frame at the top of the page, click the relevant hyperlink (Part I, Part II, etc.) to load the ContentsList for that Part of the TOGAF document into the Secondary Index frame in the left margin.
• Then click in that Contents List to load a page into this main frame.

return to top of page

Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to anyorganization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture foruse within that organization). A hardcopy book is also available from The Open Group Bookstore as document G063.