This is an old revision of the document!
Using a DIDO is not just a simple shift in policies, procedures and practices. It is a change in the architectural paradigm from centralized control to distributed requiring a change to how the system is normalized into systems, subsystems, components, etc. It also requires a shift in basic underlying principles of the system. DIDOs generally are:
The DIDO architecture does not represent a single unified enterprise but rather it represents a confederation of domains loosely defined that requires systems integration (SI)1). Although SI is not new to enterprises, the granularity and kinds of the components requires a rethink. Within the DIDO environment, the definition of a platform shifts from hardware, operating system, software languages, and services (i.e., web, app, database, etc.) components to the DIDO Platform components. It is the responsibility of the DIDO Platform to isolate the enterprise from the traditional platform concerns.
The granularity of the data elements within an enterprise can also shift to smaller more isolated objects that represent only a portion of the traditional dm. In other words, the enterprise's data model is not going to be deployed into a single DIDO and nor should it. The Enterprise data stores will continue and will be augmented by the DIDO. Some data will reside completely within the Enterprise data stores, some data will reside completely within the DIDO and some data will straddle both. Data that straddles both needs more procedures and policies defined to ensure data integrity.
The cultural shift from a stove-piped corporate or enterprise culture with almost complete control to being a systems integrator participating in numerous distributed communities that cover a wide range of domains requires a comiited leadership and a concerted effort by all the players.