Blue Print 1

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

ground up
Brian Byrne (byrneb@us.ibm.com)
STSM, Asset Development, Industry Solutions
IBM
01 November 2012
Martin Oberhofer (martino@de.ibm.com)

Senior IT Architect, Enterprise Information Architecture
IBM
Harald Smith (smithha@us.ibm.com)
Software Architect
IBM
This article provides best practices using InfoSphere Blueprint Director. Understanding
and applying these best practices enables you to create new architecture blueprints that are
effective 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 for
information-intensive projects. A thorough introduction to Blueprint Director is in an introductory
tutorial titled "Planning an Integration Landscape." Based on understanding the functionality of
Blueprint 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 introductory
tutorial and have hands-on experience with Blueprint Director.
Our purpose here is to provide best practices for users of Blueprint Director to create your own
blueprints from scratch. In addition, we provide guidance on how to use Blueprint Director to
incorporate metadata landscapes as well as physical Information Server landscapes as part of the
specific information landscape. The best practices provided in this article are needed for:
Copyright IBM Corporation 2012
Best practices for IBM InfoSphere Blueprint Director, Part 2:
Designing information blueprints from the ground up
Trademarks
Page 1 of 24
developerWorks
ibm.com/developerWorks/
Creation of legible blueprints from scratch Since one of the main purposes of using
Blueprint Director is to effectively communicate a specific solution architecture, alternate
solution architectures and their various advantages and disadvantages or the impact of
change requests to a solution architecture, clarity in the blueprints is critical. We provide a
comprehensive list of best practices to create legible and effective blueprints from scratch. We
also include best practices on adding palette extensions.
Metadata landscapes Information-intense projects are usually complex and involve
business, technical, and operational metadata, which is interlinked and interconnected. A
challenge from a project management perspective is to understand how a feature change
request on a process level affects the information structures supporting the business
processes. Without the ability to understand whether a change request is coming in which
data models, ETL jobs, etc. would be affected by the change, it's hard to control and manage
change effectively over time. Using Blueprint Director to visualize the metadata landscape
(as an information landscape itself) helps you, the information architect, to quickly understand
where you need to look to understand the impact of such change. We provide best practices
on metadata landscapes.
Physical deployment landscapes Platforms including IBM InfoSphere Information Server
or InfoSphere Master Data Management (MDM) are often deployed on multiple physical
nodes (see Resources) for a single environment used for sandbox, development, test,
preproduction and production. In addition, in more complex scenarios like SAP consolidation
projects, managing code artifacts for Information Server also requires management of the
corresponding ABAP code artifacts and SAP configurations consistently across SAP and
Information Server development, test, and production environments (see SAP Packs in
Resources). To ensure proper code propagation, backup/restore, migration, and fixpack
deployment best practices across such infrastructures, it is helpful to communicate the layout
of the infrastructure to administrators, developers, and project managers. We provide best
practices 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 blueprints

