-
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
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 ibm.com/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.
-
ibm.com/developerWorks/ developerWorks
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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
-
developerWorks ibm.com/developerWorks/
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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.
-
ibm.com/developerWorks/ developerWorks
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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.
-
developerWorks ibm.com/developerWorks/
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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.
-
ibm.com/developerWorks/ developerWorks
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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.
-
developerWorks ibm.com/developerWorks/
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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
-
ibm.com/developerWorks/ developerWorks
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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
-
developerWorks ibm.com/developerWorks/
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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.
-
ibm.com/developerWorks/ developerWorks
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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
-
developerWorks ibm.com/developerWorks/
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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.
-
ibm.com/developerWorks/ developerWorks
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
Page 15 of 24
Figure 15. Extending the palette
Figure 16. Identifying the new element
-
developerWorks ibm.com/developerWorks/
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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.
-
ibm.com/developerWorks/ developerWorks
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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
-
developerWorks ibm.com/developerWorks/
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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.
-
ibm.com/developerWorks/ developerWorks
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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
-
developerWorks ibm.com/developerWorks/
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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.
-
ibm.com/developerWorks/ developerWorks
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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.
-
developerWorks ibm.com/developerWorks/
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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.
-
ibm.com/developerWorks/ developerWorks
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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/)
-
developerWorks ibm.com/developerWorks/
Best practices for IBM InfoSphere Blueprint Director, Part
2:Designing information blueprints from the ground up
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