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:
- 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:
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 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
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.
- 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
Figure 5. Design the base diagram with logical function groups and decompose them into sub-diagrams
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.
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.
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.
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.
- 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
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
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.
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
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:
- Go to the Blueprint Menu and select Extend Palette.
- Select Add Element, as seen in Figure 15. Note the presence of other custom elements already added in the Drawer lists.
- 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).
- Optionally, assign additional properties, such as a Name or Description, for the specific instance (see Figure 17).
- 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.
Figure 15. Extending the palette
Figure 16. Identifying the new element
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.
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 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.
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 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.
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.
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.
- 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.
Dig deeper into Information management on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.