Architected Futures™

Tools and strategies ... for boiling the ocean

Introduction to Architected Futures

EATS ArchitectureThanks for Dropping By

Hi! My name is Joe Van Steen. I'm a "retired" systems architect, a computer programmer, a modeler, and a futurist. Previously, this website served as my personal blog and notebook. Most of the web content was flagged as "internal" or "restricted;" and the majority of what is now on the web wasn't on the website, but was in various documents on my desktop computer. Now, as of January 1, 2017, I wanted to "open the content" of the website to enable peer review, and to enable collaboration and further review on future development efforts.

The website content is focused around the architecture and implementation of some software I have been developing, which I call EATS. EATS is a modeling tool. The website is fundamentally a prototype web client interaction component for EATS. That means that everything you are reading and seeing should be coming from EATS. Today that isn't true. What you are seeing is coming from a Drupal database. I have had a series of these "web experiments" since I started Architected Futures in 2005. This one uses Drupal, a very small amount of my own PHP code, and a variety of generic Drupal "plug-in" modules. It serves as an operational, functional model of a capability set that I want to program into EATS, in Java and metadata models. EATS is built on Eclipse, using Java. (Test new version of the Architectured Futures web facility.)

If you click any of the pictures, you should be able to expand them, so you can read them better. In the picture above this website sits in the blue box labeled Presentation Management, as a form of "web client interaction management" system. It provides the interface between you, as my web client reader, and the content in the website database, essentially the stuff you are reading.

AIR RepositoryThe core of EATS is content and Content Management. In the Architecture Information Repository  (AIR). That's in yellow on the right in the diagram. That's where the system narrative lies. Just like this website, content can be internal or external. EATS is more concerned with relationships than with detail content. If EATS "knows about it" or "can find it," if and when needed, that is often sufficient. What EATS considers of greater importance is the semantics of the relationship to the content. What does it mean? Why is it connected?

EATS has its own modeling scheme for content, which maps to W3C concepts about ontologies. (A mechanism for defining meaning and the significance of relationships.) But using my own "encoding" schemes. What EATS, in its various incarnations, has always lacked is a good user interface, a good scheme for interactive engagement with the content and the models. I've spent a lot of time struggling with that, but I think I'm getting closer to what I've wanted. Something that makes sense for a non-programmer. 

EATS and Architected Futures define the current state in a series of a thought experiments on the part of the author, trying to be integrated into a cohesive whole. Some of it is working out, other parts need (a lot) more work.

  • The part that is working out, at least for me, is the software evolution.
  • The part that needs some work is ... determining what value its evolving capabilities have for others, and assuming value, how to proceed with its development, in order for that value to be realized.

I very much appreciate any seriously intentioned comments or suggestions. It would also be helpful if you used the Contact Form if you would like to engage further. I would appreciate hearing your level of interest, area(s) of interest, ideas, opinions, suggestions and contact information for follow-up. Please also mention any confidentiality you may wish honored with respect to any comments you provide.

Navigation

This is an open architecture, open notebook site now. At this point, you can look at EATS in a number of ways:

  1. Visit content in the EATS Library. An architect's view. The primary components are:
    1. The EATS Blueprint. Layered descriptions, defining context, the concept, logical organization and technical overviews..
    2. The Viewpoint Library.  Stakeholder views and models.
  2. Interact with other fundamental features of this website. Read the glossary, tool catalog, bibliography, blog, etc. There's some functionality there. This is an evolving "user" view. But the content is currently limited and it tends to fold into the technical material about EATS that are extensions of the Blueprint. (Use the menus and links) What's missing here, currently, is an interactive model user's view. That's the next target plateau for the platform.
  3. If you are into "code," you can look at the v1.0.9 prototype DOxygen documentation. A developer view.
  4. The Request for Evaluation link will take you a "project" view.
  5. Use Case History tries to present an "information encyclopedia" user utility viewpoint.
  6. The Vision Statement has a quality management view and describes my vision for the tool.

Ultimately the primary organization of the website is around the library, and the primary book in the library is the EATS Blueprint. For a full "view" of the concepts and thrust of the website, I suggest scanning, skimming and sometimes reading portions of the Blueprint. The viewpoint Library is a form of appendix to the blueprint, a form of supplement. Some of the links above are "dives" into specific library content. If they interest you, you need to review the Blueprint for contextual understanding.