When you reach the conclusion that you cannot reuse an existing blueprint template but need
to create a blueprint from scratch, the question arises how to decompose the overall solution
into a layered set of blueprint diagrams. For an illustration, let us use a simple example. As an
information architect, you might have the need for information integration among systems in your
enterprise. For the solution architects in your IT department who handle the design for specific
projects in the business units, you would like to provide prescriptive guidance on when to use
which information integration pattern and, for the identified patterns, which variations exist and
when they are generally applied. Identifying these patterns, you might see the need for three
distinct pattern areas for ETL, federation, and data replication. Focusing now on data replication,
the following architectural characteristics of the architecture pattern might be identified:
Page 2 of 24
developerWorks
Data replication is capturing changes on one or multiple sources and replicates them to one or
multiple targets.
For capturing the changes, at least two techniques exist at the database level with advantages and
disadvantages:
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 into
multiple targets consuming master data
Data volume: This metric determines how many capture and apply agents might need to operate
in parallel on sources and targets to achieve the throughput required and might also affect the
physical structure and location of the systems involved.
Figures 1 and 2 show a possible result to decompose the replication architecture pattern. As
you 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 is
shown 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 next
diagram (see Figure 2). Here, a decision has been made to show that the replication topologies
might look different depending on the use case. However, details on which capture and apply
techniques, which concrete systems are involved, etc. are not yet included, so the diagram
Page 3 of 24
developerWorks
focuses clearly on the topology idea. With these two diagrams, a reusable structure for the data
replication architecture pattern is created, which can be tailored in any concrete project with
additional 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 into
one or multiple diagrams in a blueprint within Blueprint Director. For the root diagram, the key
design point is to keep it simple. It is the first impression of the solution you propose and excessive
detail 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 in
turn:
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 first
impression. As noted, the key for this first diagram is to really keep it simple. In the example with
the replication architecture pattern, as shown in Figure 1, this best practice has been applied
because 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 4 of 24
developerWorks
Think about decomposition points Where in your root sketch can you add a sub-diagram
entry 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 diagram
on any level is too busy, it is not yet structured well and simplification with a decomposition into
multiple layered diagrams may still be pending.
Figure 3. Avoid excessive details
Information processing flows may be lengthy. Just consider the necessary steps to extract data
from multiple sources into a staging environment where data analysis, structural alignment, data
standardization, matching, and de-duplication and final transformations before loading it to the
target are applied.
Generally, we consider it best practice to avoid lengthy and complex data flows across multiple
functional concerns (extraction, profiling, cleansing, etc.) in a single diagram. They are cluttered
and difficult to read and understand. Instead, if practical, abstract from the details by identifying
coarse-granular functional areas, which provide a high-level overview of the overall information
processing flow and decompose each functional area with sub-diagrams. Conceptually, consider
this a divide-and-conquer approach in the design phase. This best practice is illustrated with
Figures 4 and 5.
Figure 4. Avoid lengthy information processing flow

Page 5 of 24
developerWorks
Figure 5. Design the base diagram with logical function groups and
decompose 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 and
2, for a common data replication pattern, you do not want to go too deep, particularly with
sub-diagrams. You want to convey the patterns, and options, allowing the user to readily
remove what is extraneous and focus on what's needed. But many levels of sub-diagrams
will be constraining and may box in subsequent users of the template. If a user does not
need 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 that
could cause considerable rework.
Additional considerations for managing details:

It is not always easy to keep a diagram clean, particularly after lengthy discussions. Thus, use the
notes and sub-diagram features to capture greater detail. For example, removing excessive data
source elements by grouping them reduces the number of arrows and makes the diagram easier
to read.
You should pay particular attention to concept consistency. This problem arises if an element is
used as source and target. Since you cannot have an element appear twice in one diagram, you
might need to create a sub-diagram to include the reference or add an additional element that
can have its own-sub-diagram to contain the reference. Adding methods to elements also helps to
understand 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 to
these documents, which can be file links or URLs if the documentation is on a website, to help
ensure correct understanding. In our example of the data replication architecture pattern, you
might want to point to a document with a list of all projects where this technique has been applied
or a best-practices paper discussing in greater detail the various topologies and their applicability.
Page 6 of 24
developerWorks
Aid the consumer of the blueprint by visually guiding the user exploiting the presence or absence
of links on elements:
Lack of a sub-diagram indicator on an element might indicate that the design work in this area
is 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 the
diagrams.
Once the blueprint has been developed and a number of diagrams have been created, the search
function of Blueprint Director enables you to identify information throughout the blueprint. This is
particularly 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-depth
discussion 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 a
diagram. The appropriate means to incorporate them is the asset-linking feature connecting these
artifacts to a blueprint. In a diagram, you should focus on conceptual deployment artifacts, such as
data 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 and
confusion. Also note that the same architecture shown in a solution might be able to be built with
tools from different software vendors. Therefore, particularly for blueprints capturing reusable
architectures, it is usually best practice to avoid tying the blueprints to particular software. The
discussion of applicable tools should be handled through a method describing best practices on
realization, and artifacts created by the tools mentioned in the method should be linked using the
asset-linking feature.
Page 7 of 24
developerWorks
Figure 7. Avoid placing tools into blueprints
You should place method or process step describing the sequence of task to construct the solution
in a blueprint, as shown in Figure 8. Method and process steps are best captured in the linked
method. Again, this mistake violates the concept to focus on information flows in the blueprints and
just adds cluttering detail, which distracts the user from understanding how the information flows
by 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 palette
elements are designed to support this requirement, such as the Domain and Asset Set element, as
shown in Figure 9.

