experiences from using blueprint director in a data warehouse project

© 2011 IBM Corporation

GBS – Business Analytics & Optimisation

Experiences from using Blueprint Director in a Data Warehouse project

Mattias Jönsson, Enterprise Information Management Service Area Lead, GBS BAO

9 May 2011

2


Experiences from using Blueprint Director in a Data Warehouse project © 2011 IBM Corporation

Agenda for the next 45 mins

Short introduction of the tool - Why does it exist and where does it fit in?

Think before you draw - Abstraction Layers and Areas of Architecture

How have GBS BAO used it practically in a project? (Including some examples of drawings)

– Usage of BPD after a delivery project is finalised

Session wrap-up and Q/A



Short introduction of the tool - Why does it exist and where does it fit in?


Mattias Jönsson

4



Think about your last project...

Consistency of drawings/models?– Did they all use the same notation?

– Did they all use the same perspective?

– Were drawings/models for different areas created on the same level of detail?

– Was it easy to identify the relationships between different drawings (for example for front-end vs back-end)?

Content of drawings/models?– Did they place every object in a logical context?

– Where the drawings complete – did they cover all the areas of the solution/system?

Usage of drawings/models?– After build and deploy - did the drawings still represent all the assets in the

solution/system?

5



InfoSphere Blueprint DirectorVision • Execution • Completion

A unique new paradigm for integration projects, allowing teams to define & manage the end-to-end information flow

Improve predictability and ensure success of projects by linking blueprints to:

– Reference architecture

– Reusable best practices and methodology

– Business and technical artifacts

Provides control and insight of the information roadmap and its evolution through a collaborative project lifecycle:

– Vision, Execution, Completion

6



Overview of the interface

Palette free form “sketching” elements

Diagram for a blueprint

•Method browser (displaying method content)•Asset browser (browsing metadata repository)•Glossary explorer (showing glossary tree view)

Context specific property view

•Outline (zoom in/out view)•Blueprint explorer (shows tree view of the elements in the blueprint)

7



Top-down & business-driven design

Use formally defined business terms to specify the key data elements, e.g. for analytical analysis

Generate Cognos Framework Manager model from these business-oriented definitions to even further align business & IT

– Business articulates business terms relevant for analysis

– IT starts from generated model that is linked to the same business terms

Element in diagramrepresenting dimensional store

Sub diagram for customer profitability element

generated Cognos Framework Manager model

8



Accelerate and standardize projects through templates

Standardize your approach for key scenarios (BI, MDM, ..) and leverage recommended practices by using templates

Blueprint Director comes with a set of templates (BI, MDM, …) and you can customize or create new templates

Templates include a standardized reference architecture and method

9



Understand recommended approach through methods

Understand the entire method (all phases, activities, tasks) related to a scenario

Understand for each component in the reference architecture related method guidance

Drill into method description details: identification of roles, expected artifacts, value and links to manuals etc.

10



Track if your project vision and specific blueprint elements are aligned with

– business artifacts such as requirement documents, statement of work, etc.

– technical artifacts such as metadataof a database or specific data / ETL models

Manage consistency over time through live and always current links

Open linked artifacts in tools to view & modify

360° view: project vision + business + technical artifacts



Think before you draw - Abstraction Layers and Areas of Architecture


Mattias Jönsson

12



The ”context” challenge of BPD

Creating diagrams and subdiagrams is very easy – so is the task of technically navigating a Blueprint!

It is possible to ”borrow” objects from any place or level across the blueprint, which will retain it’s subdiagram

However: Without structure to your diagrams, it will be very hard to understand where you are in the diagrams

– And where you will end up when you follow a drill-path

13



Abstraction Levels Blueprint Director is centered around

diagrams and subdiagrams – Think about the ”drill path”: What is the difference

between the current level and the next

Objects are defined only once, but ”borrowed” in other subdiagrams

– ”Borrowed” objects retain their subdiagrams, which means that objects borrowed to different levels would result in an unclear drill path

– If an abstraction level is consistent and coherent, an object can be made to exist on only one level

In order easen the navigation through the diagrams it is important to:

– Have consistent levels, with a clear purpose, for example:

– Define the scope, Pattern selection, Design, Actual Metadata Object, etc

– Keep the number of levels as low as possible

Level 1 (Scope)

Describe the scope of the functional area in a business context (presentable to ”any” business stakeholder)Diagrams at this level will be End to End

Level 2 (Pattern)

Describe the chosen pattern(s) for this functional area. This should connect to the different guidelines/component model for each vertical. As well as breaking down in detail. This level is more individual and diagrams will be more specific to each vertical.

Level 3 (Design)

Describe the design for the individual flows. Will be diveded into two types of diagrams: Source to Data (load) and User to Data (read)

Exam

ple of what IB

M G

BS

used in the project

14



Areas of Architecture & Intersections

Depending on the solution, different areas need to be included– For a BI/DW project, a good starting point is the areas defined in the standard Business Intelligence

template, which comes with Blueprint Director from the start

– (Data Sources, Data Integration, Data Repositories, Analytics, Consumers)

For each intersection between the Abstraction Levels and the Areas of Architecture - who is the audience for the models (diagrams/subdiagrams)?

– What do you want to show on the Scope level and the Data Sources area?

– Source system domains, actual source systems, etc?

– What do you want to show on the Design level for the Analytics area?

– Is it an actual report with it’s connections to data mart entities, the Cognos framework, an entire package or a specific KPI?

Also think about which tool is the ”Receiver” for the intersections– Many things you will define, will very clearly map to one or more other tools in the InfoSphere suites.

– An ”ETL” object on the lowest level should map to at least one mapping spec (for example in FastTrack) and at least one DataStage job

– A ”Data Element” should relate to one or more logical entities in a data modelling tool, for example IDA



Using the tool – How have GBS BAO used the tool


Mattias Jönsson

16



Usage of Blueprint Director

In a currently ongoing Data Warehouse project in a Telco company, we have primarily used it for:

– Documenting solution scope

– For functional system overviews– For data flows from source systems to BI consumers

– Design governance

– Ensuring consistency across four delivery streams for Staging and EDW processing on the ETL side– Documenting and managing dependencies across delivery streams

Reverse engineer – data model already created! No method used in BPD – we have BI Method

It is not the only piece of architecture/design documentation we have, but acts as one central piece

The project have just started migrating to Information Server 8.5, which means we have not been able to work with linking to actual metadata objects



Examples from a Telco project


Mattias Jönsson

18



Data loading flow

Data reading flow

19



20



Limitations

Blueprint Director is still a very new tool on the InfoSphere platform, so of course some limitations exist

Some of the most apparent ones are for example:– It is not possible to have multiple objects using the same subdiagram, which might be

desired if for example reuseable objects are used

– Having multiple users working on the same blueprint is a challenge, since the tool is file based

– Copying and/or moving (Cut/Copy/Paste) between Abstraction Layers or Areas of Architecture might be tricky – so think before you draw!

We have regular meetings with Product Managers for BPD, where we feed back our findings and questions – so expect many of the limitations mentioned above to be addressed in later versions!

(We are currently going to upgrade to Fixpack 1 for Blueprint Director, so some of these limitations might have been solved already)

21



Usage of BPD after a delivery project is finalised

We are currently analysing the benefits of using BPD in a ”Business as Usual” situation

– The functionality of linking blueprints to actual InfoSphere objects and metadata assets could be ideal for the overview

– It requires some effort to re-iterate the BPD work to align it with the actual implementation

– We have started to assess this, but will continue to do so over the course of our ongoing project



Questions?


Mattias Jönsson

experiences from using blueprint director in a data warehouse project

Documents