Introduction

In the world of technology consulting and information systems, it is universally known that architecture and design are among the most crucial ingredients of a properly functioning, well-run IT environment. However, we at Ferroque Systems have observed that it is also very common for many (most?) organizations not to have a proper enterprise architecture or one that is incomplete and/or fairly outdated, which contributes to numerous challenges.

This is unfortunate since a well-defined architecture provides crucial benefits, such as:

It facilitates the organization of ideas and a vision into a valid practical solution, and acts as a practical reference for making improvements prior to beginning physical deployment (“measure twice, cut once”).
It provides an overarching reference for the IT environment that guides technology decisions and implementations, to ensure such decisions and actions perpetuate a consistent and like-minded approach across all technology domains.
It is a foundation for defining technical design artifacts for each technology domain; such design artifacts provide additional benefits, such as:
- Detailed guidance for configuring technology components as they will exist in the real world, and ensures multiple components will be configured to orchestrate and integrate functionality into a cohesive solution.
- Justification for why a given technology component is configured in the manner that it is, which can be referenced ongoing to determine if/when a change is warranted based upon new requirements and/or use cases.

Most organizations recognize the need for proper enterprise architecture, but sometimes do not necessarily know how to go about defining one, do so in an incomplete fashion, and/or allow it to fall out of date thus becoming irrelevant.

Given the importance of architecture and design, and based upon our experience and our observations in the field, we at Ferroque Systems felt it would be beneficial to author this blog series that outlines the key concepts of IT architecture, clarifies distinctions between architecture and design, provides practical guidance for developing IT architecture and design artifacts, and highlights common pitfalls to avoid.

Architecture Frameworks/Models

Let’s start by reviewing enterprise architecture frameworks; there are too many to name here, so we will stick to the most well-known. Numerous architecture frameworks exist today, such as TOGAF, Zachman Framework, NIST, SOA. A brief summary of each framework is outlined below (this is not a comprehensive definition, just a brief outline for awareness and context).

TOGAF. The most popular enterprise architecture framework; over time TOGAF has evolved through several maturations and formal training and certification elements have grown up around it. TOGAF organizes enterprise architecture into four architecture pillars (business, data, application, technical), and describes a vocabulary, methods, and tools for defining and (equally important) maintaining enterprise architecture.
Zachman Framework. Its primary intent is to provide structured guidance on how to progress from abstract concepts to real-world implementations, primarily by leveraging a matrix that organizes decisions for core elements (who, what, when, where, etc.) across the spectrum from abstract to physical implementation, wherein tools/artifacts are prescribed to assist with the intersection of each element. Used collectively, these tools and artifacts provide the foundation of enterprise architecture and can be used for guiding ongoing architecture and design decisions.
NIST. More of an enterprise architecture model rather than a framework, NIST describes an enterprise architecture as being comprised of five primary architecture layers (business processes, information flows, applications, data descriptions, technology infrastructure) that are all interrelated. Over time, the NIST model was referenced by several prominent organizations to develop a NIST-based framework (e.g. DOE, FDIC, NWS).
SOA. A service-oriented architecture model wherein all components and processes are integrated to form and deliver numerous services. Many of these services are back-office services (e.g. identity management services) that support end-user services (e.g. submitting an automated request to be provisioned a particular application). The SOA backbone is a service catalog that includes the designation of a service owner who is accountable for all elements of the service (i.e. integration of the people, processes, and technologies that comprise the service).

The key concept here is that each of these frameworks or models promotes a different perspective on enterprise architecture, and there is no one “right” answer. In practice, an Enterprise Architect (EA) often benefits from incorporating the most helpful/useful elements from each framework/model based upon the EA’s particular needs for the organization.

Regarding architecture frameworks, another important point is that many vendors promote a native architecture model to illustrate how the vendor’s components integrate into the overall IT technical landscape. Such native models are typically specific to the vendor and thus often do not align with the “standard” architecture frameworks or models outlined above. For example, Citrix subscribes to an architecture model that organizes into seven layers: Access, Business, Compute, Control, Operations, Resource, and User Layers (Business and Operations Layers are considered as foundational layers that encompass the other five layers). Again, such native models are neither “right” nor “wrong”; rather, they provide an Enterprise Architect (EA) with another method of structuring the architecture based upon the particular needs. We will touch more upon this further in this blog series.

