Setting Up a Multi-Modeling Environment › Multi-Model Structures › Considerations

Considerations

A multi‑model structure is designed for development environments in which:

• A large project must be split so that users can work separately.
• A product is being tailored for a client but must be compatible with the standards.
• Each model in the structure represents a phase of development.
• Development is split over IBM i without a remote link.

In deciding whether your development environment would benefit from using a multi‑model structure, consider these factors:

• Development Schedule—A multi‑model structure benefits environments where data design and programming overlap.

  Note: If you are using Change Management (CM), you should consider using Check-out, User capabilities, and locks to achieve control in this kind of environment rather than using multi‑models.

• Application Requirements—Identify which interfaces to other applications are required; for example, which files must be shared between applications. Identify functions that are common to or must be shared with multiple applications. Loosely integrated or unrelated applications work well in separate models.
• Organization Requirements—You may want to separate models for security reasons, or you may want to separate or merge staff responsibilities.

  Note: If you have CA Xtras Change Management, consider partitioning the model with model object lists authorized to groups of staff and further refine access capabilities within just the one model.

If you decide that a multi‑model structure is appropriate for your environment, use the requirements you identified to design a structure that meets those requirements. This section describes some common configurations, though other configurations may best meet the needs of your environment.

In addition to identifying requirements, plan how you will maintain the structure you designed. Consider such factors as:

• Standards and procedures:
  • Shared naming library
  • Standardized functions
  • Coding techniques
  • Project time
• Staff needs:
  • Database administration
  • Operations
• System requirements:
  • Hardware
  • JOBQs
  • Subsystems
  • Pool allocations