Download - 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 ([email protected])STSM, Asset Development, Industry SolutionsIBM

Martin Oberhofer ([email protected])Senior IT Architect, Enterprise Information ArchitectureIBM

Harald Smith ([email protected])Software 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

Introduction

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 ibm.com/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:

ibm.com/developerWorks/ developerWorks


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



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.



Page 5 of 24

Think about decomposition points Where in your root sketch can you add a sub-diagramentry point which you can unfold to the next more detailed conceptual level?

Note that the advice to avoid excessive detail should be applied also to sub-diagrams. If a diagramon any level is too busy, it is not yet structured well and simplification with a decomposition intomultiple layered diagrams may still be pending.

Figure 3. Avoid excessive details

Information processing flows may be lengthy. Just consider the necessary steps to extract datafrom multiple sources into a staging environment where data analysis, structural alignment, datastandardization, matching, and de-duplication and final transformations before loading it to thetarget are applied.

Generally, we consider it best practice to avoid lengthy and complex data flows across multiplefunctional concerns (extraction, profiling, cleansing, etc.) in a single diagram. They are clutteredand difficult to read and understand. Instead, if practical, abstract from the details by identifyingcoarse-granular functional areas, which provide a high-level overview of the overall informationprocessing flow and decompose each functional area with sub-diagrams. Conceptually, considerthis a divide-and-conquer approach in the design phase. This best practice is illustrated withFigures 4 and 5.

Figure 4. Avoid lengthy information processing flow



Page 6 of 24

Figure 5. Design the base diagram with logical function groups anddecompose them into sub-diagrams

Design for template vs. design for blueprint

An additional consideration needs to be applied if designing a template for broad use vs.a blueprint for a specific project. If you are building a template, such as in Figures 1 and2, for a common data replication pattern, you do not want to go too deep, particularly withsub-diagrams. You want to convey the patterns, and options, allowing the user to readilyremove what is extraneous and focus on what's needed. But many levels of sub-diagramswill be constraining and may box in subsequent users of the template. If a user does notneed anything at the second level, but only lower levels that come from the second level,they cannot delete the second level without removing everything below that, a factor thatcould cause considerable rework.

Additional considerations for managing details:

It is not always easy to keep a diagram clean, particularly after lengthy discussions. Thus, use thenotes and sub-diagram features to capture greater detail. For example, removing excessive datasource elements by grouping them reduces the number of arrows and makes the diagram easierto read.

You should pay particular attention to concept consistency. This problem arises if an element isused as source and target. Since you cannot have an element appear twice in one diagram, youmight need to create a sub-diagram to include the reference or add an additional element thatcan have its own-sub-diagram to contain the reference. Adding methods to elements also helps tounderstand what has to be done.

Documentation is often available in many formats from different sources. When work is performed,it is useful to share with others what has been documented and reported. Create asset links tothese documents, which can be file links or URLs if the documentation is on a website, to helpensure correct understanding. In our example of the data replication architecture pattern, youmight want to point to a document with a list of all projects where this technique has been appliedor a best-practices paper discussing in greater detail the various topologies and their applicability.



Page 7 of 24

Aid the consumer of the blueprint by visually guiding the user exploiting the presence or absenceof links on elements:

Lack of a sub-diagram indicator on an element might indicate that the design work in this areais not yet done.

Lack of asset link(s) may indicate that no requirements, design, or development (e.g.DataStage jobs) has been done so far.

Use the notes feature to add checklists and annotations on what still needs to be done to thediagrams.

Once the blueprint has been developed and a number of diagrams have been created, the searchfunction of Blueprint Director enables you to identify information throughout the blueprint. This isparticularly useful if you are not sure anymore where a specific detail is located.

What belongs on a blueprint?There are common pitfalls in designing a blueprint, which should be avoided. (A more in-depthdiscussion is done in the subsequent sections on metadata and physical deployment landscapes.)

Development artifacts are usually not appropriate to be shown as elements on their own in adiagram. The appropriate means to incorporate them is the asset-linking feature connecting theseartifacts to a blueprint. In a diagram, you should focus on conceptual deployment artifacts, such asdata stores and functional processing steps. An illustration of this pitfall is shown in Figure 6.

