Chapter 9 – Frustration
In fact, it is a miracle that anything got implemented that had anything to do with what the Owners had in mind when we never defined what they had in mind in the first place. In contrast, the Row 6 implementations are locked in concrete.
The solution to this problem is to begin to see that the models are not simply a convenience for helping to build the systems. No! They are the equivalent to the Product Definition of a complex product, for example, they are like the drawings, functional specs, bills-of-material, etc., etc. for an airplane.
Summarization Column by Column the issue and degree of frustration:
Column 1: Things (the date being surrogates for the Things) – if you have redundancies and discontinuities in the data, you have a Tower of Babel problem. You are unable to communicate effectively or take inventories and analyze the asset consumption and utilization an you will lose control of the business.
Column2. Process – the same process is replicated and not being performed consistently. This is not very efficient but it won’t bring the Enterprise to a screeching halt.
Column 3 – Location – the distribution of the Enterprise as manifest in the hardware/systems software. You could have every kind of hardware/systems software known to mankind. The stability of the network deteriorates and the cost of keeping the network up 24x7 is running somewhere around 50% of the Information Systems budget.
Column 4 – People – the work flow is disintegrated… every user has a plethora of screens customized for every different application they use. This is not very efficient but it won’t bring you to a screeching halt.
Column 5 – Time – there is no coherence in the dynamic aspects of the Enterprise. I know little about this column of models but the more I understand about Industrial Dynamics, the more I suspect this is having a substantial although unrecognized impact on the Enterprise
Column 6 – Motivation – it is from here that the business rules are derived and if the same business rule is imbedded inconsistently or incoherently in multiple system, management is going to be really frustrated.
There are 3 columns of models that will cause substantial management frustration if there are inconsistencies or incoherencies across the scope of the Enterprise. They are Column 1 (the Thing Column as it is manifest in the data), Column 3(the Location Column as it is manifest in the hardware/system software) and Column 6 ( the Motivation Column as it is manifest in the business rules).
The Key is Column 1. If you can figure out how to build out Column 1 , the Thing Column, sliver by sliver, everything else will fall into place for you.
Chapter 10 – Segmentation
Promoting to Enterprise-wide Quality – Some of the Entities in the Enterprise-wide Data Model they left at only “project quality.” That is, they didn’t make any effort to acquire any agreement by any other users as to their structure..
Chapter 11 – Migration
You could build out of the Semantic Model (Column1, Row2) to 200-300 Entities, run the where used application, define the build sequence based on data dependency, pick up some slivers to flesh out in detail, transform the high level of detail Semantic Model(Row 2) to a high level of detail Logical Data Model (Row3) and build out the Logical Data Model(Row3) sliver by sliver at excruciating level of detail in dependency sequence.
Before the Enterprise would be able to perceive any practical value from the Data Model, you would have to transform it to Data Design(Row4), transform that to Data Definition(Row 5) and create the resultant database (Row 6).
Data Warehouse
If you can populate the Architected database with data from the legacy files that has consistent meaning and good quality, you can make a lot of management folks very happy reasonably quickly. The data will look integrated to them.
The Genius of Data Warehouse
- You move the output processing into an architected environment without having to rebuild all of the input processing systems…give management access to integrated appearing data with a limited amount of work, which likely makes them VERY happy(for a change)
- You set up a 3 schema environment and reduce the change liability from a geometric function(m x n) to an arithmetic function(m+n)
Technology Architecture
The same basic concept could be used for migrating out of the legacy Technology environment that is, define the to be, normalized, standard hardware and systems software Column 3, Row 4 Technology Architecture. Then rebuild the applications one at a time, moving them from the legacy environment to the Architected environment. In this fashion, you could leverage the value of the legacy up until you shift the dependency, system by system, to the new environment. This gives you time to stabilize each conversion before embarking of the next.
Process, Work Flow, Business Rules and Dynamics Architectures
Once you begin the migration to the architected environment and begin to diffuse some of the Enterprise’s frustrations relative to the Legacy in Column 1 (Data), Column 3(Technology) and Column 6(Business Rules), it will buy you some time to examine the Enterprise Processes(Column 2) and Work Flow(Column 4) with regard to possible normalization. This would provide marked improvements in efficiency and establish a baseline for facilitating process and work flow change.
In Summary on Part 4 Frustrations
The pain level in if not most Enterprises has become increasingly intense as we continue into the Information Age, and I have suggested that the cause of the pain lies in our historical lack of understanding and employment of architectural concepts in our Enterprises, particularly in Column 1, and Column 3, and Column 6.
No comments:
Post a Comment