Best practices for IBM InfoSphere Blueprint Director, Part 1: Working within a project lifecycle

This article provides best practices using IBM® InfoSphere® Blueprint Director. Understanding and applying these best practices lets you create effective and actionable architecture blueprints. It is intended for experienced users of InfoSphere Blueprint Director.

Brian Byrne (byrneb@us.ibm.com), STSM, Asset Development, Industry Solutions, IBM

Brian ByrneBrian 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. Brian's current role involves bringing this experience in information management to IBM Industry Solutions.



Martin Oberhofer (martino@de.ibm.com), Senior IT Architect, IBM

Photo: Martin OberhoferMartin Oberhofer works as Senior IT Architect in the area of Enterprise Information Architecture with large clients world-wide. He helps customers to define their Enterprise Information Strategy and Architecture 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 solving the SAP-specific information management challenges. Martin delivers Enterprise Information Architecture and Solution workshops to large customers and major system integrators and provides in a lab advocate role expert advice for Information Management to large IBM clients. He started his career at IBM in the IBM Silicon Valley Labs in the United States at the beginning of 2002 as a software engineer and is currently based in the IBM Research and Development Lab in Germany. Martin 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 over 30 patent applications for IBM. Martin is also an The Open Group Master Certified IT Architect and holds a master's degree in mathematics from the University of Constance/Germany.


developerWorks Contributing author
        level

Harald Smith (smithha@us.ibm.com), Software Architect, IBM

Harald SmithWith 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 over the past 14 years including methods and best practices. Harald has written and co-authored a series of developerWorks articles, has been issued 2 patents, and is an IBM Certified practitioner for the IBM InfoSphere Information Analyzer and QualityStage products.


developerWorks Contributing author
        level

14 June 2012

Also available in Portuguese

Overview

IBM InfoSphere Blueprint Director is a product in the IBM InfoSphere Foundation Tools portfolio that is aimed at the Information Architect designing solution architectures for information-intensive projects. Blueprint Director goes beyond traditional diagramming tools and white boards typically used to map an information solution, and enables a unique paradigm for information integration projects where teams can define, document, and manage end-to-end information flows. Blueprint Director thus enables the predictability and success of information projects by linking blueprints to reference architectures, reusable best practices and methodologies, and business and technical artifacts. With several useful features, such as built-in templates and methodology, the milestone feature, and deep integration into the Rational Team Concert platform, the evolution of architecture blueprints over their initial project lifecycle and beyond is well-supported from vision, to execution, and completion. A thorough introduction to Blueprint Director has been provided in an introductory tutorial titled "Planning an Integration Landscape", located in the Resources section. It is assumed 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.

The purpose of this article is to provide best practices for Blueprint Director. Best practices are needed for the following reasons.

  • Standardization of key information scenarios: Many companies implement enterprise-wide master data management (MDM) and business intelligence (BI) solutions that share the following aspects.
    • An enterprise-wide implementation of the solution is done in phases, which can be a series of sequential projects, a series of concurrent projects by business units, or any combination thereof. Assuring success across them requires a standardized approach from a solution architecture perspective.
    • Enterprise-wide MDM and BI systems are not static once completed – they evolve over time, and with them, the solution architecture. Keeping the solution architecture up-to-date and using it to govern these changes over time increases project success and governance.
    • For many types of projects, such as MDM, reference architectures have been created by seasoned practitioners and codified in reference architecture blueprint templates with associated and proven delivery methods. Blueprint Director has several out-of-the-box templates available for different project types such as MDM and BI. Thus, instead of re-inventing the wheel, reuse of these proven architectural best practices reduces project risk. This article shows you when to apply these templates, and how to tailor them most effectively to specific project requirements.
    • Certain information integration projects occur repeatedly in an enterprise. Standardizing the solution architecture with a new architectural template is the appropriate way to get repeatable results. How such a template is created step-by-step with specific methodology is the topic of a separate article.
  • Actionable blueprints: As opposed to solution architecture blueprints created with tools such as Microsoft Visio or PowerPoint, with actionable blueprints, you can get substantially higher benefits and impact out of the architecture deliverables. First of all, the architecture blueprints can incorporate direct links to artifacts such as data models, mappings, and other solution components. This makes the blueprint a one-stop shop to navigate through the solution architecture and find all relevant artifacts for the implementation. Second, with the deep integration into Rational Team Concert, described in a subsequent article, the information architect can determine how much of the solution architecture has been built already, and can review the implementation artifacts.
  • Consumability and usability: Architecture blueprints are also used by the information architect to communicate a vision to business users or technical representations of the solution architecture to developers. Creating these architecture blueprints requires best practices on how to design the various views to make them easy to understand for the target audience. For example, if they are too cluttered and complex, the consumer gets quickly lost in these details. This makes the blueprint less useful as a means of getting the intended message across. This article provides best practices on this topic.
  • Architecture decomposition: In the case of information projects where there is no suitable template available, the information architect needs some understanding on how to decompose the overall solution architecture from a conceptual view to the appropriate level of technically detailed views. The best practices on how to do this are in a subsequent article, alongside useful criteria for when to use a template versus starting a blueprint from scratch.

