Architecture must include technology specification but it's not about the product name or tool use

Architecture must include technology (specification) but it's not about the product name or tool used, which we configure for implementation, but rather what it is that we want.

Adding the name of a product (or tool) in a diagram makes it an implementation model, or in other words, a product or tool that will implement the archtecture. This is a very useful model, but this model is not an Architecture model as we previously thought.

This very same practice ls one of the reasons why business stakeholders are turned off when they see such implementation models being passed as Architecture models, full of implementation details rather than specifications of the system and what we want to achieve with the application.

If you want to know what "Architecture" is, you should look no further than how we as humans communicate and access information about complex objects that we want to use to achieve a goal such as how to fly an airplane or what is a skyscraper made out of; they are all Architected first, built and then used by huamns to provide a service or goal to society.

Using tools like "Hitachi Humada" or "AWS Greengrass" we can implement the entire application (for example), but the goal of Architecture is not about what tools we end up using to build the application or how to implement the application (for example), but what we want to achieve with the application.

As we can already see, building a secure, resilient IoT application using the AWS Greengrass, we can implement all its features and functions. However, because this is a complex Fleet Management Application (using IoT), we must first define what feature we wish to have and what we can achieve, how it is different from other similar applications. Then we must plan the structure of the application. This involves determining the best way to implement the functions, decide what all of the components should work together, and maintaining that they are inline with each other and know when it's right to change and decompose components and when we must assemble them.

Tools and programming studios are a means to get the job done, not the only focus of the architecture. We need "best of breed or best of style" approach and implement the technologies, tools and techniques that are best suited to the solution. No to mention tools make it easier to achieve our goals, but every tool we select has tradeoffs.

By separating the implementation models from Architecture models, you are protecting the longevity of the system. Technology (specification) can have a longer life span than Technology (Implementation) using a tool (or tools).

If your organization is using an architecture-driven strategy, the next time you implement a new technology, tool or technique, just keep in mind about separating the specifications from implementation details. The simple task of creating another diagram (clone your supposedly Architecture diagram) by removing the tool names, and you have a Architecture diagram ready for use in other works. You will be future ready.

Tools are only one aspect of the overall architecture; architecture is about more than just where to put a tool.

Obviously a very small, but incredibly valuable idea.