3.6. Exercises

Exercise 3.1

Which mistaken traditional systems assumptions are commonly applied by your organization in software development? How would you remedy this situation?

Background for Solution:

Much of what people learn in school (e.g., computer science courses) can be viewed as negative training with respect to this paradigm shift. Not everyone in the organization needs to embrace the paradigm shift completely. At a minimum, the architects of the system do have to have a solid understanding of these concepts and need to define system boundaries that mitigate the consequences of the actions of wrong-thinkers.

Exercise 3.2

Are there obvious AntiPatterns which your organization continually repeats in development after development? What alternatives would you recommend to avoid these recurring mistakes and/or refactor the results of existing solutions?

Background for Solution:

Please refer to our book AntiPatterns for a full disclosure on this sensitive topic [Brown 98]. In our experience, AntiPatterns are more prevalent than patterns of success. One of our good friends mused that if people would simply avoid the most obvious mistakes, software development would be much more successful, as an industry. In other words, our friend thinks that you may not need a new set of good practices, as long as you avoid the practices that are known not to work.

Exercise 3.3

How does the process of Enterprise Architecture Development compare with your current organizational practices for building large systems? Do you have an explicit architectural phase before hordes of programmers join the effort? Do you use Lo-Fi screen design and architectural prototyping to reduce risks? Do you have a run-ahead team? Is your architecture prework defining effectively organizational interfaces that enable parallel development?

Background for Solution:

Sophisticated architecture practices are rare indeed, in today's software industry. The one-man heroic programming team is still a commonplace fixture in many shops. Not surprisingly, some of the best-known products in today's software market are the result of one-man development teams. It works for some commercial organizations that can tolerate the release of extremely deficient products. Not so, in most application development shops. We know that it is brutally difficult to attempt to think and work architecturally, when every manager is under extreme time pressure to deliver results. First they have to understand that there is a problem. Lending them a copy of our book AntiPatterns is one way to move forward. We wrote it specifically for people who have difficulty admitting that there is a problem, when it's incredibly obvious to most other people.

Exercise 3.4

What is your organizational process for architecting and developing a system? Are there conventions for how much time is devoted to system planning (e.g., architecture) versus programming and other tasks? If you had a magic wand, how would you refactor your organizational practices to improve system successes and reduce unnecessary commitments and risks?

Background for Solution:

On a typical project (in many shops), a large group of developers (perhaps 30 or 50) join the project on day one. These people are rapidly allocated into a human organization before there is an architecture available to guide these decisions. Once in place, these organizations are almost impossible to change. Then there is a long period of negotiations as these groups struggle to define the system architecture to be conformant with their organizational boundaries. The architect has lost control. Ideally, what should happen resembles the Enterprise Architecture Development process that we describe in this chapter. Commitments for developers and equipment are delayed until adequate planning has occurred. Irreversible decisions are not made until the organization fully understands what it wants to accomplish.