Page 8 of 24
developerWorks
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 select
among them, consider the following aspects:
Visibility of the contained elements:
Domain All elements are visible within the domain grouping. Note that sub-diagrams
cannot be based on the Domain itself.
Asset Set The constituents of the Asset Set are defined in a sub-diagram and are not
visible within the diagram containing the Asset Set, but sub-diagrams may be connected to
the Asset Set. Example: In the data replication example in figures 1 and 2, the constituents
of 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 concrete
individual sources and targets are not yet relevant.
Project All elements are visible within the project grouping. Sub-diagrams cannot be based
on 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 functional
areas 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 9 of 24
developerWorks
Project This grouping container is ideal for identifying projects or project phases that make
up a changing information landscape. Where milestones are used, it may make sense to
associate specific milestones with specific project containers.
Reusing elements through references

The introductory tutorial on Blueprint Directory (see "Planning an Integration Landscape" in
the Resources section) shows how to use the references feature of Blueprint Director. When
decomposing a solution architecture into a series of diagrams and sub-diagrams, you need to
reuse elements across those diagrams, and the reference feature addresses this need while
avoiding recreation of the same items. The advantage of using references includes reduced
amount of maintenance when the properties of an element are changed because there is only
one place where the change needs to be applied. Furthermore, using references improves the
consistency across diagrams since the same concept won't be represented differently in various
diagrams because a property change of the element might have been applied on some diagrams
and sub-diagrams, but not on all. A certain function used in different areas of the architecture can
also 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. an
Asset Set), then add that same element as a reference into the sub-diagram. The element in
the sub-diagram will contain the pointer to the sub-diagram you are now on and clicking on it
creates a recursive relationship.
You cannot have the same reference twice on the same diagram (like a database element
reference you would like to use for source and target).
Avoid dangling elements in the context of milestones. Using references in conjunction with
milestones requires careful consideration as to what appears when. Using references on
elements with sub-diagrams attached to them that only appear at a later milestone have the
potential to create other dangling elements. You might need to plan for alternative routes in
such a case.
Creating a legible layout

Before you start using Blueprint Director, remember that your internal customers and stakeholders
are 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 solution
blueprints still need to be able to relate to your blueprints as seamlessly as they were used to in
these 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 in
Figure 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 10 of 24
developerWorks
Figure 10. Avoid these mistakes
Abstracting from the runtime

Creating a blueprint requires the ability to differentiate between functional aspects of the solution
and runtime considerations. A common mistake is to capture the details of the runtime in the
blueprint. Figure 11 illustrates the following best practices:
Capture the function of a solution component in the blueprint, not how the component is
internally implemented. You can use the asset-linking feature to attach the runtime artifacts of
the component to the corresponding element, but the artifacts themselves should not manifest
as elements in the solution blueprint.
Capture the logical structure and the relationship of the components through elements and
their relationships through connectors. Inputs or outputs of elements can again be attached to
them using the asset-linking capability.
Figure 11. Avoid capturing the runtime

Page 11 of 24
developerWorks
Decomposing data flows

