Introduction

In our previous post, we outlined the primary benefits of architecture and design, briefly summarized some of the most popular enterprise architecture frameworks, outlined architecture core tenets, described important distinctions between architecture and design, and outlined the natural flow/progression from enterprise architecture to detailed design.

Part I of this series set the table by outlining important architecture and design concepts and benefits; in this post, we will dive into practical details such as defining architecture principles and standards, and methods to define and use an architecture.

Architecture Principles & Standards

In Part I of this series, we mentioned that Ferroque Systems does not often see a complete, relevant enterprise architecture; we have observed that approximately half of our clients have a complete, relevant architecture that outlines their Citrix and/or access tier environment; even fewer have an up-to-date design; almost none have documented architecture principles or standards.

Architecture principles and standards are the backbones of consistent technology decision-making. We have observed that for most IT administrators, principles and standards tend to be lumped together so as to be considered one and the same; however, there is a clear distinction. Principles are technology agnostic and thus apply across all technical domains, and represent the top of the waterfall from which standards are defined. Standards are defined in a manner that upholds the principles and are typically specific to a technology and thus specific to a technology domain (i.e. a set of standards for each technology domain).

Being based in the United States, I like to draw an analogy to the legal artifacts and system that exists in the US. The US Constitution (and its 27 Amendments) is the backbone for all laws and the legal system in the USA. The authority of the Constitution applies to all 50 states in the US, and to all counties, cities, etc. that exist within each individual state. In this fashion, the Constitution sets forth the legal principles for the entire US. Any and all laws that have been and/or will be created must be in accordance with the Constitution (laws that are perceived to conflict with the Constitution are typically challenged and may be overturned). There are federal laws that apply universally across the US, laws that are specific to individual states, and also laws specific to an individual county, city, etc. within each state. In this fashion, the laws of an individual state, county, city, etc. set forth the legal standards to which each of its citizens are expected to abide (lest a person finds themselves in legal trouble). But regardless of their jurisdiction (or “domain”), each of these laws must align with the US Constitution.

Now that the distinction between architecture principles and standards has been clarified, we will provide practical guidance for defining such principles and standards. The first step is to define architectural principles. Naturally, several methods can be used; a method I prefer is what I like to call the “-ilities”, wherein an architect lists his/her Top 10(-ish) environment attributes – such as agility, availability, extensibility, interoperability, manageability, reliability, scalability, stability, usability, visibility, and security – and ascribes a definition to each attribute (to ensure a common understanding). The architect then defines architecture principles for each attribute – for example, one of the “Extensibility” principles may be “The enterprise architecture and all domain architectures will adopt a loosely-coupled design wherein each layer has a defined purpose/function”; one of the “Scalability” principles may be “Implementation of new systems will support capacity for the system’s 2-yr growth plan”; one of the “Visibility” principles may be “All technology solutions in the production environment must be monitored and measured by the corporate monitoring solution”; etc. These examples illustrate that principles should be defined at a level of detail that is sufficiently broad so as to be applicable across all technology domains yet sufficiently specific so as to be measurable (easy to recognize compliance) and actionable.

Taking it a step further, an architect may then prioritize their Top 10 architecture attributes to provide a common understanding of the most (and least) important attributes. One effective method of doing so is to conduct a pairwise comparison of the “-ilities”, wherein each attribute is compared to all other attributes to note relative priority, resulting in an ordered (prioritized) list of attributes. The table below illustrates an example of such a comparison.

The table above illustrates an example of a completed pairwise comparison that results in a prioritized list of architecture principles (the completed graphic is a sample; it is not intended for any level of influence regarding prioritized principles). This example was created via Microsoft Excel; for guidance in creating such a table, row and column indicators (aka labels or headers) have been included in the graphic, and below are the formulae for rows #13 and #14 (“Total Votes” and “Ranking”):

