Cyber-Physical View Overview
The contextual framing for the EATS cyber operational viewpoint was introduced in the EATSv5 Technology Framing introduction in terms of architectural layers and concept containerization. The focus of the discussion in that context was the application. The focus here is the technology framework for the application. The discussion included a view of the EATS Layered Product Architecture as depicted in the following diagram. The top five layers of this diagram are, from the EATS perspective, considered application. The bottom layer of the six, Deployed Technology Infrastructure, is considered the cyber technology framework. That is the layer of concern in this section.
Discussion of automated systems has historically used the term “the glass” to identify the distinction of outside versus inside of a computer system. The user and the business are considered to be on one side of the glass, metaphorically the surface of what was once a glass CRT screen; and the computer system was on the other side. The concept is valid from the perspective of distinctions of responsibility and segmentation to describe and manage separation of concerns for various parties, especially in large scale business automation; but over time is becomes blurred; and there are significant issues with the thickness of the glass as systems have become distributed onto personal devices. It becomes even more difficult when trying to differentiate between an application system and the other cyber systems that are required to support the application, but are developed and managed independent from it. That is part of the distinction being made here.
Over time automation has become both more complex and more complicated. Understanding fundamentals can help in unraveling both. The history of computing hardware is traced to earlier tools than the Abacus, which dates to the period 2700–2300 BC. Software is a more modern invention. Ada Lovelace is considered the first programmer for work on Charles Babbage‘s Analytic Engine. Babbage is considered the father of computing in the modern form. The distinction between hardware and software, in the early days, was best exemplified by the punched card system on the Jacquard machine. Complicated, but deterministic, similar to a Player Piano or a Music Box as automated music making devices. As long as everything stayed physical, including software, things were complicated, but complexity was debatable. Complexity, non deterministic behavior, really enters the picture with electronics, and a loss of comprehensible physicality to the operation of computing. Random errors can be managed with Error Correcting Codes of various forms, but only if the need for them is recognized and incorporated in design. Otherwise chaotic misinformation expands to consume the validity of process versus intent. The need arises largely as a function of the introduction of communications and chaotic random failure within the system, e.g., the Telephone Game.
Architected Futures’ fundamental framework of architecture as applied to computing is adopted from a schema identified by Dave Sheppard, the Chief Analyst of Systems Programming at Bank of America in the 1970s. The conceptual architecture provides the essential distinction between Application Architecture, the top five levels of the EATS Layered Product Architecture; and the Technical Architecture underpinning which constitutes the bottom layer; and how they come together as components in a total System Architecture. What constitutes the totality of a System Architecture is an issue of boundary specifications. Boundary is determined by the intent of the discussion and the concerns of the stakeholders. System can be considered System Under Study, or system within scope of examination. For EATS it is always a combination of humans and computers. It is never computers independent of humans. It may also include any number of additional material objects and resources as may be appropriate to bring into the scope of the architecture as elements of concern.
EATS Sheppard Architecture
The original version of the Sheppard Architecture consisted of only the second and third tier of the diagram, and the labels in the boxes were different, but the conceptual pattern was the same. The two layers, together, were defined as the subcomponents of the whole of the architecture. In the current diagram System Architecture, at the top of the diagram, was added to pull the five components in the second tier together as a unit to define the cyber architecture of an automated system. Dave Sheppard was responsible for the effective operation of the black boxes in the glass house that conducted data processing operations for the Bank. He didn’t run the operations, but if the operations broke, it was his job to fix it. He also wasn’t responsible for the application logic of the business systems that ran on the black boxes, but he was responsible for ensuring that sufficient black boxes existed, in working order, for the business applications to be able to be implemented. Effectively, his architecture model defined how he saw his domain defined in a logically concise form. The architecture has five primary components, four of which defined the technical housing for the fifth.
|Hardware System||Operating System|
|Data Management System||Communications System|
- Sheppard Architecture Primary Structure
- The hardware system on which the automated system operated; described here as Physical Implementation. At the time, this was a single, usually mainframe, computer; maintained as a secured facility in a secure building. Today it is the combination of hardware devices on which aspects of programming related to application logic operates. In a complete, EATS Cyber-Physical System View, this includes all of the physical components of the system under study, or the system in scope. It includes both computers and humans, and any additional physical elements which are input to, outputs of, or objects of concern related to system processes. It can be exclusively human, but it cannot be exclusively computers1If the system under study is exclusively non-human, non-computer physical objects, then the application defines a physics, chemistry or biological study. The meta process would still involve a human observer, and using EATS to assist in analysis would bring in the use of a computer..
- The operating system for the physical system; described here as Contextual Interaction Systems. At the time, at Bank of America, this was a version of IBM’s System/360 Operating System; one of the earliest computers which made a distinction between architecture and implementation in order to create a family of computers that was able to evolve over generations, to capture the mainframe computer market. Today it includes all of the operating systems and router management and control schemes that regulate and direct resources for use by programming related to the application system’s logic. In a complete, EATS Cyber-Physical System View, it also includes the policies and procedures which govern the human aspects of a system’s management2If the boundary of the system under study is taken to be a governmental body, the military, or a regulated business enterprise, then the constitution framework, the military organizational framework and chain of command, or the legal and regulatory framework constitute a contextual operating system which is beyond the bounds of the system design to modify..
- The structure of the application system, described here as System Structure. The application system was further subdivided as having two principal components:
- Processes, described here as System Processes. The procedural instructions to be implemented (run as programs) by the Physical Implementation.
- Data, described here as Functional Information. The memory of the application system to be managed by the Information Management Methodology.
- The data management technology, described here as Information Management Methodology, used to enable access to data in the physical system by processes within the application. In the 1970s these were file based input-output systems provided by the computer operating system (BDAM3Basic Direct Access Method, BSAM4Basic Sequential Access Method, QSAM5Queued Sequential Access Method, ISAM6Indexed Sequential Access Method) and early versions of a database management system (DBMS). CODASYL databases were prevalent at the time. In the EATS Cyber-Physical System View it includes the various techniques for the management of physical data storage and retrieval by the participants in system processes.
- The data communications technology, described here as Information Communications Methodology. This includes the physical mechanisms and associated enabling technology to provide communications between the system and its peripheral devices, or between two or more instances of physically distinct computer processes making up the application which need to exchange information via telecommunications. In the early 1970’s this was TCAM7Telecommunications Access Method; almost, literally, basic Telephone Communications Access Method, and an IBM supplied BiSynch utility8BiSynch was a utility which was able to do file exchange transfers in two directions at the same time. Bank of America used it to send small files between a San Francisco and Los Angeles data centers, to provide adjusting entries to data that was principally sent on magnetic tape on scheduled airline flights. Telecommunication speeds were not able to support large file transfers, which were faster to accomplish via physical transfer of tape.. For computer to computer, or human-computer interaction in the EATS Cyber-Physical System View this is largely the internet and its associated technologies. It also includes television, radio, speech, and smoke signals.
Dave was a technical person, and the Sheppard architecture of the 1970s ended at that point. But the distinction between the technical framing and the application was distinct. The Application Architecture was encapsulated in System Structure, and how it chose to implement System Processes and their interactions with the application’s Functional Information. The remaining four components constitute the Technical Architecture as the constraining implementation framework on which, or in which, the application system is instantiated and comes to life.
The remaining parts of the EATS Sheppard Architecture are extensions to the framework created by Dave Sheppard by adding an Information Engineering perspective to the framework using methodologies developed by Clive Finkelstein and James Martin in the 1980s. These close the loop back to intention of the (application) system and its position within a human context, rather than a simple view where automation exists in a world devoid of purpose. Computers do not invent applications to have something to do. The needs of human motivated applications drive the requirement for performance and effectiveness in the Technology Architecture that enable it.
The automated core of the Technical Architecture consists of:
- The physical elements which perform the processes and functions of the system.
- Contextual regulatory systems which goven, schedule, activate and sustain the operations of the system.
- The methodologies employed to store and maintain information within the system, and/or to exchange information with elements outside the system.
- The methodologies used for communications between components of the system, and between the system and other systems in the environmental context.
For purposes of understanding EATS, the Technical Architecture discussed here is limited to the enablement support system for the EATS software system. This further excludes humans as components in the system other than as the actors which drive the action set of system activity. On the other hand it includes both the technical enablement of EATS development AND the technical enablement of EATS operations. This is in congruence with the EATSv5 Technology Framing, shown below, which separates human aspects of systems architecture from the remaining physical aspects. This aligns with differences between the soft systems methodologies and models required to analyze and regulate human aspects of systems, versus the hard systems methodologies employed to understand non-human, technical systems. To understand how both work together in a mixed system, a model for combining them is also required.
Kruchten 4+1 Model
The principal viewpoint set for the EATS Technical Architecture is Philippe Kruchten’s 4+1 View model. The Technical Architecture defines choices made in the design of the system, and constraints that limit how the Application Architecture can, or must, accomplish intention. When constrained to the cyber components within the architecture the Kruchten 4+1 View model becomes comprehensive.
The four principal areas of the Sheppard Architecture Model are addressed in the EATS architecture using three management schemes. Two are best understood and address using containment frameworks, and two are best understood and addressed using design aspects of EATS. The containment frameworks were introduced in the architecture overview. In that discussion the following models were introduced.
The Physical Container Layering Object Architecture defines the scheme for encapsulation and control of the Physical Implementation and Contextual Interaction Systems segments of the Sheppard Architecture. EATS extends this model in simple form, using a virtual machine pattern, by choice of a JVM and Eclipse as devices within the center of the model to reduce the influence of variability of this aspect of system context dynamics by choice of well understood, open source technologies which can evolve and adapt to changes within the technology over time, without a requirement for change to occur within the detail components of the system. The EATS Infrastructure Layer of the EATS Layered Product Architecture further insulates Business Components from environmental changes as cyber technology evolves. In the diagram below the Java VM and the Eclipse e4 Workbench detail the Vendor Frameworks shown in the diagram above; and the EATS Infrastructure continues the containment pattern to provide support for the Tool Suite as a layered ladder structure climbing the product architecture shown at the beginning of this section.
EATS Eclipse VM Diagram
This is conceptually similar but functionally distinct and independent from container management schemes using technologies such as Docker and Kubernetes which encapsulate the technology at much higher levels in order to provide flexibility in administration at even higher levels in machines farms running virtualization software capable of running multiple operating systems on a single hardware platform. EATS works perfectly fine within those containers. However, as scaling occurs in that direction, entropy occurs which robs performance. This has been a problem with the direction of automation around large scale computing for a long time. Rather than scaling up, EATS is concerned with scaling out, and scaling down. The EATS container architecture can just as easily be run on a RasPi or a smartphone as in a Google, AWS, Microsoft of IBM data center. The same is not true for some other forms of virtualization. The benefit of the layered architecture is isolation of impact when absorbing change or differences between contexts. Docker type containerization, IMHO, tends to be more directed at resolving incompatibilities that have historical roots dating back to DLL Hell which still permeate the software industry today.
Technology layers, for effectiveness, tend to be defined inverted to user viewpoint, and combine with user views to define the operational achievement of user function in of the cyber architecture. They allow the architecture to effectively understand and manage, as a closed cybernetic space, and “see the system” from both sides of the glass. Either view independently presents an open system description incapable of true regulation and cannot achieve full comprehension of situation. Both views together form a scheme for reconciliation in the form a closed system. Inverted operations are achieved in design and implementation of the technology using inverted mechanics, e.g., inverted indexes, inversion of control, etc.
The Communications Protocol Layering Process Architecture is orthogonal view into, or through, the operating environment containment model. (Data management is also orthogonal but along a different form of organizational expression.) One perspective for understanding is to re-arrange the components of the Sheppard Architecture isolating on the interaction of the technology components in how they achieve function for the application. This is inverted from the relative positions of hardware and operating system in the Physical Container Layering Object Architecture, and presents a User View, more appropriately termed a Utilization View, which is what architecture is all about: durable, delightful, utilization. This is the viewpoint that drive requirements, and ultimately effectiveness in achieving intention.
|Data Management System|
The operating system (OS) physically runs on the hardware platform, in the context of the hardware platforms architecture. From a physical, electrons doing work basis, the hardware runs the system. But, from a roles and responsibilities perspective, the OS manages the operation and directs the hardware. The computer hardware, principally in the form of the Central Processing Unit (CPU), is at the heart of the system; but the OS is in control of making what the hardware accomplishes meaningful. Data management begins with the computer’s memory system and extends outward to the organization of data on hard drives and in archives. Protocols are used as the distinguishing mechanisms for organization of communications. Catalogs and index systems are distinguishing features for data management.
- Logical View
- Process View
- Development View
- Development Plan
- Component Packaging
- Eclipse IDE Configuration
- Maven Build System
- Physical View
- Model Driven Architecture (MDA)
- Architecture Description
- Application Architecture Overview
- Technical Architecture Overview
- Logical View
- Process View
- Development View
- Development Plan
- Component Packaging
- Eclipse IDE Configuration
- Maven Build System
- Physical View