8.5. Exercises

Exercise 8.1

Work with a peer or manager who is very familiar with the organizational systems. Identify the focus of the study, such as: "We want to find a way to exchange accounting information between our systems for monthly and yearly reporting" or "We want our customer service representatives to access information and post transactions across as many lines of business as possible." Then make a list of the systems, standards, prototypes, and products you already know about that are relevant to the problem. Check the Internet, too. Sort this list in terms of the importance of each system for the business and problem resolution. You are done; you have a plan for architecture mining. The next steps would be to track these resources down (leverage the knowledge of managers) and set up some 2- to 3-hour appointments with their one or two architects to walk through their interface specifications and/or schemas, depending on the problem.

Background for Solution:

Maybe we chose the wrong name for this process, but architecture mining is a quick and lightweight procedure, compared to what most people expect. You can plan a mining mission in an hour or less (e.g., this exercise) with the right pair of people in the room. Over a 2-week period, you can complete this mission. And your architectural knowledge will be increased immeasurably.

There is no deliverable from architecture mining; it's all about making architects smart. Pick the best-of-breed of the ideas you gather, and you are well on your way to specifying a quality architectural solution to a problem that is vitally important to your business organization. We can't recommend an easier or faster way to get these kinds of results. We know many groups of architects who have spent years trying to find the answers that architecture mining easily delivers within a couple of weeks.

Architecture mining has a second important benefit: it cross pollinates information between projects, creating technology transfers that are otherwise organizationally impossible. The SunSoft people who created Java Database Connectivity (JDBC) used a similar process. They met one-on-one with contributing organizations, eliminating competitive worries that larger multiorganizational meetings would surely trigger.

Exercise 8.2

Using your organization's current software process, how would you synchronize the architecture iterations to minimize fluctuations in architecture during development tasks? How would you coordinate architecture changes between iterations? On large projects, will this architecture coordination benefit from synchronization with management communications/meetings, or should architecture coordination be an entirely separate process?

Background for Solution:

The key concept of architecture iteration is to keep the architecture stable when the code is changing, and vice versa. Stabilizing the architecture during coding yields significant benefits. It eliminates much developer confusion. It reduces the wasted time spent on system discovery (estimated to consume up to half of the developer's time). It enables programmers and groups of programmers to work in parallel and in distributed laboratories.

Exercise 8.3

List the elements of your organization's design process and the resulting design elements. How would each element and step be characterized with respect to engineering procedure versus architectural judgment? In the execution of judgment, how is the judgment rationalized and/or documented? How could each judgment be re-evaluated at a later time? Who is responsible for defending key judgments when changes occur?

Background for Solution:

Software engineering has suffered from physics envy. Ideally, every process step could be decomposed into rational engineering analysis techniques. Analogies such as automobile manufacturing have been applied to software process, with disappointing results. There is an intuitive level of decision making which is often discounted and buried in software engineering processes. In this age of software architecture enlightenment, we are making these issues explicit and assigning responsibility to architects to manage these intuitive forces. To make the incredible transition from unstructured natural language requirements to a brutally logical binary machine, we must, at a minimum, insert some intermediate steps, in order to minimize risk. This is the role of software architecture, in addition to system planning, which maps the intuitive forces in rationalized steps into the logical abyss of machine code. Architectural judgment is vital to this transition, whether explicit or implicit in the software process.