Tool Suite Discussion

Element Architecture Tool Suite (EATS)
Architecture Blueprint

Tool Suite Discussion

Original Author: joe.vansteen

Created: Saturday, July 31, 2010 - 10:35

Last Changed: Tuesday, February 14, 2017 - 10:57

Document ID: AF-EATS-ADMIN-010

Version: 01.00.001.660

All rights reserved.
This document is intended for use by members of the Architected Futures™ Community of Practice (AFCoP) and the developers and stakeholders of related systems that may desire to interface with Architected Futures™ technology or products. Use of this document is subject to the licensing terms described below.

architectedfutures.net web site by Joe Van Steen is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. Permissions beyond the scope of this license may be available at http://architectedfutures.net/contact/.

For information on how to mark content with an appropriate attribution please see the Creative Commons Best Practices for attributions page on the Creative Commons web site.

THE SITE AND THE MATERIALS ARE PROVIDED ON AN AS IS BASIS, WITHOUT ANY WARRANTY WHATSOEVER. WITHOUT LIMITING THE GENERALITY OF THE FOREGOING, ARCHITECTED FUTURES AND JOE VAN STEEN HEREBY DISCLAIMS ALL WARRANTIES, EXPRESS, IMPLIED, STATUTORY, ARISING FROM COURSE OF DEALING, OR OTHERWISE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NON-INFRINGEMENT OF THIRD PARTY RIGHTS. THE SITE AND THE MATERIALS (INCLUDING WITHOUT LIMITATION THE FORMS) MAY BE INCORRECT, OUT OF DATE, INAPPROPRIATE FOR ANY PARTICULAR TRANSACTION, MAY CONTAIN "BUGS," ERRORS AND DEFECTS, AND MAY NOT OPERATE ERROR FREE OR PRODUCE RESULTS AS EXPECTED. YOU AGREE TO ASSUME SUCH RISKS.

Purpose

The purpose of this element within the library is to provide a design notebook of annotated contextual specifications and understanding for the Element Architecture Tool Suite (EATS).

Objectives

The objectives of the EATS include the following elements:

• Provision of an integrated set of tools to facilitate the analysis, design, development and long-term management of architectures. (See Emergence in Methodology)

Principles

Key principles in the development of the Tool Suite include:

• The Tool Suite should be methodology agnostic. Selected methodologies have been followed in the development and management of the tool suite, but the tool suite itself should not require the adherence to any particular methodology or management practice in order to be useful. While elements of the tool suite were derived from selected methodologies, the tool suite as a whole has no methodological leanings. At the fundamental level, meaning is derived from how the tool is used. Not directly from what it delivers as outcomes. Selected tools may be provided within the suite which are principally found to be of value among particular methodologies or practices, but they are free and sometimes encouraged to be used in mixed or hybrid methodologies.
• The tool suite is science, engineering and fact (reality) based. As an engineering tool, reality is based on scientific thought. As an architectural tool, one that involves the engineering of human systems (systems involving humans as elements), all sciences can, and should, be represented in the tool suite. Core sciences involve those which specialize in human computer interaction and behavior.
• The tool suite, to be the most effective, must be an impeccable agent of information exchange. It must be trusted. The utility of any outcomes produced is reduced in value if trust in its derivation can not be certified. Tools need to work to known standards within specified applications. This is achieved by measurement of precision and accuracy of the tooling to the application.
• Everything is a system. The generalized rules and engineering principles about system apply; and rules and concepts for specialized general cases (disciplines or domains) apply when operating within the domains. The rules of mathematics apply in terms  of use in mixed environments. These include such techniques as logic, basic science formulae, statistical evaluation, etc.
• All systems have architecture. Architecture, in a manner is how systems reflect back on their human observers. Systems that work well in the context of their human observers have high satisfaction, otherwise satisfaction suffers. Tuning satisfaction can be achieved by tuning element architectures or by adjusting relationships between elements.
• Values matter and circumstances matter. Outcomes in human interactions are value based and circumstantial. Values involve morality, ethics, beliefs and other factors. The integration of those elements with other elements influences behavior in system where human activity is involved.  
• Systems are real, but the map is not the territory. Systems are ultimately conceptual maps that define mental models of the real world. A specification of the way that one or more humans hold mental models of what "reality" consists of. The degree of reality of a system, is the degree to which the system mirrors the physical reality of the world. No "system model" can completely define everything about any system. But, for practical engineering purposes, some systems can meet and exceed requirements, others make approximations but fall short. At best, the tool suite can approximate an integrated mental model,
• To be functionally sustainable the tool suite must incorporate a means of ongoing renewal and refinement. Renewal and refinement is a scheme for increasing confidence in outcomes that are generated and trust in the overall system.