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 fundamental change in how a system is normalized into systems, subsystems, components, etc. It also requires a shift in the basic underlying principles of a system. DIDOs are generally:
The DIDO architecture does not represent a single unified enterprise; rather it represents a loosely defined confederation of domains bound together by systems integration (SI)1). Although SI is not a new concept to enterprises, the granularity and kinds components associated with a DIDO architecture 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, which represent only a portion of the traditional Data Model (DM). In other words, the enterprise's data model is not going to be deployed into a single DIDO, nor should it. 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 will need more procedures and policies to ensure data integrity.
The cultural shift from a stove-piped corporate or enterprise culture with almost complete control to one with a systems integrator participating in numerous distributed communities covering a wide range of domains requires committed leadership and a concerted effort by all the players involved.