Figure 6. Avoid the placement of development artifacts into blueprints

Avoid placing tools used to construct the solution into the blueprint, as shown in Figure 7.Basically, they are irrelevant from an information-flow perspective, adding complexity andconfusion. Also note that the same architecture shown in a solution might be able to be built withtools from different software vendors. Therefore, particularly for blueprints capturing reusablearchitectures, it is usually best practice to avoid tying the blueprints to particular software. Thediscussion of applicable tools should be handled through a method describing best practices onrealization, and artifacts created by the tools mentioned in the method should be linked using theasset-linking feature.



Page 8 of 24

Figure 7. Avoid placing tools into blueprints

You should place method or process step describing the sequence of task to construct the solutionin a blueprint, as shown in Figure 8. Method and process steps are best captured in the linkedmethod. Again, this mistake violates the concept to focus on information flows in the blueprints andjust adds cluttering detail, which distracts the user from understanding how the information flowsby mixing in details on how to construct the solution.

Figure 8. Avoid putting method steps into the blueprint

Using grouping containers

Creating a readable diagram sometimes requires grouping related artifacts visually. Some paletteelements are designed to support this requirement, such as the Domain and Asset Set element, asshown in Figure 9.



Page 9 of 24

Figure 9. Container elements like Asset Set in the drawing palette

The elements in the Groups Palette are Asset Set, Domain, and Project. If you need to selectamong them, consider the following aspects:

Visibility of the contained elements:

Domain All elements are visible within the domain grouping. Note that sub-diagramscannot be based on the Domain itself.

Asset Set The constituents of the Asset Set are defined in a sub-diagram and are notvisible within the diagram containing the Asset Set, but sub-diagrams may be connected tothe Asset Set. Example: In the data replication example in figures 1 and 2, the constituentsof the sources and targets were not explicitly named. That's still a task on a sub-diagram,which is fine because these two diagrams provide the baseline concept where the concreteindividual sources and targets are not yet relevant.

Project All elements are visible within the project grouping. Sub-diagrams cannot be basedon the Project itself.

Recommended elements which should be placed into this grouping container:

Domain Any Asset Set In this grouping container-only assets such as databases, applications and

similar entities should be placed. Project Any

Primary use case for grouping container:

Domain This grouping container is ideal for identifying architectural layers, major functionalareas or a grouping of related elements.

Asset Set Abstraction for list of assets in a diagram like lists of source or target systems,etc.



Page 10 of 24

Project This grouping container is ideal for identifying projects or project phases that makeup a changing information landscape. Where milestones are used, it may make sense toassociate specific milestones with specific project containers.

Reusing elements through references

The introductory tutorial on Blueprint Directory (see "Planning an Integration Landscape" inthe Resources section) shows how to use the references feature of Blueprint Director. Whendecomposing a solution architecture into a series of diagrams and sub-diagrams, you need toreuse elements across those diagrams, and the reference feature addresses this need whileavoiding recreation of the same items. The advantage of using references includes reducedamount of maintenance when the properties of an element are changed because there is onlyone place where the change needs to be applied. Furthermore, using references improves theconsistency across diagrams since the same concept won't be represented differently in variousdiagrams because a property change of the element might have been applied on some diagramsand sub-diagrams, but not on all. A certain function used in different areas of the architecture canalso be linked wherever applicable through references. Now, from a best-practices perspective,when working with references, you should consider the following:

Avoid recursive references. It is possible to create a sub-diagram on an element (e.g. anAsset Set), then add that same element as a reference into the sub-diagram. The element inthe sub-diagram will contain the pointer to the sub-diagram you are now on and clicking on itcreates a recursive relationship.

You cannot have the same reference twice on the same diagram (like a database elementreference you would like to use for source and target).

Avoid dangling elements in the context of milestones. Using references in conjunction withmilestones requires careful consideration as to what appears when. Using references onelements with sub-diagrams attached to them that only appear at a later milestone have thepotential to create other dangling elements. You might need to plan for alternative routes insuch a case.

Creating a legible layout

