This chapter is from the book
This chapter is from the book
This chapter is from the book
Working in Unison
I reject the images perpetuated by Dilbert that marketing departments are buffoons and that engineering departments must bear the pain they incur. Instead, marketects and tarchitects should work together to ensure that the total system achieves its objectives. Lest I be misunderstood, I will try to be much more explicit: There is much for each side to gain from a strong, collaborative relationship. While this sounds good, learning to work in unison takes time and effort. Are the potential benefits worth the effort?
Let's first consider this question from the perspective of the marketect. Over the years I've found that marketects routinely underestimate or fail to understand the true capabilities of the system created by the development team. Working with tarchitects or other developers can expose marketects to unexpected, and often delightful, system capabilities. Think about systems that can be extended via plug-ins or APIs. I was delighted when a member of the professional services team of an enterprise-class software company I worked for elegantly solved a thorny customer problem by hooking up Excel directly to the system through the client-side COM API. We had never intended the API to be used in this manner, but who cares? One of the primary goals of creating extensible systems is that you believe in a future that you can't envision (extensibility is explored in greater detail in Chapter 8).
Now consider features that can be offered because of choices the development team made when implementing one or more key requirements. In one project I managed, the development team had to build a functional replacement of an existing server. The old architecture had a way of specifying pre- and postprocessing hooks to server messages. Unfortunately, the old architecture's solution was difficult to use and was not widely adopted, so the development team implemented an elegant solution that was very easy to use. Among other things, they generalized the pre- and postprocessing hook message handlers so that an arbitrary number of hooks could be created and chained together. The generalization was not a requirement, but it created new features that the marketect could tap.
A final set of examples illustrates marketing's ability to exploit development tools for customer gain. I've co-opted and subsequently productized developer-created regression test suites for customers so that the operational health of the system could be assessed by the customer onsite. I've converted log files originally created by developers so they could be used as sources of data for performance analysis tools. I'm not advocating goldplating, which is wasteful. But marketects who fail to understand the capabilities of the system from the perspective of its creators lose a valuable opening for leveraging latent opportunities. By establishing strong relationships with tarchitects, marketects can quickly capitalize on their fertile imaginations.
Reflexively, a tarchitect's creative energy is most enjoyably directed toward solving the real problems of real customers. By maintaining a close relationship with marketects, tarchitects learn of these problems and work to solve them. I'm not referring to the problems that the tarchitect would like to solve, that would be cool to solve, or that would help them learn a new technology. I'm talking about the deep problems that don't lend themselves to an immediate solution and are captured on the maps described earlier. Working on these problems provides a clear outlet for the tarchitect's strategic energy.
The following sections describe activities that have proven effective in fostering a healthy working relationship between the marketect and the tarchitect.
Reaching Agreements
Agreement on the project management principles and resultant practices driving the project. A variety of principles can drive any given project. Project leaders select the specific techniques for managing the project from them. Differences on principles and resulting techniques can cause unnecessary friction between marketects and tarchitects which will be felt throughout the entire project organization.
To illustrate, many software projects are driven by a "good enough" approach to quality assurance, but some, especially those dealing with human safety, require much more rigor. These goals motivate marketects and tarchitects to utilize different principles. These different principles motivate different project management practices. Not better or worse, just different.
Identifying and agreeing to the set of principles that drive the project, from the "style" of documentation (informal versus formal) to the project management tools used (MS Project or sticky notes on a shared wall), are an important step toward marketects and tarchitects working in unison. As described earlier, this agreement is also vital to meeting the cultural requirements of the development team.
Making Data Available
Visibility to maps and features is crucial. None of the approaches I've described for capturing and planning for the future are much good if the data are hidden. Get this information into a forum where everyone can share it. Some teams accomplish this through an intranet or a Lotus Notes database. Other teams are experimenting with Swikis, Twikis, or CoWebs with good results, although my own experience with these tools has been mixed and is heavily influenced by team culture. Other teams simply make lots of posters available to everyone. Visibility, in turn, is built on top of a corporate culture founded on trust and openness. Putting up posters merely to look good won't fool anyone. Making a real commitment to visibility—and dealing with the inevitable issues your project team members will raise—is a powerful tool to ensure marketect and tarchitect cooperation.