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.

Sustainability in IT

For one of the projects I'm currently involved in, we want to have a better view on sustainability within IT and see what we (IT) can contribute in light of the sustainability strategy of the company. For IT infrastructure, one would think that selecting more power-efficient infrastructure is the way to go, as well as selecting products whose manufacturing process takes special attention to sustainability.

There are other areas to consider as well, though. Reusability of IT infrastructure and optimal resource consumption are at least two other attention points that deserve plenty of attention. But let's start at the manufacturing process...

Getting lost in the frameworks

The IT world is littered with frameworks, best practices, reference architectures and more. In an ever-lasting attempt to standardize IT, we often get lost in too many standards or specifications. For consultants, this is a gold-mine, as they jump in to support companies - for a fee, naturally - in adopting one or more of these frameworks or specifications.

While having references and specifications isn't a bad thing, there are always pros and cons.

Containers are the new IaaS

At work, as with many other companies, we're actively investing in new platforms, including container platforms and public cloud. We use Kubernetes based container platforms both on-premise and in the cloud, but are also very adamant that the container platforms should only be used for application workload that is correctly designed for cloud-native deployments: we do not want to see vendors packaging full operating systems in a container and then shouting they are now container-ready.

Defining what an IT asset is

One of the main IT processes that a company should strive to have in place is a decent IT asset management system. It facilitates knowing what assets you own, where they are, who the owner is, and provides a foundation for numerous other IT processes.

However, when asking "what is an IT asset", it gets kind off fuzzy...

An IT conceptual data model

This time a much shorter post, as I've been asked to share this information recently and found that it, by itself, is already useful enough to publish. It is a conceptual data model for IT services.

Ownership and responsibilities for infrastructure services

In a perfect world, using infrastructure or technology services would be seamless, without impact, without risks. It would auto-update, tailor to the user needs, detect when new features are necessary, adapt, etc. But while this is undoubtedly what vendors are saying their product delivers, the truth is way, waaaay different.

Managing infrastructure services implies that the company or organization needs to organize itself to deal with all aspects of supporting a service. What are these aspects? Well, let's go through those that are top-of-mind for me...

The pleasures of having DTAP

No, not Diphtheria, Tetanus, and Pertussis (vaccine), but Development, Test, Acceptance, and Production (DTAP): different environments that, together with a well-working release management process, provide a way to get higher quality and reduced risks in production. DTAP is an important cornerstone for a larger infrastructure architecture as it provides environments that are tailored to the needs of many stakeholders.

Creating an enterprise open source policy

Nowadays it is impossible to ignore, or even prevent open source from being active within the enterprise world. Even if a company only wants to use commercially backed solutions, many - if not most - of these are built with, and are using open source software.

However, open source is more than just a code sourcing possibility. By having a good statement within the company on how it wants to deal with open source, what it wants to support, etc. engineers and developers can have a better understanding of what they can do to support their business further.

In many cases, companies will draft up an open source policy, and in this post I want to share some practices I've learned on how to draft such a policy.

Hybrid cloud can be very complex

I am not an advocate for hybrid cloud architectures. Or at least, not the definition for hybrid cloud that assumes one (cloud or on premise) environment is just an extension of another (cloud or on premise) environment. While such architectures seem to be simple and fruitful - you can easily add some capacity in the other environment to handle burst load - they are a complex beast to tame.