it:ad:information_management_lifecycle:home

IT:AD:Information Management Lifecycle

Summary

  • Vision, Mission, Desired Outcomes
  • Constraints
    • Define Framework to communicate expected Community Culture developed from addressable Individual/Behaviour
    • While meeting Legal and any other other Preexisting Agreements

    * Lifespan expectations of:

    • Service (implies there is a Terms & Conditions that communicates the end of service date, associated to specific versions)
    • Catalogs (implies that the service may take offline service modules, again communicated in T&C)
    • Catalog Items (implies records have an expiration date, to address possible Copyright & Maori ownership constraints)
  • Funding to cover operations, maintenance, and deployment through the whole service lifespans (not just the project go live date).
  • Receiving information from others (adhoc/unscheduled addition of information)
  • Collection of information from sources (implies linking to source catalogues, contact lists, etc.)
  • Recording (implies a place to record source information beyond what is ultimately developed into a presentable resource)
  • Define Viewpoint (same data can be presented to different stakeholders in different ways)
    • (Self)Learner: data should be accessible, comprehensible for users to gain value without external assistance.
    • Whanau: progress, achievements and alerts should be shareable with others
    • Teacher: a teacher should be able to assess the relationship of the learner to the material, and add additional value.
    • Peers: learners should be able to learn in pairs and teams. Teachers are learners as well. So are BOT members.
    • Adminstrators: providers should be able to plan with their teachers
    • BOT: boards of trustees should be able to provide governance to the provider based on learner's progress.
    • Sector: analysts should be able to view the sector's providers, and anonymous learner progress.
    • Authenticated Public: same
    • UnAuthenticated Public
    • Etc.
  • Structure:
    • Logical elements of the Resource (Summary, Introduction, Appendices, etc.)

    * Related Metatdata

    • Who is RASCI for this document
    • When released, updated, changes
      • Constraints (expiration, ownership, attribution & copyrights, cost to access, etc.)
  • Formatting (the Structure is often rendered as connected views and/or sections under headings)
    • Note that an alternate technique to show multiple related Viewpoints alongside each other in the same View is by using Gutters/Sidenotes, or side-by side comparison screens.
  • Collaboration (by Responsible and Supporting roles)
  • Classification (Security Classification, Tags, Attribution, Location usable (eg, visible only in-country?), etc.)
  • Contribution (who Supported, who was Consulted)
  • Attribute (who authored this resource)
  • Reference (to other resources, generally as Footnotes)
  • Link (to related resources, which is not same as footnotes)
  • Comment (by Consulted and Informed stakeholders)
  • Sequence (set position within a larger collection)
  • Compliance:
    • Validate
      • Correctness
      • Alignment
      • Attribution
      • Ownership/Lifespan
  • Change control:
    • Notify changes to Responsible, Consulted collaborators and Informed commentators.
    • Notify upcoming changes to interested/related development stakeholders to minimize impact when released.
  • Publish
    • First time
    • Revise/Replace (ie: Update published resources, releasing a Minor Change Version)
    • Supersede (release a Major Change Version, linking previous version to new)
      • Includes Merge operations
    • Revert:
      • Include Undo Merge operations
  • Notification:
    • notify published changes to interested/related stakeholders
  • Comment (by consumer)
  • Correct (live edit by appropriate users)
    • Self-Correct (when it's a personal record, allow the person who knows themselves best to correct their PII)

    * Rate by User @ specific date (all information deprecates over timeā€¦)

    • Tag by User (custom categorization)
  • Interrelate/Link to other Resources:
    • To items in the same system
    • To items in External systems
  • Compare:
    • To Historical Records
    • To Different Records
      • To Different Viewpoints
  • Moderate
    • Correctness
    • Comprehension / Understandability
    • Clarity
    • Conciseness
    • Appropriateness / Relevance / current value
    • Legality (Laws change over time, impacting privacy, etc.)

    * Moderate Metadata

    • Moderate/Rationalize user Tagging choices
    • Moderate user Comments (PII, profanity)
      • Address behaviour, reference T&C, change user roles and status as necessary.
  • Curate: basically, keep it a valuable Resource rather than developing into a Liability.
  • Monitor Trends of Usage/By, informing Resourcing/Funding
  • Manage (phone/email/non-system users) Requests for Correction
  • Manage Requests for Owned data (GDRP) in non-normalized/normalized formats
  • Manage Requests for Deletion (RTBF)
  • Deprecate/Retire
  • Archive
  • Remove record (soft)
  • Decommission record Catalogue
  • Export Data in normalized format as preferred by National Archives
  • Decommission System
  • /home/skysigal/public_html/data/pages/it/ad/information_management_lifecycle/home.txt
  • Last modified: 2023/11/04 03:25
  • by 127.0.0.1