Architected Futures™

Tools and strategies ... for boiling the ocean

EATS Library

The EATS Library defines the formal collection of the Element Architecture Tool Suite (EATS) specification documentation. It exists to provide a central repository for this set of materials. The library is divided into three segments as follows:

  • EATS Blueprint — This segment is meant to address the high level contextual and conceptual architecture of the Element Architecture Tool Suite (EATS).
  • EATS Infrastructure — These titles are meant to address aspects of the EATS technical framework that provides the infrastructure for the business domain components. To reintroduce an old analogy, the infrastructure is the part of the system that acts like the mortar in a brick wall. (In this analogy the EATS System Components, described below, are the bricks.) The mortar (infrastructure) holds the bricks (components) together and enables them to become a wall. The mortar is how the bricks interact and communicate with each other. The mortar (and reinforcing) is what allows them to become something more than just a loose pile of bricks. EATS Infrastructure titles define the technology and policy set that allows the component pieces to coordinate their actions and behave in a unified, systematic manner. 
  • EATS System Components — These titles define various domain specific component subsystems1. These are the pieces that actually accomplish things. This is where function happens. Some of these subsystems are utilitarian, and provide general capabilities that are used by most, if not all, of the other sub-systems. Some are business application domain specific. Some are technology specific.

In line with most of the material on the website, and our general method of problem solving, you will find that most of the material in these books is unfinished. Outlines may be sketched, but not filled in. To understand some of this, I would refer you to Scott Ambler's web page on Agile/Lean Documentation. I don't claim to be following a strict Agile methodology in my work, but there are similarities in some basic philosophies.

Generally the sparsity of documentation is a result of typical developer mind-set. Things get documented if they have to get documented in order to retain sanity while developing the system. But that isn't exactly in concert with the philosophy of the site, so I try to fight that mind-set. 

At a high level, I believe that architecture that is meant to have some enduring lifespan needs some enduring documentation. The enduring documentation does not need to cover every detail of construction. But, there is such a thing as architecturally significant documentation. The documentation of core principals, design patterns and related criteria by which the architecture accomplishes its intended purpose. These are necessary insights that need to be made available to later architects and developers who may be responsible to adapt, extend or maintain the original system. These are the types of elements where we try to focus the documentation effort.

At a low level, I believe the best documentation is the code2. However, not everyone reads code. So aspects of code that need to be understood by normal people, stakeholders, should have some form of documentation. 

If you have suggestions about additional material that might be included here, or have suggestions about how it might be better organized, please send us a note using our Contact page.


Library Segment: EATS Blueprint

  • The purpose of this document is to describe the standardized viewpoint collection used in the creation of Architecture Descriptions for the Element Architecture Tool Suite (EATS). The use of a standardized collection of viewpoints, representing the concerns of a uniform set of stakeholders provides for consistency in the development of the architecture across a wide set of subsystems.

  • The purpose of this document is to describe the analysis work products for the Element Architecture Tool Suite (EATS).

  • The purpose of this document is to contain information about the concepts, tools and facilities used in the planning, construction and maintenance of this site for the benefit of the site administrators and content developers.

  • The purpose of this document is to describe the history and evolution of the technical design for organization and structure of the Architecture Information Repository (AIR).

  • The purpose of this document is to summarize the Architecture Blueprint for Architected Futures’ Element Architecture Tool Suite (EATS). The Architecture Blueprint is an informal title for the summary form of the Architecture Description. It describes the overall high level contextual and conceptual architecture of the EATS. It frames the discussion and provides a contextual understanding for the other components of the Architecture Description in the EATS Library.

Library Segment: EATS Infrastructure

  • The purpose of this document is to describe the logical design for the Element Architecture Tool Suite (EATS) infrastructure.

  • The purpose of this document is to describe the System Specification for the Architecture Information Repository (AIR) subsystem of the EATS infrastructure. The AIR subsystem is responsible for content management of Architecture Descriptions and related architectural information in a consistent encyclopedic repository.

  • The purpose of this document is to describe the System Specification for the Java Desktop GUI Presentation Manager (JDGPM) subsystem of the EATS infrastructure. The JDGPM is a technical subsystem responsible for enabling desktop processing for EATS applications in Java-based, thick-client delivery environemnts.

  • The purpose of this document is to describe the System Specification for the Java Web Presentation Manager (JWPM) subsystem of the EATS infrastructure. The JWPM is a technical subsystem responsible for enabling Java-based, web server processing for EATS applications in internet and intranet, browser and web services delivery environments.

Library Segment: EATS System Components

  • The purpose of this document is to describe the System Specification for the Component Services Mediator (CSM) subsystem of the EATS infrastructure. The CSM subsystem is responsible for message routing and orchestration within EATS.

Pages

  • 1. Use of a common acronym accross a set of documents would tie that set together as the documentation series for a consistent component, or component family.
  • 2. Code takes multiple forms. Rules based, or parameter driven technology is still code when you get down to the bottom specification level.