Jazz Library CLM configuration management: Adoption guidance and practices
Author name

clm,elm,continuous-engineering-solution,jazz-reporting-service,sse

Mon, 13 Nov 2017
5 min read
0

CLM configuration management: Adoption guidance and practices

Kathryn Fryer, IBM, and Catherine Trinkwon, Persistent Systems
Last updated: 13 November 2017
Build basis: IBM Collaborative Lifecycle Management Solution (CLM) 6.0.4 or later, IBM IoT Continuous Engineering (CE) Solution 6.0.4 or later

This article is part of a series that provides guidance for planning configuration management for the IoT CE solution.

Introduction

For years, source code management has embraced configuration management and the ability to use versioned artifacts in multiple streams and baselines. Since version 6.0 of the IBM IoT Continuous Engineering (CE) solution and the IBM Collaborative Lifecycle Management (CLM) solution, the requirement, design, and quality management applications offer configuration management. Also, a new global configuration management application groups configurations (streams and baselines) across these applications so that you can reuse components and manage different versions or variants. With these solutions, you can reuse artifacts across multiple configurations, creating new versions to reflect variation. Instead of duplicating artifacts and trying to manually manage the associations across domains, configurations enable component reuse and easier management of versions or variants.

After you determine whether your organization would benefit from configuration management, you need to evaluate your existing processes and determine how they will change to reflect the new concepts and operations.

This article guides you through important considerations for adopting configuration management. See the related articles for additional details about practices and decisions points.

If you are new to the concepts, capabilities, and terminology of configuration management, read this help topic in IBM Knowledge Center.

If you need assistance with adopting configuration management, ask your IBM representative about service offerings that can help you.

Deciding if configuration management is right for you

You need to consider the benefits and costs to your organization of extending configuration capabilities to requirements, tests, and designs. Your IBM team can help you with these decisions.

Would configuration management benefit your organization?

Consider these questions:

  • Do you want to reuse artifacts or groups of artifacts (“components”), but struggle to do so effectively?
  • Do you work on more than one release at the same time? For example, do your requirements and test teams work on multiple releases concurrently?
  • Do you have different variants of your releases or products? For example, do you build different products or systems to meet the needs of different markets?
  • Do you need change control over your requirements? If so, is a state-based workflow sufficient, or do you need more automated tool support for change management?

If you answered “yes” to one or more of these questions, your organization might benefit from configuration management.

Do the benefits justify the cost?

Like any transformation initiative, adopting configuration management requires both effort and cost. You need to consider these costs:

  • Infrastructure: Configuration management introduces additional applications, with increased server, disk space, and memory requirements. See Identifying your infrastructure needs for details.
  • Process and tool changes: To take advantage of the capabilities, you’ll have to update your processes, and configure your applications to support your usage model. See the links in Defining your adoption strategy and usage models.
  • Pilot and transition: Like any significant change, you should validate the approach in a pilot environment before rolling out to production.
  • User training: You will need to invest in training your users on the process and tool changes. You’ll need more training if your teams are not familiar with the CE and CLM applications.

Are you ready to absorb the cost and effort of adopting configuration management?

Even if your organization could benefit from these capabilities, there is also a cost associated with adopting them. You need to determine whether the expected benefits are worth the cost, and whether your organization can accept those costs at this time. Questions to inform your decision include:

  • Process Foundation: Do you have clear processes around managing lifecycle artifacts like requirements, tests, and models? You need a good foundation on which to layer the additional complexity of configuration management.
  • Transformation: Does your organization have the capacity to change now?  If your organization is already in the midst of a transformation, would configuration management make things simpler? If you are making significant changes in other areas, can you take on both challenges at once?
  • Sponsorship: As for any transformation, do you have executive sponsorship, and adequate budget and infrastructure? You need one or more pilot teams who want to innovate and can deal with the ambiguity and overhead of innovation.
  • Scalability: Can your environment scale appropriately? If your environment is already nearing capacity, you will likely need more infrastructure to support the additional applications and future scalability.
  • Capabilities: Are the capabilities provided in the current solution adequate for your needs, especially scalability, cross-stream merging, and reporting? See Getting familiar with the capabilities later in this article.

If you think your organization could benefit from configuration management but you are not ready, read the resources listed at the end of this article, and explore the capabilities in the Jazz.net sandbox.

If you are new to the CE and CLM solutions

Most clients who are new to our offerings start by adopting one or two application domains: requirements management (RM), change and configuration management (CCM), quality management (QM), design management (DM), or source control management (SCM) for files (models or source code).

It’s a separate decision to use configuration management, depending on your priorities and pain points. For example, you might want to start with requirements, and then enable configurations. After that is working well, you could add quality management, and enable configurations for that. Or, it might make more sense for you to start using requirements and quality management together, and then enable configurations for both. Only you can decide which approach is best for your projects and organization.

If you’re already using our offerings, evaluate the capabilities and consider how best to roll them out across teams and applications, as described later in Implementing and deploying your solution.

Getting familiar with the capabilities

Defining your adoption strategy and usage models

By its nature, configuration management changes how you work. Be sure to understand the effects of configurations and versioning on your current processes, and define how your teams will deploy and use the new capabilities to achieve the results you want.

  1. Identify your goals for adopting configuration management and the capabilities that will help you address them.

    Goals might include managing requirements change, optimizing artifact reuse, reducing reliance on ‘clone and own’ methods, managing complex product lines and variants, isolating artifacts in flux from those that are stable, or protecting teams that work on downstream artifacts (such as development or test artifacts) from changes to upstream artifacts such as requirements.

  2. Understand your current processes and roles related to the disciplines and processes you are targeting.

  3. Define your usage model and key scenarios. This step helps you identify changes to your processes, and how to implement the processes in the tools. Be sure to address the following topics:
    • Component strategy: organizing your system or product into the right-size components, which makes it easier to reuse and work with parts of a project. Each component is like a building block that represents a physical or logical part of your project.
    • Patterns for stream usage, including when to create baselines and branches
    • Change management, including cross-stream delivery
    • Roles and permissions across the applications
    • Integration with other applications
    • Reporting needs and how best to address them
    • Naming and tagging conventions for objects such as configurations, change sets, and reports