A data flow between two systems might involve a large number of individual tasks such as
extraction, 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 steps
into a single blueprint might create a single blueprint with excessive details. A solution might
involve several data flows between multiple systems exacerbating this problem of a data flow
between just two systems even further. Thus from a best-practices perspective, we recommend
the following:
Decompose the overall solution into logical, coarse-grained building blocks representing key
requirements. The logical, coarse-grained building blocks become the top-level components
in 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-diagram
showing 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 aspect
is to provide insight during the design phase into the relationships of certain business entities and
how they are managed at a conceptual level. In this case, decomposing a data warehouse both
into components for processing (ETL load, etc.) as well as a conceptual view of schemas may
be useful. The schemas might be incrementally decomposed to more fine-grained concepts with
noted properties. This process is shown in figures 13 and 14.
Page 12 of 24
developerWorks
From a best-practices perspective, there are certain guidelines you should follow when using
conceptual views:
The decomposition for conceptual views is a free-form approach for the schemas and
is neither intended nor capable of replacing the necessary data model creation using
appropriate object or entity-relationship modeling techniques. Such modeling should continue
to happen in tools like IBM InfoSphere Data Architect. If you have Blueprint Director installed
and shell-shared with InfoSphere Data Architect, it is possible once a conceptual view of
the schema has been created in Blueprint Director to start the actual data modeling work
in InfoSphere Data Architect (and also seamlessly switch back to Blueprint Director in case
during the actual data modeling work a need to change the conceptual view has been
discovered).
The decomposition and creation of conceptual views for a schema is ideally driven and
governed by standard glossary definitions. Thus, entities in a conceptual view should be
linked 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 of
the solution and are able to communicate them to appropriate audiences.
Figure 13. Creating a conceptual schema

Page 13 of 24
developerWorks
Figure 14. Decomposing a conceptual schema
Extending the palette

Designing your solution blueprints always has the objective of communicating critical aspects of
the solution to other users. Therefore, you may identify the need to create elements for specific
operations or systems in your IT environment that are easily distinguished from others. Extending
the drawing palette with your own elements is supported by Blueprint Director. The process is
simple 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 specific
instance (see Figure 17).
5. Click Finish when you are done.
If you save and distribute your blueprint, these new palette elements are distributed with those
blueprints or templates automatically. Note that you can also change and extend existing elements
in the palette.

Page 14 of 24
developerWorks
Figure 15. Extending the palette
Figure 16. Identifying the new element

