Business Ramifications

Providing ways for the system to be integrated has a number of business ramifications for both the marketect and the tarchitect. Handle all of them and you increase your chances for success. Miss any of them and you may seriously cripple your product's viability.

Professional Services

The various technical options for integrating a system can create a bewildering array of choices for a customer. Too often, customers are left unsure of the best way to integrate a system within their environment or they fear that the integration process will take too long, cost too much, and ultimately result in failure. Some of this fear is justified, as many large-scale integration projects don't realize key corporate objectives. To address these issues, vendors of systems designed to be integrated or extended should establish a professional services organization to help customers achieve their integration goals, answer their questions, and reduce the time necessary to integrate a system within the customers environment.

The marketect should help create the professional services, outlining their offerings, business, and licensing models, and providing assistance in setting and pricing models. The degree of control can vary. I've worked in organizations where my product managers had complete responsibility for establishing professional services. In other companies, professional services itself was responsible for prices and creating some offerings, in close collaboration with product management. My strong preference is that product management set the standard service offerings because this forces them to understand the needs of their target market. The most essential work of the marketect is in mediating requests from professional services to development.

The marketect also plays a key role in determining how professional services are organized. The two basic choices are inhouse and a partnership with an external firm. In practice, these choices are mixed according to the size of the company and the complexity of the integration. Smaller firms have small professional services organizations and rely heavily on partners; larger firms can afford to bring more of this inhouse. This is a decision of strategic importance, and the marketect should provide data that help senior executives make the best one. My own experience is that smaller companies do a very poor job of enlisting the aide of larger consulting partners , to their detriment.

Development (or engineering) plays a strong, but indirect, role in assisting customers, not working directly with them, but instead with professional services, making certain that they understand the product and its capabilities. A key service that development can provide is the creation of sample programs that demonstrate how to use APIs. I've found it especially beneficial if one or more members of the development team, including the tarchitect, help professional services create some of the initial customer solutions. The feedback on the structure, utility, and usability of the APIs is invaluable, and both professional services and developers welcome the opportunity to work on real customer problems instead of artificial examples.

The tarchitect assists the marketect in selecting external professional services partners. Like any other developer, the tarchitect should assess a potential partner's skills, examine their portfolio of successful projects, and interview the potential partner's key customers to assess their overall satisfaction with the quality of work.

Training Programs

Training programs are required for the successful use of just about any system. The trick to creating a winning solution is making certain that the training program matches the specific requirements of the target user . End users, for example, are typically given a base of training materials that show them how to use the application for common purposes. As systems increase in sophistication, so do the required training materials. Training is an excellent investment, because well designed training programs improve customer satisfaction and reduce support costs.

The primary role of the marketect in creating end user training is to coordinate the efforts of technical publications , quality assurance, and development to ensure that the training materials are created and are technically correct. A tarchitect committed to usability can play a surprisingly influential role in this process, ensuring that the training materials are not only accurate but truly represent, capture, and convey "best practices."

The basic training provided to end users must be substantially augmented for systems designed to be extended and/or integrated. Returning to the Adobe Photoshop example, training programs must clearly detail how a developer is to write a plug-in. For enterprise-class systems they can be surprisingly extensive , including several days of introductory to advanced training in dedicated classrooms.

When designing training solutions for the target market, the marketect must take into account all of the system's stakeholders. In one enterprise class system I worked on, we designed training programs for

Developers who wanted to integrate the system with other systems
System administrators who wanted to ensure that the system was configured for optimal performance

How Do I Add a Document?

One of the most frustrating experiences I ever had was when I was working for a company that used Lotus Notes. When I joined the company, I received a total of three minutes of Notes training. Specifically, I was taught how to log in, read, and send e-mail.

Over the next several months I watched other people in the organization use Lotus Notes in ways that seemed mystical to me. While they were successfully using Notes' collaboration and file management tools, I was struggling to manage my calendar. It took me several months of trial and error to achieve a modicum of skill.

You might wonder if I used the built-in help and tutorial materials to learn more about the system. I tried this, but to no avail. In my opinion, these materials were useless. I've been left with a very poor impression of Lotus Notes, which is sad because my problems could have been easily corrected by a motivated marketect working in partnership with a similarly motivated tarchitect.

Solution partners who were integrating their software into our software
Consulting partners who used our system to provide enhanced consulting services to our mutual clients

This list is not exhaustive and can include programs to service different constituents depending on the specific system. What is important is that complex systems rarely stand alone, that many different people within a company touch these systems, and that their ability to use the system can be improved through the right training.

I've found that training materials often suffer from a number of flaws, several of which can be mitigated or even removed by involving the tarchitect. One flaw is that APIs and example programs are often incorrect: In extreme cases, examples don't compile, and they fail to represent best practices. Also, they fail to expose the full set of features associated with the product, which is especially serious, because it exposes your product to serious competitive threats (smart competitors will see these flaws and use them to their advantage). A slightly less serious, but related , flaw, is that the examples provided don't have sufficient context for developers using the APIs to build a good mental model of the system. The result is that it takes developers far longer to effectively use your system's APIs.

Certification

