Enterprise Architecture Principles

A Definition

Enterprise Architecture Principles are high level statements of the fundamental values that guide Business Information Management, Information Technology (IT) decision-making and activities, and are the foundation for both business and IT architectures, standards, and policy development.

See The Open Group’s definition here.

Scope and Control

EA Principles are universally applicable to the enterprise and are typically approved by an enterprise architecture committee or review board.. Principles are sufficiently abstract, stable, and up-to-date so as to withstand technology evolving or otherwise changing, but also as to be relevant to support the enterprise business.

Restating, EA Principles are guidelines that reflect an enterprise's priorities, the business processes and other business requirements (Business Architecture), the information, data, and user applications (Information Architecture), and the Technology Architecture, which is the underlying infrastructure necessary to support the use of applications and management of data.

EA Principles are consistent with the EA Framework. (Frameworks will be discussed in a later posting.)

Declarations of EA Principles are Structured

EA Principles are formatted with a title (not required in some environments), a statement, a rationale, and implications. Though the wording for each principle title and statement typically remains constant, rationale and implications can evolve with experience and changes in the enterprise. Updates to rationale and implications can be responses to evolution of the enterprise mission, vision, and strategic plan, or to a variety of external forces.

Taxonomies of EA Principles

For convenience and clarity, EA Principles can be grouped and put into hierarchies. The Open Group, for example, in its framework, TOGAF 9, suggests that EA principles be organized into a descending hierarchy, including Enterprise Principles, IT Principles, and Architecture Principles.

Looking at another that is similar yet different, the National Institute of Health groups their EA Principles as follows:

Enterprise Principles
“Enterprise principles are applicable to all areas of the NIH Enterprise Architecture.”

- and -

Domain Principles
“Domain Principles are generally applicable to a specific area of the NIH Enterprise Architecture Framework, though some principles may be applicable to more than one area.
* Applications Principles
* Collaboration Principles
* Data Principles
* Integration Principles
* Network Principles
* Security Principles
* Systems Management Principles”

Examples of EA Principles

From the National Institute of Health:

Title: “Principal Principle” (sic)

Statement: “The NIH Enterprise Architecture applies to all aspects of NIH information technology (IT).”

Rationale: “In the NIH federated environment, a framework for information technology promotes better results.”

Implications: “This applies to all NIH systems and includes systems, data and infrastructure. EA must be followed by all NIH organizations to strengthen the ability of the NIH IT to provide a consistent and measurable level of quality to customers. An exception process will be in place to accommodate new technology and specific needs. Standards must be flexible enough to be responsive to address business needs. “

The (US federal) Government Audit Organization’s "Practical Guide to Enterprise Architecture" offers this one:

Title = Statement: Architectures facilitate change.

Rationale: In the rapidly changing IT environment, organizations need tools to manage and control their business and technical growth and change. As the technical development life cycle shortens, with new technologies replacing older systems every 18 months, organizations require an overarching architecture to capture their systems design and operating environment.

Implications: The systems developer and the chief architect should ensure the coordination between technology investments and business practices. Architectures must be used in the evaluation function of the Capital Planning and Investment Control process.

I like to think of Enterprise Architecture Principles as "The Constitution" of an organization's information management. These Principles will be amended occasionally, and lots of managerial edicts ("laws") will be passed that will come and go, but the EA Principles are the bedrock of business IM in the organization.

Millar Consultants EA Principles

This list of principles will be evolved here as the associated blog postings are published. We bring the full list to engagements as a starting point for client consideration:

Title: “Support Business Success”

Statement: “All business structures and supporting technical structures will be designed and implemented so as to support the success of the business pursuing its strategy and mission.”

Rationale: “The Enterprise mission and its strategy identify the very purpose for existence of the organization. No other agenda will be allowed equal stance.”

Implications: “In cost/benefit calculations, the business' success may, at times, force otherwise-preferred architectures to be compromised. Based on inputs from "the business", all significant present and likely future benefits to the business should be weighed and included.
Also, the implementation of both short term and long term implementations will be given greater consideration: an initial fast-reaction response to at least partially meet a new business need, followed by the sustaining architectural approach that is more cost effective in the long term.“

Title: “Support Business Agility”

Statement: “All business structures and supporting technical structures will be designed and implemented so as to support the agility of the business.”

Rationale: “Businesses must be able to change how they do business, sometimes, quickly. Architectures that support business' processes must adapt to those changes at a level that optimizes business advantage.”

Implications: “Business process changes that are subject to software update queues months-or-even-years long must be radically diminished. Solutions that offer significant possibilities of reducing updates to weeks must be considered and, as appropriate, pursued.“

Title: “Governance to Sustain Alignment”

Statement: “In order to achieve sustained alignment between business and IT, a governance practice is to be maintained. This practice includes both business and IT personnel, as well as agreed processes, and be sponsored by business operations executives. Alignment is quantified using Key Performance Indicators, with verified accountability and corrective actions. This governance is ongoing, indefinitely.”

Rationale: “To maintain continuous improvement of the business, and address inevitable business change, this governance must be created to oversee and continuously maintain alignment of IT support and information management with business operations.”

Implications: “To establish this alignment support infrastructure, adjustments in perspectives of the both business and IT executives may be required, new roles and accountabilities in both business and IT will have to be established, and migrations to update major IT architectures may have to be planned and executed.“

Title: “Business Processes”

Statement: “Manipulations and tranformations of data in the enterprise that are the enterprise's business processes should be primarily located in the 'business layer' of enterprise architecture with features, such as non-technical business administration, that support agility.”

Rationale: “The logic and other details of business processes, in which data is manipulated and transformed, can be implemented in a number of places in any enterprise architecture, including ETL facilities, Portals, ESBs, servlets, and other places.  This principle declares that in order to support both business agility and enterprise resource reusability, all such logic and other related details will be located in an environment such as a business process management system primarily under the control of the stake-holding business organization(s).  This principle facilitates the rapid change of business processes by putting the greatest amount of authority and dependency for process changes uniquely in the hands of the business silo(s).”

Implications: “The underlying IT infrastructure for this context can be considered a platform onto which there will be an IT focus on standardized integrations, security, performance, availability, extensibility, and other dimensions needed to support optimized usefulness of the BPMS by the business silo(s).“

Millar Consultants Domain Principles - Applications
Application Architecture Principles are subordinate to EA principles and are separated out so as to more easily target the correct enterprise demographic including functional silos such as business analysts and business application developers.  

Title: “Browsers are preferable to 'thick client' user interfaces”

Statement: “Web browsers are considered preferred for hosting client - side application user interfaces.”

Rationale: “Most packaged applications are being released in 2010 with web user interfaces, that is, browser access.  New, proprietary applications should be planned to have a browser-client.  Web technology in 2010 supports rich interfaces which all but equal, and at times surpass, the user experience that was unique to thick clients years ago.  The web interface by default provides the user with a familiar client-side context, and supports maximizing user acceptance while minimizing training and maintenance.”

Implications: “The design of the user interface must conform to web interface best practices.“

Title: “Application Embedded Technical Domain Capabilities”

Statement: “Applications that include bundled technical domains such as search, reporting, and integration tend to provide such functionalities as limited capabilities and should be discouraged.”

Rationale: “Examples:  The search engine available in a CRM package is not as useful to the enterprise as an enterprise search engine.  The integration available in a portal package tends to be proprietary, less useful, and significantly less strategic than corporate standards for integration based on open source.”

Implications: “Enterprises must face up to having a suite of generic resources that sufficiently meet the enterprise requirements for technical domain capabilities.“