Simplicity is a form of art...

Diagrams are no communication channel

IT architects generally use architecture-specific languages or modeling techniques to document their thoughts and designs. ArchiMate, the framework I have the most experience with, is a specialized enterprise architecture modeling language. It is maintained by The Open Group, an organization known for its broad architecture framework titled TOGAF.

My stance, however, is that architects should not use the diagrams from their architecture modeling framework to convey their message to every stakeholder out there...

An enterprise framework for architects

Certainly, using a single modeling language like ArchiMate is important. It allows architects to use a common language, a common framework, in which they can convey their ideas and designs. When collaborating on the same project, it would be unwise to use different modeling techniques or design frameworks among each other.

By standardizing on a single framework for a particular purpose, a company can optimize their efforts surrounding education and documentation. If several architecture frameworks are used for the same purpose, inefficiencies arise. Supporting tooling can also be selected (such as Archi), which has specialized features to support this framework. The more architects are fluent in a common framework, the less likely ambiguity or misunderstandings occur about what certain architectures or designs want to present.

Now, I highlighted "for a particular purpose", because that architecture framework isn't the goal, it's a means.

Domain-specific language, also in architecture

In larger companies, you'll find architects with different specializations and focus areas. A common set is to have architects at different levels or layers of the architecture:

• enterprise architects focus on the holistic and strategic level,
• domain architects manage the architecture for one or more domains (a means of splitting the complexity of a company, often tied to business domains),
• solution or system architects focus on the architecture for specific projects or solutions,
• security architects concentrate on the cyber threats and protection measures,
• network architects look at the network design, flows and flow controls, etc.

Architecture frameworks are often not meant to support all levels. ArchiMate for instance, is tailored to enterprise and domain level in general. It also supports solution or system architecture well when it focuses on applications. Sure, other architecture layers can be expressed as well, but after a while, you'll notice that the expressivity of the framework lacks the details or specifics needed for those layers.

It is thus not uncommon that, at a certain point, architects drop one framework and start using another. Network architecture and design is expressed differently than the ICT domain architecture. Both need to 'plug into each other', because network architects need to understand the larger picture they operate in, and domain architects should be able to read network architecture design and relate it back to the domain architecture.

Such a transition is not only within IT. Consider city planning and housing units, where architects design new community areas and housing. These designs need to be well understood by the architects, who are responsible for specific specializations such as utilities, transportation, interior, landscaping, and more. They use different ways of designing, but make sure it is understandable (and often even standardized) by the others.

Your schematic is not your presentation

I've seen architects who are very satisfied with their architectural design: they want nothing more than to share this with their (non-architect) stakeholders in all its glory. And while I do agree that lead engineers, for instance, should be able to understand architecture drawings, the schematics themselves shouldn't be the presentation material.

And definitely not towards higher management.

When you want to bring a design to a broader community, or to stakeholders with different backgrounds or roles, it is important to tell your story in an easy-to-understand way. Just like building architects would create physical mock-ups at scale to give a better view of a building, IT architects should create representative material to expedite presentations and discussions.

Certainly, you will lose a lot of insight compared to the architectural drawings, but you'll get much better acceptance by the community.

Location view of infrastructure

In this last post on the infrastructure domain, I cover the fifth and final viewpoint that is important for an infrastructure domain representation, and that is the location view. As mentioned in previous posts, the viewpoints I think are most representative of the infrastructure domain are:

• process view
• service view
• component view
• zoning view
• location view

Like with the component view, the location view is a layered approach. While I initially wanted to call it the network view, "location" might be a broader term that matches the content better. Still, it's not a perfect name, but the name is less important than the content, not?

Process view of infrastructure

In my previous post, I started with the five different views that would support a good view of what infrastructure would be. I believe these views (component, location, process, service, and zoning) cover the breadth of the domain. The post also described the component view a bit more and linked to previous posts I made (one for services, another for zoning).

