Beyond Software Architecture[c] Creating and Sustaining Winning Solutions

2017-07-07 02:10:07

The brand elements most likely to impact your product are names , slogans, graphic symbols, designs, other customer- facing or customer-visible elements, and even URLs. Elements can be registered for legal protection as trademarks by the U.S. Patent and Trademark Office (USPTO). Registered trademarks have special restrictions on their usagea topic explored later in this section.

Names

The brand elements often having the biggest effect on your system are the various names associated with your product and your company. Here are some of the areas in which names can affect your tarchitecture .

Physical Location of System Components

Most deployment models, including service provider models such as an ASP or MSP, result in one or more software components being installed on the customer's or user 's computer. These range from simple browser plug-ins to the full executable and its supporting files, including DLLs, sample data, documentation, and help files. Once you have identified the platform-recommended location for the software, chances are you will still have to create a subdirectory or subfolder for storing your application components. I recommend the combination of your company name/product name/subcomponent name or, in rare cases, just the product name/subcomponent name .

This approach has several advantages. It gives you additional branding information for your company and product, and it supports expansion in multiple ways: You can conveniently add subcomponents to a given product or add products. Even if you sell just a single product, you're likely to create additional modules, over time, and you're going to need a place to store them.

If you support multiple versions of your application or product on the same system, it may be convenient to incorporate version numbers in directory names, although this may become irrelevant as operating systems increasingly support the management of component and component versions. Regardless of operating system support, carefully consider your choice because multiple versions on the same system increase testing complexity (remember the matrix of pain?) and often increase version support costs. See Chapters 12 and 15 for more information on supporting multiple versions of the same product.

This approach does not remove all risks associated with identifying the right physical location to store or install a product. A company, product, or subcomponent name, or a concatenation of the three, may be longer than the allowed length of a subdirectory or subfolder name. Any of these may contain special characters not allowed by the supporting operating system. While rare when using fully qualified names, there is always the possibility of name collision. Special symbols that may be associated with the product in printed material, such as , , or , are probably not allowed. Despite the potential challenges, your company name/product name/module subcomponent is the best place to start when determining the physical location of your product.

Names of Key Components

Complex products often have many sellable components, and in addition to the overall product, marketects must name them as well. It is best if the marketect or another person trained in marketing does the naming. This is an important, strategic decision, and you want to make certain that it is made by individuals with the proper training and background. Some companies allow developers to name products. I don't approve, because developer-created names are often confusing.

As for customer-visible technical components and/or features, I encourage marketects to include developers in this naming because the goal is often "technically" accurate names that convey exactly what is going on. These names can be exciting, and a good marketect can use their straightforward, direct, and descriptive nature to quickly educate a potential customer on key features and also differentiate the product from the competition. Creative technical names may also be easier to protect.

Developers Should Name Variables, Not Products

Product names are extremely important, especially in the consumer market. Product and marketing managers spend a lot of time trying to create good ones, and they should. A well-named product has a significantly greater chance for success than a poorly named one. Like a good class, variable, or function name, a good product name has many desirable attributes: It is short, it describes or highlights one or more positive attributes, it is a good fit for the company, it can be legally protected via a trademark, it has a freely available URL, it is unique, and it can be easily pronounced and spelled by members of the target market. This is just to name a few!

Here are some of my favorite high-technology product names and why I like them:

Palm . Can you think of a better name for a hand-held computer?

Latitude . It sounds like a computer made for people on the go, and it is.

Photoshop . A software workshop for image manipulation.

Easy CD Creator . The product lives up to its namea double win!

I'll admit that product names are often less important in the enterprise market than in the consumer market in which other brand elements dominate. There are many reasons for this, chief of which is that customers of enterprise software often refer to the company more than the product: Siebel Sales, Oracle Financials, SAP R3, Tibco ActiveExchange. There are a few exceptions, such as OpenView (from HP), or CICS, DB2, and VTAM (from IBM). In some sense, product name versus company name is a bit of a toss-up when it comes to enterprise softwareas long as one of them is good and drives your branding strategy, you're probably OK.

The desirable attributes of a product name are sufficiently different from those of technical names that it is almost always better to ask your marketing experts to do the naming. I've inherited a few projects in which product names were created by developers. In a few cases this was okay, as customers found these names acceptable and the names addressed a sufficient number of attributes. Most other times, a name had to be changed because it was too " geeky ," the company couldn't secure a trademark, it was too close to a competitor's name, or it conveyed a poor brand (such as when a name seemed cool to a developer but a customer viewed it negatively). As discussed later in this chapter, changing the name of a product is an expensive operation that can often can be avoided simply by letting someone skilled in product marketing select the name to begin with.