Before you start using Blueprint Director, remember that your internal customers and stakeholdersare used to looking at solution architectures shown to them in Microsoft PowerPoint and Visio,or drawn on whiteboards. Once you start using Blueprint Director, the consumers of the solutionblueprints still need to be able to relate to your blueprints as seamlessly as they were used to inthese other tools. Thus, from a best-practices perspective, the layout must be clear and simple particularly important on the root diagram. To achieve this, you should avoid the mistakes shown inFigure 10:

Cluttering Use sub-diagrams Overlapping elements Use sub-diagrams Crossing connectors Use orthogonal lines Excessive use of containers Only apply them where they really add value Poorly sized elements Resize them appropriately



Page 11 of 24

Figure 10. Avoid these mistakes

Abstracting from the runtimeCreating a blueprint requires the ability to differentiate between functional aspects of the solutionand runtime considerations. A common mistake is to capture the details of the runtime in theblueprint. Figure 11 illustrates the following best practices:

Capture the function of a solution component in the blueprint, not how the component isinternally implemented. You can use the asset-linking feature to attach the runtime artifacts ofthe component to the corresponding element, but the artifacts themselves should not manifestas elements in the solution blueprint.

Capture the logical structure and the relationship of the components through elements andtheir relationships through connectors. Inputs or outputs of elements can again be attached tothem using the asset-linking capability.

Figure 11. Avoid capturing the runtime



Page 12 of 24

Decomposing data flows

A data flow between two systems might involve a large number of individual tasks such asextraction, structural alignment, semantic alignment, standardization, matching and de-duplication,and a final transformation to the data model of a technical load interface. An effort to put all stepsinto a single blueprint might create a single blueprint with excessive details. A solution mightinvolve several data flows between multiple systems exacerbating this problem of a data flowbetween just two systems even further. Thus from a best-practices perspective, we recommendthe following:

Decompose the overall solution into logical, coarse-grained building blocks representing keyrequirements. The logical, coarse-grained building blocks become the top-level componentsin your first blueprint diagram.

Decompose the top-level components by using sub-diagrams incrementally. While applying decomposition steps, use the reference techniques explained earlier to better

illustrate the context of the more detailed definition.

Figure 12 shows how the component Integrate Sources is decomposed using a sub-diagramshowing all the detailed steps, which are required to actually achieve the integration of sources.

Figure 12. Decomposition of data flows

Defining conceptual views

For many solutions,such as data warehousing or master data management, an essential aspectis to provide insight during the design phase into the relationships of certain business entities andhow they are managed at a conceptual level. In this case, decomposing a data warehouse bothinto components for processing (ETL load, etc.) as well as a conceptual view of schemas maybe useful. The schemas might be incrementally decomposed to more fine-grained concepts withnoted properties. This process is shown in figures 13 and 14.



Page 13 of 24

From a best-practices perspective, there are certain guidelines you should follow when usingconceptual views:

The decomposition for conceptual views is a free-form approach for the schemas andis neither intended nor capable of replacing the necessary data model creation usingappropriate object or entity-relationship modeling techniques. Such modeling should continueto happen in tools like IBM InfoSphere Data Architect. If you have Blueprint Director installedand shell-shared with InfoSphere Data Architect, it is possible once a conceptual view ofthe schema has been created in Blueprint Director to start the actual data modeling workin InfoSphere Data Architect (and also seamlessly switch back to Blueprint Director in caseduring the actual data modeling work a need to change the conceptual view has beendiscovered).

The decomposition and creation of conceptual views for a schema is ideally driven andgoverned by standard glossary definitions. Thus, entities in a conceptual view should belinked to the appropriate terms in InfoSphere Business Glossary.

As a result of creating conceptual views, you create and capture the key concepts of this part ofthe solution and are able to communicate them to appropriate audiences.

Figure 13. Creating a conceptual schema



Page 14 of 24

Figure 14. Decomposing a conceptual schema

Extending the palette

Designing your solution blueprints always has the objective of communicating critical aspects ofthe solution to other users. Therefore, you may identify the need to create elements for specificoperations or systems in your IT environment that are easily distinguished from others. Extendingthe drawing palette with your own elements is supported by Blueprint Director. The process issimple and straightforward:

1. Go to the Blueprint Menu and select Extend Palette.2. Select Add Element, as seen in Figure 15. Note the presence of other custom elements

