Architected Futures™ could be viewed as a version of "The Matrix" that's benevolent, and can be used to to solve and manage wicked problems. The approach works for a wide assortment of problems, of any size. It works better and its more effective when it's used collaboratively. So I want to share it with as many people as possible. Everybody on the planet. Well, most of the people on the planet. That would be cool. So, its free. Well, at least it doesn't cost money. Think of it as an app for your phone, which is exactly how parts of it will be implemented. Would you like to have one?
Does that sound better than: a collaborative problem solving method and tool suite that frames a way of thinking and managing circumstances; and that generates highly accurate and precise solutions to complex problems; a tool to help solve a problem or get a job done, and keep it done; a tool and process to keep the solution running effectively; and to manage phase out and replacement in a manner that has minimal impact on everyone's ability to enjoy life. A tool that's a Swiss Army knife for managing the planet?
Both are true. On'es a little more Sci-Fi and fantastical. The other is more geeky. One is Star Trek. One is, well, head-on complicated. It should make your head hurt to just read that second paragraph. It certainly makes me slow down, and I wrote it! Architected Futures™ is a Yin Yang kind of place.
Architected Futures™ is a technology originally developed by as a personal tool to help solve architecture problems. And I've used then current versions for over 35 years to solve and manage some big problems for a major financial institution (Bank of America); and I was paid pretty well because of my successes. I've been using increasingly sophisticated versions of the technology for the last 45+ years, the last 10 as a semi-retired software researcher. And I've finally figured how to put the finishing touches on the architectural design, to make the magic happen.
The newest version will be Architected Futures™ is about using architectural engineering methods to manage the evolution of future environments. It's about systems for managing and analyzing information about systems.used for a variety of purposes, given a little training. to pursue, develop and invite comment on a series of ideas involving futurism, architecture, sustainability, business planning and engineering, systems engineering, information technologies and related concepts. Concepts related to where we are going, and how we are going to get there. It's open. It's free. And, you're invited to join us in the dialog. Share your issues and concerns. Or just lurk for a while by subscribing to one or more of our feeds. Discover our thoughts, experiences, strategies and directions. Maybe you'll want to engage later.
- It is about the future: envisioning a conceptual model of what it should be, planning a path toward its achievement and providing a scheme to manage its evolution.
- It is about architecture and engineering and systems thinking as practices and disciplines to go about those tasks in an orderly manner.
- It is about the Element Architecture Tool Suite (EATS) framework as a tool-set to help architects, engineers and related stakeholders envision, build and manage the conceptual frameworks and information sets involved in that process.
- It is about documentation, data mining, modeling, software engineering, IT, Six Sigma and a variety of other tools and technologies as components within the tool suite.
- It is about the various subject domains for which the futuristic forecasting, visioning and planning is desired to be accomplished.
- It is about Communities of Practice as an interdisciplinary technique to pursue these concepts.
The Extended Narrative
Most of the concepts documented here are extensions in various forms of ideas, musings and work efforts engaged over the course of a 40+ year career working in information processing. Some go back earlier than that. (See this short biographical note on my architectedfutures.info blog.)
On my retirement from Bank of America I thought of pursuing these concepts toward the development of a proprietary, commercial software product. As I pursued that goal my understanding of the task, my motivation, and my methods evolved. The task, which sometimes sounds so simple, is enormous. I knew that up front. That's part of what appeals to me. From certain views it is extremely simple, or so it seems. From other views the scale and the complexity of the inter-relationships between some of the elements becomes more evident and the enormity of the task becomes almost overwhelming. (One reason for the subtitle: Boiling the ocean ...)
As I mentioned, my motivations and methods have evolved. Profit in some form is still a motive (hey, I'm human and who doesn't like nice things). However, maximizing my personal financial gain was never the core driver. In a lot of ways I am becoming much more interested in the evolution of the concepts, seeing them implemented in a meaningful way, and put to use helping real people solve real (complex) problems. I don't personally want to focus on marketing, but finding a way to have the endeavor pay for itself is still a concern. And, in the meantime, my horizons have broadened. Both in terms of seeing potential applications for the work, and in the advancement of available tools and techniques to help in solving some of the related technical issues. With that in mind I've created this site, architectedfutures.net, to open and share my journey with others. The site consists of information that falls into one or more of the concept groupings presented below.
At its inception, the site provides a place for me to document and share my own ideas and work in these areas. A blog of sorts, with a complex organization. Also, a public notebook exposing my thoughts and activities on these matters for review and comment by others. Over time, if there is interest, I would like to make this more of a community exercise rather than a personal effort. If the topics interest you, feel free to comment. If you want to engage in a deeper way, please use the contact form and tell me your thoughts.
For me, it all started with futurism. This is sometimes referred to as futurology or future studies. The concept of envisioning some future evolved state of affairs, and then postulating hypotheses about how to achieve that state. Where are we going, and how do we get there? It starts with vision. Then it moves to strategy and engineering.
I studied architecture, of the buildings and city planning type, for a while in college. And that sort of architecture would be very interesting to include as a subject domain. But in the context of this site I'm talking in a much more general sense. There is architecture to buildings, towns and cities, which focuses on space, light, flow and similar elements. But there is also architecture to software systems, planes, trains and automobiles. There is architecture to social systems and governments. There is architecture to biological systems and business enterprises. There is architecture to all composite systems, where the parts act together as a synergistic whole. Architecture is the manner in which the relationships and parts of a system, the functions and features and the manner of their interrelationships, are selected and choreographed to achieve utility, durability and delight to the stakeholders of the system.
As we move from vision to strategy and engineering in terms of our hypothesized futures, architectural engineering is a critical element in arriving at achievable results which persist and provide long-term, sustainable satisfaction.
Systems and Systems Thinking
Systems in the sense that I talk about them here is not limited to computer systems. I take a broad engineering view. My definition is:
A system is a concept describing a coherently organized arrangement of related elements with emergent properties not found in any subset of those elements and which collectively is defined by its function or purpose in a larger system of which it is a part.
A system is a set of elements or parts that is coherently organized and interconnected in a pattern or structure that produces a characteristic set of behaviors, often classified as its 'function' or 'purpose.'1
Another definition, ascribed to J. Willard Gibbs, states:
Any portion of the material universe which we choose to separate in thought from the rest of the universe for the purpose of considering and discussing the various changes which may occur within it under various conditions is called a system. 2
Everything is a system. And all systems are composed of smaller systems, and act as parts of larger encompassing systems. Systems may be abstract or concrete. The elements of abstract systems are concepts. The elements of concrete systems are physical objects. The boundaries of systems are a function of the perspective and purpose of their observers. Where we draw the line of distinction is a function of purpose. The purpose of the system, AND the purpose of the study, the reason we have for drawing the line. The universe is a continuum of systems, from the galaxies to bacteria colonies and beyond. While we can move through interconnected and overlapping layers of systems from galaxies to sub-atomic particles, when we look at particular systems we have some intent, some focus, in mind. This narrows our range to a particular set of related elements within a particular context. We also filter our view from a conceptual viewpoint. We may only be interested in abstract, logical entities, or we may be interested in technical roles, or we may be interested in the actual physical instances of the parts in a particular incarnation of a system. From that specific set of interacting parts, with that focus in mind we draw boundaries on a set of elements to define a conceptual model of the system, which we then tend to call "the system." The selection of parts tends to be determined by what we define as the function, or purpose, of the system that we are defining, and our viewpoint. Taken from a different perspective, studied for a different purpose, we (or a different observer) might leave out some parts and include others.
Systems Thinking is the process of approaching problem solving with an understanding and appreciation of this continuum of interconnectedness. Systems Thinking involves understanding that systems have emergent characteristics that are inherent to their architecture that cannot be isolated and managed as one-off variables of our choosing. As expressed by Donella Meadows: "One of the most frustrating aspects of systems is that the purposes of subunits may add up to an overall behavior that no one wants." Which is why the purposeful architecting of systems, those visions we have for the future, is critical to ensure achievable and sustainable results.
Element Architecture Tool Suite (EATS)
EATS is about software. Designing and developing software systems has been my passion for a long time. And, in a sense, it is at the core of this effort. But software systems as stand-alone objects are somewhat meaningless. There is some intellectual curiosity that might be scratched by investigating them. They make interesting puzzles for people who are into that sort of thing. They provide a challenge. "Can it be done?" But that, by itself, is a dead-end effort. Unless you are talking about a very special case, perhaps an educational exercise, software systems exist to play a role as a part of a more complex system. Envisioning and architecting the software needs to see that role and be accomplished from the perspective of utility, durability and delight within that larger system.
Throughout my career I've work in IT and I've spend a lot of time envisioning and engineering systems, and at times re-architecting systems that had been engineered by others. Not all, but most of this work was focused on software systems. I think one reason for my success was that I did not think in terms of software (computer) systems as stand-alone entities. My automation projects were viewed, at least by me, as business processing, workflow, or information management efforts which were high integrated into the human business processes and activities which they were designed to support. The envisioning and engineering effort, to be successful, needed to start with an understanding of the host system which provided the contextual framework for the software system. And the the specification of the new system needed to be accomplished as a combined system which included both human and computer processes, acting together, accomplishing some function within the larger context. Within that framework, functional responsibilities were assigned to either humans or computer processes as the design was detailed; but it always stayed one integrated system. Certain tasks, certain functions, make more sense to allocate to the computer. And other tasks make more sense to allocate to humans, or to other non-computerized tools that the humans can direct. Using that framework, essentially designing a series of interacting systems at multiple levels on a simultaneous basis, the large system has the best chance of successfully accomplishing its purpose, and the smaller contained systems function more effectively as components of the whole.
What does this have to do with EATS? EATS is the name I've given to the software system I was attempting to develop as a commercial product after my retirement from Bank of America. But in a deeper sense the effort was about an approach to systems engineering. In the beginning, it was about systems engineering as applied to Enterprise Architecture.
As I became more deeply involved in the design of the software system, and I thought more deeply about the essence of the functions and activities that I wanted to provide tool-set support for, it became clearer to me that Enterprise Architecture (EA) as a subject domain was a very artificial constraint. Even when my target scope was EA, my desire was to support analysis and contextual modeling of the business functions that encapsulated the EA activity. I felt this was needed to provide understanding of the cascaded system orientation that is in effect. Only by understanding the operation of the EA details in context can you provide some assurance of coverage and validation that loose-ends are being addressed. It became clear that my focus had evolved more to systems engineering, rather than simply Enterprise Architecture. The Enterprise Architecture Tool Suite became the Entity Architecture Tool Suite. (Entity is a more generic term and, IMO, can fit a wider range of interpretations.) This is evolving to a label that hopefully will be more meaninful to more people: the Element Architecture Tool Suite. At the core of this discussion, it is the System Architecture Tools Suite (but I like EATS better than SATS.)
The tool suite is not meant to be "an architecture machine." It does not create architecture. That is a human architect's function. However, when looking at the architectures of large scale, sustainable systems there is a viewpoint which is extremely important to me; and which is enormous in scope. That viewpoint relates to life-cycle management of the system. Life-cycle management of complex systems is so enormous that it is not capable of being effectively encapsulated in the minds of mere mortal humans. And this is where computers and software come into play. Computers don't exhibit true creativity. Computers can't evaluate value judgments for problems they haven't been programmed to address. Those are tasks best left to humans. But computers can keep track of thousands upon thousands of details, and they can report back exceptions, point out discrepancies, and remember miniscule and arcane facts involving obscure relationships. And they can do this much, much better than human beings. Computers can augment humans and extend the reach of human intelligence in the accomplishment of complex and technically overwhelming tasks.
When dealing with today's complex systems engineering challenges, I see a form of augmented intelligence software support for the architect as critical in the management of sustainable systems throughout their life-cycle. This includes amplification of the architect's and related stakeholders' intelligence through the life-cycle activities of:
- Envisioning and Development
- Operation and Maintenance
- Re-engineering and Disposal
Envisioning is the task of creation. Developing the complex conceptual framework of the system in response to some need and arranging the choreography of components required to achieve utility, durability and delight. This requires being able to understand the role and activity of the system in its environment, it's organization and operation as a cohesive whole, and the proper tasking of responsibilities and orchestration of subsystems which sometimes have goals that are not easily maintained in alignment with the successful operation of the primary system. Bringing the vision to reality, development, can involve the monitoring and management of the construction process for the system, and/or it can involve the activities required to phase out old systems and phase in in the new methods and ways of doing business.
Operation and maintenance is critical to the issue of sustainability. While the system is engaged operational awareness needs to be maintained. Effectiveness of the architecture needs to be monitored. Corrective guidance, or subsystem redesign, when needed, must be accomplished in an orderly fashion. And both operational management and maintenance must be accomplished based on a current knowledge of system design, not based on obsolete blueprints of what may have been when the system was first created.
Re-engineering and disposal are often neglected aspects of design. No material system lives forever. But end-of-life phase out should be orderly and not disruptive to the hosting environment. Re-engineering on live systems can complicated and life-threatening. (Think of changing the tires on a car while the car is in motion on a highway!) Phase-out can also be life-threatening if not done correctly. A lack of awareness of the full purpose of, and critical dependencies on, system components can be catastrophic if those components are removed without compensating actions. (Removing a load-bearing wall is one example.)
Full awareness of the details involved in these processes for complex systems is well beyond the limits of typical humans. Providing that extended awareness and intelligence amplification for the human stakeholders involved in these activities is what EATS is about.
Architectural Engineering Technology
Architectural engineering technology has to do with the hard and soft tools used in the creation and/or maintenance of system's architectures. By design EATS is methodology agnostic. It should be able to be used in conjunction with any one of a number of systems engineering, enterprise architecture, or other methodologies. Ideally it can be used to help bridge differences of perspective between methodologies or process technologies if two or more techniques are involved in the same or overlapping system spaces.
The EATS infrastructure is not designed to address the specific issues involved with architecting systems. Rather it is a product line architecture designed to facilitate the integration of the detail tools within the tool suite, and to facilitate the use of those separate components in a coordinated manner using an integrated knowledgebase about the system being architected.
Since EATS is methodology agnostic, the tools discussed here can cross methodologies and may apply to any phase within the architectural engineering process. Tools are envisioned to vary from simple support for the analysis and specification process to management and control tools. These may include modeling facilities of various types. Six Sigma techniques are felt to be valuable for inclusion.
One of the key features of the system is not so much the individual tools and modeling techniques that are to be provided here, but the idea that all of these tools and models will be used to obtain views of the same integrated set of knowledge about the systems being studied. And the overall automation tool suite, EATS, will be capable of using the information set from one view to assist in evaluating the same system from other views. One model of the system can be used to audit and validate other models of the same system. If a subsystem is identified as playing a role in two or more composite systems, the same subsystem specification is used for all composite system evaluations. The subsystem as defined in composite one is the same system evaluated in composite systems two and three. It cannot be round in one system and rectangular in another. If the characteristics are changed in one design, those changes automatically carry to other designs which use the same part, and the changes need to be accounted for in all composite systems which use the part. This is the type of detail audit and management which is easy for a human to loose track of when managing the architecture of one or more highly complex systems. But this is what computers do with ease. Figuring out how to manage and adjust when discrepancies are found, is a task for the architect. Running audits and evaluations and providing exception alerts is something the system will be designed to do.
Subject domain content involves discussions about the various application domains where the EATS technology has been identified, or is under investigation, as providing value. Initial areas that will be identified come from my own work experience and my interests. These would include systems engineering, software systems, enterprise architecture, business architecture, social systems, political systems, and ecology. Given the generic scope of systems engineering, my thoughts are that there may be many other specialty perspectives that may be worth examining as unique application domains. If you have an interest in applying EATS to a discipline for which you have a special passion, please join our conversation. We'd love to hear from you.
The requirements derived from the specification of subject domains is not expected to greatly influence the EATS infrastructure. That is one benefit of the product line architecture approach. However there are two major areas where individual specialty domains would, or may, influence the development of unique tool support:
- Certain specialties may drive toward the creation of new or different visualization, analysis or modeling tools as part of the architectural engineering technology within the suite.
- Most specialties will drive toward an expansion of the metadata of the knowledgebase, as appropriate to support detail models constructed from that particular specialty's point of view.
Communities of Practice / Communities of Interest
There is some high level similarity, and some lower, detailed, level distinction between these two terms: Communities of Practice (CoP) and Communities of Interest (CoI). I'm not sure at this point whether the distinction makes a difference in the context of this site.
I approach this area from two perspectives.
- The practice of architecture development and maintenance, especially for complex systems, seems to me to be a community effort. It is accomplished through collaboration. I view EATS as a tool that can facilitate in that collaborative effort. A facility for the development and communication of shared mental models. As such, I am interested in understanding Communities of Practice and their needs to better address those needs with the EATS technology.
- This web site is starting out as a public brain-dump of ideas and concepts that I have worked on for a long time during my career as a systems engineer, and directions I have pursued with those ideas since my retirement from Bank of America in 2005. The point of putting this material on a public site is to invite critique and comment from others about these concepts, and to invite those who may be interested to join in the conversation and the journey. To that end, assuming there is sufficient interest, this may become a hub for a new Community of Practice centered around the tools and concepts identified above. If interest is sufficient, there may even be subgroups formed around one or more of the subject domains relative to the application of the tool suite, or the concepts, or both.
That's it. That's the story. Enjoy the site! Leave a comment and let me know what you think.
The subject matter on the site is focused, but it covers a very broad range. Participants do not need to engage across the spectrum. One area is fine. A subspecialty within an area is fine. Anyone who wishes to contribute, with an understanding of what the overall context of the discussion is, is welcome.