To illustrate just how important it is to review names, one of my developers actually named a database upgrade program after himself! We missed the name in our review, and the program was actually shipped to customers. Quite an embarrassment.

Tarchitects and developers should realize that developer-created component names, which probably had a strong correlation to the tarchitecture in its first few releases, are much less likely to maintain this strong correlation over subsequent releases. If a developer-created name catches on, you're going to want to keep it. At the same time, chances are good that the team will want to modify the underlying implementation and possibly even the tarchitecture over time. The result is that the "technical" name and its underlying implementation will diverge.

Instead of fighting this divergence , accept it. Names associated with the marketecture evolve more slowly than the tarchitecture and its implementation. The usually substantial cost of changing a component name is not justified just because you want to maintain a strong correlation between the marketecture and the tarchitecture.

I realize that these are somewhat paradoxical arguments. Fortunately, the marketect is the final arbiter and selector of customer-visible names. By working with developers, a skilled marketect can usually select the best names possible.

Names May Or May Not Be Internationalized

One element of internationalization that needs marketectural and tarchitectural consideration is that the actual name of the product may be different in different target markets. Installing the product in a U.S.-centric directory structure may cause confusion among your user population in countries where English is not dominant. In addition, many product names that make good sense in English must be translated into different names in other languages. Any good marketing book can provide horror stories about good product names created in one culture that were horrible in another. Ultimately, you have to check all names before blindly assuming that locally created names will work on a global scale. If you suspect that this might be a problem, make certain that you're storing brand elements in appropriate resource files or are using some other technique to extend your internationalization architecture into brand elements.

Configuration and Log Files May Contain Brand Elements

Product and company names can affect the location, name, content, and structure of configuration and log files.

Error, Diagnostic, and Information Messages May Contain Brand Elements

Messages presented must often refer to the marketing names for key components or functional areas of the product. If they don't, your user and technical support organizations can be confused on how to identify and resolve problems in the field.

Names Are Volatile, Especially in the First Release

The first release of any project is where names are most volatile. This volatility can have negative effects on, for example, the source code management system. I recommend that developers refer to the product through a code name for the first release, such as the name of a fruit or a mythological creature. You don't want to create entries in your source code management system that closely reflect a product name that may change two or three times before the release date. Because names may change during any release, continue using this code name for as long as the product is in development.

Graphics, Slogans, and Other Brand Elements

It seems obvious, but sometimes development organizations forget that graphical user interfaces (GUIs) will be affected by graphics and iconic brand elements. Similarly, voice-based user interfaces will be affected by slogans and other brand elements. While many of these effects are not tarchitectural, they should be addressed by the development team. Pay attention to the following areas.

Icons and Splash Screens

Product management should approve every icon and/or graphic presented to the user, as they are all brand elements. I worked on two projects where the product didn't have a logo until we realized that some kind of icon on the desktop was necessary. In the first project, I was fortunate to have a developer who was also a skilled graphic artist. He created a logo that marketing approved, and it later became the approved trademark. On the other project, we had to add time to our schedule for an outside design firm to create the necessary icons and splash screens, have marketing approve the design, and ensure that the icon was sized correctly and used the right colors. As you might guess, we missed our initially projected delivery date.

Brand Colors

Companies often specify everything they can about their brand, including specific colors, presentation templates, and document templates that are either associated with the brand or must be used with the product. Tarchitects should check in with marketects to determine the effects that any of these brand elements may have on the architecture.

Voice Branding

An emerging area of brand management is voice-based user interfaces. Picking the right voice talent is a powerful way to make certain your brand is properly represented.

When to Use the Trademark ( ) Symbol

There are legal implications to the proper use of various brand elements, especially those that have been registered as trademarks. Here are the most important things to keep in mind.

Protect Your Legal Rights

Trademarks are based on use. Failing to use a mark may result in losing your legal right to it.

Give Notice

You have to tell the person viewing the registered information that it is, in fact, a registered trademark. The easiest way to do this is to use the symbol (referred to as a mark ). There are other waysconsult your inhouse legal counsel for the preferred approach, as it may differ from the above. Do not use the symbol if the mark has not been registered with the USPTO. Surprisingly, the government claims that to do so is a crime. Instead, use the symbol for unregistered trademarks.

Use Marks Only as Adjectives

A mark should never be used as a noun or verb, never be pluralized, and never be used in the possessive form.

Include Registered Trademarks in the Distribution and/or Prominently Display Them on Usage

Traditionally, marks were affixed to goods and services. In the world of software, they must somehow be displayed to the user, so include them in the distribution, installation, and execution of your software.

Domain Names Can Be Trademarked, Subject to Certain Restrictions

If you've created an interesting URL for your product, service, or company, you may want to register it as a trademark. Additional information can be found at http://www.uspto.gov/.