The one I want to tackle here is the most elaborate one, also the most enterprise-ish, and one that always is a balance on how much time and effort to put into it (as an architect), as well as hoping that the processes are sufficiently standardized in a flexible manner so that you don't need to cover everything again and again in each project.

So, let's talk about processes...

Component view of infrastructure

IT architects try to use views and viewpoints to convey the target architecture to the various stakeholders. Each stakeholder has their own interests in the architecture and wants to see their requirements fulfilled. A core role of the architect is to understand these requirements and make sure the requirements are met, and to balance all the different requirements.

Architecture languages or meta-models often put significant focus on these views. Archimate has a large annex on Example Viewpoints just for this purpose. However, unless the organization is widely accustomed to enterprise architecture views, it is unlikely that the views themselves are the final product: being able to translate those views into pretty slides and presentations is still an important task for architects when they need to present their findings to non-architecture roles.

Disaster recovery in the public cloud

The public cloud is a different beast than an on-premise environment, and that also reflects itself on how we (should) look at the processes that are actively steering infrastructure designs and architecture. One of these is the business continuity, severe incident handling, and the hopefully-never-to-occur disaster recovery. When building up procedures for handling disasters (DRP = Disaster Recovery Procedure or Disaster Recover Planning), it is important to keep in mind what these are about.

What is the infrastructure domain?

In my job as domain architect for "infrastructure", I often come across stakeholders that have no common understanding of what infrastructure means in an enterprise architecture. Since then, I am trying to figure out a way to easily explain it - to find a common, generic view on what infrastructure entails. If successful, I could use this common view to provide context on the many, many IT projects that are going around.

Organizing service documentation

As I mentioned in An IT services overview I try to keep track of the architecture and designs of the IT services and solutions in a way that I feel helps me keep in touch with all the various services and solutions out there. Similar to how system administrators try to find a balance while working on documentation (which is often considered a chore) and using a structure that is sufficiently simple and standard for the organization to benefit from, architects should try to keep track of architecturally relevant information as well.

So in this post, I'm going to explain a bit more on how I approach documenting service and solution insights for architectural relevance.

Not sure if TOSCA will grow further

TOSCA is an OASIS open standard, and is an abbreviation for Topology and Orchestration Specification for Cloud Applications. It provides a domain-specific language to describe how an application should be deployed in the cloud (the topology), which and how many resources it needs, as well as tasks to run when certain events occur (the orchestration). When I initially came across this standard, I was (and still am) interested in how far this goes. The promise of declaring an application (and even bundling the necessary application artefacts) within a single asset and then using this asset to deploy on whatever cloud is very appealing to an architect. Especially in organizations that have a multi-cloud strategy.

Integrating or customizing SaaS within your own cloud environment

Software as a Service (SaaS) solutions are often a quick way to get new capabilities into an organization’s portfolio. Smaller SaaS solutions are simple, web-based solutions which barely integrate with the organization’s other solutions, besides the identity and access management (which is often handled by federated authentication).

More complex or intermediate solutions require more integration focus, and a whole new market of Integration Platform as a Service (iPaaS) solutions came up to facilitate cross-cloud integrations. But even without the iPaaS offerings, integrations are often a mandatory part to leverage the benefits of the newly activated SaaS solution.

In this post I want to bring some thoughts on the integrations that might be needed to support customizing a SaaS solution.

An IT services overview

My current role within the company I work for is “domain architect”, part of the enterprise architects teams. The domain I am accountable for is “infrastructure”, which can be seen as a very broad one. Now, I’ve been maintaining an overview of our IT services before I reached that role, mainly from an elaborate interest in the subject, as well as to optimize my efficiency further.

Becoming a domain architect allows me to use the insights I’ve since gathered to try and give appropriate advice, but also now requires me to maintain a domain architecture. This structure is going to be the starting point of it, although it is not the true all and end all of what I would consider a domain architecture.