Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
| Changing brand elements is usually harder than changing other parts of the system that are seen by the user, such as in an internationalized user interface that can be readily localized to different languages. There are two primary reasons for this. First, brand elements change quite slowly and are therefore not generally required to support change. This is unlike internationalized software, which has been designed to support change. I am not advocating that you create requirements to support changing brand elements, unless this is specifically required as part of your overall strategy. Specific requirements to support changing brand elements are usually rare. Second, brand influences a product and its architecture in very subtle ways. The product development team (marketing, engineering, QA, technical publicationseveryone associated with creating a winning solution) often doesn't realize the full requirements when one or more brand elements are changed. I vividly remember the challenges one of my teams faced when we decided to change a product name . We debated, and eventually changed, a large number of items that didn't initially appear to be related to the change. These ranged from the labels used in our source code management system to the categories in our bug-tracking system (more on this later). Of course, there are many legitimate reasons to change brands and brand elements. Products and components do change names. Companies change names , either voluntarily or because a company is acquired or a product line is sold from one company to another. Product Areas to Change
When you're faced with changing a brand or brand elements, consider these product areas. Subsystem Names
A tarchitect must name a subsystem or a component something. Ideally, the name is functional, but quite often it is related to the product or the brand. As described earlier, it also happens that functional or technical names become part of the product and brand. Changing the name of a product or any of its brand elements may motivate internal subsystem or other component name changes. Source Code Repositories
It is easier for everyone if the product and brand element names either are not reflected in the source code repository (i.e., use code names) or match, as closely as possible, the product names. If you name repository structures after products, keep them synchronized. It is very confusing to track down a set of changes when the source code repository refers to a product that no longer exists! QA and Technical Support Tracking Systems
Good QA and technical support systems provide bug categorizations. These categorizations inevitably reflect product and brand elements and should be maintained in close alignment with the actual products. This is especially important if you utilize any kind of customer self-service solutions, such as a Web site where customers can review problem case histories (which also reinforces that your brand is really your total customer experience, including technical support!). Physical Location of Components
As described earlier in this chapter, it is often easiest to place physical components where they reflect the company, the product, and the module. Your upgrade process may have to account for this. If you change any components, be patient. I've worked on products where it took two full releases before all changes associated with the new product name were implemented, including upgraded versions of the product. Naming and Structure Of APIs
APIs often reflect, either by name or by function, a variety of brand elements. Company or product names, for example, may appear as prefixes on functions and functions may be organized or grouped according to product-specific branding requirements. Because of this, changing the name of the product or any of its associated brand elements may even require changes to your APIs. Error, Information, and Diagnostic Messages
Because any of these may contain references to corporate or product brand elements, each needs to be examined for potential changes. QA and Test Automation Infrastructure
If you're changing any subsystems, error messages, or user interfaces, or your automated build system or any externally visible APIs, chances are good that you'll also have to make some modifications to your QA and test automation infrastructure. Sales Collateral
Sales collateral refers to all materials created to support sales. This includes Web sites, whitepapers, case studies, "glossies," and so forth. These also require changes if the brand or brand elements change. QA and Change
The QA effort to change a brand or key brand elements is often substantial. With so many parts of the system changing, and with the potential for tarchitectural change, you have to perform a full QA cycle. One of my teams had to track down a particularly nasty bug when the installer, under certain circumstances, put the new software in the old location! Fortunately, this was captured in the beta testing process (which is essential when brand elements change because it gives your customers time to adjust). |