The next logical step beyond training is certification. This is a rare step and one that is required only for systems with sufficiently large market shares. Certification is almost exclusively the domain of the marketect. In deciding whether or not to create a certification program, I recommend considering the following factors.

Product Ecosystem

Certification makes sense in product ecosystems characterized by many third parties who provide services to customers and by customers who want to know that their service providers have achieved some level of proficiency in their offerings. One example is hardware markets, like storage area networks (SANs) that are typically sold and distributed through value-added resellers (VARs). Another is IT/system integration and management markets, where certifications such as the Microsoft certified systems engineer (MCSE) have value.

Competitive Edge

Certification must provide a personal competitive edge that will motivate employees to invest their time, energy, and money in acquiring it.

Currency

Well-designed certification programs include ongoing educational requirements. In general, the more specialized the knowledge, the shorter its half-life. If you're not willing to invest the time to create an ongoing program, don't start one.

Professional Recognition

A well-designed certification program involves professional recognition. In practice, this means that certification must be hard enough to attain that you have to work for it. If anyone can obtain the certification, why bother?

Independent Certification

Although many companies benefit by designing and managing their own certification programs, it is often better if a program is designed and managed by an independent organization. This usually reduces overall design and implementation costs and has the chance to include marketplace acceptance. For example, the Computerized Information System Security Professional (CISSP) certification, created and managed by an independent third party, is a demanding program that requires detailed knowledge of a wide variety of vendor-neutral concepts as well as specific knowledge of various vendor's products. Working with the CISSP, a security vendor could ensure that their products are properly covered without incurring the expenses associated with a comprehensive training program.

Academic Credentials

Some certification programs can be used toward a university degree. This is, of course, an added advantage.

User Community

A healthy and active user community provides a number of benefits to the marketect and the tarchitect. For the marketect, user communities provide primary data on desired features, product uses, and product futures . For the tarchitect, understanding the user community means understanding how people are really using your application. For example, I am always amazed at how creatively people can use an API if given the chance!

User communities don't magically happen. They need to be nurtured. The marketect, especially, should seek to foster a healthy and active user community. Here are some activities that can help in this endeavor.

Community Web Site

Establish a corporately supported community Web site where customers can share tips and techniques regarding all aspects of your system. If you provide an API, have sections where they can post questions, receive official and unofficial answers, share sample programs, and so forth.

Educational Materials

Distribute unsupported educational and sample programs with your core product so that customers can learn how to create such applications on their own. These programs should be created or certified by your development or professional services organization (or both). Make certain that this kind of reference and/or sample code is high qualityyou don't want your customers to emulate poor practices. The programs themselves don't have to be tested to the same level of detail as the released software, but it should use the system in a corporately approved manner.

Thanks, But I Think I'll Build My Own User Interface

My team had labored mightily to build a great user interfacenot a good one but a great one, a testament to usability. When we learned of a "power user" who loved our system and wanted to share some of his ideas for improving it, we jumped at the chance.

After a long day of travel, we arrived at his cramped office. He was a senior research scientist working for a major chemical company, and amid the many stacks of paper on his desk was a workstation. With an excited wave of his hand, he motioned us over to review his use of our system. Imagine our surprise when we watched him type a few values into Excel, hit a button, and then manipulate the results in a pivot table. What happened to our beautiful user interface? "Oh, it was nice, but it didn't really meet my needs. Fortunately, you guys built a really cool COM API, so I just programmed what I wanted in Excel. Isn't it great?" Yes, it was.

Mailing List

A very low-cost way to stay in touch with your customers is an e-mail mailing list. Such a list is a marketing program and should be managed by your outbound marketing department. However, the contents of each e-mail should be driven by the marketect in consultation with development, QA, support, and professional services.

User Conferences

It is vitally important to have one or more user conferences. Depending on the size of your user base, this can be a single annual event or multiple conferences throughout the year around the world. Organizing an effective user conference is a very specialized skill, and, like your mailing list, its objectives and structure should be driven by the marketect. However, the conference itself should be managed and run by your outbound marketing department.

License Agreements

The marketect needs to review proposed license agreements to make certain that the legal team does not put in language unnecessarily restricting use of the API. Such language is usually added with good intentions, but the end result can put the customer in a tough position. At the same time, as discussed in Chapter 5, license agreements for in-licensed technology must be examined to make sure rights to in-licensed technologies are clearly defined.

No License for Testing

Simplistic license agreements often inadvertently prevent customers from utilizing systems as intended by marketects and tarchitects. In one enterprise-class system I worked on, the original terms of the license agreement restricted the use of our system on only one hardware configuration, however, it did allow them full and free access to our API. The problem was that the agreement did not meet the legitimate needs of the customer to install the system on development and staging (or "model office") configurations to create and test their integrations and extensions before installing them on production hardware.

One way around this problem is to make certain that your legal team understands your objectives for use of the API. If you've designed a system to be integrated and/or extended, your customers are going to need development and testing licenses. Some vendors charge for these; others provide them as part of the basic license. (I recommend against charging because that will inhibit customers from integrating and extending their systems.) Regardless of whether or not you choose to charge for them, you need to make certain that they are clearly defined.