Experiences from using Blueprint Director in a Data Warehouse project

1. 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. 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

3. Short introduction of the tool - Why does it exist and where does it fit in? Experiences from using Blueprint Director in a Data Warehouse project 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. Diagram for a blueprint Overview of the interface • Method browser (displaying method content) • Asset browser (browsing metadata repository) • Glossary explorer (showing glossary tree view) Palette free form “sketching” elements • Outline (zoom in/out view) • Blueprint explorer (shows tree view of the elements in the blueprint) Context specific property view

7. Top-down & business-driven design Element in diagramrepresenting dimensional store • 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 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 architectureand 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. 360° view: project vision + business + technical artifacts • 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

11. Think before you draw - Abstraction Layers and Areas of Architecture Experiences from using Blueprint Director in a Data Warehouse project 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 Example of what IBM GBS 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

15. Using the tool – How have GBS BAO used the tool Experiences from using Blueprint Director in a Data Warehouse project 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

17. Examples from a Telco project Experiences from using Blueprint Director in a Data Warehouse project Mattias Jönsson

18. Data loading flow Data reading flow

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

22. Questions? Experiences from using Blueprint Director in a Data Warehouse project Mattias Jönsson