Qazwer wrote: ↑Thu Apr 01, 2021 8:50 am
iDave - would you be willing to post here or in another thread what factors you would look at from a system engineering framework? The redundancy aspect of this model jumps out but I do not have the words/knowledge to know what it should look like though.
Okay, this isn't very good, and it's long/rambling. I forgot Easter is this weekend and I won't have a chance to do a good job as I'd intended. It's likely I'll come back and make edits over the next couple days without warning.
TL;DR - Have a good understanding of what the core requirements of your system are, and within time/resource constraints try to balance resilience, redundancy, adaptability, reliability, maintainability, availability, transportability, maybe others according to your value hierarchy and goals.
With an engineering hat on we have a system we want to design and implement.
The first step is to understand what we want the system to do. Maybe it's a vehicle to drop on Mars and have autonomously move around, feed back information, and analyze material as directed. Maybe it's a plan for an individual to manage resource needs over a period of time. Either way some sort of definition, or requirements, or mission statement, etc., is needed.
So in thinking about resource management system for a retired guy ...
I never made a detailed list of requirements/specifications but I always had a list of desires in mind. Things like, resources should be:
-conveniently available
-regularly and smoothly delivered
-malleable/fungible
-obtainable with minimal demands on my time
-of sufficient capacity to hold up through adverse conditions
-growing in capacity during benign times
-capable of absorbing increases in ongoing need
-etc.
Were not talking about tactics and strategies yet. Just what the ideal system would deliver. Like goals, the more specific, obtainable, and measurable they are the better. Inherent to the process are ongoing reality checks. Objective systems that require Unobtanium by the ton are non-starters. It can't take 10,000 years to build or trillions of $ and the labor of a million people (some people in Washington would disagree with me).
So we have to assess what we can afford. Cost comes in the form of $, time, difficulty, sacrifice, any other regret inherent to it. Then comes the art of how to come closest to meeting all the desires within the cost constraints. The specification/requirement definition. In the real engineering world on large complex systems, all the up front stuff can make up a third of the total effort. It's basically the foundation of the system. In the engineering world you emerge with a set of requirements.
Either in the envisioning or the process of examining "how to best meet ..." robustness becomes a desireable characteristic. A working definition might be:
A system is robust if it fulfills its core mission under a variety of conditions.
Obviously we would want the "variety of conditions" to bound a meaningful space of future events and conditions. The greater the expanse of the condition/event space is, the more certain dimensions of the cost will increase.
For my own personal use I like to break robustness in three main categories:
-Resilience is the ability to maintain core mission through stress and damage, which might include self-repair capability
-Redundancy is the ability to replace a failed system component with another/backup component to maintain the core mission
-Adaptability is the ability to operate outside the core mission for the benefit of the system of which the object system is a subsystem. The iDave Phase III Resource Management System is a subsystem of the iDave Phase II system.
I didn't think explicitly in these terms, but when one starts asking questions like
-what if the market drops 50%?
-what if I only get 50% of the SS the SSA is telling me I'll get?
-what if my or a family member's health takes an unfavorable turn?
-what if I get married and/or have another kid, or become primary caretaker of grandchildren?
-what if I have to relocate
-what if combinations of the above happen?
you're getting into the realm of those three characteristics. Chances are if you "and" enough of those kinds of things together the system will be increasingly difficult to build and actuate. It requires a judgement call of "good enough" at some point and an acceptance that the probability of failure is nonzero.
If we just consider a normal "salaryman's toolkit", tactics can be mapped
"Oversaving" (a big one for me) adds to resilience. Example: the iDave Phase III Resource Management system will not break down if the stash lost half its value and never recovered. It also adds to adaptability in that iD3RMS can keep up with a pretty substantial increase in ongoing spending without failing. It's marginally viable if both those things happen. As we see in this thread, it's ability to address redundancy is limited, although moving away from the stocks/bonds/cash recipe into real estate and commodities/resources can help.
Another tactic, simultaneously "designing" for a higher than planned spending level and keeping the ability to lower spending below planned contributes to all three. Becoming a skilled gardener or DIYer facilitates similarly.
I'm not recommending anyone go out and do those things.
Back in the engineering realm there is a whole subdivision of system engineering that called specialty engineering. Stuff like reliability, maintainability, availability, transportability, etc., go in there. For example, reliability speaks to how often a "breakdown" might occur. Maintainability is how much cost/effort is required to keep the system operational. A retirement resource management system that requires 80 hours/wk "care and feeding" might not fit everyone's definition of retirement. Others may jump at it because it can drive the need for ongoing cash flow down, maybe to almost zero, something a true ere-er might weight much heavier in their trade space than I did.
There's nothing fancy involved. If you think about it, we all think about these things routinely in our problem solving. System engineering provides a process intended to ensure all those considerations are given their due, tailored to what is relevant to the need being addressed, among other things.