already added in the Drawer lists.3. Name your new element as seen in Figure 16, select the relevant Drawer for it, and provide

the locations for the small icon to a 16x16 pixel file and for the large icon to a 32x32 pixel file(these icons will represent your new element graphically).

4. Optionally, assign additional properties, such as a Name or Description, for the specificinstance (see Figure 17).

5. Click Finish when you are done.

If you save and distribute your blueprint, these new palette elements are distributed with thoseblueprints or templates automatically. Note that you can also change and extend existing elementsin the palette.



Page 15 of 24

Figure 15. Extending the palette

Figure 16. Identifying the new element



Page 16 of 24

Figure 17. Adding attribute properties to your new element

From a best-practices perspective, we advise not to extend the palette arbitrarily. The key decisionpoint is to make reasonable decisions between visual clarity vs. too much information (i.e. toomany visual images for people to keep track of). The purpose of an element in the palette is to:

Provide distinct icons help to differentiate among elements that are not the same. Avoid having too many icons as that defeats the purpose because the user will be unable to

recognize all of them.

You need to strike a balance between adding for clarity and adding for the sake of havingsomething different.

The information blueprint

Large-scale information-intensive solutions typically process data from a wide range of persistentforms, such as files, different forms of databases, content stores, etc., as well as processingthat data through a wide range of data integration techniques, such as data federation, ETL,information service, and change data capture.

The range of technologies and patterns in use could be considered unbounded, each with its owntooling, methods, and approach to metadata management. An information blueprint may be bestthought of as a logical representation of the information-intensive solution and all of its many parts.An information blueprint typically expresses a top-level abstraction of the entire solution, supportedby multiple layers of decomposition of segments of the solution, illustrating the interaction ofcomponents of the solution, as seen in Figure 18.



Page 17 of 24

Figure 18. Reviewing an information blueprint

This information blueprint can provide limited value simply as a diagram. A true informationblueprint must be both linked and actionable. Being linked and actionable means that the blueprintis connected to and interacting with the tooling being used to construct the components of theinformation-intensive solution.

Theoretically, an information blueprint can be linked to and interacting with any artifacts or tools,but for simplicity, we can consider two main forms of linking:

Linking to the metadata artifacts of the solution Linking to the development deployment tooling and artifacts supporting the solution

It is worth nothing that there can be some degree of overlap here. Metadata-aware tooling, forexample, will typically contain the metadata of components of the solution (for any of the threemetadata forms discussed earlier) and the development artifacts being used to construct specificcomponents of the solution.

Linking to the metadata landscapeMetadata, also known as data about data, describes data structures from a range of differentperspectives, including business metadata (business terms and regulations applicable for a



Page 18 of 24

specific type of information like employee, for example); technical metadata (the logical andphysical structure of data in terms of logical and physical data models, for example); andoperational metadata (runtime details of an ETL job, such as the runtime and duration and numberof rows processed, for example). It is important to note that this metadata should not be seen as aset of interesting, but disconnected structures. Rather, this metadata becomes most useful when itis seen as an interconnected web of artifacts where the edges between these artifacts have clearlyunderstood semantics depending on the artifacts involved and the relationship type considered.

For example, customer information exists in many enterprises in many IT systems with differentlogical and physical data models, which can be linked to the same business term "customer"in an enterprise glossary. A central MDM system might act as the trusted source of informationfrom which the customer information is fed to the numerous consuming systems with differenttransformations mapping it from the customer data model in MDM to the various data models ofits consumers. Deciding to change the MDM data model in such an environment is something thatcannot be done without considering the impact to the related artifacts in environment. Thus, whenlooking at the metadata landscape, the following aspects need to be considered separately:

Lifecycle management Where change management is an important aspect, capabilitiessuch as data lineage (where is the data I am looking at coming from?) and impact analysis(how many artifacts are affected if a certain change is applied?) exploiting metadata are keytechniques for governing change management.

Design and development aspect Metadata is obviously a critical part in any datadesign or data development project. Data models (the data about the data of the systemsupposedly build or changed) are developed during the design phase and is a key input forthe development work of ETL jobs, etc.