Total Votes (row #13): COUNTIF($C$2:$M$12,C1) *this formula exists in cells C13-M13; only the red letter (column) changes in each cell’s formula, based upon the column.
Ranking (row #14): RANK(C13,$C$13:$M$13,0) *this formula exists in cells C14-M14; only the red letter (column) changes in each cell’s formula, based upon the column.

Defining architecture principles in this fashion provides a framework that can facilitate architecture governance and assist in ongoing technology decision-making. For example, let’s say Acme Rocket Co. has prioritized their architecture principles per the table above and is implementing new application software. In doing so, Acme Rocket Co. would like to enhance security by requiring MFA (multi-factor authentication), but the IT team knows the extra steps required for MFA will frustrate the user community. In this case, the IT team refers to their prioritized principles and notes that “Security” is prioritized above “Usability”, thus the IT team configures MFA. The IT team will follow the same approach in making future such decisions, thus promoting consistent decision-making and alignment with architecture principles. This is an over-simplified example, but it clearly illustrates the concept.

Once architecture principles have been defined, architecture standards can then be defined. Naturally, several methods can be used; since architecture standards are specific to technology domains, technical standards are often categorized by technology domain – such as application delivery, directory services, endpoints, hardware, hypervisor, network, storage, etc. The SMEs for each technology domain will define the technical standards for their respective domain(s); e.g. one of the “Application delivery” standards may be “All external access to components and resources residing on the internal network will be via Citrix Virtual Apps & Desktops”; one of the “Security” standards may be “All remote access solutions must use multi-factor authentication via SAML 2.0”; etc. Together with architecture principles, defining technical standards in this fashion facilitates a practical method of consistent technical decision-making and a reliable method of technical governance.

Practical Usage

In our previous post we looked at an analogy from a long time ago; here, let’s look at a more modern analogy to illustrate practical usage.

This being the holiday season, my wife and I were recently shopping for gifts at a store that had nothing of interest to me, so I found a chair out of the way. While waiting (impatiently, if I’m being honest), I noticed all the Sales associates had tablets and were conducting point-of-sale (mobile) transactions with customers on the floor rather than requiring customers to wait in line to pay at a cash register. While observing, my mind wandered to thinking about how someone had made the decision to implement this new mobile sales/transaction capability and likely challenged the IT team to figure out how to make it happen. In doing so, I’d like to think the IT team referenced their enterprise architecture to determine if it was possible to leverage existing capabilities, identified any gaps for new capabilities, and worked with a BRM (business relationship manager) to understand if any business processes had to be updated. At this initial (conceptual) level, the teams were more focused on capabilities and processes (e.g. capability to meet PCI data requirements for mobile transactions) than on specific technologies and components.

Once capabilities and processes were determined, from an IT perspective, the focus shifted to whether existing technologies could be leveraged or if a new technology(ies) was necessary. The architecture principles and standards were likely referenced during the brainstorming sessions that probably occurred, to help evaluate and prioritize the proposed ideas that were discussed. During this time, several ideas were probably diagrammed on a whiteboard, and these diagrams were likely framed in the context of a logical architecture for an existing IT system(s) and expanded upon to illustrate necessary components and data flow. As well, remember that architecture is about people, process, and technology, so process diagrams were probably also used to illustrate the process workflow amongst the included roles (people). Once a “winning” idea was identified – but before it was finalized – the implementation details of that idea were likely discussed amongst relevant IT teams to verify the proposed solution would align with existing principles and standards and would integrate “cleanly” with existing systems.

Once the logical architecture and workflows were determined, from an IT perspective, the focus shifted to physical components. At this point, pros and cons of specific components were likely discussed – such as the specific type of mobile endpoint (e.g. iPad, Surface, Chromebook, etc.) and options for capturing payment transactions on the endpoint (e.g. Square Card Reader for magstripe or chip, portable credit card reader, etc.) – and evaluated and prioritized based upon overall fitness for purpose and costs.

This overall process was outlined here in a simplified and streamlined fashion to illustrate the concept of how the artifacts of enterprise architecture, principles, and standards are often used in practice. As we can see, such artifacts are instrumental in providing a framework to facilitate multiple teams working together to define the optimal solution for a new business initiative. Yes, these activities could certainly be performed without such artifacts, but as we can see in this example, there are key moments wherein having such artifacts helps accelerate a common understanding and decision-making, and does so in a consistent and repeatable fashion. Said another way, in the modern economy wherein time is always of the essence, such artifacts facilitate quicker and smarter decision-making that accelerates the time to market (TTM) for business initiatives and generates less technical debt.

To Be Continued…

In this post, we outlined the key distinctions between architecture principles and standards, walked through a practical method of defining such principles and standards, and reviewed a practical example of how such artifacts are used in the real world.

The initial blog post set the table for the overall conversation, this post dives into practical details of how to define and use architecture principles and standards, and our final post in the series will review the common pitfalls that we have seen many organizations experience in attempting to define and/or use architecture principles and standards. Please stay tuned; there is much more to come in our next post!

Subscribe