4.6 Exercises

EXERCISE 4.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 must have a solid understanding of these concepts and need to define system boundaries that mitigate the consequences of the actions of programmers who think incorrectly.

EXERCISE 4.2 Does your organization continue to repeat obvious AntiPatterns 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 the book Antipatterns and Patterns in Software Configuration Management [Brown 1999] for a full disclosure on this sensitive topic. In most domains, AntiPatterns are more prevalent than successful design and organizational patterns. Obviously, if people would simply avoid the most common and frequently recurring mistakes, software development would be much more successful. Sometimes, it is less important to have a cutting edge set of software best practices as long as a team is able to avoid the practices that are generally 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? Does your architectural prework effectively define organizational interfaces that enable parallel development?

BACKGROUND FOR SOLUTION: Sophisticated architectural 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. Most application development shops, however, use larger teams to ensure a quality product. It is brutally difficult to attempt to think and work architecturally, when every manager is under extreme time pressure to deliver results. First, they must understand that there is a problem. Lending them a copy of Antipatterns and Patterns in Software Configuration Management could be one way to move forward. It was written specifically for people who have difficulty admitting that there is a problem, when it may be incredibly obvious to most other people.

EXERCISE 4.4 What is your organizational process for designing and building 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 an architecture is 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 described 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.