Blueprint best practices in the project lifecycle

A blueprint starts as a planning tool, typically within a project, though it can be used to sketch the scope or parameters for a project still under consideration as well. While you can simply start sketching an information landscape with IBM InfoSphere Blueprint Director, framing its use in a project-based context helps to create and maintain a better blueprint that communicates the desired information even when there is no formal project.

Fundamentally, good blueprints are about communication across an organization even when competing visions are in play (whether they are business and IT views, ETL and SOA views, and so on). To achieve effective communication, a blueprint needs to incorporate the following basic principles from the start.

  1. Focus on communication and consensus
    • Use the blueprint diagrams to aid communication across teams to get to a common vision. A blueprint is not a monolithic, single point-of-view document.
    • Where different teams have conflicting views, explore how these views can be captured in the blueprint. In this capacity, treat Blueprint Director as a whiteboard to shape the project and discuss alternatives.
    • Tailor the blueprints to the needs of your organization. While certain practices can make it easier or harder to work through different layers or levels of understanding, there is no single right way to use the blueprints.
  2. Maintain clarity at the high level
    • Cluttered blueprints make communication and understanding difficult. Use the sub-diagrams to explore and elaborate detail.
    • Use the glossary, asset, and method links as a means to keep ancillary materials identifiable and distinct but accessible.
  3. Target the end goals of the project
    • Use the blueprint as an aid in understanding the landscape of your project. It is not the project plan, nor the methodology for the project, but a visual statement of the scope and direction.
    • Consider building sub-versions as needed to provide focused views of specific project phases or components.

Relationship to project lifecycle

Planning an information landscape through a blueprint is a task that should occur at the inception of a project, helping to communicate the project scope, and to align the efforts of the business and IT. Initially, the blueprint may be applied as scope and objectives are discussed, but it is particularly useful in ensuring consistency of the end-to-end vision of the information landscape with objectives in each key component.

For instance, a customer consolidation initiative focusing on increasing campaign and store profitability is shown in Figure 1.

Figure 1. Exploring a customer consolidation blueprint
shows originating sources of information and need for integration from originating sources to trusted sources

The blueprint captures the following important factors in the project.

  • The consumers/users of the information (the end points in the initiative).
  • The core information products (profitability reports).
  • The sources of trusted information (the Customer Master and the data warehouse).
  • The originating (initial) sources of information (the Customer Relationship Management systems and the purchase orders).
  • The information landscape then conveys the need for integration from the originating sources to the trusted sources.

This is a useful high-level view of the project clear to both business users (expecting trusted information in their reports), and IT (developing and delivering the integration processes and the analytical reports). There are also implied components that need further exploration, including what trusted information really means.

Here the project team creates a sub-diagram from the Integrate Sources routine that drills into more detail. Trusted information can be described as information from the three originating sources that is extracted, cleansed, transformed, and then loaded into one or both of the targeted trusted sources. And this can be expanded further. The correct business terminology can be linked via the glossary, the data cleansing process can be expanded to show that name and address must be standardized, matched, and consolidated, and so on. Each component becomes a visual elaboration or description of the requirements supporting the project.