With that in mind, the metadata landscape can be characterized as an information landscape itself,below the level of a common business view because it represents insight into how informationis grouped and managed. From a best-practices perspective, we advise that you incorporatea metadata landscape as a sub-diagram under a given information landscape. This helps tounderstand how glossaries and models support a given data structure and where change/lifecyclemanagement needs to be applied in the target view. With such a metadata landscape diagramavailable, you also get the following advantages:

You have a place to link directly to assets representing these metadata components. You can build out conceptual maps under this metadata landscape.

Note that such a structure might require encapsulation into a reference object if the metadatalandscape supports multiple components. An example of a metadata landscape is shown in Figure19.



Page 19 of 24

Figure 19. An example metadata landscape

In the metadata landscape shown above, it is not the individual glossary elements, logical entities,or physical models that are included. It is the store of such items, treated as data, that is included,which makes this metadata landscape another instance of an information blueprint. Modelingremains the province of modeling tools, but the understanding of how the metadata as informationflows or moves from point to point is captured and understood.

The physical deployment landscape

The physical deployment landscape is another view on the information landscape. Understandingwhich products are utilized to manage the information landscape or how information assetsare deployed in a production landscape is information you expect from this view. Note that it'sconsidered best practice that the tools used to construct the solution are described through themethod and the tool artifacts are linked to the blueprint diagrams with the asset linkers. However,from a lifecycle management and a change management perspective, understanding the physicalstructures of a solution become important.

As part of the solution represented in Blueprint Director through diagrams, you might want toinclude a sub-diagram to visualize the deployment view in terms of the development, test, andproduction environments, illustrating how assets linked to the solution blueprint developed inthe development environment are propagated through the test processes to the productionenvironment. From a best-practices perspective, you might want to consider applying the followingdesign considerations:

Create one blueprint showing all the environments Create a blueprint per environment showing the details

Figure 20 shows that for an SAP consolidation project, there is an InfoSphere Information Serverenvironment for each SAP environment configured for development, test, and production. Jobsextracting or loading data to SAP systems might have ABAP code components. As shownin Figure 20, these ABAP code components are only permitted to be uploaded into the SAPdevelopment system from the Information Server (IIS) development system. They are propagatedon the SAP side from development to test and from test to production. This approach is followedon the Information Server side to ensure that in the test and production environments, all code



Page 20 of 24

artifacts are read-only, and that any change must be done in the development environment andpropagated through the appropriate test cycle again to the SAP production system. As illustratedwith this example, you can use Blueprint Director to establish an architectural view supportinghow code (or parameter configuration, patches, etc.) have to be propagated to test and productionenvironments.

As a side note, the SAP application icon shown in Figure 20 is a palette extension developedfor an SAP consolidation use case and gives you a concrete example how you can use paletteextensions in your own blueprints.

Figure 20. Environments

In Figure 20, for each environment, the actual physical deployment topology is not shown yet toavoid excessive detail in a blueprint. For each environment, you can see the yellow +, indicatingwe added sub-diagrams for more detail. Figure 21 shows the detail for the InfoSphere InformationServer (IIS) Development system. As you can see, Information Server is installed across fivephysical nodes:

One application node (ISD) Three nodes for three instances of the DataStage parallel Engine (PX1 to PX3) One node for the metadata repository (XMETA)

All five nodes of the primary system are in one data center (IT Location 1). For the primary systemfor high availability and disaster recovery (HADR) reasons, a secondary system in a different datacenter (IT Location 2) is configured. Such a configuration for an IIS development system might berequired if the data migration development team consists of several dozen developers (we haveseen projects with 50-150 developers on an IIS development system) distributed across variousgeographies demanding an environment with 24-hour availability at least from Monday throughFriday.



Page 21 of 24

Figure 21. Physical topology for IIS development system

By capturing this deployment architecture in a blueprint, it's easy to communicate:

There is a requirement to the administrator team for education to configure and operate aHADR deployment of IIS.

Precautions are needed for business stakeholders to make systems available and resilientaccording to requirements to use, for example, offshore resources for cost reasons.

Backup/restore procedures need to be more advanced due to the advanced deploymenttopology.

Changing requirements and their impact on the physical deployment topology can becommunicated.

