Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
Authors: Hohmann L.
Published year: 2005
Pages: 23-26/202
Buy this book on amazon.com >>

Check This

  • The dependencies that exist between subsystem components are clearly identified.

  • Each person on the team is working on a subsystem that he or she finds personally interesting.

  • Each person on the team is working in a way believed by all to improve productivity.

  • Our architecture is profitable.

  • We know if our current release is focusing on issues of evolution or issues of maturation .

  • We understand the degree of technical debt we've incurred in our system. We can identify such debt (e.g., we have placed special comments in our source code identifying areas to fix).

  • We are in proper compliance with all in-licensed components (see also Chapter 5).

  • The architect has articulated the principles that are driving architectural choices.

  • Our team is about the right size to accomplish our objectivesneither too large nor too small.


Try This

  1. One way to summarize my position on software architecture is that I see software architecture as organic. This position informs a host of management practices, including such things as spending time in each release caring for and feeding the architecture. What is your position on software architecture? How does this position affect your management practices?

  2. Here is an exercise that I've found especially helpful when working with troubled development teams , because it helps me identify potential sources of confusion and/or conflict. Ask members of your team to take a plain sheet of paper and draw the architecture of the system. They have to draw it, meaning that they can't just fish out some diagram and print it. The drawing must be done individually, with no talking between team members. When finished, tape each of the drawings to a wall to create an "architecture gallery." What occurs to you, and each member of your team, as you review these diagrams? Do you find congruence ? If not, why not?

  3. Do you have a visual representation of your architecture posted in an easily viewed space? If not, why not? If yes, when was the last time it was updated?

  4. Can you enumerate the capabilities of your current architecture?

  5. Check out the definitions of software architecture posted at http://www.sei.cmu.edu/. Which of the posted definitions work best for you? Why?

  6. What are the specific artifacts, or views, that you have created to describe your architecture? Why have you created them?


Chapter 2. Product Development Primer

Many software developers are at a decided disadvantage in creating winning solutions because they don't understand many basic and important concepts in product management. This chapter outlines crucial concepts and processes in product management, including defining the product manager role. If you're comfortable with these basic principles already you may find it sufficient to skim this chapter. If not, you should read it carefully .


What Is Product Management?

Like software architecture, product management has a variety of definitions. One that I've found useful is as follows :

Broadly speaking, the product manager has two responsibilities. First, the product manager is responsible for planning activities related to the product or product line. Thus, the product manager's job involves analyzing the market, including customers, competitors , and the external environment, and turning this information into marketing objectives and strategies for the product. Second, the product manager must get the organization to support the marketing programs recommended in the plan. [Lehmann and Winer, 2002]

My own definition is a bit simpler: Product management is the comprehensive set of activities required to create and sustain winning solutions. It is like software architecture in that it is also about "the big picture." In reality, though, the big picture of product management is an even bigger picture than that of software architecture. Product managers deal with everything from pricing the product to creating data sheets, from defining and educating the sales channel to monitoring the behavior of competitors. The job is no less difficult than that of an architect and in some ways is considerably harder.

Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
Authors: Hohmann L.
Published year: 2005
Pages: 23-26/202
Buy this book on amazon.com >>