Architecture Core Tenets

As mentioned above, there is no one “right” architecture framework/model; a given organization’s enterprise architecture is based upon the organization’s needs, existing technologies, in-house skillsets, process maturity, risk appetite, and budget. Balancing all of these elements to define a relevant architecture is challenging, but there are core tenets of a well-defined architecture that provide practical guidance:

Solution-focused. In a modern IT landscape, nothing exists in a vacuum, and all components in the landscape must fit together to deliver the required solutions. Thus, a well-defined architecture outlines the scope of a complete solution rather than focusing on individual components. For example, a Citrix-powered solution includes many more technologies than just Citrix components, thus a well-defined Citrix logical architecture includes ancillary technologies (such as the hypervisor, database, endpoints, storage, and Active Directory, just to name a few) to depict the different technologies that must fit together to deliver a Citrix solution.
Technology agnostic. An enterprise architecture purist will typically emphasize that enterprise architecture should make no mention of technologies; i.e. it is technology agnostic. Thus, as a rule of thumb, any architectural definition that is based upon a specific technology is inherently going beyond the scope (definition) of a true enterprise architecture. In practice, this level of architecture rarely comes into play once a basic architecture has been defined; instead, this approach is more relevant for defining a new architecture (vs. maintaining an existing architecture), and can help initiate architecture definitions to enable new business initiatives. During such times, it is very helpful to reference an enterprise architecture that illustrates all of the IT capabilities that are in existence, to determine if a new capability is required to enable new business objectives, or if it is possible to instead leverage an existing capability.
Emphasis on capabilities. Given that enterprise architecture is intended for technical use, the “technology agnostic” rule of thumb may seem very limiting. That is because the intent of this concept is to focus initial energies on the capabilities that must be enabled in order to fulfill requirements and use cases. In this context, a given technology is a proposed solution to a requirement(s), thus the emphasis to instead focus on capabilities. For example, an architecture diagram for a new work-from-home use case may simply illustrate that the capability for multi-factor authentication (MFA) is required, but will not specify if the MFA solution will be RADIUS, Azure AD, DUO, etc. This is intentional and focuses decision-making on all relevant parties deciding whether or not MFA is required for external users. A decision regarding the specific MFA solution is a downstream decision and one that should (at least in part) be based upon the organization’s architecture principles (covered later in this blog). It is worth noting that some capabilities may have a process-based solution rather than a technology-based solution; e.g. many healthcare organizations still conduct real-time patient charting via traditional clipboard/pen-and-paper (and only later are those details entered into an EMR application).
Comprehensive. An enterprise architecture, as well as an architecture for any area of the IT landscape, must depict all elements necessary to fulfill the requirements that are expected of the solution that is being architected; i.e. it must be comprehensive. Being comprehensive is one reason why a core tenet is to focus on capabilities since it allows business leaders (who typically do not possess deep technical knowledge) to participate in the initial architecture review process to help determine whether or not the proposed integration of capabilities will fulfill the business objectives in the manner (usage) in which such objectives are envisioned by business leaders. Thus, focusing on capabilities helps an architecture to have a higher level of completeness, and facilitates delivering a solution that aligns with what was envisioned by the business.
Requirements-driven. The importance of gathering requirements is no surprise, but it is very surprising how many projects do not accurately document requirements. Requirements should be organized into functional requirements (capabilities required by the business in order for end-users to do their job), technical requirements (items that are necessary for the systems that comprise the solution to function properly), usage (the scenarios in which the solution will be used), and use cases (examples that outline who, when, and where the solution must be able to be used). One person’s bed is another person’s pull-out sofa, so requirements should include a description of how end-users will use the solution in practice (i.e. usage and use cases) to ensure that what will be delivered matches what the business envisions; other processes such as SDLC can be adopted to assist in this capacity.

Distinguishing Architecture from Design

Thus far, we have outlined the primary benefits of maintaining a relevant architecture and design, briefly summarized some of the most popular enterprise architecture frameworks, and have outlined core tenets. As with most Ferroque Systems blogs, our goal is to provide practical guidance, and here we will dive into a popular topic of distinguishing architecture from design.

