Open Framework, Information Management Strategy & Collaborative Governance | Data & Social Methodology - MIKE2.0 Methodology
Wiki Home
Collapse Expand Close

Members
Collapse Expand Close

To join, please contact us.

Improve MIKE 2.0
Collapse Expand Close
Need somewhere to start? How about the most wanted pages; or the pages we know need more work; or even the stub that somebody else has started, but hasn't been able to finish. Or create a ticket for any issues you have found.

MIKE2:Release Cycle

From MIKE2.0 Methodology

Share/Save/Bookmark
Jump to: navigation, search
Open methodology framework logo.jpg
This article is a key aspect of the Open Methodology Framework and has therefore been protected. Propose changes to this article on its corresponding discussion page.

The concept of a Release Cycle is an important part of the MIKE2.0 Methodology. One of the key differentiators on the collaborative MIKE2.0 approach is its ability to change to adapt to new techniques, technologies and methods. Supporting Assets are added continuously to the methodology from various contributors, but MIKE2 also needs to provide a degree of stability to its users. This is done through Releases Cycles and the Contribution Model.

Release Cycles are a grouping of MIKE2.0 Content into a selected baseline at a point in time. Content that is part of a Release Cycle can only change at a pre-defined time so that users know the content they are working with is stable. Just as with software components as part of an overall package release, not all articles will change with a particular release and users will be able to access previously released versions of an article.

Contents

Relationship to MIKE2 Content

Different types of MIKE2.0 Content operate within different Release Cycles:

Core MIKE2 Methodology

The Core MIKE2.0 Methodology includes the MIKE2 Overall Implementation Guide, Usage Model and selected Supporting Assets and Solutions. This aspect of the methodology is more stable and only changes at different Release Cycles. Mapping of Supporting Assets into the overall approach also occurs as part of a Release Cycle.

Non-Core Solutions and Supporting Assets

Solutions and Supporting Assets can be added to the methodology in a continuous fashion and provide the promotion path through adding more detail or extending the overall approach. All Supporting Assets go through their own independent cycle of development, often starting as a Wanted Article or Stub before going through the Peer Review process to become a more mature article.

Unlike the Core Methodology, where changes to content happen as whole (i.e. all changes happen at once), each Supporting Asset has its own release cycle unless it becomes a Core Supporting Asset, at which point it is only undergoes changes as part of a Release Cycle. MIKE2.0 Solutions can also become part of the Core MIKE2.0 Methodology.

Therefore, users of Supporting Assets and MIKE2.0 Solutions that are not part of the Core MIKE2.0 Methodology need to use caution in that they may not fit in well with the overall MIKE2.0 approach. The lower the level of maturity of an article within the Contribution Process, the less the article has been reviewed in terms of its relationship to the overall methodology.

Release Cycle Delivery Roadmap

As best as possible, the MIKE2.0 Methodology will try and provide a Product Roadmap of planned changes and enhancements. These will be largely at the major functional level and will go out on a projected horizon of 6 - 12 months. The methodology will track its progress against these planned delivery milestones and use them to help drive work efforts and focus.

The Product Roadmap will be driven from requirements which come through Wanted Article and Stub and the guidance of the Data Governance and Management Consortium.

Revisions to New Functionality Releases

MIKE2 will be be focused on progressively building functionality across the overall approach and its more detailed assets. There will, however, be times when the Core MIKE2.0 Methodology will need to revised - such as when:

  • A particular approach is shown to consistently yield poor results
  • Technology advances render an old approach as out-of-date
  • A piece of new functionality changes existing dependencies

These changes can be seen as "defect releases" and will generally be focused on a particular article or group of articles.

Backward Compatibility

As MIKE2.0 will be in use by implementation teams at all different point on projects, new releases should offer a transition from the old release to the new release and help accommodate users who are currently in the process of using the methodology. Much like a software release, "defect" releases should result in a change to the existing approach whereas new functionality only needs be used when required.

Contribution Model

The Contribution Model provides the hierarchy of what users can change certain articles; for example Protected Content can only be changed by members of the Leadership Team for MIKE2.0. As with the Release Cycle, the purpose of the Contribution Model is to add stability to the MIKE2.0 Methodology that balances the continuous enhancements being made to the overall approach.

Wiki Contributors
Collapse Expand Close