PacGenesis

Experts in DevOps and UrbanCode

Designing CLM Topologies - Scaling for the Enterprise

Today is an exciting day for PacGenesis.  We’re kicking off our guest blogger series with our first author, David Arnone! Recognized as an innovative and strategic thought leader, David has an incredible wealth of SCM knowledge in his over 27 years of industry experience.  We’re thrilled to share our blog with an expert like David, now let's hear what he has to say about CLM topologies...

Rational Team Concert (RTC), as a collaborative platform for application development, is a very work item and team centric tool.  In the recent blog on distributed work item management across multiple CCMs, Scott discusses how to coordinate development activities between project areas on different CCMs in order to link these efforts together.  In this post, we will cover some of the design decisions necessary to determine the correct project area topology for your group, department, line of business, or enterprise.  We will discuss this further by reviewing a number project area “patterns”.  These patterns provide a set of re-usable project area designs when applying RTC across an organization.

Singular Application Project Area Pattern

In the simplest case, users of RTC will instantiate a single project area to represent a space for coordinating work for the development of a single application.  This pattern is where most deployments begin with RTC and usually implement one timeline, one team, and one or two streams.  Depending on the size of the development team, this model may or may not leverage organizing the development staff into teams that align to the application architecture by layer, function, or technology.  In either case, this topology leads to a segregation of development staff against applications.  If the organization is small, with many developers cross connected to multiple applications, deploying this pattern may create higher overhead in coordinating development resources.

Figure 1: Single Project Area Pattern

Multiple Application Project Area Pattern

Another alternative to segregating development resources by application is to create a project area to house multiple applications and use team areas to separate them.  In this case, Team A is responsible for Application 1 and Team B is responsible for Application 2.  Team areas may be further decomposed into sub teams around the components of the applications and work item categories can used to differentiate work items intended for one team from another.  Because all of your resources are in one project area, the reports and dashboards in RTC provide an aggregated view of your project plans and resource allocations.  This pattern works well for department implementations of RTC where the applications are closely associated.

Figure 2: Multiple Application Project Area Pattern

PMO Project Area Pattern

The Multiple Application Project Area Pattern has its limitations depending on the size of the organization and the number of developers.  When looking at this from an enterprise point of view, the need for more that one project area will still be required in order to manage performance considerations of RTC and the CLM solution.  In this case, a top level project area can be created to roll up all of the activity across multiple project areas, on different CCMs if necessary, to handle needs of your enterprise.

Figure 3: PMO Project Area Pattern

In RTC 3.x, plans were limited for an iteration but in RTC 4.0 and later, plans support the tracks link type for work items, thus enabling users to track high-level items that belong to different projects and on potentially different repositories.

Figure 4: PMO Project Area Pattern

At PacGenesis, we have the expertise and know how for implementing scaleable CLM solutions tailored to meet the needs of organizations of any size.  Having implemented RTC at various levels of the organization for enterprises encompassing more then 20,000 developers, PacGenesis’ Solution Architects are skilled at leading your organization’s stakeholders through a set of design sessions in order to design a successful and scalable CLM solution.

David is an enterprise application and software process architect with 27 years of experience in the design, implementation, test, and deployment of software and hardware systems.  With over 16 years of experience operating as an enterprise scale systems architect, David has demonstrated leadership in establishing standards and software engineering best practices encompassing technology, system architecture, modeling, program design, and software development processes. David currently holds a position of Chief ALM/CLM Architect and Strategist for a large financial services company and holds a BSEE from Rutgers University, College of Engineering. Find David on Linkedin to learn more about his experience.

Copyright © PacGenesis, Inc. 2016. All rights reserved.