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.
- 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.
- 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.
- 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
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
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.
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
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
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.
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
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
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
- 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
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
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
- 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
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
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
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.
- For basic information on using Blueprint Director, see the IBM InfoSphere Blueprint Director User Guide.
- 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" (developerWorks, 2012).
- In the InfoSphere area on developerWorks, get the resources you need to advance your skills on a variety of IBM InfoSphere products.
- Learn more about Information Management at the developerWorks Information Management zone. Find technical documentation, how-to articles, education, downloads, product information, and more.
- Discover InfoSphere Information Server best practices.
- Learn about InfoSphere Information Server on ibm.com.
- The "Enterprise Master Data Management: An SOA Approach to Managing Core Information" book, co-authored by Martin Oberhofer, is available on Amazon.
- The "The Art of Enterprise Information Architecture: A Systems-Based Approach for Unlocking Business Insight" book, co-authored by Martin Oberhofer, is available on Amazon.
- Visit the developerWorks Information Management zone to find more resources for DB2 developers and administrators.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools as well as IT industry trends.
- Follow developerWorks on Twitter.
- Watch developerWorks on-demand demos ranging from product installation and setup demos for beginners, to advanced functionality for experienced developers.
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.
- Participate in the discussion forum.
- Get involved in the developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.
- Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.