Developing this visual landscape sooner, rather than later, as with any planning or design task in a project, helps to ensure that misunderstandings are addressed early when changes are easier to make and have less impact to the project delivery.

As the project progresses, the blueprint remains a living document.

First, you can track if your project vision and specific blueprint elements are aligned with the business artifacts, (such as requirement documents, statement of work, and so on), or with the technical artifacts such as metadata of a database, or specific data / ETL models. This is accomplished through specific asset links connected to blueprint elements as shown in Figure 2.

Figure 2. Connecting to associated assets
shows blueprints associated with active project documents

These could be the URL to the project requirements document, the link to the metadata for the originating sources, or the data model for the warehouse. You can open or launch these linked artifacts in the tools they were designed in to view and modify as necessary.

Useful URL links

Consider using a URL for a file directory rather than an individual file, particularly for project documents that may still be undergoing revision.

For example, you may have a wiki for your project initiative. Within that wiki are different directories for requirements documents, specifications, and so on. You could use the URL for the project wiki, or the URL for the requirements document directory within the wiki, rather than the URL for the Requirements_v2.doc file. If there is a subsequent Requirements_v3.doc file, you will be able to see and find that document as well.

Second, you can manage consistency over time through live and always current links. By connecting via links, rather than embedding details in the blueprint, you ensure that the blueprints are associated with the active project documents rather than static and outdated content.

The blueprint itself becomes one of the project assets and should be managed like other project documents (such as requirements document) with the blueprint file (.bpt) stored for additional use.

As the project progresses from planning and analysis through design, development, and deployment, different types of assets will be connected to the blueprint.

Linking project documents

There is a common need to link documents to solution components to ensure the correct understanding of information. Such linkage makes documents available in context, and allows traceability from solution architecture to objectives and goals.

In the initial planning phase, assets to link are typically documents of one of the following types.

  • File: this asset will be a specific file stored in a common directory location. It is best to use a common location to ensure that others using the blueprint can open the link.
  • URL: this asset will be a web, http, or ftp location for the specified object. As with files, use a common location to ensure that others can open the link.
  • Microsoft Word/Excel link: this will connect directly into a specific area of a specific Word or Excel document, as shown in Figure 3. While this can be useful to bring you quickly to the right content in a large document, it is likely to be more volatile or sensitive to changes made in the document, such as losing the link if a section is deleted.
Figure 3. Types of connected documents
diagram shows requirements spreadsheet.xls, nonfunctionals.xls, business objectives.doc, and reporting goals.doc all connected in to the data repositories

By making the connection, you can visibly see an asset link to the document, URL, or file as a green arrow by the blueprint element. The asset link may be navigated at any time by clicking the green arrow and then selecting the desired document. This action invokes or launches the document, URL, or file, at the specified location.

This activity is not limited to the planning and analysis phase, but is most common at that point, particularly as those documents get close to their final form. Design documents, specifications, and test plans are additions that will be made during the design phase, test results are made during the development phase, and implementation plans are made during the deploy phase. The goal from the process is to ensure that individuals looking at the blueprint can find the associated supporting material that confirms or describes the visual representation at the right level of detail.

Top-down vs. bottom-up planning

When blueprint development is initiated within a project, it can be driven from one of three perspectives: Top-down, bottom-up, or a meet-in-the-middle approach, as shown in Figure 4.

Figure 4. Planning perspectives
described below

A top-down approach could be described as a conceptual approach or a business-driven approach. Typically, such an approach will broadly sketch the initiative from a business view, for example, the business case, the business objectives, and the general requirements and scope. More about this is described in the Business-driven design section.

A bottom-up approach looks at the existing landscape or architecture and how that can be altered or changed to address a given initiative. It tends to be an IT-focused view with particular reference to existing systems and infrastructure, and how new initiatives will fit into that information landscape.

Given the goal of establishing effective communication and consensus, it may be useful to consider a meet-in-the-middle approach. Such an approach is generally as follows.

  • Driven by project requirements (functional and non-functional).
  • Driven by goals of the business.
  • Driven by desired target architecture.

No single approach will be universally applicable, and ideally the approach used will suit the needs of your organization and your project. The point is to be aware that you can initiate a blueprint design with any of these approaches.

