Architectural Principles

Introduction    Characteristics     Components     Developing Principles    Applying Principles     Example Set of Architectural Principles   

This section builds on work done by the U.S. Air Force in establishing its "Headquarters Air Force Principles for Information Management", 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 in which 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 the organization, from values through to actions and results.

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

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

The remainder of this subsection deals exclusively with architectural principles.

Characteristics of Architectural Principles

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

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

Components of Architectural Principles

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

A recommended template is given below.

Name Should both represent the essence of the rule as well as be easy to remember. Specific technology platforms should not be mentioned in the name or statement of a principle. Avoid ambiguous words in the Name and in the Statement such as: "support," "open," "consider," and for lack of good measure the word "avoid," itself, be careful with "manage(ment)", and look for unnecessary adjectives and adverbs (fluff).
Statement Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organization to the next. It is vital that the principles statement be unambiguous.
Rationale Should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations. Also describe the relationship to other principles, and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision.
Implications Should highlight the requirements, both for the business and IT, for carrying out the principle - in terms of resources, costs and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to "How does this affect me?" It is important not to oversimplify, trivialize, or judge the merit of the impact. Some of the implications will be identiifed as potential impacts only, and may be speculative rather than fully analyzed.

Table 1: Recommended Format for Defining Principles

An Example Set of Architectural Principles following this template is given below.

Developing Architectural Principles

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

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

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

Qualities of Principles

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

A good set of principles will fulfill the intended purpose of providing a firm foundation for making architecture and planning decisions, framing policies, procedures, and standards, and supporting resolution of contradictory situations. A poor set of principles will quickly become disused, and the resultant architectures, policies, and standards will appear arbitrary or self-serving, and thus lack credibility.

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

Applying Architectural Principles

Architecture principles are used to capture the fundamental truths about how the enterprise will use and deploy information technology resources and assets. 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 product architectures 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 defined architectures. 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 basis for justifying architecture activities.
  6. The Implications statements (see below) provide an outline of the key tasks, resources and potential costs to the enterprise of following the principle. They also provide valuable inputs to future transition initiative and planning activities.

Principles are interrelated, and need to be applied as a set.

Principles will sometimes compete: for example, the principles of "accessibility" and "security" tend towards conflicting decisions. 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 rationale for 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-evident does not mean that the principle is actually observed in an organization, even when there are verbal acknowledgments of the principle.

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

Example Set of Architectural Principles

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

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

Another example of architectural principles is contained in the U.S. government's Federal Enterprise Architecture Framework.

 

Business Principles

1. Principle: 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 organizations abide by the principles.

Implications:

2. Principle: 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 value than decisions made from any particular organizational perspective. Maximum return on investment requires information management decisions 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:

3. Principle: Information Management is Everybody's Business

Statement:  All organizations in the Enterprise participate in information management decisions needed to accomplish business objectives.

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

Implications:

4. Principle: 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 of such systems throughout their design and use. Business premises throughout the Enterprise must be provided the capability to continue their business functions regardless of external events. Hardware failure, natural disasters, and data corruption should not be allowed to disrupt or stop Enterprise activities. The Enterprise business functions must be capable of operating on alternative information delivery mechanisms.

Implications:

5. Principle: Common Use Applications

Statement: Development of applications used across the Enterprise is preferred over the development of similar or duplicative applications which are only provided to a particular organization.

Rationale: Duplicative capability is expensive and proliferates conflicting data.

Implications:

6. Principle: 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 that lead to changes in policies and regulations.

Implications:

7. Principle: IT Responsibility

Statement: The IT organization is responsible for owning and implementing IT processes and infrastructure that enable solutions to meet user 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 effective solutions have reasonable costs and clear benefits.

Implications:

 

Data Principles

8. Principle: 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 aid decision making. Accurate, timely data is critical to accurate, timely decisions. Most corporate assets are carefully managed, and data is no exception. Data is the foundation of our decision making, so we must also carefully manage data to assure that we know where it is, can rely upon its accuracy, and can obtain it when and where we need it.

Implications:

9. Principle: Data is Shared

Statement: Users have access to the data necessary to perform their duties; therefore, data is shared across Enterprise functions and organizations.

Rationale: Timely access to accurate data is essential to improving the quality and efficiency of Enterprise decision making. It is less costly to maintain timely, accurate data in a single application, and then share it, than it is to maintain duplicative data in multiple applications. The Enterprise holds a wealth of data, but it is stored in hundreds of incompatible stovepipe databases. The speed of data collection, creation, transfer, and assimilation is driven by the ability of the organization to efficiently share these 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 and timely managed data for all of our decision making. Electronically shared data will result in increased efficiency when existing data entities can be used, without re-keying, to create new entities.

Implications:

10. Principle: 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 information requests and service delivery. Using information must be considered from an Enterprise perspective to allow access by a wide variety of users. Staff time is saved and consistency of data are improved.

Implications:

11. Principle: 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 the Enterprise. As the degree of data sharing grows and business units rely upon common information, it becomes essential that only the data trustee make decisions about the content of data. Since data can lose its integrity when it is entered multiple times, the data trustee will have sole responsibility for data entry which eliminates redundant human effort and data storage resources. (Note that a trustee is different than steward - trustee is responsible for accuracy and currency of the data while responsibilities of a steward may be broader and include data standardization and definition tasks.)

Implications:

12. Principle: 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 to enable sharing of data. A common vocabulary will facilitate communications and enable dialogue to be effective. In addition, it is required to interface systems and exchange data.

Implications:

13. Principle: Data Security

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

Rationale: Open sharing of information and the release of information via relevant legislation must be balanced against the need to restrict 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 and open access. Pre-decisional (work-in-progress, not yet authorized for release) information must be protected to avoid unwarranted speculation, misinterpretation, and inappropriate use.

Implications:

 

Application Principles

14. Principle: Technology Independence

Statement: Applications are independent of specific technology choices and therefore can operate on a variety of technology platforms.

Rationale: Independence of applications from the underlying technology allows applications to be developed, upgraded, and operated in the most cost-effective and timely way. Otherwise technology, which is subject to continual obsolescence and vendor dependence, becomes the driver rather than the user requirements themselves.
Realizing that every decision made respect to information technology makes us dependent on that technology, the intent of this principle is to ensure that applications software is not dependent on specific hardware and operating systems software.

Implications:

15. Principle: 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 positive incentive for use of applications. It encourages users to work within the integrated information environment instead of developing isolated systems to accomplish the task outside of the Enterprise's integrated information environment. Most of the knowledge required to operate one system will be similar to others. Training is kept to a minimum, and the risk of using a system improperly is low.

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

Implications:

 

Technical Principles

16. Principle: 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 information technology 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 information technology changes will be minimized. A change in technology may provide an opportunity to improve the business process and hence, change business needs.

Implications:

17. Principle: 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 be responsive to their needs.

Implications:

18. Principle: Control Technical Diversity

Statement: Technological diversity is controlled to minimize the non-trivial cost of maintaining expertise in and connectivity between multiple 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 implementation impact; predictable valuations and returns; redefined testing; utility status; and increased flexibility to accommodate technological 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 of technology.

Implications:

19. Principle: Interoperability

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

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

Implications:

Copyright © The Open Group, 2001