Simplicity is a form of art...

Evaluating the zero trust hype
by Sven Vermeulen, post on Tue 05 October 2021

Security vendors are touting the benefits of "zero trust" as the new way to approach security and security-conscious architecturing. But while there are principles within the zero trust mindset that came up in the last dozen years, most of the content in zero trust discussions is tied to age-old security propositions.

Scale is a cloud threat
by Sven Vermeulen, post on Tue 28 September 2021

Not that long ago, a vulnerability was found in Microsoft Azure Cosmos DB, a NoSQL SaaS database within the Microsoft Azure cloud. The vulnerability, which is dubbed ChaosDB by the Wiz Research Team, uses a vulnerability or misconfiguration in the Jupyter Notebook feature within Cosmos DB. This vulnerability allowed an attacker to gain access to other's Cosmos DB credentials. Not long thereafter, a second vulnerability dubbed OMIGOD showed that cloud security is not as simple as some vendors like you to believe.

These vulnerabilities are a good example of how scale is a cloud threat. Companies that do not have enough experience with public cloud might not assume this in their threat models.

Naming conventions
by Sven Vermeulen, post on Wed 15 September 2021

Naming conventions. Picking the right naming convention is easy if you are all by yourself, but hard when you need to agree upon the conventions in a larger group. Everybody has an opinion on naming conventions, and once you decide on it, you do expect everybody to follow through on it.

Let's consider why naming conventions are (not) important and consider a few examples to help in creating a good naming convention yourself.

Location view of infrastructure
by Sven Vermeulen, post on Tue 07 September 2021

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:

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
by Sven Vermeulen, post on Wed 01 September 2021

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
by Sven Vermeulen, post on Fri 27 August 2021

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
by Sven Vermeulen, post on Fri 30 July 2021

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?
by Sven Vermeulen, post on Mon 19 July 2021

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
by Sven Vermeulen, post on Thu 08 July 2021

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
by Sven Vermeulen, post on Wed 30 June 2021

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.