Whats Your Architectural Language?
The word of the year here at Wiresmith Technology is process. In areas where I have standardised processes life has got easier, less stressful and more reliable. Now I’m looking at the software processes to see where we can get the same benefits.
Something that I have wanted to address for a while is architecture. Working on my own has given me the benefit of being able to be quite ad-hoc and try different designs on different projects.
Well, I often think coming back to your own work after 6 months isn’t so different from working with someone else and I’ve certainly felt the drag of having to review how I built the architecture on each project. So I want to at least have some standard templates.
What I found when I came to it was I first had to define what is in a program!
Language Is Important
There are so many conflicting terms and every framework has its own terminology.
I really wanted to start with knowing what I want in a generic sense. By doing this without looking at specific frameworks it gives me the freedom to find a framework that fits the way I work best (as well as the freedom to change or not use frameworks depending on the project).
I’ve seen this approach work in my business. I’ve been trying to find tools to help me be more productive, but it isn’t until I decide on what the process is that these tools are supporting, I waste hours trying to choose as I have no way to determine what is best!
So before even trying to work with templates or frameworks, I reviewed my previous projects to try and pull out and name the different elements of my architectures so I can map other tools to this.
What I Picked
So here is what I listed as my architectural definitions. Before you read them, understand I am sharing these for your curiosity – you may have your own set of definitions in your team already. This isn’t about right or wrong, this is about consistency between team members and projects.
| Term | Description | Not to be confused with… |
| Application Component | An asynchronous VI with it’s own lifetime and own control of when to run. This is the top level of the architecture design. | |
| Data | A piece of engineering data e.g. acquired data. | Messages: We split this concept as messages are more framework-oriented. |
| Message | A framework command for a process to do something. | Data: although they are data in the strictest sense, they are not directly related to the data involved in the engineering domain. |
| Message Handler | A process that receives heterogenous messages and data. | Data-driven process: this has homogeneous data to handle. |
| Module | A set of related code. In our system, it is a class. It is generally unit testable. | Module (DQMH), Actor (AF) – These are processes or message handlers. |
| Process | A loop within an application component. It has a single reason to run. |
I’m pretty happy with this – the one element of confusion is where the actor style module (whether that is an actor framework actor or another QMH based framework like DQMH). In reality, this sits somewhere between a module and a process but I need to experiment more with how to think about those.
The one I think is particularly important is modules. Too often the important logic gets muddled and mixed with framework code
Next Steps
For me the next step now is to create templates or frameworks to handle these items in a consistent way – more on that in a future post.
My challenge to you is to think about this for yourself. Maybe you already have a framework so you don’t need definitions like this, but where do you find you or your time are inconsistent over time and would a common language help?
Nicola Bavarone
April 1, 2018Hi, thanks for this post. Only for module your definition seems API , module for us is a core based on API that work itself, and like you say is unit testing. For example we tent to use FGV for module, and we use that in process. Thanks