Designing for Flexibility

Relative to Dewey's conceptual innovations, in addition to his observation that the secret to the whole thing lies in the coding and classification of the data, Dewey identified and formalized the Process orientation in the late '60s long before Mike Hammer and Jim Champy popularized the concepts of Process Reengineering in their 1993 book. 

When we, the DP (Data Processing) people came on the scene in the 1950's and early '60's, there already were a lot of formal systems in place. In fact, there was a large Systems and Procedures community in many large Enterprises. They had formalized a lot of manual systems deriving from the Frederick Taylor "Principles of Scientific Management" in 1911. The formal systems resulted from the work flow studies that focused on the allocation of responsibilities for most efficient production of the product or service. Therefore the systems were very organization dominant and we, the new Data Processing people, simply coded up the existing formal, manual systems and told a machine what to do rather than the manual systems that told some person(s) what to do. In doing so, we automated, hard-coded, the organization structure. Then, Management would change the organization! Good night!! Every time Management changed the organization, it rendered the systems obsolete and we had to re-build them!

Dewey pointed out that the Process was different from how you allocate responsibilities (the Organization). You should build the systems around the Processes, not the Organizations. That way, you could change the systems all you want and it wouldn't affect the Organizations ... or, you could change the Organizations all you want and it wouldn't affect the systems. That is, there is a "many-to-many" relationship between Process and Organization. (Any one Process may be performed by many Organizations and any one Organization may perform many Processes. Organization and Process are independent variables. Orthogonal.)

Apparently this Process to Organization independence is still not very well understood. Within the last two or three years, I heard Steve Towers a notable figure in the Process Management community speaking at a Conference in Bangalore India emphasizing a strong point, "The Process TRANSCENDS the organization!" That is, a Process may have many Organizations involved and conversely, an Organization may be involved in many Processes. That is, once again, there is a many-to-many relationship between Processes and Organizations ... or, they are "independent variables." Dewey had figured that out sometime before I found him in 1970.

We learned this in the Data Processing community decades ago! It is called "LATE BINDING". The moment you hard-bind two independent variables together, they are fixed. If you want to change one or the other variable, you have to throw the whole thing out and start over again. The best of all possible worlds is to "bind only at execute time"! Why aren't we doing this? Most people would argue that the technology doesn't support it. I would say, the problem is, we haven't defined the independent variables! We don't know how to keep independent variables separated because we don't even know what the independent variables are! We do not accept an ontologically-based definition of Enterprise Architecture that identifies and separates all the relevant independent variables (facts that exist) upon which the Enterprise is dependent for its existence.

As I've mentioned, this works in every other scientific field. Architecture is no different. I will try to define that further shortly with Enterprise Architecture Perspectives.