return to Fundamental Views

Using a DIDO is not just a simple shift in policies, procedures, and practices. It is a change in the entire architectural paradigm. Moving away from centralized control to distributed requires a complete change in how the system is normalized into systems, subsystems, components, etc. It also requires a shift in the basic underlying principles of the system. DIDOs are generally:

• Comprised of thousands if not millions of independent nodes
• Outside the control of any one individual or corporation
• Lacking any centralized authority; decisions are made by consensus

The DIDO architecture does not represent a single unified enterprise, but rather a loosely defined confederation of domains that requires systems integration (SI)¹⁾. Although SI is not new to enterprises, the granularity and types of components require a rethink. Within the DIDO environment, the definition of a platform shifts from hardware, operating system, software languages, and services (e.g., web, app, database) components to the DIDO Platform components. It is the responsibility of the DIDO Platform to isolate the enterprise from 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 to be needed but will be augmented and complemented 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 require the definition of policies and procedures to ensure their 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 covering a wide range of domains, requires committed leadership and concerted effort by all the players.

• None at this time.

• There are none at this time but the Open Source Communities often rely heavily on the products of both Technical Standards Bodies and de facto Standards Bodies in building their projects.
• There are many guides available for participating in Open Source initiatives. Talk Openly Develop Openly ( TODO) provides an extensive reading list.²⁾. TODO also provides the following excellent guide as a place to start: TODO: Participating in open source communities.