Beyond Ad-Hoc: to a practical IT Reference Architecture

In the dynamic world of IT, there inevitably comes a tipping point where ad-hoc solutions no longer suffice. Such solutions typically arise from ad-hoc architectures. However, as businesses grow and technology evolves, the need for a structured approach becomes undeniable. Eventually, ad-hoc architecture loses its effectiveness. Ideally, you’ll notice the signs early, before things become chaotic, compelling a shift from ad-hoc initiatives to a more standardized architectural method.

However, this is also the point where some people tend to shy away. Why? Because it can quickly become vague and lead to hypothetical debates. That’s exactly what we want to avoid. Of course, we understand that in large multinationals, you might require these complex and strict regulations. But for small midsize companies, IT reference architectures can be quite simple. That’s exactly what we’re aiming to do here. We have intentionally kept this reference architecture simple, introducing a practical and user-friendly framework. It ensures effectiveness across all layers and for all stakeholders within the organization. Therefore, it must be easily accessible and straightforward to adapt.

The main goal was to create an architectural blueprint that ensures every technological initiative aligns its design and implementation across various IT projects. This is achieved by following an iterative & incremental approach based on initiatives that pop up within your organization. At its core, an IT reference architecture serves as a compass, guiding the integration of new technologies, systems, and practices into a manageable IT landscape.

But foremost, without becoming overly theoretical or “fluffy.”

Setting the scene

The IT architecture follows a layered approach, where each layer has specific standards and characteristics to ensure that components within a layer adhere to predefined principles. This layered approach not only facilitates the easy incorporation of new components but also promotes a ‘speaking the same language’ culture within the organization, establishing a common ground of understanding. This helps in scoping and finding the right solutions for specific problems. When building new components, the pre-established standards of each layer serve as guidelines. Here is an overview of our identified layers, but again, it’s not the holy grail; it can vary based on your organization.

In a book, we could delve into every detail of each layer, but in this blog, we’ll focus on a single layer as an example to illustrate how you can tailor it to your needs:

Let’s take a look at the Product Layer!

The Product Layer

The Product Layer is the commercial face of our IT architecture, transforming complex internal systems into market-ready products. It acts as a bridge between resources and consumers, ensuring our offerings meet industry standards and expectations.

Characteristics

•Productization: Each offering within this layer is designed to be productizable and sellable, aligning with the goal of generating value and revenue.

•Market Standards: Ensures that all offerings adhere to market standards, meeting requirements and customer expectations in terms of quality, security, and performance.

•Gateway to Internal Resources: Opening “internal” services and APIs to its consumers. The  layer can also aggregate various services into products.

•Avoiding business logic Designed for straightforward and efficient delivery. By excluding business logic, it ensures swift access to services without added complexities.

:

Design Patterns

Throughout this blog, we descend the ladder of abstraction, making each concept more concrete. The next step on our ladder involves design patterns.

While the layers themselves do not offer standalone solutions, the collaboration across these layers is crucial for constructing effective solutions. Design patterns integrate different layers of architecture to provide optimal solutions. These patterns offer universal resolutions to recurring challenges, promoting a standardized approach to problem-solving. This ensures developers and architects don’t have to “reinvent the wheel.“

We’ve identified a subset of design patterns that have proven instrumental within our organization. however, it’s important to recognize that this list is far from exhaustive. With each new challenge that we encounter, we reflect and strive to develop or adapt a design pattern. Thus, these design patterns are ever-evolving, ensuring our architecture continuously improves and innovates. To give you an idea below is a subset of our design patterns:

Let’s adopt the same approach as before by selecting one layer to explore in more detail. For a simple and easy-to-understand example, let’s consider the incoming webhook design patterns.

A decision tree of design patterns

To clarify the selection process of design patterns for everyone, we have established a decision tree. This tool not only helps in choosing the appropriate design pattern for a given problem but also helps to avoid unnecessary discussions by providing clear guidance. Multiple design patterns may emerge as suitable options from this decision tree. Acting as a quick guide, this tool facilitates the construction of new solution architectures, ensuring that decisions are both informed and efficient.

Technology Mapping

Now that we understand which design patterns to use, it’s time to delve deeper into the technology. However, before we address the technical architecture, we must first map out and standardize the technologies that best fit the characteristics of each layer in our IT reference architecture. For our hypothetical organization, we have selected some technologies, but the choice ultimately depends on what your organization currently employs. This exercise will also help you identify any gaps in your technology stack and determine which technologies may be strategic for your future, incorporating them into your organization in line with your maturity.

 Here, we began with a simple greenfield example, but of course, mapping your current landscape onto these layers can be a really time-consuming exercise.

The technical Architecture

Let’s delve deeper into the previously discussed design pattern of the incoming webhook and integrate it with technology mapping to create a technical architecture in Azure. To construct an incoming webhook architecture, we utilize API Management to streamline the webhook implementation. This approach involves handling security, standardizing the event format (CloudEvents), and publishing to an event broker (Event Grid), aligning with our IT architecture principles of loose coupling and scalability. Consequently, any application within our landscape should be capable of subscribing to the webhook event.