Brand architecture
The way a system is designed affects how the system works—and the results you get from it. In both technology and branding, we call this process of designing systems “architecture.” Just like our customers build architectures for more reliable and flexible cloud infrastructures, our brand architecture helps us build a more consistent and impactful brand.
What is brand architecture?
Brand architecture defines the relationships between brands, products, and services. A clear brand architecture should reflect the company’s strategy and brand platform. This structure helps companies to make smart decisions about how we brand new offerings so that our customers understand how different parts of the brand work together.
Red Hat brand architecture
Red Hat is an independent brand owned by IBM. Within the Red Hat® brand, we use a “parent brand” architecture, meaning that we invest in the Red Hat brand first. While other companies may choose to brand each product or service separately, all of our products and offerings are part of the Red Hat brand and share common naming and visual strategy.
We chose a parent brand strategy because it aligns to our brand strategy—our mantra that no one innovates alone is not just the promise we make to our customers, but the way our offerings work together. When we build trust and awareness for our parent brand, that extends to all of our products and services and increases customers’ confidence that Red Hat is the right choice for their hybrid cloud platform.
Within the Red Hat parent brand, our architecture is divided into our product portfolio, programs, events, and internal groups. Red Hat also endorses or supports the independent open source communities that are “upstream” of our technologies.
This helps our customers navigate the landscape of open source software. When customers see our name and logo they know it means they’re getting an enterprise-ready and supported solution.
Our brand adapts based on our audience and goals, but our parent brand architecture means a few things always stay the same: we include “Red Hat” in every product name, we use a logo system that includes our hat, and we use the same design language across our entire portfolio and in our marketing. Everything we do is tied back to our parent brand.
Branding our product portfolio
Our brand architecture has a direct influence on the way we brand our technology offerings. In order to help customers navigate our broad portfolio, we rely on two key strategies: The first is to create a hierarchy of offerings, and the second is to organize most of our technologies into 4 sub-brands that align to our product platforms. Where an offering fits into this structure informs how it’s named and branded.
Parent brand
The corporate brand; sub-brands and product names feature the parent brand name and/or logo.
Platform sub-brands
Distinct brands that operate under the umbrella of the parent brand.
Products
The software and services that we sell.
Components
Features, plug-ins, operators, builds, and other technologies that are part of or used alongside our products.
This diagram is not a comprehensive list of product and technology offerings.
Naming and branding offerings
We focus most of our branding and marketing efforts at the top of our brand architecture—the parent level and platform sub-brand level. Our platform sub-brands allow us to tell broader stories about the value our technologies provide our customers. As we move down to the product and component level, the information we share gets more specific and technical, so the branding becomes more direct and focused on helping users navigate our offerings.
Platform sub-brands
Platform sub-brand names start with "Red Hat." These names may also appear in the names of the products that make up each platform. They have a logo and a technology icon, as well as a full visual language that brings the value of our technology to life for our customers.
Products
All of our product names start with "Red Hat," followed by a descriptive name. Products usually have a logo and a technology icon, and can use the visual language of the platform sub-brand they are aligned with.
Components
Most of the time, components are used in the context of a product, so we don’t need to include "Red Hat" in the name. They may have a technology icon if it’s needed for an interface or marketplace, but otherwise their visual branding is minimal.
Red Hat and IBM
In 2019, Red Hat was acquired by IBM as part of what was the largest software deal in history. While Red Hat is now owned by IBM, we remain a wholly distinct entity with our own independent brand, culture, and industry partnerships.
When we appear with IBM, we’re careful to remain true to our identity and reinforce our neutrality. We co-brand with IBM in the same way that we co-brand with all of our partners. We don’t blend our brands or mix brand elements together.
Start with the Red Hat logo. Most of the time, Red Hat communications and projects should use the Red Hat logo alone.
When our goal is to communicate our partnership with IBM, use a co-brand with the lead brand first.
When Red Hat is the lead brand, Red Hat comes first in the co-brand and we use Red Hat brand elements and templates.
When IBM is the lead brand, IBM comes first in the co-brand and we use IBM brand elements and templates.
IBM sells both Red Hat and IBM products, and may use our product logos or icons in the context of their brand.
Avoid these things
Not this: Don’t create co-branded swag with IBM.
Not this: Don’t combine the IBM and Red Hat logos or place them too close to each other.
Not this: Don’t use color or gradients to symbolize IBM and Red Hat’s partnership.
Not this: Don’t create co-brands with IBM or Red Hat product logos.
Not this: Don’t use IBM colors, fonts, or other brand elements for Red Hat materials.
Not this: Don’t create vertical or stacked co-brand lockups with IBM.
Branding teams, programs, and events
Our brand architecture informs not just how we brand our products, but also how we brand programs, events, and internal teams. Our parent brand architecture means that program, event, and team branding stays closely aligned to the Red Hat brand.
Even when a team, program, or event is internal to Red Hat, we follow similar rules for naming, logos, and visual elements to those we use for other parts of our brand. You never know when a team t-shirt worn outside of the office or a team logo in an email signature will be someone’s first impression of our brand.
Program, team, and event names always start with "Red Hat." To differentiate these names from products that we sell, we always include descriptors like “team” or “program.”
When a team, program, or event needs its own logo, we use a defined logo system that ties them back to the Red Hat logo and brand. Any team or program can request and use a universal logo. Select programs and events may meet the criteria for a more custom logo treatment, like an initiative logo or event logo, that provides more differentiation from the Red Hat brand.
Red Hat and communities
As an open source company, some of our most important relationships are with our upstream communities. When we’re at our best, we act as a catalyst for innovation within the open source ecosystem, and are careful not to overstep our role within communities by using Red Hat branding in a way that implies ownership. We should be seen as a trusted partner that respects and supports their independence.
When Red Hatters are part of the creation of a new upstream community, Red Hat can help establish the naming and branding for the community. The goal should be to create a brand that feels distinct from Red Hat and that the community can own and embrace going forward.
Remember that while open source code is free, project logos are usually the trademarks of the project or foundation. We should always ask permission before we use a community logo. You can read more about how we brand non-Red Hat offerings in marketplaces in the product branding handbook.
Create unique brands for community projects.
Not this: Don’t use the Red Hat logo or a red fedora to represent a community project.
Not this: Don’t use Red Hat brand elements in the design of community logos or websites.
Not this: Don’t create the impression that Red Hat “owns” a community project.