Caveat Emptor: The Blueprint and related materials were originally written and structured as a set of keystone documents around what was to be a commercial endeavor. That "endeavor" has been abandoned, but the writing has not been edited to remove that viewpoint from the text.

Those that want additional background should keep reading. Those who want to "dig in" to content should us one of the approaches mentioned above.

Navigation note: A lot of content on this website uses a "book" organization scheme. This is true for the library material. For those elements, look to the column on the far right of the page to find a Book Navigation block. You should see a form of Table of Content opened to the section for the page you are reading. You can navigate in the book by using the links in the Book Navigation block.

Book pages also have links at the bottom of each page. Near the right and left bottom corners, there are page references for the next and previous pages, to allow forward and backward scanning. If a page is a "group" and has a set of "fan out" sub parts (chapters, sections, etc.) the list of those elements should appear at the bottom as links, to allow you to go to a particular element directly.

 

What follows are "thoughts" about EATS, grouped into some subject headings. It's yet another way to survey a set of perspectives concerning EATS. Different ways of looking at it, or talking about it.

Content Authoring

I get a fourth view, an author view. Ideally, in the vision, everyone should have the ability to have an author view. Exercising it is optional. Currently it's limited to comments. But, ideally, since conceptually EATS is a modeling tool suite, every real "user" of the system should be able to author their own models. In that regard, it's a version of InsightMaker1.

Believe me, right now; you don't want my kind of author view. The tool set is terrible. I have a whole lot of "good" tools on my workstation. One is good at this. One is good at that. A different one is good at something else. Office suites made a lot of money integrating that stuff when PCs first became popular. (I go back to Hollerith cards.) But, to develop and maintain code, for multiple platforms, and to try to maintain documentation, and exercise models, do a QFD, construct a website, and do routine maintenance; you end up using a lot of tools that don't talk to each other.  It then gets worse, when the same ideas need to get documented, essentially the same way, in multiple places (i.e., tool frameworks). 

What I'm "synchronizing" across all of those tools and environments is various views of "EATS." And, I'm trying to use EATS to document EATS, as a sample of an "Element" content. (Element is my generic name for system.) I'm using EATS, as a system architecture modeling tool, to document the system architecture for EATS, more or less as a test case, defining it's current capabilities and potentials. (It gets recursive, and complex. But that's what all of the other stuff on the site is about.)

Currently this website is written using PHP and Drupal. And it runs on a totally separate database than EATS (which is a Java system). But the kinds of things you can do on a website, the generic interaction set, are anticipated to be coded into the EATS Presentation space largely using metadata and generic code. At that point the web authoring issues go away, and overhead associated with synchronization gets minimized because the architecture can be joined. (If Drupal is still used, it would only be a sample "presentation glass" for access2 to an EATS function set.)

Because the EATS database and the Drupal environment are separate, and I work alone right now3, with largely online interactions around EATS related subjects. 

Some content on this site is written in what seems a frivolous, or haphazard manner. I thought I could get away with combining 2, 3, or more trains of thought in a paragraph. I was wrong. Especially if that paragraph was meant to be read by others. Sometimes I played with punctuation to "leave tracks" that an automated parser could use to help separate stuff later; but I doubt that that worked either. But a manual edit process will work, and the page count isn't to high yet. (My other option, is to try to have Watson read it. As a kind of Turing test?) So, a lot of edit and re-write will be in my 2017 plans. (If you see pages with strikeout text, you may want to just skip it. Or, read it, your choice. There's other stuff to read. I'm going to try to point out the focal pages, where I'd really appreciate any "first draft" feedback. If you want to go past those pages and wander. Then you'll probably find "weird prose" that doesn't have strikeout text. You might want to bail on that too.

Context (January, 2017)

I'm trying to prepare this web site for review by some invited people, with whom I've had varying degrees of dialog at the tail-end of 2016.  I've set a self-imposed deadline of EOY to be "done" and ready for publication. For review, of a final draft, of an iteration. You are reading where I arrived at my deadline. 

I started this effort a little over 10 years ago, when I "retired" from BofA. Each of these dates, my retirement date, the publication date, along with an optional set of others, can be viewed as "Event Horizon" points-in-time on a pathway. Causes concentrate inward on a focal point, the date, and effects distribute outward after the event occurs. I can line up a series of these dates to analyze, from a thinking perspective, how certain things in the past can be defined by relationships with other things, that cascaded on yet other things, leads to here and now, and me writing this, and you reading it, in your own "now." If you try to draw it out, it goes from 2 points to a lot of points really fast. Too fast to keep track of a lot of it in your head, if you're a human; and too fast for computers to be able to really make sense of it either. Which is, or can be, a problem; because ... I'm getting ahead of myself.

I'm publishing this for anybody and everybody that want's to take the time to read it. I appreciate you being here, for however long you decide to stay, or however many times you may choose to come back. Except for spammers. I don't appreciate spammers, or hackers, or that whole ilk. FYI: There ain't much to hack. It's all open and free. Just read it. The code is, or will be, or can be, all open source, based on other open source. The ideas are all open source, based on "open knowledge" published all over the place. It's in public libraries. And my add-ons, or mash-ups, are what you see here. They're free. I go out of my way to "ban" hackers not because there's anything to hide, but you guys create maintenance head-aches. Like rodents that chew holes in walls. You're not welcome.

Modeling support for systems thinking?

Back to the subject. The images below are of the Earth's magnetosphere. They are visualizations of models of something we can not "see" with our eyes. [I need to find a way to encode attribution. Some are NASA. I'm not sure who authored the others. Maybe NASA, but are sourced on web pages with Arabic characters in the names. I found them with a Google search of magnetosphere, then using the images tab.]