These are examples only, but they illustrate the usefulness of using Blueprint Director tocommunicate the physical deployment topology of a solution architecture and an InformationBlueprint to different audiences like administrators, developers, project managers, and businessstakeholders.

ConclusionIBM InfoSphere Blueprint Director provides the capability for you to communicate a vision of yourinformation landscape to your organization and broader team. In this article, you have:

Reviewed best practices in creating your own effective blueprints from scratch. Learned about the benefits for creating and managing blueprints, visualizing the metadata

landscape based on best practices. Learned that you can incorporate the physical deployment landscape into your information

blueprint based on best practices.

By following these best practices, you can focus more closely on the critical aspect ofcommunication to drive your projects forward. Clarity in presentation, consistent understanding,and an ability to view all aspects of the information landscape for your project at varying levels allhelp facilitate this process.



Page 22 of 24

Resources

Learn

For best practices in using an information blueprint in a project context, see "Best practicesfor IBM InfoSphere Blueprint Director, Part 1: Working within a project lifecycle."

Learn about examples of Information Server SAP Packs landscapes in "Security anddeployment best practices for InfoSphere Information Server Pack for SAP applications, Part2: Deployment."

Check out Designing a topology for InfoSphere Information Server. For a tutorial on Blueprint Director, see "Designing an integration landscape with IBM

InfoSphere Foundation Tools and Information Server, Part 1: Planning an integrationlandscape."

For basic information about using Blueprint Director, see IBM InfoSphere Blueprint Director. Learn more about Information Management at the developerWorks Information Management

zone. Find technical documentation, how-to articles, education, downloads, productinformation, and more.

Stay current with developerWorks technical events and webcasts. Follow developerWorks on Twitter.

Get products and technologies

Build your next development project with IBM trial software, available for download directlyfrom developerWorks.

Now you can use DB2 for free. Download DB2 Express-C, a no-charge version of DB2Express Edition for the community that offers the same core data features as DB2 ExpressEdition and provides a solid base to build and deploy applications.

Discuss

Check out the developerWorks blogs and get involved in the developerWorks community.



Page 23 of 24

About the authors

Brian Byrne

Brian Byrne was the lead architect behind InfoSphere Blueprint Director, bringing 15years of experience in the architecture, design, and implementation of large-scaledata architectures and tooling, to the creation of a new paradigm for the design andspecification of data integration architectures. His current role involves bringing thisexperience in information management to IBM Industry Solutions.

Martin Oberhofer

Martin Oberhofer works as senior IT architect in Enterprise Information Architecturewith large clients worldwide. He helps customers to define their enterprise informationstrategies and architectures, solving information-intense business problems. Hisareas of expertise include master data management based on an SOA, datawarehousing, information integration and database technologies. He especially likesto work with enterprises running SAP applications. Martin provides in a lab advocate-role expert advice for information management to large IBM clients. He started hiscareer at IBM in the IBM Silicon Valley Lab at the beginning of 2002 and is currentlybased in the IBM Research & Development Lab in Germany. He co-authored thebooks Enterprise Master Data Management: An SOA Approach to Managing CoreInformation and The Art of Enterprise Information Architecture: A Systems-BasedApproach for Unlocking Business Insight, as well as numerous research articlesand developerWorks articles. As inventor, he contributed to more than 30 patentapplications for IBM. He is also an The Open Group Master Certified IT Architect andholds a master's degree in mathematics from the University of Constance/Germany.

Harald Smith

With nearly 30 years in IT and software development, Harald Smith has focused onthe design and delivery of information integration and information quality solutionsand products, including methods and best practices.

Copyright IBM Corporation 2012(www.ibm.com/legal/copytrade.shtml)Trademarks(www.ibm.com/developerworks/ibm/trademarks/)



Page 24 of 24

Table of ContentsIntroductionBest practices for creating and modifying blueprintsManaging detailWhat belongs on a blueprint?Using grouping containersReusing elements through referencesCreating a legible layoutAbstracting from the runtimeDecomposing data flowsDefining conceptual viewsExtending the palette

The information blueprintLinking to the metadata landscapeThe physical deployment landscape

ConclusionResourcesAbout the authorsTrademarks

Download - blue print 1

Top Related