Regardless of the approach taken, it is useful to bear the following in mind.

  • Ensure that the blueprint development captures the needs and views necessary for effective communication and consensus. If you are not getting buy-in from this initial visualization, then address that before moving forward.
  • Consider optimum use of existing infrastructure. Generally you are not starting in an open landscape devoid of information, systems, infrastructure, or business process, yet you don't want to bring everything into view, so you need to identify what pieces are important in order to communicate the goals, and clearly place your initiative in the context of what exists.
  • Ensure awareness of existing assets, the quality of these assets, and so on. The pre-existence of specific assets or processes does not guarantee optimal usage, so you may need to bring such considerations into the blueprint design.
  • Observe constraints of time, organization structure, technology, and so on. There is never enough time to address everything that could be covered, so use the blueprint to map out key milestones and phases, as well as segmenting what is outside the scope of what can be included.

Business-driven design

Blueprint Director provides the opportunity to tie the information landscape or solution to the language of the business. Further, you can drive the development of the information landscape from a business perspective that ensures effective communication of requirements.

Such business-driven design can be approached in several ways, depending on whether the focus is on the business concepts, the intersection of business process and information process, or on the information landscape. The focus that you choose can bring you close to modeling, and it is important to remember that Blueprint Director is neither a glossary, nor a modeling tool. There is a fine line between vision and modeling; you want to achieve reasonable clarity in the vision and then connect to the modeling tools that add detail.

With that distinction in mind, you can choose the following approaches.

  • Abstract connections with the business processes, such as for key functional services, as shown in Figure 5 (from the delivering trusted master data blueprint template).
    Figure 5. Master data management services
    shows Domain Services and Business Servicess that cross domains, withing Entity Management
    These representations focus on the business functions and intersections with the information landscape. Details might be captured in requirements and specification documents, or in business process models, that are linked as assets such as URL's or files.
  • Incorporate formally defined business domains, as shown in Figure 6 (from the Delivering Trusted Master Data blueprint template).
    Figure 6. Master data management domains
    shows account domain, party domain, and product domain withing MDM Server
    Details might be captured in requirements and specification documents, or in the business glossary. If the latter, then one or multiple elements from the glossary browser could be dropped onto each of the domains (see the Govern terminology section for more information). By capturing the business domains at multiple information nodes (data sources, databases, and so on) in the blueprint, the information flow for each domain can be traced and confirmed at the architectural level. This can then guide subsequent discovery, analysis, and design steps to ensure the right contents are addressed.
  • Initiate modeling efforts to further align business & IT, particularly for business-associated marts and reports. In this instance, you can utilize Blueprint Director to generate Cognos Framework Manager models from the business-oriented definitions, as shown in Figure 7.
    Figure 7. Generating a Cognos framework model
    shows steps listed above
    • Blueprint captures a high-level information artifact, such as dimensional data store.
    • Business articulates business terms relevant for analysis, such as entities and attributes for measures and dimensions.
    • From the sub-diagram of Blueprint Director, a model is generated.
    • IT starts from a generated model that is linked to the same business terms, such as the Cognos Framework model.

These approaches are not mutually exclusive, and incorporating some or all of them may best suit your organization's requirements for effectively communicating between the business and IT.

Govern terminology – use the right terms from the start

As part of the effort to ensure effective communication between business and IT, it is important to ensure that the right terminology is used from the start of any project initiative. From a blueprint perspective, this means you want to do the following.

  • Understand existing terms with their context, and their detailed definition, stewards, and trusted sources right from the beginning of your project.
  • Specify key data elements aligned with business terms in your information project, such as the following.
    • Use formally defined and governed terms instead of ambiguous language.
    • Understand trusted sources for key data elements and ownership (stewards).
    • Drive design artifacts from business terms.

As shown in Figure 8, the glossary browser provides up-to-date business terms that can be dragged directly onto the Blueprint canvas to form new concepts not yet described, or onto an element on the canvas (such as an existing concept, database, or file) to provide detailed business terminology to that element.

Figure 8. Integration of business terminology
illustrates dragging Policy Number to Properties

