This chapter describes principles for use in the development of an Enterprise Architecture.
20.1 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 within different domains and at different levels. Two key domains
inform the development and utilization of architecture:
Enterprise Principles provide a basis for decision-making throughout an enterprise, and inform how the organization sets
about fulfilling its mission
Such principles are commonly found as a means of harmonizing decision-making across an organization. In particular, they are a
key element in a successful Architecture Governance strategy (see 44. Architecture
Governance).
Within the broad domain of enterprise principles, it is common to have subsidiary principles within a business or organizational
unit. Examples include IT, HR, domestic operations, or overseas operations. These principles provide a basis for decision-making
within the subsidiary domain and will inform architecture development within the domain. Care must be taken to ensure that the
principles used to inform architecture development align to the organizational context of the Architecture Capability.
Architecture Principles are a set of principles that relate to architecture work
They reflect a level of consensus across the enterprise, and embody the spirit and thinking of existing enterprise principles.
Architecture Principles govern the architecture process, affecting the development, maintenance, and use of the Enterprise
Architecture.
It is common to have sets of principles form a hierarchy, in that segment principles will be informed by, and elaborate on, the
principles at the enterprise level. Architecture Principles will be informed and constrained by enterprise principles.
Architecture Principles may restate other enterprise guidance in terms and form that effectively guide architecture
development.
The remainder of this section deals exclusively with Architecture Principles.
20.2 Characteristics of Architecture Principles
Architecture 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 Architecture Principle should be clearly related back to the business objectives and key architecture drivers.
20.3 Components of Architecture 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.
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 is
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 identified as potential impacts only, and may be
speculative rather than fully analyzed.
Table 20-1: Recommended Format for Defining Principles
Architecture Principles are typically developed by the Enterprise Architects, in conjunction with the key
stakeholders, and are approved by the Architecture Board.
Architecture Principles will be informed by principles at the enterprise level, if they exist.
Architecture Principles must be clearly traceable and clearly articulated to guide decision-making. They are chosen
so as to ensure alignment of the architecture and implementation of the Target Architecture with business strategies and
visions.
Specifically, the development of Architecture 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, and threats - and its current enterprise-wide initiatives (such as process improvement and quality management)
Current systems and technology: the set of information resources deployed within the enterprise, including
systems documentation, equipment inventories, network configuration diagrams, policies, and procedures
Emerging industry trends: predictions about economic, political, technical, and market factors that
influence the enterprise environment
20.4.1 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 be founded in the beliefs and values of the organization and expressed in language
that the business understands and uses. Principles should be few in number, future-oriented, and endorsed and championed by senior
management. They provide 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. 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 standards to 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
the organization is defined - the principles cover every situation perceived
Consistent: strict adherence to one principle may require a loose interpretation of another principle
The set of principles must be expressed in a way that allows a balance of interpretations. Principles should not be
contradictory to the point where adhering to one principle would violate the spirit of another. Every word in a principle statement
should be carefully chosen to allow consistent yet flexible interpretation.
Stable: principles should be enduring, yet able to accommodate changes
An amendment process should be established for adding, removing, or altering principles after they are ratified
initially.
20.5 Applying Architecture Principles
Architecture Principles are used to capture the fundamental truths about how the enterprise will use and deploy IT
resources and assets. The principles are used in a number of different ways:
To provide a framework within which the enterprise can start to make conscious decisions about Enterprise
Architecture and projects that implement the target Enterprise Architecture
As a guide to establishing relevant evaluation criteria, thus exerting strong influence on the selection of
products, solutions, or solution architectures in the later stages of managing compliance to the Enterprise Architecture
As drivers for defining the functional requirements of the architecture
As an input to assessing both existing implementations and the 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
The Rationale statements within an Architecture Principle highlight the business value of implementations
consistent with the principle and provide guidance for difficult decisions with conflicting drivers or objectives
The Implications statements within an Architecture Principle 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
Support the Architecture Governance activities in terms of:
Providing a "back-stop" for the standard Architecture Compliance assessments where some interpretation is allowed
or required
Supporting the decision to initiate a dispensation request where the implications of a particular architecture
amendment cannot be 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
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 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 obvious and does not need to be documented". The fact
that a principle seems self-evident does not mean that the guidance in a principle is followed. Having principles that appear
obvious helps ensure that decisions actually follow the desired outcome.
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 fulfil its mission.
20.6 Example Set of Architecture 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 Architecture Principles, and the recommended
format for defining them, as explained above.
20.6.1 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 organizations
abide 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 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:
Achieving maximum enterprise-wide benefit will require changes in the way we plan and manage information -
technology alone will not 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 should pursue information management initiatives which conform to the blueprints and
priorities established by the enterprise. The plan will be changed as needed.
As needs arise, priorities must be adjusted; a forum with comprehensive enterprise representation should make
these decisions
Principle 3: 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 IT.
Implications:
To operate as a team, every stakeholder, or customer, will need to accept responsibility for developing the
information environment
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 of
such systems throughout their design and use. Business premises throughout the enterprise must be provided with 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:
Dependency on shared system applications mandates that the risks of business interruption must be established in
advance and managed
Management includes but is not limited to periodic reviews, testing for vulnerability and exposure, or designing
mission-critical services to ensure 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 of continuity 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 applications
which 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
replacement enterprise-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-wide capabilities; in this way, expenditures of scarce resources to develop essentially the same capability in
marginally different ways will 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
other organizations) will be replaced by enterprise-wide capabilities. The impetus for adding to the set of enterprise-wide
capabilities may well come from an organization making a convincing case for the value of the data/information previously produced
by its organizational capability, but the resulting capability will become part of the enterprise-wide system, and the data it
produces will be shared across the enterprise.
Principle 6: Service Orientation
Statement:
The architecture is based on a design of services which mirror real-world business activities comprising the enterprise (or
inter-enterprise) business processes.
Rationale:
Service orientation delivers enterprise agility and Boundaryless Information Flow.
Implications:
Service representation utilizes business descriptions to provide context (i.e., business process, goal, rule,
policy, service interface, and service component) and implements services using service orchestration
Service orientation places unique requirements on the infrastructure, and implementations should use open
standards to realize interoperability and location transparency
Implementations are environment-specific; they are constrained or enabled by context and must be described within
that context
Strong governance of service representation and implementation is required
A "Litmus Test", which determines a "good service", is required
Principle 7: 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:
The enterprise must be mindful to comply with laws, regulations, and external policies regarding the collection,
retention, and management of data
Education and access to the rules
Efficiency, need, and common sense are not the only drivers. Changes in the law and changes in regulations may
drive changes in our processes or applications.
Principle 8: 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:
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 9: 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 - even trust 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 must be capable of both avoiding compromises and reducing liabilities
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 ensure that we know
where 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
easily accessible
The implication is that there is an education task to ensure that all organizations within the enterprise
understand the 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 personnel and 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 to prevent and correct errors in the information and to improve those
processes that produce flawed information. Data quality will need to be measured and steps taken to improve data quality - it is
probable that policy and procedures will need to be developed for 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 be assigned at the enterprise level
Principle 11: 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:
This is one of three closely-related principles regarding data: data is an asset; data is shared; and data is
easily accessible
The implication is that there is an education task to ensure that all organizations within the enterprise
understand the 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
data management 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 migrating legacy 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 and develop 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 new application developers to ensure that data in new applications remains available to the shared environment and
that data in the shared 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 the data 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
circumstances will the 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 ensure that 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 12: 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 a 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 is improved.
Implications:
This is one of three closely-related principles regarding data: data is an asset; data is shared; and data is
easily accessible
The implication is that there is an education task to ensure that all organizations within the enterprise
understand the 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 their corresponding methods of access
Access to data does not constitute understanding of the data - personnel should take caution not to misinterpret
information
Access to data does not necessarily grant the user access rights to modify or disclose the data
This will require an education process and a change in the organizational culture, which currently supports a
belief in "ownership" of data by functional units.
Principle 13: 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 makes 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:
A trustee is different than a steward - a 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:
Real trusteeship dissolves the data "ownership" issues and allows the data to be available to meet all users'
needs
This implies 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
is accountable
It is essential that the trustee has the ability to provide user confidence in the data based upon attributes such
as "data source"
It is essential to identify the true source of the data in order that the data authority can be assigned this
trustee responsibility
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
Quality control 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 of their designated data element(s) and, subsequently, must then recognize the importance of this trusteeship
responsibility
Principle 14: 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 dialog to be effective. In addition, it is
required 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" job titles and forums with charters implying responsibility
Significant additional energy and resources must be committed to this task. It is key to the success of efforts to
improve the information environment. This is separate from but related to the issue of data 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 throughout the 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 and understanding
Multiple data standardization initiatives need to be co-ordinated
Functional data administration responsibilities must be assigned
Principle 15: 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:
Aggregation of data, both classified and not, will create a large target requiring review and de-classification
procedures to maintain appropriate control
Data owners and/or functional users must determine whether the aggregation results in an increased classification
level. Appropriate policy and procedures will be needed to handle this review and de-classification. Access to information 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 software solution to separating classified and unclassified data? The current hardware solution is
unwieldy, inefficient, and costly. It is more expensive to manage unclassified data on a classified system. Currently, the only way
to combine the two is to place the unclassified 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 be identified 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 for access 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 must be protected from unauthorized access and manipulation. Headquarters
information must be safeguarded against inadvertent or unauthorized alteration, sabotage, disaster, or disclosure.
New policies are needed on managing duration of protection for pre-decisional information and other
works-in-progress, in consideration of content freshness
20.6.3 Application Principles
Principle 16: 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 with respect to IT makes us dependent on that technology, the intent of this
principle is to ensure 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, as many of these applications are technology and platform-dependent
Subsystem interfaces will need to be developed to enable legacy applications to interoperate with applications and
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 priority to platform-independence
Principle 17: 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:
Applications will be required to have a common "look-and-feel" and support ergonomic requirements; hence, the
common look-and-feel 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.
20.6.4 Technology Principles
Principle 18: 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 be minimized.
A change in technology may provide an opportunity to improve the business process and, hence, change business
needs.
Implications:
Changes in implementation will follow full examination of the proposed changes using the Enterprise
Architecture
There is no funding for 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 does not hinder responsive change to meet legitimate business
needs. The purpose of this principle is to keep the focus on business, not technology needs - responsive change is also a business
need.
Principle 19: 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:
Processes for managing and implementing change must be developed 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
implementation of that need
If changes are going to be made, the architectures must be kept 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 20: 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:
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 the acceptable technology set to meet evolving requirements will have to be developed and
put in place.
The technology baseline is not being frozen
Technology advances are welcomed and will change the technology blueprint when compatibility with the current
infrastructure, improvement in operational efficiency, or a required capability has been demonstrated.
Principle 21: 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:
Interoperability standards and industry standards will be followed unless there is a compelling business reason to
implement a non-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
return to top of page