© 1999-2000 NuovoDoc last updated 2001-06-01-16:15 -0700 (pdt)
My assessment is that early adoption of DMA is risky for an organization that isn't already immersed in applying DMA.
The opportunities to manage early-adoption exposure will vary depending on the nature of the company, the existence of any established legacy products, and the relevance of interoperability capabilities in the target market and product timeframe.
If time-to-market and customer engagement is more urgent than demonstrated interoperability, mitigate the added costs and risks of being an early DMA adopter by isolating dependencies.
Make sure that everything that is done with DMA in the early stages provides value. Derive immediate value. Don't invest in the potential of DMA for future value. Make sure that everything that is done is already valuable, even if only through providing an already-worked model, integration approach, and first steps toward a fully-developed implementation.
-- Dennis E. Hamilton
DMA Risk of Adoption 0.04:
|Learning Curve||The DMA Specification is neither fully rigorous nor designed
to serve as a developer's guide. There are assumptions and expectations known only
to the authors.
Available examples and implementation samples provide limited coverage.
|1. Specification is inadequate by itself..
2. Development and performance unpredictable without practical experience, especially for low-cost-of-entry approaches.
|1. Wait for public components, reference implementations, and
2. Limit early adoption to having product architecture anticipate interoperability with DMA. Design for staged interception. Gain repeatable experience by adoption in manageable increments.
|Unproven Features||Content Based Retrieval and Compound/Structured Documents
have been defined for trial-use.
The extensions have not been confirmed in public trial use. They have not been verified against existing solutions and products.
|1. Adoption at this time can be risky depending on moves by major vendors.||1. Look for practices that don't require a full solution.
2. Provide for upgrading to the DMA model for extensions once there is confidence in their usage.
|Limitations / Missing Features||Integration into distributed-object system (DCOM or CORBA)
Security model limited to authentication interface. No authorization mechanism and no administration in the model.
Transaction model inconsistent with major transaction management systems.
|1. DMA has many pitfalls if full feature set attempted.||1. Avoid suspect features that don't follow industry
2. Limit extension beyond DMA coverage to DMA-consistent customizations or work outside of DMA.
3. Be willing and able to work with others to establish and publish precedents.
|Uncertain Product Availability||There are no commercial, fully-compliant products that can be
assessed and with which interoperability can be verified.
Final DMA technical work was in the hands of a tiny number of regular participants (1 Hitachi, 1 Xerox, 3 FileNET, 1 Ricoh, 1 independent). The process is not external-requirements driven.
|1-2 years before interoperable multi-vendor products in the
same market space.
Absence of broad participation may result in short-sighted solutions.
|1. Limit initial employment of DMA to internal product
operations and generic functions that pose little interoperability risk. Stay with
basic feature set.
2. Have flexible metamodel mechanism for adjusting to standards set by dominant products that emerge.
created 1999-05-13-22:40 -0700 (pdt) by
$$Author: Orcmid $
$$Date: 05-12-13 20:49 $
$$Revision: 17 $