#itarchitecture

I recommend the C4 model for anyone interested in IT architecture, from beginner to expert. I feel it has just the right amount of architecture to represent the IT system you are trying to describe. It doesn't burdened you with creating too many artifacts. You don't have to learn a lot of rules (e.g. which arrow to use for different forms of relationship). The C4 model lets' you focus on what's essential to communicate to others and avoid debates about nomenclature. You can represent your IT architectures at all levels, from conceptual to physical, which means you can use it through the entire lifecycle of your IT system. In addition, you can represent your architecture with many different diagrams, from system context diagrams to deployment diagrams. And while it's meant for software architects, it is suitable for any IT architect.

Another nice thing about the C4 model diagrams is that they are supported with PlantUML. That allows you to have your diagrams as code. I love that. Each time you diagram your architecture using PlantUML, you can push your .puml (PlantUML) files into a source code repository. A repository like github gives you greater traceability and accountability. You could have each change be a pull request that can be reviewed and approved before being accepted. And each change can come with a reason for why the architecture is changing (e.g., new requirement, constraint or architectural decision). The result is better architectures and better IT Systems.

Dive into our latest blog post where we unravel the mysteries of TOGAF - a key framework in IT enterprise architecture. It's more than just code; it's about crafting a future-proof, adaptable structure in the tech world. 🚀

🔗 Explore here: https://www.advisedskills.com/about/news/416-togaf-experts-design-it-enterprise-architecture-to-meet-current-and-future-needs

One thing I like about system context / use case diagrams is that they help me define and uncover scope for an IT system. To see what I mean, let's say I was called in to help understand or build an IT system that has a touchscreen device like this:

A preliminary system context model (with an underlying use case) would look like this:

Pretty simple. But not the whole context. Let's dig further.

For any information that a user reads in an IT system, there is an implicit create information use case that has to exist. There may also be an update information and delete information use case (think C.R.U.D.), but there is definitely a create information use case.

Now in this example, the shopper is not creating items to search for. There must be another actor who is doing that. The person responsible for this IT system says that an Admin person does that. The diagram expands to something like this:

We may wonder if each item is added individually, or if there is a process to automatically add items. Through interviews we find out there is an inventory system that transmits information to our IT system and adds items to it overnight. Now our system context looks like this:

In conclusion, by asking questions about the information our initial user ("Shopper") is searching for, we find our scope has expanded to include two new users/actors: an Admin and an Inventory System. The scope of our new IT system is now better understood.

If you think of deployment diagrams at all, you might think of something like this:

Yep, most of the time, when you see examples of deployment diagrams, they feature very old technology. (e.g., The Sun Fire servers in the above diagram were around in the 2000-2010 period.)

These days, when IT architects draw their solutions, they are more likely to be cloud centric and look like this:

While this is an IBM Cloud example, all the major cloud service providers have reference architectures that look like this.

In my opinion, the second diagram is also a deployment diagram. It doesn't follow the UML format, but it is essentially showing where services and other technology are deployed and how they relate to each other.

What I want to argue for is that these new diagrams could take a few things from the old deployment diagrams. For example, in the new diagram, we see a number of services running in a Kubernetes cluster. If this was a traditional deployment diagram, it might show nesting of boxes that would be something like this:

Kubernetes cluster > Worker node > Pod

Or it could be even more specific, and state what version of Kubernetes is being used in the cluster, how many worker nodes there are, what is the capacity of the worker node, and what is the OS of the pod. You could also state within the pod what containers are running there.

To extend this approach further, the new diagram could show which application components the containers are manifestations of. It’s here where the deployment diagram provides value, for it’s here where you see the linkage between the application and the runtime environment. You could even have tag or other information. For example you could have one pod manifesting one version of application components and another pod manifesting a different version. That linkage from the software components being designed by the application architect and the cloud infrastructure being designed by the cloud architect can be very powerful.

What I sometimes see is the application architect will design the software independently of how it will be deployed. They will provide the cloud architect with needs the application has for specific services. From there, the cloud architect will work to build out the cloud infrastructure.

What I would prefer to see is the application and cloud architects working together to determine how the code should be deployed, and then working together to come up with the right deployment model. The properties of deployment diagrams are suited for making that collaboration and communication more effective.