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.

Technology Backplane Development

From MIKE2.0 Methodology

Share/Save/Bookmark
Jump to: navigation, search
Activities in Phase 5
Phase 5 - Incremental Development, Testing, Deployment and Improvement
Content Model Relationship

Contents

Activity: Technology Backplane Development

Objective

Getting the Technology Backplane available as soon as possible is critical for the development of Business Intelligence Applications. The tasks explained below cover the core areas of Infrastructure and Information Development for build and unit test.

The tasks below are not meant to reflect a sequence, but apply to the different types of development tasks that would apply to the Technology Backplane. In general, most of these tasks can be done in parallel.

Note: Although this is a single activity, it may comprise a significant portion of the project work effort.

Major Deliverables

  • User docs and training materials
  • All software development completed
  • All test cycles completed
  • Deployed solution
  • Signoff from client
  • Update of knowledge management systems
  • Update to overall MIKE2 methodology

Tasks

Implement Target Database

Objective:

The database is the heart of the information management environment and as such will need to be implemented as soon as possible for the surrounding processes to work from. This task delivers the implemented, working database.

The following sub-tasks are necessary to implement the database:

  • Allocate physical space
  • Load system tables
  • Create physical tables
  • Create metadata tables
  • Database security enabled


Input:

  • Physical Data Model
  • Physical Database Design


Output:

Develop ETL Interface Components

Objective:

These components interface directly into applications, for extracting or loading data. When interfacing through an application layer, these are often referred to as adapters; for data integration technologies these are typically directly into the database tables. Interface Services are a combination of the interface into the application and transformation into the Common Messaging Model.

Regardless of the Solution implementation approach, this task covers the development and unit testing of software they would be used to extract (or receive publications) from source and then the interface into the target.


Input:

  • ETL Physical Design
  • Message Modelling (for SOA)
  • Common Services (for SOA)
  • Interface Services Design (for SOA)


Output:

  • ETL Adapters and Interface Services Developed and Unit Tested

Develop ETL Mediation Components

Objective:

These components provide the process integration flow from producer to consumer. Whilst in a Services Oriented Architecture the Mediation layer is seen as separate from the Interface layer, in traditional ETL implementations this is generally seen as a single set of process from source to target. Therefore, depending on the solution approach, the implementation tasks may be performed differently. The overall scope of development and unit test, however, is the same independent of the solution approach.


Input:

  • ETL Physical Design
  • Message Modelling (for SOA)
  • Common Services (for SOA)
  • Interface Services Design (for SOA)
  • Business Services Design (for SOA)
  • Data Management Services Design (for SOA)


Output:

  • ETL Mediation Components Developed and Unit Tested

Develop Automation Components

Objective:

Automation Components are used to ensure that the implementation solution runs in a completely automated fashion and refer primarily to the integration environment. There is some degree of overlap between the mediation components and automation components. The automation paradigm also works quite differently depending on whether it is batch-driven or event-oriented.

Input:

  • ETL Physical Design
  • Message Modelling (for SOA)
  • Common Services (for SOA)
  • Interface Services Design (for SOA)
  • Business Services Design (for SOA)
  • Data Management Services Design (for SOA)

Output:

  • Automation Components Developed and Unit Tested

Develop Operationalised Data Re-Engineering Processes

Objective:

Whilst Data Re-Engineering processes are performed as manual activities during the Foundation Activities, they may also be operationalised as run-time processes that can be executed through the integration environment. In a Services Oriented Architecture implementation, reusable Data Re-Engineering processes are referred to as Data Management Services.


Input:

  • Data Re-Engineering Jobs
  • ETL Physical Design
  • Message Modelling (for SOA)
  • Common Services (for SOA)
  • Data Management Services Design (for SOA)


Output:

  • Data Management Services Developed and Unit Tested

Develop Metadata Management Integration

Objective:

Metadata Integration will need to be an going part of the process for development, as metadata covers design and run-time design assets and most components of the overall solution will have their own stores of metadata. Depending on the solution approach, metadata integration may be as much a by-product of the development lifecycle as a specific set of tasks.

Input:

  • Metadata from multiple sources
  • ETL Physical Design


Output:

  • Software products and processes to integrate metadata
  • Integrated Metadata Environment

Develop Infrastructure Management Processes

Objective:

Infrastructure Management software and processes cover a number of areas that fits under the workstream of Infrastructure Development, such as backup software, archiving, purging, storage, security. The development work in this area is often left until late in the project and inevitably causes delays. Whilst it is necessary to do some of this development work towards the end due to dependencies around data loads and table structures, it should be ensured that there is enough time available to properly build and test these components.

Input:

  • Implemented Database
  • Technology Backplane Non-Functional Requirements
  • Infrastructure Management Design


Output:

  • Backup & Recovery Procedures
  • Archiving Procedures
  • Partitioning Procedures
  • Purging Procedures
  • Security Implementation

Core Supporting Assets

Yellow Flags

  • Developers are not unit testing software
  • Delays in development result in components being delivered late into testing and the testing cycle does not slip accordingly
  • Reuse requirements are not met by the software being delivered

Key Resource Requirements

Potential Changes to this Activity

The tasks in this activity should be generalised to cover information integration. It should be more than mediation in the "middle", it should also cover other types of business services. It should be also re-worded to reflect integration of unstructured content.

Wiki Contributors
Collapse Expand Close