Perspectives of the Earth's Magnetosphere

NASA Drawing of Earth's Magnetosphere

The reason I included these images is that, for me, they visualize in a beautiful way, how the interaction between systems looks. We used to, and still do, look at "relationship maps" with grids, tables, and spreadsheet mechanisms. Today you also see a lot of network maps showing various topologies of interconnections between nodes. Those maps have some utility, as do the various domain language models drawn in UML and other languages. But they lack completeness. They slice a dimensional view through a model of a system. But they don't show a lot of other stuff in order show you some structural aspect. In building architecture, they are like plans, elevations and details. They don't really convey the building as a complete idea. To do that, architects draw perspectives and build small scale models. (And today, I believe they also do VR studies.) I think that we might appreciate systems and systems thinking better if we had better ways of seeing them, and seeing how they interrelate.

[7/6/2017 JVS edit: See Splash! by Creative Learning Exchange. I think it will be a good tool for the general public, not just k-12. Good STEM K-12 educational tools also work as tutorial material for anyone else who may need to be educated in the subject matter in order to understand the new economy, or the new world we all now live in. Made available online, by foundations, they also becomes boot-strapping tools that can be used to gain entry into new technologies and new fields of knowledge.]

The image set of the Earth's magnetosphere, somehow, to me, shows completeness of the system it is describing. It conveys what is going on with the magnetosphere and how it interacts with it's ambient medium (its environment). To me, modeling a system "from the top down" requires an understanding of "completeness." Most of the time, you fake it. Because there are a whole lot of environmental factors that you don't know about. So you model with "assumptions." But, if you maintain your models4, and iterate, and fill in assumptions (which is a never ending job), better pictures of completeness emerge, and the models become more useful.

My other thought was to try to approach this from a philosophical framing, like Yin and Yang Theory. But it's easier to visualize, and maybe explain, using magnetosphere. I think both apply, but magnetosphere is better for an "engineering" viewpoint. Another way "in" to this web site is to get a copy of Derek and Laura Cabrera's book: Systems Thinking Made Simple5, or, any book on systems thinking [Google "systems thinking book"].

