So as I’m unpacking and going over in my head all the things I said I’d build for the SILO GROUP portfolio, it occurred to me that these might go better if I went ahead and formalized a systems architecture lifecycle, starting with a system design document specification of some kind. This really should cover non-distributed systems as well as distributed systems.
One thing I’ve noticed about that style of architecture is that it gets kind of in its own way because in distributed systems there are so many components and its hard to keep track of when you move from complex single-node systems to distributed composite systems.
For example:
- Orchard
- Ircthulu
- Foster
- SME/D
- IDM/A
- SMQ/S
These are all distributed systems, meaning they are made up of systems that go across nodes and separate concerns between the components. To do a real SDD on them the component systems have to first exist, either in design or implementation, which is problematic because you want the components to evolve with the design of the distributed system ultimately being built if the components are not your real aim.
That dependency tree is where things get complex.
So, I’m thinking this might actually be a problem solvable by software. What if you had a database system you could log in to, and create a small system in, and then save– and then reuse that system as a component in a larger distributed system once it was saved — and then as you are grinding away on the distributed system you’d be able to dive into the smaller components (also designed as systems in this database system) and update those to fit into the larger picture of the system they make up?
So that’s what SAL/M is likely to be. Eventually.
I’m just tired of all the dependencies getting in the way. SAL/M depends on SME/D. SME/D depends on IDM/A. IDM/A is boring and slow because it has to be. But what if I could flesh out SME/D without IDM/A being fully developed? It’s in there, it’s moving, but it’s not necessarily complete.
So I need to build an SDD for a system that generates dynamic SDD’s, does basic portfolio management, etc. Is this a meta loop, like some kind of psychological tick manifesting, or am I on to something?
When I talk about SDD’s in corporate settings I get eye rolls usually. Or I hear a quiet “YES FINALLY” from some outliers. This used to be a standard tool.
Interestingly enough, I did a study a while back where I interviewed other architects all over the country about just this and what their process and artifacts were in the design process, and it turns out, the vast majority of corporate architects seem to be using just visio to just spit out blueprints without any of the other contextual analytics documents, no design decisions documented. Functional and non-functional requirements are terms that are still used alot in software development shops but they don’t mean the same thing. And, I have to admit, I do what the industry does at work. Not because I want to, but because I have to — you can’t change the market, and if you go against it, you’d better win (and you won’t, because folks who don’t document their architecture have taken over the market).
That doesn’t mean I have to do it here. Hrm.