Let’s start with a simple statement: architecture focuses on what and design focuses on how. In practice, architectural disciplines are used to identify the people, process, and technologies that will be pieced together in a manner that enables the desired solution; in this context, architecture defines the framework (i.e. the “what”) of a solution. Once this framework is established, it can be further defined by providing substantive details to define specific roles and responsibilities, processes and procedures and workflows, and how the various technologies will be integrated; in this context, design defines the “how” of a solution. In practice, this is often not a linear process; it may start off in a natural progression from architecture to design, but the act of defining new details often elicits new questions and/or previously unknown needs (requirements) that require going “back to the drawing board” to update the framework (e.g. perhaps a new role, process, and/or technology becomes necessary), before then proceeding again to define additional design details.

Let’s use a real-world analogy. As a Star Wars fan, I am also interested in similar real-world matters such as the US space program that was born in the late 1950’s. Living in the world of IT, I find it amazing to think of how the US landed a man on the moon with antiquated 1960’s technology. If we put ourselves back in that time, there was no NASA, no rockets, no spacesuits…nothing. Today, we often use the phrase, “architect of the system”; when the space race began in the late 1950’s, someone had to architect the program that would enable the US to compete: someone was tasked with defining and putting together all the elements that were required to make manned space flight possible. In 1958, NASA was formed via the evolution of NACA (which was focused on aeronautics; NASA added “and space”), and had to define all of the roles and responsibilities (e.g. flight director, mission commander, systems engineers, etc.), processes (e.g. CAPCOM processes, launch procedures, lunar landing procedures, etc.), and technologies (e.g. too numerous to name) necessary to achieve this goal. The enormity of the goal necessitated that a proper framework be defined to view all of the elements that had to come together to form a cohesive solution; only once a top-level framework was defined could the various teams then proceed to define their specific details (i.e. design). In the case of NASA and the spaceflight programs, due to sheer size, frameworks existed at various levels; for example, the diagram below illustrates a top-level framework (architecture) of key roles and responsibilities, wherein each box begets a lower-level framework of key roles and responsibilities, and each lower-level framework is extrapolated into more granular levels of detail that define the specific roles, processes, and systems, how they all work together, and the key inputs and outputs. These lower-level granular details are analogous to design.

In the space program analogy, the sheer size makes it easier to see the distinction between architecture and design; in the world of IT, initiatives are magnitudes smaller thus the distinction is usually much more subtle and is often blurred. But as we shall see in this post, such distinctions still exist.

At this point, it is worth mentioning the various technology architecture types; for practicality, we will limit to what Ferroque Systems most often sees in the field: conceptual, logical, and physical architectures. For the purpose of this blog, we will define these architecture types as follows:

A conceptual architecture has essentially the same attributes as the core tenets described above; i.e. focuses on capabilities and is technology-agnostic, and depicts a complete solution that depicts all the back-office and front-office capabilities that are necessary for the solution to function as needed.
A logical architecture indicates specific technologies and depicts how those technologies will work together to deliver expected outcomes that fulfill requirements. Depending upon the solution being depicted, it may also indicate traffic flows and indicate areas where non-technical solutions (e.g. processes) play a key role. A logical architecture often bridges the gap between architecture and design and is what Ferroque Systems most often sees in the field.
A physical architecture indicates specific components and depicts how those components are physically connected; e.g. it often depicts specific hardware, hardware specs and sizing, switch ports and configurations, cabling diagrams, rack configurations, cloud regions, network topology, IP addresses, and DNS names, etc. As the saying goes, “A picture is worth 1000 words”, so this most often accompanies a design document to graphically illustrate (rather than just verbally describe) how all components will work together to deliver a solution.

Regarding the primary benefits outlined at the beginning of this blog, these architecture types align as follows:

Facilitates the organization of ideas and a vision into a valid practical solution, and acts as a practical reference for making improvements prior to beginning physical deployment (“measure twice, cut once”). >> Conceptual architecture
Provides an over-arching reference for the IT environment that guides technology decisions and implementations, to ensure such decisions and actions perpetuate a consistent and like-minded approach across all technology domains. >> Conceptual and Logical architectures
Foundation for defining technical design artifacts for each technology domain; such design artifacts provide additional benefits. >> Logical architecture
- Detailed guidance for configuring technology components as they will exist in the real world, and ensures multiple components will be configured to orchestrate and integrate functionality into a cohesive solution. >> Physical architecture
- Justification for why a given technology component is configured in the manner that it is, which can be referenced ongoing to determine if/when a change is warranted based upon new requirements and/or use cases. >> Design document (containing various architecture diagrams)