When I "retired" I just kept working. More or less along the same thinking pathways that I had been traveling before I retired. (I was lucky enough to have had a career working with my brain, as a "knowledge worker," doing things I enjoyed. And the abstract thinking paths I had followed during my employed career, were pathways that I was now free to follow on my own. I just wasn't getting paid to solve specific, other directed, financial systems problem sets anymore. If I could afford it, I could self-direct. I could, so I did. And, Architected Futures is what came out of that.

Architected Futures

Two quotes I wrote down, a while ago as I was starting this:

You can have the best technology in the world, but if you don’t have a community who wants to use it and who are excited about it, then it has no purpose.

Chris Hughes: Facebook Co-founder

The number of people who are willing to start something is smaller, much smaller, than the number of people who are willing to contribute once someone else starts something.

Clay Shirky: Here Comes Everybody, Penguin Books, 2008 pg 239

I'm not sure how "universal" those are as "truths," but they seem to make some sense. Sense-making is an important frontier in thinking about things. I've been thinking and trying to "make sense" of a lot of things for as far back as I can remember. Architected Futures is my way of explaining what I've come up with, and sharing some tools I use to help me do it. Most are borrowed tools, from others. But I also see myself as a blacksmith of sorts with computer systems. I craft my own tools some times using available IT as my forge. So I'm also sharing my software. (Most of it is in Java, and should run on anything with a JVM. It can then be configured to run standalone, or it can be configured to operate as a part of an EATS network. Networks can be configured in arbitrary arrangements of a private or public nature.)

Sensemaking and situational awareness are viewed as working concepts that enable us to investigate and improve the interaction between people and information technology. Within this perspective, it is recognized that humans play a significant role in adapting and responding to unexpected or unknown situations, as well as recognized situations.

Wikipedia: Sensemaking

So, what is Architected Futures? AF started a little over 10 years ago as a concept for a business. A methodology, and a software suite to support it, to promote better ways to architect IT within enterprises. That was then, this is now ... What I'm parsing:

I'm a retired systems engineer, with an ongoing interest in the architectural engineering of systems. I want to expand my knowledge and awareness of how to do that using best practices, and pass along what I learn.

  • I'm not a researcher, or a consultant. I've just "had a lot of practice" and people seemed to think, most of the time, that I knew what I was doing. The same might be true about the EATS framework. But it's just a start along a pathway, for a task.
  • Architected Futures is a potential pathway to shared learning
  • Architected Futures is a way to test my understanding of what I'm sensing about where "we" are, and where "we" are going. And pass along my ideas of what I learn.

Architected Futures is an approach, my approach, a methodology, for investigation and problem solving, on a multi-dimensional, polarity aware basis. It is a way to attack problems through pattern modeling. It involves ideas around multiplexing and demultiplexing of concepts. It is about reasoning from fundamental principles. It is a version of "pragmatic architectural engineering." It can be accomplished with "open" tools [techniques, processes, mechanics] freely available in cyberspace. 

Architected Futures vision is a method for using systems thinking and augmented intelligence to demultiplex polarities of concern about where we are, where we want to be, and how to get there. (Using modeling for steering and guidance.)

Architected Futures is my way to invite dialog on my ideas, and to share my tools. (FYI: EATS V4.6.1 is in the shop. I think there is a v4.5.x around if somebody really had to have one. But, I'm thinking more now about shared building of a v4.7.x as a better target.)

Modeling as a Problem Solving Strategy

Architected Futures is one face of what I am trying to construct as a tool to help me "augment" my intelligence. To be able to model my environment as it is, and to be able to, with reasonable accuracy, model one or more future versions of how I would like my environment, or my grandson's environment to turn out. Partly out of curiosity, partly because navigation helps. And, partly because I'm a Sci-Fi fan. As an architect, if I start to construct a hypothetically achievable realization in a model, I start becoming interested in pathways to move from here to there. More models and modeling. I sense that doing this type of activity is going to be bigger and bigger business in the future. It's very STEM. We do a lot of it now, at least in the more scientifically advanced countries. We model plastics, drugs, genomes, air planes, boats, America's Cup yachts, food additives, car engines, social relationships, product placement, and the list goes on. It requires a trainable skill set, but looks to be a valuable way to potentially employ the entire human race. Maybe, by 3535, or sooner. 

We [people, humans] do a lot of modeling these days. We model a lot of things. And, we're getting better and better at very specific stuff. But that old cliche, about the forest and the trees; most of you guys have been focusing on a wide variety of trees. Some people, including myself, have been focusing on forests. Actually I've done a lot of forests and trees simultaneously in my career. Usually, I get paid for modeling one or more trees. But my "style" is to model the forest instead, as a way of "seeing" or "looking at" the trees, and then apply what I see to the one or more specific trees. That's my secret in a nutshell. 

That has a couple of "patterns" in it. Patterns are generalizations, but they are generalizations that occur in "regular" configurations. You can buy books of patterns. You can fill a book shelf, a large shelf, with books of, and book about patterns. Patterns are a big business. In the details of this site, you can see my ideas about patterns, and you can see some patterns that I use in my thinking. A lot of them are shared patterns that most "pattern aware" people use in problem solving. Some are ones that I made up, to "document" my thoughts. Patterns are like blue prints or shop drawings. They tend to detail out how something is constructed. Modern "pattern" documentation also includes other information. Problem resolution guides are useful. Diagnostic tools follow patterns. Help "manuals" follow patterns. Templates and forms are patterns. Commoditized products are variations on patterns. Generic drugs are patterns.

  • Some of us spend our time putting patterns together to make special patterns for special tasks (multiplexing, trees, what I refer to as "verticals")
  • Problem solving involves pattern recognition in complex arrangements (forests, "systems"), and then isolating more fundamental patterns from the composite jumble (demultiplexing) for solution.
  • The more regular (conforming to appearance of "typical" size, shape, color, behavior, function, etc.) the pattern is, the easier it is to isolate. And thus, the easier to model, manage quality, and solve problems with targeting and replaceable components.
  • The more irregular the pattern, or less frequent occurrences, the harder to identify and isolate. Modeling becomes harder, and less certain. But it can be even more important as a discovery tool, for humans, to tackle the "unsolved" problem set.
  • Forestry is, in my head, about using knowledge of the general pattern of patterns of trees, to manage the whole of the forest; and then using that same knowledge to isolate and deal with the irregular exceptions, for the benefit of the whole of the forest.
  • Patterns, accurately identified, are very powerful for problem solving, and for forecasting. Being able to handle regularity, across a scale range,  and accurately predict variations, and trends, are keys to efficiency and productivity (think Six Sigma).
  • Patterns are generics. Generics are models. Generic models of  models are Metamodels.

The "secret" is integrated thinking of the problem set from both viewpoints, the forest and the trees, and solving the problem from the perspective of the forest. More trees achieve satisfaction that way. That requires dealing with metamodels.

EATS Metamodel LayersModels of Metamodels

Model-driven architecture (MDA) has been evolving over a long time period in both building architecture and software architecture. Models, models of models, and models of models of models. And cascades and recursion of models. The Object Management Group's (OMG) Meta-Object Facility was designed to deal with issues realted to model cascades.  

Meta-Object Facility (MOF)

In the EATS Architecture the MOF concept, shown in the diagram to the right, is as a fully generic implementation of the OMG defined pattern. The top 4 layers of the diagram define the types of content in the EATS repository that define the "model" of the system. The bottom layer, M0, defines the objects in the system being modeled: people, processes, physical objects, concepts, etc.

At the bottom MOF layer, M1.0, we define models of "things," which we call Elements, as sets of specifications in a consistent scheme. Everything that EATS "knows about" is defined as an Element. Elements can be anything, physical or conceptual. Every one is unique and defines an instance of whatever it is. The definition provided for the item defines what EATS knows about it. If all EATS knows is an identifier, then it knows that there was cause to create an entry, but the all memory of the entry has been deleted. If a current or historical specification document, an AIR Document, exists keyed by the identity value, the GUID, then EATS will know what type of element it is or was, name, author, content, possible relationships, etc. Elements are unique instances, but they can represent populations or individuals. They are also able to be viewed as "agents" with personalities in a modeled environment, and they may have populations of arbitrary size.

The M1.1 layer in the diagram is defined by EATS Element Types. Every element defined in the M1.0 layer is specified in terms of some M1.1 layer Element Type.  (Core element types are "hard coded" within the EATS infrastructure models.) The Element Types define the metamodels for the M1.0 elements. (The M1.1 element defines that a "Person" has a "Name." A person, defined at the M1.0 level, representing a real person named "Sam," would be expected to have a "Name" property with the value "Sam."

The M1.2 layer in the diagram is defined by EATS Class Types. All Element Types, defined in M1.1, are members of some structural composition hierarchy defined by an EATS Class. Classes form a structural taxonomy. The class taxonomy defines the nature of the structural elements that EATS is aware of and knows how to manage.

The M1.3 layer at the top of the diagram defines the EATS Core Metamodel. This is the foundation model for managing the content in the other layers.

EATS provides foundation models in all of these layers that implement core concepts of information processing, including aspects of model management and process management using model guidance. EATS is also designed for extension using object-oriented techniques. This allows the EATS capabilities to be "inherited" by user-defined elements. 

  • Every element has a unique ID, and an immutable type. After that, we have lots of ways to apply attributes, a lot of which are able to be applied by class inheritance. Which makes it easier to code up and maintain models.
  • This gives us the framework to use these elements in a "routine" modeling scenario, based on the modeling concepts that have been programmed into the tool. Agent-based Modeling, Systems Dynamics, Monte Carlo, etc. 
  • If we climb this cascade, we can "weave" modeling techniques to create a model that uses multiple techniques with the same base elements.

There is an orthogonal view to this as viewed by the MOF. While you were "climbing the cascade" in the "subject model" you were staying pretty much on the same level in the MOF. These two different views, along separate axes, with orthogonal views of the same "space" is dimensioning starting to happen. To move up a level in the MOF, we might look at the general model that you are using to specify and run the models. Whether the environment is implemented as a specific variant, or an abstract variant of a "model execution environment." It it's an abstract variant execution environment, how many variants can it run? How robust is it? Now we are talking about abstracts on both the model subjects space dimension, and on the modeling capabilities dimension.

As you climb the MOF model you build and abstract frameworks, for building abstract execution environments, for modeling abstract models, using various very generic, parameter driven technologies. Current technology supports the bottom level processes, for some subjects, to be "dynamically generated code." That is not what I'm currently doing in EATS, but it's an option. There is real world software using those techniques, or so I believe. I'm not sure of volume, or the mission critical nature of the code. (People have reasons for wanting to, or needing to, hand-craft software. But, we've also "generated" code for a long time now.) This becomes a very powerful leverage scheme for building and maintaining models.

AF System ModelGeneric, Semantic Models of Systems

The modeling metamodel that I've created in EATS is currently a "vertical" model for content management. It uses an RDF-like semantic relational statement to define element assemblies and relationships that are used to define systems of things. In EATS v4.5 these are "static" relationships. They have a state, like an entry in Wikipedia. They can be assembled as models, and inspected. Elements can be changed, which may impact the specifications of other elements, but then, after the changes are made, the model is again "static," or what I sometimes call "flat." This is a standard "encyclopedia" view, or dictionary view, or catalog view. In EATS v4.6.1 I am (read was) in the process of implementing dynamic modeling. But that's a work in process. I'm looking very closely at Ascape as a Java, ABM code library to incorporate to help with that effort. It seems to have an architecture that will fit well with other EATS code patterns.

EATS semantics are all defined in simple RDF-like triples as GUID-GUID-GUID (subject, semantic relationship, object) relational models. All semantics are Subject (Object Actor doing action), Predicate (Relationship or action performed), Object (Entity acted on). The intention is to adopt the RDF and OWL vocabularies, along with any number of other ontologies through mapping, But then map them in the metadata using EATS GUIDs (as IsA or InstanceOf relations) so that translation is not a user concern. By adopting a requirement for ontology set management  in the metadata space. The good thing is that this pro-rates across the "field model" set since the same metadata is reused across whatever "applications" are built. "Dogs bark." So Collies and Pugs can be modeled as dogs and not worry about how that happens, whether it's considered good or bad, or issues about noise ordinances.  But, they might, or might not, chose to use volume controls. The semantic features n the infrastructure also allow models to incorporate reasoning in a generic way. (Jena has been tested as an integrated unit.) 

System Cascades

Systems Thinking causes us, me anyway, to think in terms of cascades. Systems, inside systems, inside systems, nested to some semi-arbitrary depth. Within EATS, my current approach is this. 

  • Every element is potentially a system. If no component elements have been identified, the element is considered atomic. Indivisible, as known to the system. If some process calls on it to have components, that would be an error, or some form of diagnostic. You, the element, are of a type which should have a "living will" and an "accounting plan." You have neither, yet you are in the population. Uncertainty about results increases, human attention may be required. Other wise, you're benign. You may get called out in an audit. You're usable as a generic "leaf" node component in somebody else's context.
  • At any stage of analysis, a "system has a boundary." The specification of that contextual space defines the system, as known to the modeling environment. Boundary conditions can change through the life of a model, but the concept of the system, and it's boundary conditions, does not change. That whole conceptual arrangement, is defined by an element, that has is subtype of a system type. That identity is distinct from the identity of any of the elements in the system specification. But, any and all references to the system, are made through that elements GUID, which, for modeling purposes, is the system. Specifications ties to the GUID define state, context, components, behaviors, policies, stewardship, governance, etc., etc.
  • Systems are elements, like any other element. They can be components of other systems, They can define contexts for other systems.
  • Contextual relationship cascades can overlap, these are what I define as modeling dimensions. A person can appear as a persona in the model database. That same persona can be used in multiple models. There can be a family model where the persona is a child to a mother and father, has siblings, marries, has children, etc. In "another model" using a different dimension the persona is an employee, or an employer, is a farmer or a machinist. These are two verticals. With the EATS architecture, the intention is to be able to generically use the same persona specification in both models simultaneously, or serially, or independently. For all types of entities. For all types of models. Which provides for the modeler a lot of fine, or course, grain variety variables. (Some of this reflects approaches I was beginning to implement with some of our Six Sigma exercises before I retired.)

Direction - VSM Model Management

Given the architecture of the framework, my design work sees the implementation of a VSM "management" dimension as a "natural" extension. Fundamentally, I see this as bringing the MOF out of the "construction management space" and into the "management management space" in a cascade of management models. In simplified form, I see Beer's VSM model as an implementation pattern for a kind of MOF, using levels of management models, which at their leaf nodes, manage non-management models.

Fields of Study - Subjects

All, or most, of the above discusses the how of the modeling process. Cool tools.  Orthogonal to that is the subject of what is being modeled. There are generic pattern sets available here also, although some standard patterns are easier to adapt as almost "plug-in" models for a generic engine like we have explained above. One extensive collection is Hartmut Bossel's System Zoo series. These are sets are reasonably well defined, standardized system dynamics models arranged in subject oriented categories. Initial verification of the EATS modeling infrastructure for systems dynamics models will be to code the same models into EATS, bootstrapped form the System Zoo, and then calibrate the EATS code against the results in the System Zoo library. The same techniques can be used to calibrate model cascades where simple models are used as components of more complex models.

An alternate source of bootstrap material in the subject space are open source ontologies. Ideally, within EATS, most model specifications should be accomplished in metadata. For the System Zoo, we need to reverse engineer the metadata out of the detail models in the zoo. Stella may not care what a Horse is and how it differs from a Car, but EATS does. EATS runs on the basis of semantic awareness. When we load an ontology, we load semantic awareness of abstract object sets.

This immediately lets us do reasoning with "static" semantics. The ontology is the model. We just need to frame the questions. We have no uniform upper level ontology, so there are conflicts between ontologies. My approach to this is to embrace variety. As is the case in the real world, different ontologies are more useful with certain problem sets. Given the MOF architecture, "what ontology would you like" can become a "system context" attribute. Model A runs using Sowa, Model B runs using Basic Formal Ontology. Both Sowa and Basic Formal Ontology are defined using their specification codes as EATS Architected Content. GUIDs and types and instances of types. Running Model C, which includes both Model A and Model B as components, can be accomplished thru GUID mapping of those elements that map not already have common ancestry. This kind of mapping can reap its own rewards as an analysis technique when comparing or contrasting modeled systems, when problem solving, or when looking for synergistic opportunities. If common ontologies are used by two systems being evaluated, the benefits are accrued at an even greater efficiency. Since human intervention is not required to reconcile semantic discrepancies,  automation can do more of the task, asking for help mainly on exception conditions. Augmented intelligence.

Communities

Ultimately, in one way or another, all the models related to people. If nothing else, models are a way for us to define and agree on an external, objective statement, defining a concept that we have i our head. If you can agree, and I can agree, that our mutual objective statement is a complete and correct version of what we think we have in our head, we can debate it's relative merits. Or, first, we can debate how it needs to change to become a complete and correct statement of what both of have, at the same time, as a concept, so we can understand each other, before we debate things we don't understand completely.

Architected Futures is concerned with architectures for us to get together, because two heads are better than one. Then we can get a calculator or computer to crunch the numbers, and then we should be able to hammer some real "fix it" nails in some problems. The basic framework here is the idea of levels of engagement. My generic definitions, which apply to AF, but could be used as a "involvement grade scale dimension" for other models, is, or includes:

  • A Community of Practice (CoP), interactions involving a form of active engagement.
  • A Community of Interest (CoI), regular interaction of a monitoring and/or browsing interest
  • Community interest, irregular and/or incidental interest by others than known individuals
  • Lack of Interest, everyone else

People in favor can be considered "plus" with degrees, people opposed can be coded as "minus" with degrees, and neutrals are 0. This applies a polarity vector to the dimension for determining conflict or agreement, or political alignment in models, etc.

Communities can be mapped and modeled at the CoP and CoI levels, cross indexed by, hypothetically, any algorithmically definable index. And these groups can be extended as a taxonomy in the EATS Metamodel to further sharpen reasoner facilities within this set as a high level model for defining element interactions in EATS6. The idea is to be able to use this as a population structure layering capability in an extended System Zoo of modeling capability. Coding is done on a sparse basis. The tendency is to assign values in metadata, and then, if needed, override at lower levels of a hierarchy using an object oriented modeling pattern.

Communities exist in AF in two forms (1) as personas in agent-based models as described above, and (2) as a potential community of real people, i.e., you the readers of what I'm writing. (Like Jules Verne fans? Some times it seems like Jules Verne writing.) My plan is to address (2) as an issue when it happens. I think some of you will be interested; but you've all got lives, and other interests, too. So, we'll deal with that later, when we have better awareness of your interest levels.

Current State

I've been working on Architected Futures as a one-man-band since 2005. The early focus was on creating a software tool as a business product. A lot of documentation you see here dates from that period. Originally I was looking for some other tool, a web CMS (Content Management System), that could host my architecture management software, as a component. But, the more I looked, and tried, the less satisfied I was. So I had to refocus and create a proper infrastructure to support what I wanted to do.

In 2016 my infrastructure development finally got me back to a point very close to where I wanted to be, with a framework for building the architecture specification and management tool that I was originally looking to build. And my concepts about the architecture tool have grown along the way. In the summer of 2016, as I began my latest revision of EATS, I could see a lot of convergence, and emergence of potential utility beyond what I had previously envisioned. So, I started an effort to update this website with information about what I am doing and how I am doing it so I can share it with others and gain insight from their perspectives of the work product. That is what you are reading now.

The level at which I talk about Architected Futures and EATS throughout this web site, is reflective of where it is in my head as I release this. I see a lot of potential, and the hazy parts around how to do it, how to make it happen (the stuff I'm discussing), is reasonably clear in my head. But it's also evolving and churning as I write and as it cooks. Trying to explain yourself, myself, to others has always had a certain clarifying exercise for me as the speaker. Half of debugging code is explaining the problem to someone else. Then, sometimes without conversation, you can go back and code the solution. Sometimes.

After what's in my head, theres the matter of documenting it, so it can be worked on and used; assuming a level of interest. When I work by myself I have a very different pattern than when you work on a team. And team size matters. Which is why somewhere out there I said something about 35 max. And that was supposed to be hyperbole. But, even when I work by myself, I produce documentation. This website is documentation, in a number of forms.

I've also assembled a set of various files which are available for download, depending on what your interests are. Caveat Emptor and all that. Like most research, all documentation is out of date before it gets written. Some is more out of date than others. 

I've tried to include diagrams of relevant design models. Some are obviously in transition, as is the code that they reflect. Trying to explain state in more detail would require a specific inquiry on your part. My world is chaordic.

 

  • 1. Scott or Gene, if you are reading, please let me know.
  • 2. At that point, Drupal could still do a lot for someone other than me. The purpose of the statement was to identify that Architected Futures would no longer be dependent on Drupal tools to maintain the website. If there was interest, Drupal-EATS interactions could be used to develop whatever combined facilities the Drupalistas might dream up. EATS would be just another "back-end" system.
  • 3. I live in Berkeley. I don't commute. I work on stuff that I choose.
  • 4. This is one big bugaboo. Which is the reason for all my "talk" about user interface in various ways and places. My solution approach is "normalization" and layered modeling, the MOF.
  • 5. The framework described in the Cabrera book, DSRP, is one "tool" we will be referring to in various places in this web site.
  • 6. I make this sound easy. It's not. But it is doable. And, it's a very valuable job with a valuable when done right. And, it's work. Mental work. People called "analysts" do this stuff. Subject matter expert analysts. Doing it for Chemistry, Physics, animals, vegetables and minerals is hard. Doing it for people stuff is harder.

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.
SystemsThinking