As you define your usage model, optimize the most common processes and workflows; consider possible exceptions but avoid adding complexity just to simplify infrequent scenarios. Walk through your proposed scenarios, and explore how the tools might streamline your current processes or inspire a different approach. This can be an iterative process.

Jump-start your deployment with help from experts. Ask your IBM representative about service offerings to help you define and realize your usage model, and involve internal and IBM subject matter experts in your planning.

Identifying your infrastructure needs

As you determine how you will use configuration management and the CE and CLM applications, you also need to understand what installation topology will work best for you.

Before you plan your infrastructure, review these resources:

Determine how many users you have, the amount of data in your projects, and the complexity and frequency of the reports you need.

If your current or future needs require you to have multiple Jazz Team Servers (JTS), plan for a federated topology and add a shared central server for the Global Configuration Management (GCM) and link index provider (LDX) applications. All the other applications can references this server.

Discuss your needs with your infrastructure team, and review the proposed deployment infrastructure with IBM subject matter experts to ensure your environment will support your scenarios and planned usage.

Implement a strong monitoring strategy to confirm that your infrastructure can reach the necessary performance levels, to help with diagnostics, and to inform future growth. See this article on the Jazz Deployment wiki for more details on monitoring.

Implementing and deploying your solution

When you are satisfied with your proposed usage model, consider how to implement it.

Remember, you can’t disable configuration management after you enable it in a project area, so first implement your solution in a pilot (non-production) environment so you can validate and tweak your new processes. When you’re satisfied with your implementation, plan incremental adoption across the project areas and teams in your production environment.

Pilot environment:

  1. Identify project areas to use in the pilot.
    1. Create one or more new project areas for the initial validation activities. Configure them based on the processes you defined in your usage model.
    2. As you explore the capabilities in new project areas, expand the pilot scope to existing project areas. Re-create one or more representative projects to validate whether changes are needed to support existing project areas.

  2. Identify candidate users for the pilot activity, ensuring representation across the roles and disciplines identified in your usage model. Train users on the new concepts, processes, and capabilities. Make sure they understand both configuration management and how to use the applications.

  3. Ensure you have allocate adequate infrastructure and install the versions of the CE and CLM applications you need. Back up your systems as needed. See Deployment and installation planning for the Rational solution for CLM.
  4. Work through the scenarios identified in your usage model, identifying opportunities to optimize or gaps to address. You might need to update the usage model or the implementation based on your findings for both new and existing projects.

  5. If you identified the need for additional reports, start building them during your pilot so they can be available as early as possible in production.

Production environment:

When you are satisfied with the pilot results and updates to your processes, plan how to roll out configuration management capabilities to projects in your production environment. Like any major transformation, roll out the changes incrementally: start with selected projects, measure against established success criteria, and have regular checkpoints with project teams to identify and address issues.

  1. Select projects for the initial wave of adoption, considering factors like these:
    • Mission-critical projects: Consider starting with non-critical projects first. Postpone mission-critical projects until others are working successfully.
    • Team size and skills: Ensure that project teams are well-prepared to adopt both tools and process changes. In some cases, it might be easier to start with smaller project teams.
    • Project lifecycle status: You might choose to have projects adopt at a particular milestone or transition point in their lifecycle.
    • Similarity to your pilot projects: Start with projects that are similar to the pilot projects. Those with different characteristics (size, methodology, complexity) from the pilot scenarios might require more changes to processes or tools before they can adopt configuration management.
    • Cross-project relationships: To support OSLC links between artifacts in CE and CLM applications, all related (linked) project areas must be enabled for, or be compatible with, configuration management.

    You don’t have to enable all of the projects in your organization; the capabilities and changes might not be suitable in some cases.

  2. Train the teams and ensure that they have a clear understanding of the following:
    • New or unfamiliar concepts and terminology associated with configuration management
    • Roles and their permissions
    • Conventions for naming, tagging, linking, change sets, global configurations
    • Workflows and how to complete tasks using the tools

  3. Manage the changes to the production environment as explained in Identifying your infrastructure needs. As always, back up your environment before installing or upgrading, and before enabling your projects. Ensure the necessary hardware and software are in place, including the license key for configuration management.

  4. Enable and configure the selected project areas:
    • Set up the local and global components and configurations
    • Configure process such as roles, permissions, and workflow
    • Create and update dashboard and reports.

As your initial adopters succeed, expand to other projects and teams as defined in your rollout plan.

Summary

Clients who have been successful in adopting configuration management have invested in understanding the capabilities and defining how best to implement in the context of their goals and usage scenarios.

Planning your adoption is a critical step to ensuring success. Use the materials referenced here to assist you, and contact your IBM representative for additional guidance or services to aid you in adoption and implementation.

For more information

Contact Tim Feeney at tfeeney@us.ibm.com or Kathryn Fryer at fryerk@ca.ibm.com.

About the authors

Kathryn Fryer is a Solution Architect who works with customers, sales, and development to develop usage models, aid adoption, and improve product offerings. She can be contacted at fryerk@ca.ibm.com.

Catherine Trinkwon is an experienced technical writer for configuration management, reporting, and product line engineering. She can be contacted at catherine_trinkwon@persistent.com.


© Copyright IBM Corporation 2017

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Mon, 13 Nov 2017