blue print 1

Download blue print 1

Post on 05-Oct-2015




0 download

Embed Size (px)


blue print 1


  • Copyright IBM Corporation 2012 TrademarksBest practices for IBM InfoSphere Blueprint Director, Part 2:Designing information blueprints from the ground up

    Page 1 of 24

    Best practices for IBM InfoSphere Blueprint Director,Part 2: Designing information blueprints from theground upBrian Byrne (, Asset Development, Industry SolutionsIBM

    Martin Oberhofer ( IT Architect, Enterprise Information ArchitectureIBM

    Harald Smith ( ArchitectIBM

    01 November 2012

    This article provides best practices using InfoSphere Blueprint Director. Understandingand applying these best practices enables you to create new architecture blueprints that areeffective and actionable. It is intended for experienced users of InfoSphere Blueprint Director.

    View more content in this series


    IBM InfoSphere Blueprint Director is a member of the IBM InfoSphere Foundation Tools portfolio.Blueprint Director is aimed at the information architect designing solution architectures forinformation-intensive projects. A thorough introduction to Blueprint Director is in an introductorytutorial titled "Planning an Integration Landscape." Based on understanding the functionality ofBlueprint Director, we provided a first best-practices article working with blueprint templates here:"Best practices for IBM InfoSphere Blueprint Director, Part 1: Working within a project lifecycle."We assume for the purpose of this article that you are familiar with the content of the introductorytutorial and have hands-on experience with Blueprint Director.

    Our purpose here is to provide best practices for users of Blueprint Director to create your ownblueprints from scratch. In addition, we provide guidance on how to use Blueprint Director toincorporate metadata landscapes as well as physical Information Server landscapes as part of thespecific information landscape. The best practices provided in this article are needed for:

  • developerWorks

    Best practices for IBM InfoSphere Blueprint Director, Part 2:Designing information blueprints from the ground up

    Page 2 of 24

    Creation of legible blueprints from scratch Since one of the main purposes of usingBlueprint Director is to effectively communicate a specific solution architecture, alternatesolution architectures and their various advantages and disadvantages or the impact ofchange requests to a solution architecture, clarity in the blueprints is critical. We provide acomprehensive list of best practices to create legible and effective blueprints from scratch. Wealso include best practices on adding palette extensions.

    Metadata landscapes Information-intense projects are usually complex and involvebusiness, technical, and operational metadata, which is interlinked and interconnected. Achallenge from a project management perspective is to understand how a feature changerequest on a process level affects the information structures supporting the businessprocesses. Without the ability to understand whether a change request is coming in whichdata models, ETL jobs, etc. would be affected by the change, it's hard to control and managechange effectively over time. Using Blueprint Director to visualize the metadata landscape(as an information landscape itself) helps you, the information architect, to quickly understandwhere you need to look to understand the impact of such change. We provide best practiceson metadata landscapes.

    Physical deployment landscapes Platforms including IBM InfoSphere Information Serveror InfoSphere Master Data Management (MDM) are often deployed on multiple physicalnodes (see Resources) for a single environment used for sandbox, development, test,preproduction and production. In addition, in more complex scenarios like SAP consolidationprojects, managing code artifacts for Information Server also requires management of thecorresponding ABAP code artifacts and SAP configurations consistently across SAP andInformation Server development, test, and production environments (see SAP Packs inResources). To ensure proper code propagation, backup/restore, migration, and fixpackdeployment best practices across such infrastructures, it is helpful to communicate the layoutof the infrastructure to administrators, developers, and project managers. We provide bestpractices how Blueprint Director can be used to develop such blueprints.

    This article will help you:

    Learn how to create effective blueprints from scratch. See how to apply Blueprint Director to understand and manage metadata landscapes. See how to use Blueprint Director to visualize the physical deployment landscape.

    Best practices for creating and modifying blueprintsWhen you reach the conclusion that you cannot reuse an existing blueprint template but needto create a blueprint from scratch, the question arises how to decompose the overall solutioninto a layered set of blueprint diagrams. For an illustration, let us use a simple example. As aninformation architect, you might have the need for information integration among systems in yourenterprise. For the solution architects in your IT department who handle the design for specificprojects in the business units, you would like to provide prescriptive guidance on when to usewhich information integration pattern and, for the identified patterns, which variations exist andwhen they are generally applied. Identifying these patterns, you might see the need for threedistinct pattern areas for ETL, federation, and data replication. Focusing now on data replication,the following architectural characteristics of the architecture pattern might be identified:

  • developerWorks

    Best practices for IBM InfoSphere Blueprint Director, Part 2:Designing information blueprints from the ground up

    Page 3 of 24

    Data replication is capturing changes on one or multiple sources and replicates them to one ormultiple targets.

    For capturing the changes, at least two techniques exist at the database level with advantages anddisadvantages:

    Trigger-based capture of changes Transactional log-based capture of changes

    There are at least four recognized data replication topologies:

    Unidirectional replication between a source and a target system Bidirectional replication between a source and a target system requiring considerations on

    possible conflicts and their resolution Roll-up replication is a typical scenario in data warehousing environments where data from

    multiple data sources is replicated to a single target: the data warehousing system Distributed replication occurs in typical scenarios like replication from a central data

    warehouse to local data marts or from a central master data management system intomultiple targets consuming master data

    Data volume: This metric determines how many capture and apply agents might need to operatein parallel on sources and targets to achieve the throughput required and might also affect thephysical structure and location of the systems involved.

    Figures 1 and 2 show a possible result to decompose the replication architecture pattern. Asyou can see, not all of the above-noted characteristics have been placed into a single diagram.Instead, just the core idea of moving data from one or multiple sources to one or multiple targets isshown at the high level.

    Figure 1. Basic structure of the replication pattern

    Then, by creating a sub-diagram related to the replication function, we proceed into the nextdiagram (see Figure 2). Here, a decision has been made to show that the replication topologiesmight look different depending on the use case. However, details on which capture and applytechniques, which concrete systems are involved, etc. are not yet included, so the diagram

  • developerWorks

    Best practices for IBM InfoSphere Blueprint Director, Part 2:Designing information blueprints from the ground up

    Page 4 of 24

    focuses clearly on the topology idea. With these two diagrams, a reusable structure for the datareplication architecture pattern is created, which can be tailored in any concrete project withadditional diagrams to concrete systems and physical considerations of the solution landscape.

    Figure 2. Sub-diagram introducing the four topologies

    So, for the information architect, the question arises as to how to put all these characteristics intoone or multiple diagrams in a blueprint within Blueprint Director. For the root diagram, the keydesign point is to keep it simple. It is the first impression of the solution you propose and excessivedetail prevents others from getting the core idea of the solution.

    Following this example, let us consider the best practices applied here, which we will introduce inturn:

    Managing detail What belongs on a blueprint? Using grouping containers Reusing elements through references Creating a legible layout Abstracting from the runtime Considerations for metadata landscapes Considerations for physical landscapes

    Managing detail

    When you start to create a blueprint, the first diagram (the root diagram) shown creates the firstimpression. As noted, the key for this first diagram is to really keep it simple. In the example withthe replication architecture pattern, as shown in Figure 1, this best practice has been appliedbecause the solution architecture shown has been reduced to its minimal number of constituents:One or multiple source and target systems between which a data replication pattern is applied.Thus, on the root diagram, you should apply the following considerations:

    Avoid excessive details Instead, reduce to the core constituents (see Figure 3). Identify the core components detailed on subsequent sub-diagrams.