There is typically a natural flow/progression to defining technology-focused solutions, which starts when business leaders state the organization’s primary objectives, followed by business group leaders stating their business groups’ initiatives and requirements for achieving those objectives. Soon thereafter, the organization’s IT teams will become involved to figure out how to leverage the organization’s technology investments to help enable those objectives and requirements. It is at this point that an enterprise architecture should be referenced, to help identify the areas that are expected to play a role in fulfilling the requirements (e.g. by identifying required capabilities and whether or not all such capabilities already exist); i.e. the enterprise architecture is the top of the waterfall that elicits the flow of necessary downstream technical discussions. Being at the top of the waterfall underscores the importance of the completeness of the enterprise architecture.

As suggested above, the key distinction between architecture and design is overall scope and level of detail (and thus intended usage): an enterprise architecture is a conceptual architecture that depicts the entire technical ecosystem, a conceptual architecture often exists for each key system within the enterprise, systems-level conceptual architectures are often expanded into a logical architecture(s) to depict additional details, and such logical architectures may be further expanded into physical architecture(s) and design documents to provide justifications for detailed design decisions. In practice, this natural flow from architecture to design most often manifests as follows:

Starting with a conceptual architecture to define tangible scope boundaries and provide a technical framework (skeleton) to drive ongoing discussions and decisions. Assuming the architecture follows the core tenets, it can be appropriate to include business leaders in some of these discussions to help ensure the outcomes will more closely align with the business needs (particularly regarding usage, as there are often multiple options for fulfilling a requirement, so including business leaders can help identify the option that most closely aligns with the business’ vision of how the new requirements will be used).
Evolving into a logical architecture by drilling down into the areas (capabilities) that will be used to fulfill the new requirements, for the purpose of adding more details; e.g. to indicate specific technologies and how those technologies will integrate. Although it may not be specified as such, often a logical architecture will inherently define a logical system (which may traverse technology boundaries) and indicate the necessary inputs and outputs (e.g. data sets, security token, reports, etc.), as well as traffic flows within the system (to more clearly define sequencing and dependencies).
Further detailing by using a physical architecture to translate a logical architecture into real-world implementation. This will often include specific details necessary for the real-world solution to function, such as physical hosts, IP addresses, storage and folder shares, DNS names, URLs, etc. A design document will often also be created to document (capture) the justifications for the design decisions. Such physical architectures and design documents typically act as a blueprint for configuring and integrating the necessary technologies/components to implement the real-world solution.

Having now walked through the natural progression and key distinctions, let’s take a minute to recall we mentioned above that many vendors (e.g. Citrix, VMware, and others) promote a native architecture model, which in this context is typically depicted graphically as a logical architecture (since it is specific to the vendor’s technology and any ancillary technologies). We mention this here because often such architecture diagrams are described as being a conceptual architecture, which may seem a bit confusing given the content of this blog. In practice, whether it is called a conceptual or logical architecture is not significant – what some persons call a conceptual architecture, others may consider a logical architecture, and vice versa – what matters is for the architecture diagram to be informative, accurate, and useful for driving ongoing decision-making.

That said, within a given organization, it is practical to subscribe to a common definition of conceptual, logical, and physical architectures, so everyone has the same expectations when creating and reviewing such artifacts. As mentioned above, within Ferroque Systems we most often work at the logical architecture level, primarily as that is inherent in the nature of designing application delivery solutions that focus on technologies such as Citrix and various cloud solutions (such as Microsoft Azure and Amazon/AWS). As well, in practice, such logical design efforts often extend the design for key elements to include physical design details; the level of physical design consideration depends upon customer need, the product stack being designed, and the design type (e.g. high-level vs. low-level).

As outlined above, there are key distinctions between architecture and design, and each of these artifacts has a specific purpose, use case, and target audience; done correctly, each artifact facilitates the ensuing downstream discussions and decisions.

To Be Continued…

In this 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.

This initial blog post is intended to set the table for our ensuing posts in this series, wherein we will dive into practical details such as defining architecture principles and standards, methods to define and use an architecture, how to evolve architecture into design, and common pitfalls to avoid when defining architecture and design. Please stay tuned; there is much more to come in our next post!

Subscribe