Page 15 of 24
developerWorks
Figure 17. Adding attribute properties to your new element
From a best-practices perspective, we advise not to extend the palette arbitrarily. The key decision
point is to make reasonable decisions between visual clarity vs. too much information (i.e. too
many 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 having
something different.
The information blueprint

Large-scale information-intensive solutions typically process data from a wide range of persistent
forms, such as files, different forms of databases, content stores, etc., as well as processing
that 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 own
tooling, methods, and approach to metadata management. An information blueprint may be best
thought 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, supported
by multiple layers of decomposition of segments of the solution, illustrating the interaction of
components of the solution, as seen in Figure 18.
Page 16 of 24
developerWorks
Figure 18. Reviewing an information blueprint
This information blueprint can provide limited value simply as a diagram. A true information
blueprint must be both linked and actionable. Being linked and actionable means that the blueprint
is connected to and interacting with the tooling being used to construct the components of the
information-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, for
example, will typically contain the metadata of components of the solution (for any of the three
metadata forms discussed earlier) and the development artifacts being used to construct specific
components of the solution.
Linking to the metadata landscape

Metadata, also known as data about data, describes data structures from a range of different
perspectives, including business metadata (business terms and regulations applicable for a
Page 17 of 24
developerWorks
specific type of information like employee, for example); technical metadata (the logical and
physical structure of data in terms of logical and physical data models, for example); and
operational metadata (runtime details of an ETL job, such as the runtime and duration and number
of rows processed, for example). It is important to note that this metadata should not be seen as a
set of interesting, but disconnected structures. Rather, this metadata becomes most useful when it
is seen as an interconnected web of artifacts where the edges between these artifacts have clearly
understood semantics depending on the artifacts involved and the relationship type considered.
For example, customer information exists in many enterprises in many IT systems with different
logical 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 information
from which the customer information is fed to the numerous consuming systems with different
transformations mapping it from the customer data model in MDM to the various data models of
its consumers. Deciding to change the MDM data model in such an environment is something that
cannot be done without considering the impact to the related artifacts in environment. Thus, when
looking at the metadata landscape, the following aspects need to be considered separately:
Lifecycle management Where change management is an important aspect, capabilities
such 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 key
techniques for governing change management.
Design and development aspect Metadata is obviously a critical part in any data
design or data development project. Data models (the data about the data of the system
supposedly build or changed) are developed during the design phase and is a key input for
the 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 information
is grouped and managed. From a best-practices perspective, we advise that you incorporate
a metadata landscape as a sub-diagram under a given information landscape. This helps to
understand how glossaries and models support a given data structure and where change/lifecycle
management needs to be applied in the target view. With such a metadata landscape diagram
available, 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 metadata
landscape supports multiple components. An example of a metadata landscape is shown in Figure
19.

Page 18 of 24
developerWorks
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. Modeling
remains the province of modeling tools, but the understanding of how the metadata as information
flows 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. Understanding
which products are utilized to manage the information landscape or how information assets
are deployed in a production landscape is information you expect from this view. Note that it's
considered best practice that the tools used to construct the solution are described through the
method 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 physical
structures of a solution become important.
As part of the solution represented in Blueprint Director through diagrams, you might want to
include a sub-diagram to visualize the deployment view in terms of the development, test, and
production environments, illustrating how assets linked to the solution blueprint developed in
the development environment are propagated through the test processes to the production
environment. From a best-practices perspective, you might want to consider applying the following
design 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 Server
environment for each SAP environment configured for development, test, and production. Jobs
extracting or loading data to SAP systems might have ABAP code components. As shown
in Figure 20, these ABAP code components are only permitted to be uploaded into the SAP
development system from the Information Server (IIS) development system. They are propagated
on the SAP side from development to test and from test to production. This approach is followed
on the Information Server side to ensure that in the test and production environments, all code
Page 19 of 24
developerWorks
artifacts are read-only, and that any change must be done in the development environment and
propagated through the appropriate test cycle again to the SAP production system. As illustrated
with this example, you can use Blueprint Director to establish an architectural view supporting
how code (or parameter configuration, patches, etc.) have to be propagated to test and production
environments.
As a side note, the SAP application icon shown in Figure 20 is a palette extension developed
for an SAP consolidation use case and gives you a concrete example how you can use palette
extensions in your own blueprints.
Figure 20. Environments
In Figure 20, for each environment, the actual physical deployment topology is not shown yet to
avoid excessive detail in a blueprint. For each environment, you can see the yellow +, indicating
we added sub-diagrams for more detail. Figure 21 shows the detail for the InfoSphere Information
Server (IIS) Development system. As you can see, Information Server is installed across five
physical 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 system
for high availability and disaster recovery (HADR) reasons, a secondary system in a different data
center (IT Location 2) is configured. Such a configuration for an IIS development system might be
required if the data migration development team consists of several dozen developers (we have
seen projects with 50-150 developers on an IIS development system) distributed across various
geographies demanding an environment with 24-hour availability at least from Monday through
Friday.

Page 20 of 24
developerWorks
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 a
HADR deployment of IIS.
Precautions are needed for business stakeholders to make systems available and resilient
according to requirements to use, for example, offshore resources for cost reasons.
Backup/restore procedures need to be more advanced due to the advanced deployment
topology.
Changing requirements and their impact on the physical deployment topology can be
communicated.
These are examples only, but they illustrate the usefulness of using Blueprint Director to
communicate the physical deployment topology of a solution architecture and an Information
Blueprint to different audiences like administrators, developers, project managers, and business
stakeholders.
Conclusion
IBM InfoSphere Blueprint Director provides the capability for you to communicate a vision of your
information 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 of
communication 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 all
help facilitate this process.
Page 21 of 24
developerWorks
Resources
Learn
For best practices in using an information blueprint in a project context, see "Best practices
for IBM InfoSphere Blueprint Director, Part 1: Working within a project lifecycle."
Learn about examples of Information Server SAP Packs landscapes in "Security and
deployment best practices for InfoSphere Information Server Pack for SAP applications, Part
2: 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 integration
landscape."
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, product
information, 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 directly
from developerWorks.
Now you can use DB2 for free. Download DB2 Express-C, a no-charge version of DB2
Express Edition for the community that offers the same core data features as DB2 Express
Edition and provides a solid base to build and deploy applications.
Discuss
Check out the developerWorks blogs and get involved in the developerWorks community.

Page 22 of 24
developerWorks
About the authors

Brian Byrne
Brian Byrne was the lead architect behind InfoSphere Blueprint Director, bringing 15
years of experience in the architecture, design, and implementation of large-scale
data architectures and tooling, to the creation of a new paradigm for the design and
specification of data integration architectures. His current role involves bringing this
experience in information management to IBM Industry Solutions.
Martin Oberhofer
Martin Oberhofer works as senior IT architect in Enterprise Information Architecture
with large clients worldwide. He helps customers to define their enterprise information
strategies and architectures, solving information-intense business problems. His
areas of expertise include master data management based on an SOA, data
warehousing, information integration and database technologies. He especially likes
to work with enterprises running SAP applications. Martin provides in a lab advocaterole expert advice for information management to large IBM clients. He started his
career at IBM in the IBM Silicon Valley Lab at the beginning of 2002 and is currently
based in the IBM Research & Development Lab in Germany. He co-authored the
books Enterprise Master Data Management: An SOA Approach to Managing Core
Information and The Art of Enterprise Information Architecture: A Systems-Based
Approach for Unlocking Business Insight, as well as numerous research articles
and developerWorks articles. As inventor, he contributed to more than 30 patent
applications for IBM. He is also an The Open Group Master Certified IT Architect and
holds 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 on
the design and delivery of information integration and information quality solutions
and products, including methods and best practices.
Copyright IBM Corporation 2012

(www.ibm.com/legal/copytrade.shtml)
Trademarks
(www.ibm.com/developerworks/ibm/trademarks/)
Page 23 of 24
developerWorks

Page 24 of 24

Blue Print 1

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Blue Print 1

Încărcat de

Drepturi de autor:

Formate disponibile

Best practices for IBM InfoSphere Blueprint Director,

Part 2: Designing information blueprints from the

Martin Oberhofer (martino@de.ibm.com)

Best practices for creating and modifying blueprints

Figure 1. Basic structure of the replication pattern

Figure 2. Sub-diagram introducing the four topologies

Figure 3. Avoid excessive details

Figure 4. Avoid lengthy information processing flow

Best practices for IBM InfoSphere Blueprint Director, Part 2:

Design for template vs. design for blueprint

Additional considerations for managing details:

What belongs on a blueprint?

Figure 6. Avoid the placement of development artifacts into blueprints

Figure 7. Avoid placing tools into blueprints

Figure 8. Avoid putting method steps into the blueprint

Using grouping containers

Best practices for IBM InfoSphere Blueprint Director, Part 2:

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

Reusing elements through references

Creating a legible layout

Cluttering Use sub-diagrams

Best practices for IBM InfoSphere Blueprint Director, Part 2:

Figure 10. Avoid these mistakes

Abstracting from the runtime

Figure 11. Avoid capturing the runtime

Best practices for IBM InfoSphere Blueprint Director, Part 2:

Decomposing data flows

Figure 12. Decomposition of data flows

Defining conceptual views

Figure 13. Creating a conceptual schema

Best practices for IBM InfoSphere Blueprint Director, Part 2:

Figure 14. Decomposing a conceptual schema

Extending the palette

Best practices for IBM InfoSphere Blueprint Director, Part 2:

Figure 15. Extending the palette

Figure 16. Identifying the new element

Best practices for IBM InfoSphere Blueprint Director, Part 2:

Figure 17. Adding attribute properties to your new element

The information blueprint

Figure 18. Reviewing an information blueprint

Linking to the metadata landscape

Best practices for IBM InfoSphere Blueprint Director, Part 2:

Figure 19. An example metadata landscape

The physical deployment landscape

Figure 20. Environments

Best practices for IBM InfoSphere Blueprint Director, Part 2:

Figure 21. Physical topology for IIS development system

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

Best practices for IBM InfoSphere Blueprint Director, Part 2:

About the authors

Copyright IBM Corporation 2012

Best practices for IBM InfoSphere Blueprint Director, Part 2:

S-ar putea să vă placă și