As shown in Figure 9, you can do the following to connect the business terminology.

  • Navigate and view glossary terms directly in a browser.
  • Review details of the existing glossary terms.
  • Drag and drop to create conceptual elements.
  • Drag and drop to classify existing blueprint elements.
Figure 9. Connecting the business terminology
illustrates concepts listed above

Metadata visibility in the landscape

Business terminology is not the only component to make visible through your information landscape blueprint. In communicating with the IT organization, you can connect to a range of existing IT assets, enhancing understanding of how those pieces fit into the larger framework.

Since applications, integration initiatives, databases, and warehouses do not exist in isolation, it is important to incorporate these into the overall picture. This can be thought of as providing meta data visibility in or through the blueprint. Though again, it primarily serves as a communication vehicle across different members of a project team, particularly those addressing the technical considerations, including architects, modelers, data analysts and stewards, developers, and data base administrators.

Through Blueprint Director, you can do the following, as shown in Figure 10.

  • Get immediate and deeply embedded access to existing assets, such as databases, ETL routines, BI reports, and so on, including the following.
    • Browse and search meta data.
    • See related meta data.
    • View detailed definition.
  • Improve re-use by adding existing assets to your new information project through simple drag and drop process.
  • Allow the team to drive a project through the following perspectives.
    • Top down: the business-driven perspective noted previously.
    • Bottom-up: start with where you are and define changes, such as consolidate existing systems.
    • Meet-in-middle: start with a pre-defined reference architect and connect with existing business terms and technical assets.
    Figure 10. Connecting the meta data and technical assets
    screen cap shows metadata and technical assets

    Click to see larger image

    Figure 10. Connecting the meta data and technical assets

    screen cap shows metadata and technical assets

When to use timelines

Unless a project or initiative is particularly small, there will likely be multiple phases, or work with multiple deliverables in the project. The blueprint of the proposed information landscape can incorporate this time dimension into the overall picture.

As shown in Figure 11, Blueprint Director allows you to do the following.

  • Manage a list of milestones.
  • Associate elements to milestones, including specifying when to show and/or hide them at which milestone.
  • Show blueprint evolution, including filtering blueprints by time line.
Figure 11. Managing milestones
shows dragging and dropping Manage Milestones

As projects move forward, and more detail is incorporated into a blueprint, remember the following two important factors from a milestone perspective.

  • It is easier to introduce timelines early on before the number of artifacts and sub-diagrams becomes challenging.
  • While elements can be linked to milestones, links cannot, so you may not always get the picture or view of the milestones you intended.

Templates versus ad-hoc blueprints

Blueprint Director is delivered with a set of base templates around key scenarios such as business-driven BI development, managing trusted master data, and managed data cleansing. Other templates may be included in subsequent releases, or you may take your own blueprints and use them as templates within your organization.

Templates allow you to standardize your approach for work with these scenarios and leverage recommended practices or methods associated with those templates. Templates also allow you to jump start your work so that you don't have to reinvent the wheel for each individual effort. Developing a standardized approach allows for consistency across teams, greater productivity, and may help avoid costly mistakes or oversights.

Not all projects lend themselves to existing templates, so rather than trying to force a new effort into an existing template, there are cases where it will be best to start adhoc, and then develop a blueprint from scratch. Situations where adhoc blueprints are advisable include the following.

  • Greenfield initiatives that cover new ground and are not related to common information integration, master data, information lifecycle, or business intelligence solutions.
  • Industry-specific or line-of-business applications which are specialized or customized to your organization.
  • Established architectures undergoing consolidation or restructuring where it is best to map out what exists and how that will evolve.

