Architected Futures™

Tools and strategies ... for boiling the ocean

Genesis

WISDM

The conceptual origin of the Architected Futures™ modeling framework dates to the mid-1980's and techniques inspired by a methodology termed WISDM which was offered by a company called the Western Institute of Software Engineering, or WISE. WISE appears to have been later re-formed as the WISDM Corporation and, at the time of this writing, a website in that company name is still active although it hasn't been maintained and there is no response to e-mail contacts.

WISDM, as practiced at the time, was a methodology for defining requirements for large, complex software systems. The methodology was similar to JAD (Joint Application Design/Development) which was being espoused by IBM at the time, but used a unique set of requirements models and techniques that had been developed by Dr. H Blair Burner1, the founder of WISE, during his tenure at the Boeing Corporation in the 1970's.

Correction

Looking back at documentation from this time period, it may not be fair to say that the WISDM framework was truly the inspirational fountainhead for the AF framework. At, and before, that time:

  • The GCMTAD Architecture document had been developed which provided a top level conceptual framework for a 100% business-based system specification. Inspiration for that included:
    • IBM's BSP process and methodology
    • The Information Engineering concepts espoused by James Martin and Clive Finkelstein and practiced at the time by the World Banking Group
    • The data modeling practices of the retail group and the development of the 1983 RSA documentation
  • The BISD Systems Architecture Methodology book had been written in 1983 based on the above references plus:
    • Datamanager dictionary model - which may have had a more significant influence
    • Model 204 and the IDMS(?) dictionary
  • Dave Shepard's application architecture concept
  • The Systems Planning Process Manual which had been developed partially based on the Kempnor-Tregoe problem solving method.

I think the impact of the WISDM exercise had the following effects on the conceptual development:

  1. It demonstrated how to incorporate a JAD-like process of multi-disciplinary team involvement to develop a coordinated set of specifications.
  2. The exercise provided an example of a scheme for layered drill-down from a high-level, conceptual layer to a lower-level logical layer where high level functions were decomposed into manual and automated functions and there was concrete traceability in the models from layer to layer.
  3. The exercise demonstrated a pre-Zachman version of Zachman layered models, where lists are defined as models at the top layer and the interaction between the elements on the list form a different, more detailed model at a lower level. As the interaction models are built, the lists are updated.
  4. The exercise demonstrated the use of multiple model views which could be used to cross-validate each other and thus enhance the confidence level in the overall specification.
  5. Automation of the WISDM models into DModel (not WISDM itself) led to the development of a metamodel layer above the actual WISDM models which then enabled the tool and the framework to be expanded and reused for the BISD compliance exercise which followed.
  6. Automation of the WISDM models also chrystalized selected features of the AF encyclopedia model:
    1. Development of the basic three models:
      1. The entity list model defining each entity and it's type
      2. The entity association model which are the RDF statements where the various predicate types are implicitly associated with certain interaction model types
      3. The narrative text model where various narrative statements are "typed" and then brought together to form a combined narrative document defining an entity and it's attributes.

Note. The WISDM models were not unique, even though some unique labels were applied.

  • The EIM which defined external interfaces was simply a context model.
  • The DFM was a simple data flow diagram
  • The FFM was a process flow model

Note also - Zachman did not write his IBM System Journal article until 1987. This was all concurrent activity!

  • 1. Blair needs to go into the "hall of ancestors" or whatever we develop for that sort of thing.

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