Sometimes, isn't redundancy and complexity necessary or even desirable? For instance, isn't a large retailer more successful with thousands of redundant stores and massive complexity?

Sometimes, isn't redundancy and complexity necessary or even desirable? For instance, isn't a large retailer more successful with thousands of redundant stores and massive complexity?

You can have as many instances (redundant retail stores) as you want in Row 6:Operations Instances, but you only want a single abstraction in Row 1:Scope Contexts, Row 2:Business Concepts and Row 3:System Logic. It is conceivable to have more than one abstraction in Row 4:Technology Physics and Row 5:Tool Components, but if you do, you have to keep track of them as they relate to Row 3:System Logic or else you will go out of control- potentially have an entropy problem. They will get out of sync.

That is, you don't want any discontinuity in the Concepts (Row 2) or the Logic (Row 3). It is conceivable that you might want to implement in more than one Technology (Row 4), but now you have a synchronization problem that you will have to manage. 

In terms of Row 6:Operations Instances, there can by "n" of those, but you want each instance to trace back to the Components Transformation (Row 5), the Physics Transformation (Row 4), the Logic Transformation (Row 3), and the Concept Transformation (Row 2), and probably the Scope Transformation (Row 1) as well. That is how you insure that the reality of the Enterprise is consistent with the Enterprise Architecture. And when the "Systems" say there are 423 Employees in stock, there are actually 423 Employees in stock, etc., etc... and when we say the Concept "Employee" (Row 2:Business Concepts), it means the same across the entire Enterprise and that all the Employee instances (Row 6:Operations Instances) obey that authorized Enterprise Concept (Row 2:Business Concepts) definition.

If you did this, you could actually manage the Enterprise.



Stay Connected