To take advantage of the existing templates, review those that exist to determine what is most suitable for your project needs. A standard approach to utilize the templates includes the following key steps.

  • Develop the initial information blueprint.
    • Start with and review the relevant template.
    • Conduct initial white boarding of goals and scope. It may be easiest to project the blueprint on a screen and modify the blueprint directly in such a session.
    • Document and track progress. Notes can be added directly to the blueprint to capture action items; or asset links can be made to documents or URL's that contain meeting minutes or status updates.
    • Maintain control and improve knowledge base. Designate a specific individual to maintain the blueprint. If multiple individuals are to work with the blueprint, store that in a common location. It may be useful to use a source control system or a version numbering scheme for the blueprint to track changes.
  • Utilize the methodology.
    • Understand the entire method (all phases, activities, tasks) related to a scenario and template.
    • Understand the related method guidance for each component in the reference architecture.
    • Drill into the method description details, including identification of roles, expected artifacts, value and links to manuals, and so on.
  • Publish drafts of the blueprint for communication and consensus.
    • Capture relevant images for discussion in emails or documents.
    • As changes are identified, the blueprint owner should coordinate updates to the blueprint and republish to ensure everything is incorporated.

Extending or building on a template

Keep in mind the following factors when you work with templates, extend them to your needs, or create your own templates.

  • Alter the diagram. You should expect to change the base template to meet your needs. No two organizations have the same information landscape, though similarities and common practices do exist. There is no best way to alter a diagram, but if you start from a template and find that a particular alteration does not work, you can always go back to the template and start fresh.
  • Find the right starting point. In the top-level diagram, it may make sense to start at the end point, for example, data consumers, and work back through to ensure the requirements are captured. Consider the following factors.
    • Is the target singular or multiple? Even if singular, it may be easier to maintain a general group such as an asset set or domain at the high-level, allowing easier future change.
    • Select the object and edit the properties. Make the name & description meaningful and assign an owner, if relevant.
  • Prune details. Working from a template there will inevitably be items you do not need. If they are not needed, feel free to remove them – it will improve clarity and understandability.
    • Open the relevant diagram or sub-diagram and keep what you need, change where you need to, delete what is extraneous, and annotate as needed.
  • Expand Concepts. The templates contain generic place holders. Add specifics to replace or expand on these concepts. You can utilize these in one of the following ways.
    • Keep them in place, but create sub-diagrams for the specifics in your information landscape.
    • Keep them in place, but attach asset links for the specific associated items such as links to glossaries, models, and documents.
    • Replace them with more specific palette elements to reflect your environment.
    • As you work, consider how these concepts will tie into communication around the higher level pictures.
  • Clarify in Sub-diagrams. Pay particular attention to how and where you add or modify sub-diagrams. Once you have created several layers of diagrams, it can be difficult to adjust intermediate layers, so think about the value that a given layer adds.
    • From asset sets. An asset set represents a collection of items such as database tables. A sub-diagram from an asset set would be expected to identify these items, possibly grouping them in a logical way, such as trusted sources vs. untrusted sources, or customer vs. product domains.
    • From operation or process elements. At a high-level, these summarize some sequence of actions (processes) that may represent manual or automated steps. A sub-diagram from an operational or process element could elaborate or detail a specific process, or a group of such processes. Since a given element can only have one sub-diagram, you need to find the right balance in drilling down into these levels.
  • Communicate through established content.
    • It is important to tie to a business glossary, if available, as this helps establish communication across business and IT. Connect any element on the canvas with the business glossary, particularly to identify the right terms.
    • Enrich content with relevant supporting material. Connect any element on the canvas with documentation.
  • Save as a template. If you have defined a particular information landscape at a broad level, it may be appropriate to turn this into a template for others to use. As shown in Figure 12, by selecting File > Save as Template, you can define the information for others working with Blueprint Director to see and utilize.
    • Include a useful name and template description.
    • Save it to a location that other users can find.
    • Add a version number (and possibly a date in the description) so that the template can evolve over time.
      Figure 12. Saving as a Blueprint Template
      screen cap: saving as template

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 done the following.

  • Reviewed best practices in planning and supporting blueprint usage through the project lifecycle.
  • Identified when to use a blueprint template vs. creating a blueprint from scratch.
  • Considered the advantages in constructing blueprints from top-down, bottom-up, or meet-in-the-middle approaches.
  • Assessed approaches to ensure the right level of communication to a broad audience.

By following these 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 the information landscape for your project at varying levels, all facilitate this process.

Resources

Learn

Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.
  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=820982
ArticleTitle=Best practices for IBM InfoSphere Blueprint Director, Part 1: Working within a project lifecycle
publish-date=06142012