Architected Futures™

Tools and strategies ... for boiling the ocean

Generations, Flow or Space Travel?

This is started as a discussion branch around concepts of generations. Or what we label as generations. I was reading and starting to think about a response or commentary to the "currently" current issue of Computing Now, a publication of the IEEE Computing Society. The idea was "fold in" some of their "vision" into a "Vision World" framing narrative. I was intrigued by the list as I started to read, and it seemed to fit within the framework of my head as I discovered it (the article, not my head). They were talking right up my alley, what I am (currently, as I write) trying to put together on this web site which now serves as my notebook. (That part is beginning to work nicely in spite of the poor quality of integration of the tools. It just takes a little more work to deal with those issues, so progress slows down. But it's functional.)

<Needs links to "generations" in planning and use of MGP>

<Needs to lead to deeper discussion of "impulse forces" as they define and give character to "impacts" and "frequencies" and "harmonies"

  • "flows" define linear connection sets.
    • They have length, which may be capped over a discrete set, or continuous which extend to infinity
    • They have "direction" which may be positive, or negative. They can be paired in opposite directions defining a bi-directional force.
    • They operate along their axis, and at least in physics, have a variety of properties, some of which appear useful in other fields to explain patterns of behavior. (e.g., spin effects)
    • Waves, or frequencies, along flows can be used to define "generations"
    • Flows have volume, flows have rate. Think Plumbing 301.
    • Travel on a flow involves linear, directional navigation, start/stop, stair climbing, wave surfing, etc.
  • "spaces" conceptually are a "space" of a 3D size and irregular "shape" which encloses a set of flows.
    • They are capable of exhibiting the characteristics of any of their component flows in "raw" form, but they typically exhibit some form of blended characteristics as "emerged properties"
    • "Emerged properties" may, and typically do, change as exhibited by a "space" over the course of the life of the "space" (e.g., gestation, birth, childhood, adolescence, maturity, old age, retirement, termination or transmutation.)
    • There can be additional significant shifts in emergent properties as a function of operation, and operational health. 
    • Emergent properties define a "shape" for a "space"
    • Spaces appear to have "optimal shapes" which can very in form
    • Generations for spaces are determined by long term shifts in design patterns for "effective and efficient" shapes (systems). Otherwise, variations tend to be more a function of "variety" for (a purpose?)

Flows tend to define fundamentals, Shapes are defined by more complex models.

*Needs to move to Geometry?*

>

Generations

What hit me as I went down that page was the content label "5G." I had just finished writing some content about generations, referring to 1st generation, second generation, third generation, etc. flow labels used to describe hardware (computer systems) in the 1960's and 1970's. And the same labels being used at the same time to describe computer languages. Hearing the same label on multiple different things does not do much for communications and understand. (I think COBOL was a "third generation" language, the "report generators" we described as 4th generation at that time.) So, I wondered, "What the heck is 5G?" especially in this context? (I found out later. It's the new phone companies trying to confuse me for marketing purposes. Network coverage. 5G after 4G after 3G of cellular. Big Whoop. Useful I guess for consumers who ignore all the technical significance of the term and are simply "hooked" on "gotta buy a new phone." Useful, if you need the features. But confusing, 5G of what? Commander Data? Would it have been that hard to label it 5G Networks? I could go on, but there's other stuff to do, and it's dinner time. I'm getting called. (Hey, it's a notebook!)

...

[Architectural notes.]

This "book page" in its current form reads like an "article." Which it probably should be, or a blog post. It needs to be "reclassified" but I'm unsure how that works in Drupal, and if I have top do a whole element cut and paste to get it done. That's clumsy and needs to be addressed in the maintenance UX interface for people who are asked to maintain content. For true "content" kind of stuff, They should be working with more of an "office" suite. There are multiple candidates of "open source" office suites, one of which should be chosen and integrated if this goes "live" and breaks out of the lab. That seems like an easy "TODO" for the "Target MGP" for this Core EATS technology, for people who want to, or need to, work directly with Core EATS. 

  • Short term, this needs to be a factor in consolidating development tool kits to a smaller, consistent framework. Eclipse, EATS, Drupal, etc.
  • Long-term, only a small batch of users will use this "direct-to-EATS" type connection. But when they need it, the more critical the use of the system as a technological substrate, like a lot of other "computer" technology, the more critical it becomes that the engineers and controller/regulators have real time tools for inspection and analysis. When the need for a "stock market" option to do a "shut down" in truly out of whack conditions arise, it is not acceptable in tomorrow's real world. Access to correct documentation and the ability to do "right now" "Do IT!" commands1 already exists for some systems. That volume is going to grow over time.
  • Regular users (i.e., the general membership) will not want to use EATS directly. Although curious members may want to "traipse the maze" to learn, or to satisfy curiosity. (Ref: The Architecture Layer Diagram of 12/14/16 as annotated) "Regular membership" (users) are assumed to interface with the knowledge architecture through whatever computer UX interface technology they find comfortable for doing whatever task they are trying to accomplish. This is not an direct EATS interface technology.
    • Users interface with various facilities: (Facebook, Twitter, Google, etc. using iPhones, VR Glasses, internet browsers, "XBox" equivalents, car automation, home automation devices, IoT devices, garden sprinkler controllers, game apps, whatever.) Those devices use standard protocols to connect to EATS Architecturally Specified Interface Channel Adapters. The adapters provide "connections" that can be managed as "sessionless" like today's HTTP, or with "sessions." EATS supports both. The sessions provide entry and access to the rest of the knowledge base and facilities. The "user interaction" is with the service and context and facility, as they chose to use it, and dealing with whatever the feature set of that facility as the facility provider chooses to provide it.
    • Entering "EATS" through an "Interface Channel Adapter" brings the activity into "Architected Space." Validation, authentication, etc. all happens originally at the gateway. To be allowed an "access portal" the interface adapter facility needs to be certified as "trusted," then we double-check as access is granted. Access is assumed to possibly be multiplexed (multiple users over a single channel for efficiency), so that is taken into account by applying certain security precautions at a (message-based) transaction level, not at a connection level, although the connection itself can also be security checked at various levels. Levels of service determine such things as degree of privacy and security required. (My thoughts are that high-security packets are more likely to gain security quality by being mixed in with general message traffic rather than needing to try to protect themselves by using private routing facilities. (Demultiplexing a message stream to gain intelligence is not going to be easy. It easier to break a stream that you know is some form of secret, than having to first find the particles of "secret" in the haystack before beginning to process.) {Remember how they broke Enigma? Clean streams, known tokens in the stream.}
    • Once "service requests" are in the Architected Space, channel adapters route to Interaction Coordination and Orchestration service providers. 98% of these should be generic processors of various levels of complexity. Use a bell curve for development estimating based on a bell curve of function complexity units times some count, which will probably be a bit, or a lot, low. That shouldn't matter, because this is a "function pool." The front end coordination function pool is a different style than the knowledge algorithm pool. This is and includes a lot of personalization around core processing that applies viewpoint tailoring. Think in terms of camera angles on a scene, or variations in architectural plans: site plans, elevations, perspectives from multiple view points, electrical plans, plumbing plans, framing plans, roofing plans, and on, and on. ("Which version of logical analysis do you want to frame the argument from this time?" asked the personal assistant named AnI2.)
    • See a fuller explanation of the layers for more.

The point of the above is to explain the "architectural position and requirements for" the development path of the EATS UX code, versus how UX is envisions for the 10 year year "target product space." (Target as in "facility" not as in commercial product. All this needs to be "open" but with possible "benchmark" implementations. Benchmark implementations should have a "clean" ownership and separation from any commercial products. All published as "open source" to be able to be used as nucleus code for commercial implementations, or for personal use by whoever wants to make the effort to play with it.

[Portions of the above need to move to a better place in the documentation, specifically a layer diagram exposition page.]

To Do

Come back here and write the "Generations" ARTICLE that discusses the referenced IEEE "ARTICLE" discussing generations of technology and how they relate to what we are talking about and doing. There are a set of "states of development" discussed in the article, areas of impact, involved technologies, and vectors that can be identified in the conjectures. These form the basis for defining one segment of the "Vision World Model" that we need. This is what we are proposing for Vision World.

  1. Base everything on the reality of today, and a model that "explains" today as well as we can make it "fit" That's Real World.
  2. Project through extrapolation, forecast, and various forms of modeling, using the same models that explain "Real World" and see how "Vision World" operates and behaves at various projected distances in time.
  3. Based on the "issues" forecast, see what the impact is on identified, desired objectives.
  4. Develop and map alternative planning strategies to enhance probability of objective achievement in the most efficient manner, at minimal disruption to existing plans, with optimal cost/benefit ratios.
  5. Monitor feedback and unknown event occurrences, and loop as time passes for a dynamic, continuous process.

Forecasts used in step 2 include such material as is identified in the subject IEEE article. They are "Use Cases," in this case probably more "use and usage Scenarios"

Note: For an individual, all of this provides "context" for them to be able to map a plan on how the grandkids might be able to live out their lives, how to get them through graduate school, and what types of education might be most appropriate for them to live an enjoyable life: as whatever they want to become. Or, play a fantasy game based on a fictional reality. Which can also be fun. With VR glasses that will have been perfected within our 10 year horizon.

 

How would the game work? The same as the serious model. We roll out a projection using the knowledge base to what the situation might be like (Florida underwater, mostly, a few people maybe exploring asteroids, nation state conditions projected forward from today, terrorism and travel conditions projected to define what the world looks like, business, economics, pollution, and then you basically play "Sims" in that environment. Or, in the "fantasy" version, you could go off the visit "Lucy World" which might be very realistic, more so than Jurassic Park, or you can visit 3535 with Mason.)

The Title

Before I leave this for awhile, I need to explain the title.

  • Generations is fairly obvious. Iterations over time of "increased?" capability. (So always what exactly happens though. You got to whatch things. There are also "mutations of nefarious benefit that arise, and cancers, viruses, etc. Evolution doesn't always pick "goodness" based on a human benefit evaluation, or does it?)
  • Flow, or Space travel refers to EATS Geometry. Impulses, forces, generational inheritance in models (and in real life?) can travel along "flows" or "across spaces" which are conceptually different in how they operate.
  • This means that "genealogy" needs to be considered as either a flow (traveling exclusively in selected linear flows within confined trails or stream, or as possibly a type of thing that spreads like a fire or a virus across an entire "landscape" or "surface" or both.

This is not a "predicament" for EATS. EATS only needs to provide a generalized mechanism to manage the "genealogy" model by providing parameter sets, probably all "standard" and "inherited" in the metadata. Some difficulty comes up in algorithm writing in generalized service routines as to how to use of blend this into an aggregate, integrated formula for whatever is being modeled: humans, plant or animal species, iPhones, cars, technologies, economies, political systems, star systems... 

The challenge comes to the "modelers" in terms of how to use the facility, and tune it for accuracy. This is a BIG ISSUE which requires complete disclosure so everyone knows what we're basing estimates and forecasts on. Is this a linear progression, a SOP estimate, PERT, Delphi? ... and just what exactly was the basis in fact or historical trend and existing system behavior analysis?

For an example of work related to this, potentially useful for both historical trend pattern analysis and for forecasting, see, for example, "Technological Substitution, Forecasting Techniques and Applications" edited by Harold A. Linstone and Devendra Sahal, Elsevier1976.

Generations are layer after layer of "technological substitution" in a flow or a space. Reforestation after a disastrous fire. Slow mutation, or fast mutation of a species over time. It was once "about 5 years" on a moving average basis for a fleet of cars. It's also, legitimately, "Significant technical innovation and enhancement" in a computer or cellular service capability. A lot of these can be seen and projected. Seeing them coming and properly planning for them as they arrive can ease their impact on everybody. You don't make overnight shifts from coal to solar. But, you do need to understand where you are going, and how to get there with the least pain, and the greatest overall efficiency for everyone involved.

  • 1. What George Jetson might have been getting paid for!" Current systems like this involve practice on things like shutting down the exchange, or firing nuclear weapons. Neither of which is done casually without a lot of thought and practice (modeling), and both of which cause (potentially? duh! major) disruptions. There are lots of examples. Like aborting the Challenger launch. The list will get bigger than it already is. "Stop the technology (presses) from doing what it's about to do, it ain't a good idea! said the human in command. George is well worth what he gets paid."
  • 2. Siri's 'next gen?'

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.