Architectural Principles

Architectural, or engineering, principles are the cornerstone of the enterprise architecture. IT cannot effectively design an architecture without such guiding principles, nor can it enforce an architecture that is out of congruence with those principles. The principles do not have to be verbose, but they need to be documented to ensure they are considered with every design decision. This document must be owned by the IT management; accordingly, they should not absentmindedly delegate the drafting of these principles to architects/engineers or technical writers.

These principles are arguably the most critical section of the Enterprise Architecture. Theoretically, if these principles are sound and comprehensive, any architecture spawned from that foundation should be successful. Conversely, if IT management does not thoughtfully consider the technology architecture and its alignment with the business goals, the more likely they are to end up with an “accidental architecture”.

Below are some typical principles or concepts that such principles might address.

  • The Iron Triangle: Although technically not an architectural element, the iron triangle of scope, time and cost is an obvious yet often forgot truism that is worthy of remembrance on any list of architectural principles. No matter what an organization’s design strategies are, the Iron Triangle is implicitly a factor. Whether consciously considered or not, design decisions are made in the context of trade-offs between time to build, scope/quality and cost. Generally, only two of these three elements may be satisfied.
  • Enterprise Focus: IT exists solely to support the needs of the business, and IT should be committed to serving customers at the local level. While any particular IT design should attempt to meet the requirements of its sponsor, project, or user community, IT has a primary responsibility to keep the computing environment reliable and flexible to meet the needs of the *entire* enterprise. It is common tactic for a department head, account manager, or site to accuse IT of not having a customer focus because they will not do this or that. The IT manager must communicate that IT is customer-focused but it is responsible for ALL the customers, not just one department, client, or site.

The enterprise must be the dominant design element, even if the ensuing design fails to meet expectations of any one of IT’s particular customers at any one particular time. The violation of or partial adherence to this principle would then be a business decision rather than a technical one. Getting executive support for this enterprise responsibility and vision is imperative for any architecture to succeed.

Conversely, if the organization has no regulatory requirements and its data is mostly public domain, then this should be stated here, as it will make a large difference on how data repositories will be architected. Obviously, all organizations will have some data with security requirements such as HR and payroll-related information, but if the architecture does not have to accommodate this as a standard, it can offer much more flexibility.

  • Reliability: Reliability is an obvious element to any design and the IT manager must consider a number of questions. What is the architecture’s position on – and strategy with – reliability? Is the entire environment to be considered as having to be highly-available? Does IT serve external customers 7×24 or primarily host internal applications from 8-5? How will the architecture differ if both types of applications are supported? Does IT rely on a small number of vertically-scaled redundant devices or does it embrace failure by spreading the load over a large number of commodity devices?

These are questions the IT manager and the organization must answer honestly. It is one thing to talk about purchasing redundant circuits and hardware, but yet another to actually fork out the cash. There needs to be some soul-searching about service level expectations and what is really acceptable. In actuality, many businesses can live with the risk of a day-long outage as new hardware is rapidly installed to replace failed hardware.

  • Business Continuity: Intertwined with the principle of Reliability, the principle provides guidance on the importance of large scale disaster recovery. As above, there needs to be some soul-searching because DR plans do not come cheap.
  • Recovery: Related to reliability, this element addresses the recovery of resources once they have been damaged or compromised? What is the RTO (recovery time objectives), .e.g., do customers and users expect immediate failover to a new system or data center or can they stomach some down time? What is the RPO (recovery point objectives); e.g., can the organization afford for any data to be lost?
  • Scalability: All organizations generally plan to grow and information technology should be able to scale to meet increased usage in a timely manner without major disruptions. This principle should comment on strategies such as load-balancing, adding connectivity ports, multi-tier application architectures, horizontal and vertical scaling, management economies of scale, etc.
  • Flexibility: Concerns how the element can support a change or an overhaul in the type of function and services it performs.
  • Interoperability: Computing software, hardware and processes should promote the compatibility and usability between systems, applications and data.
  • Manageability: Administering, monitoring and managing IT resources are too often an afterthought and the IT manager is usually expected to just make it happen. The IT manager needs to create a principle reflecting the organization’s commitment to the management and monitoring of resources. Will there be funding for a unified management platform, or will there be point solutions based on the priority of the target systems?
  • Predictability: Closely related to manageability, this is a commentary on all the above items in terms of how accurately we can predict outcomes and how soon. What is the confidence level that IT has in its assessment of security, reliability, scalability,flexibility manageability? How well can it predict successes and failures?
  • SDLC: What is IT’s perspective on the systems development lifecycle? How many development and testing environments will there be? Should every purchase of a production device require purchases of like items for testing and development? How similar should Test be to Production? Will the SDLC environments need to be physically separated?
  • Isolation, Segmentation and Tiering: This concept is an enabler of the principles above – manageability, scalability, and security. Grouping components into discrete segments and tiers allows provides more efficient management and support as you address differing levels of accessibility, security, capacity management and traffic characterization. This principle plays out as modularity in software engineering and as the n-tier model in the data center stack.
  • Centralization and consolidation of Enterprise Services: What applications and services will be centralized, if any? Consider such items as DNS, FTP, mail, line-of-business applications, externally-facing applications, etc… Again there is a trade-off between flexibility and security (one point to secure), to manageability (one point to manage) and to reliability (one point to make redundant).
  • Vendor/Framework Standards: This principle adds a control technical diversity. Standards allow for efficiencies in management, support, and procurement. Will the organization standardize on a vendor, a technology, or framework in the enterprise, or will flexibility be more valued?
  • Other Technical Standards: Architecture principles should address all technical standards that are important to IT and that will likely enforce other principles. These may be termed “engineering” standards. These might include database standards, use of virtualization, naming standards, VLANs, encryption, remote access, etc.

Architectural principles will represent the standards for design in the enterprise. New solutions would then be evaluated according to these principles and additional justification should be required when they violate the standards.

<<–Enterprise Architecture
–>>Architectural Principles
–>>Enterprise Operating Principles