Solution-Architecture Design Methodologies: eXtreme Solution Design (XSD)


Roger Hill

December 2007

Summary: Documenting the architecture of the design of a software solution can be performed with agility. (9 printed pages)


XP Background
eXtreme Values
eXtreme Laws
The Approach
Critical-Thinking Questions


While in the company's workout room at lunch one day, Jared, a Python programmer, was exercising on the machine next to me. He started a conversation by explaining that he was working on a project that seemed more challenging than he had previously experienced. He was accustomed to building small software applications by using XP, but was wondering how it would work for a bigger project. The project would need to be partitioned into several manageable units, with multiple developers working on the various pieces. How could the bigger project be controlled? How would he decompose the components, and manage the higher risk of change with agility? Could he still apply the rules of eXtreme Programming? I framed my response to him by using terms with which he was familiar: the values and laws of agile software development.

XP Background

Kent Beck invented eXtreme Programming (XP) as a lightweight methodology for software development. His intent was to reduce the development time and enhance the flexibility of developing quality software solutions in a team environment. His work has also spawned a new approach to software analysis and design, called "agile." The term "agile" refers to the ability of the methodology to accommodate change during the development process. The capacity to change, to refactor the solution, is embedded in the use of story cards as the mechanism to capture the business requirements. Similar to Ivar Jacobson's use-case approach to object-oriented software engineering (OOSE), eXtreme Programming relies on the "story." The metaphor of the business is captured as a set of story cards that define the required business functionality, and is backed up with data that is defined as domain objects.

Traditionally, software-development practices have focused on complete and thorough up-front architecture, because the development of the solution was costly, time-consuming, and inflexible. By using XP, the cost and schedule for delivering a system is greatly reduced, and the flexibility of the delivered application is significantly enhanced. With the focus on rapidly prototyping a possible solution, there is a tendency to jump to a solution and quickly hack out something to show the customer. By applying the principles and practices of eXtreme Solution Design (XSD), programming teams can take the "hack" out of rapid development and deliver an integrated collection of software services.

eXtreme Values

Jared was familiar with Scott Ambler's five values of agile modeling. I used his knowledge by showing how the values to which he was accustomed applied to small software-application development projects—namely, communication, simplicity, feedback, courage, and humility [Ambler, 2006]—as well as how they apply to an XSD approach for larger development projects.

In XSD, models are the key element in communicating understanding. A semantically accurate model communicates business facts that are compileable into data and/or methods at the lower implementation levels of system definition. The models should be tested through customer walk-throughs and by playing the models together. For example, the stories must be reconciled with the domain object model and the analysis model, to verify that those models fully support the requirements of the metaphors. This is a form of early user testing that is paramount to maintaining an agile development environment.

It is important for developers to understand that models are critical for simplifying both software and the software process. It is much easier to explore an idea and improve upon it by drawing a diagram or two, instead of writing hundreds of lines of code. "Simple Design focuses on delivering a system that meets the customer's immediate needs—no more and no less." [English, 2002]

Jared agreed with me that feedback was, in essence, a specialization of communication, but he wondered what was meant by courage. Is this a willingness to modify the requirements without customer buy-in?

On the contrary, I stated that courage is the willingness to press a decision on an unfavorable perspective for closure with the support of the stakeholders. Courage is vital, because important decisions must be made quickly and do not need to be cast in concrete. Changes in direction can be accommodated by refactoring the design, when current decisions prove inadequate. Oftentimes, courage is needed to go against the established standard of architecture. Gordon Benett notes, "One problem with using Unified Software Development Process (USDP) and the Universal Modeling Language (UML) for Web development is that they require a large up-front commitment. Users must be interviewed by process experts who develop formal use cases, from which the architect(s) produce(s) a UML model indicating the static and dynamic structure of the system being developed." [Benett, 2001]

I cautioned Jared that humility is the most difficult value for a developer. Software engineers have a unique set of skills that they employ for creating automated tools, to drive the company's strategic initiatives forward. Yet, the best developers have the humility to recognize that they do not know everything. Their fellow engineers, their customers, and, in fact, all project stakeholders have specific areas of expertise and value to add to the design of the project. An effective approach is to assume that everyone who is involved with the project has something of value to add for the successful completion of the project, and, therefore, should be treated with respect.

eXtreme Laws

I explained to Jared that projects were successful not by chance, but by adherence to established principles. To employ his knowledge of agile development further, I stated these principles as "laws."

Eschew Obfuscation

The KISS principle (Keep It Simple, Stupid) is a paramount law for being agile. The model should be lean and should depict only the important artifacts for the level of definition for which the model is targeted. The model should not represent data or processing that is not going to be implemented. The requirements that are represented on the model are the business requirements that are today's reality. They are not the hopes and dreams of a designer gone wild. Future refactoring will accommodate any additional requirements, as they evolve.

Maintain Flexibility

Knowledge is evolutionary. As soon as the perfect system is designed, stakeholders, customers, and developers will find additional uses for it, and new and improved technologies to apply to it. Adaptability to change is the defining characteristic of being agile. Both business and industry are replete with examples of projects that were canceled upon completion, because the requirements had changed during development, and that change had not been accommodated.

Provide Extensibility

Akin to flexibility, extensibility is the capacity to add future functionality, to extend the system's capabilities over time. The extensibility attribute comes into play in each phase of an agile methodology. One of the objectives of defining the exit criteria for a phase is to set it up for the next iteration. Keep in mind that the next iteration might be a small refinement of the current understanding, or it might be a major refactoring of the model elements.


An agile model must be semantically correct enough to feed information to the next phase. The method by which this can be measured is the compileability of the model, which asks the question, "Can the model be compartmentalized into design blocks that play through the metaphors as self-contained objects?" The content of the model is the important focus of an agile enterprise. It must be adequate enough to avoid errors in the interpretation of the model.

Develop Iteratively

The solution design does not have to be perfect on the first pass. Instead, the focus is put on it being only semantically correct enough to pass information to the next phase and set it up for the next iteration. This guiding principle helps prevent the analysis paralysis that is inherent to many enterprise definitions and development projects. The model should allow the placement of "a stake in the ground" [Ambler, 2006], and then move on to the next stake. It should be expected that the stakes can be moved (reshuffled) or repartitioned (refactored) during future iterations.

Rapid Feedback

Agility implies quickness, and nowhere is speed more important in XSD than in the capture of feedback. The rapid turnaround of information that is collected in joint architecture teams (JAT) that comprise stakeholders, customers, and developers builds on the momentum of the methodology to stage a mindset of quick thinking among the participants. Too long of a break between the identification of an issue and the definition of its resolution can cause the entire focus of the team to be derailed. Stay on track by avoiding breaks in thought that allow time for mental derailments.

The Approach

At this point, Jared had a taste of the philosophy, and he was eager to learn the pragmatics of making it work. I started with the topic of getting the "customer commitment." He would need not only a sponsor, but a real champion who would continuously sell the benefits to the customer with real passion, to keep the stakeholders committed. Because of the speed of an extreme approach, a JAT of business-domain experts, IS architects, and key decision-makers combines to drive out the design without interruption or distraction. A full commitment to active participation, quick decision-making, and immediate follow-up on assignments is expected by every member of the team. One should assemble a team that has the right knowledge, the authority to make decisions, and the commitment to do nothing else until the task is completed. Because every person on the JAT is active in the creation of the models, everyone has personal ownership of the deliverables. The creation of a JAT requires senior-management approval to free-up the stakeholders, domain experts, and architects from their other duties.

Story-Card Metaphor

Story cards are a briefly stated requirement in story form. They should define the requirement from triggering the action to completing the action, and should identify the domain objects that play through the story. "Get requirements by having the customers tell stories about how the functionality of the system will be used. Customers write the stories on cards, organize stories into topic areas, and classify them by priority and risk." [Jeffries, 1999] Arthur English notes that "XP encourages stories, which are brief descriptions of a system task, instead of more traditional Unified Modeling Language diagrams and models." [English, 2002] Follow-on iterations through the stories will append test scenarios to them. This practice forces the solution designers to think early on about the implementation aspects of the requirements.

I suggested to Jared that he focus on "data first." Data is the most concrete aspect of any system development. While processes can change with reorganization of the company, changes in the data objects are generally linked to changes in the product. Consequently, a good data model can drive the evolution of the enterprise model with fewer changes needed. The data can be driven out of the stories by listing the business assets that the stories mention. Care should be taken to resolve all synonyms and homonyms in the data names. The domain object model (DOM) is the foundation for the glossary of terms for the project. The model does not need to have its transitive dependencies resolved; however, the closer it is to Codd's Second Normal Form (2NF), the closer it will be to being a compileable model that is easily partitioned into design blocks.

Figure 1 represents a domain object model for student records at a university:

Click here for larger image

Figure 1. Domain object model (DOM) (Click on the picture for a larger image)

Cluster Functionality

After an object is defined on the domain object model, the important processing can be applied to it. Keeping with the value of simplicity, functionality should be limited to the activity of creating, modifying, removing, and viewing the data. Although the Transcript, Attendance Roll, and Report Card were defined as domain objects during the development of the DOM, the model now evolves with the transformation of those elements to be the results of processing, instead of data elements (see Figure 2).

Click here for larger image

Figure 2. Domain process model (DPM) (Click on the picture for a larger image)

I introduced Jared to the use of Ellen Gottesdiener's "Wall of Wonder" [Gottesdiener, 2001] as a mechanism to "review continuously." By having the in-work model in full view of the JAT at all times, an environment of continuous review prevails. Ellen suggests using a Wall of Wonder to foster healthy group participation. Use the wall from the very beginning of the JAT for posting, combining, sequencing, and refactoring the story cards. Post the domain objects on an adjacent wall, and cluster sticky notes of functionality around the domain objects. Keep the wall current. All discussion and decision-making should be immediately reflected by changing the model artifacts on the wall. Having the model displayed on the workroom wall improves ownership of the model content, by encouraging a continuous walk-through of the information. When one artifact of the model is modified, participants can quickly point out discrepancies in—and impacts to—related artifacts.

The wall also promotes the simultaneous development of model artifacts. A data object can have its functions clustered around it before other objects are posted. This seemingly random approach to model creation is conductive to brainstorming, and it plays well with the iterative approach. If the latest decision does not hold up under greater scrutiny in the next iteration, change it again.

Test Everything

Testing is a point of pain for most programmers, and Jared was no exception. He knew how to test executable programs, but he wondered how the design might be tested and when you would know if you were done. Ron Jeffries has stated, "It isn't enough to write tests: You have to run them." [Jeffries, 2001] How is a test run on enterprise architecture? The first thing that is tested is the compileability of the model. The questions that must be asked are the following:

· Are the domain objects uniquely defined?

· Are the relationships between domain objects normalized (2NF)?

· Is the functionality uniquely clustered around the domain objects?

· Can the business be cleanly partitioned between the domain objects?

Secondly, the functionality of the model is reconciled with the story cards for requirements traceability. To verify the functional mapping, the model must be partitioned into cohesive design blocks, with little or no coupling between them. These design blocks are akin to Ivar Jacobson's "blocks" [Jacobson, 1992, p. 205]. The evolution of the model into design blocks might require refactoring, and might also require a further refinement of the story cards. At this point, I reminded Jared that any change to a story must be approved by the JAT. For reconciliation, the important questions to ask are the following:

· Does each story card map to one and only one design block?

· Does each design block map to one or more story cards?

· Do the story cards tell a complete story?

Testing provides feedback; and, as mentioned in the eXtreme Laws section, rapid feedback is an essential part of keeping the team focused. Ron Jeffries notes, "The most important form of feedback is testing. Testing gives you rapid development [and] confidence, and, often most important, it builds support from your constituency." [Jeffries, 1999]

Figure 3 is an example of partitioning the model into design blocks. I emphasized to Jared that the minimal coupling between the design blocks is a prerequisite for avoiding the pain of significant refactoring in the coding phase. The design blocks are the pieces that are then assigned to the pool of programmers, and they are the crux element of effectively managing the solution development.

Click here for larger image

Figure 3. Design blocks (Click on the picture for a larger image)


The failure of most software-development projects lies in the inability to manage change. This is the strength of agile methodologies; but too much change can topple any tower. Using the XSD methodology reduces the impact of change that is inherent to application development, by merging architecture principles and practices with the laws and values of agile software development. These sound strategies provide for the partitioning of requirements into highly cohesive blocks of data and methods. The resultant projects are minimally coupled for enhanced flexibility, extensibility, and reuse. Jared learned that good architecture can be agile, and that, without it, XP is just another hack job.

Critical-Thinking Questions

· When decomposing a solution set into manageable pieces, what are the advantages of partitioning based on data? What are the disadvantages?

· What is "cohesion" versus "coupling" in software design? Why is it important to have highly cohesive and loosely coupled solutions?

· What are the next steps, if management does not charter a JAT or does not emphasize the level of commitment to all JAT members?


· [Ambler, 2006] Ambler, Scott. "Agile Modeling: Effective Practices for Modeling and Documentation." Agile Modeling Web site. (Accessed on November 29, 2006.)

· [Benett, 2001] Benett, Gordon. "Extreme Programming (XP) Holds Promise for Intranet Development, Part I." Intranet Journal Web site posting of September 2001. (Accessed on November 29, 2006.)

· [English, 2002] English, Arthur. "Extreme Programming." Network World Web site posting of January 28, 2002. (Accessed on November 29, 2006.)

· [Gottesdiener, 2001] Gottesdiener, Ellen. "Specifying Requirements with a Wall of Wonder." The Rational Edge Web site posting. (Accessed on November 29, 2006.)

· [Jacobson, 1992] Jacobson, Ivar. Object-Oriented Software Engineering: A Use-Case-Driven Approach. Reading, MA: Addison-Wesley Professional, 1992. (ISBN: 0201544350)

· [Jeffries, 1999] Jeffries, Ron. "Extreme Programming: An Open Approach to Enterprise Development." XP Magazine online posting of September 1, 1999. (Accessed on November 29, 2006.)

· [Jeffries, 2001] Jeffries, Ron. "What Is Extreme Programming?" Web site posting of November 8, 2001. (Accessed on November 29, 2006.)


First Normal Form—E.F. (Ted) Codd defined the steps for normalization of relational databases. His First Normal Form (1NF) is the state in which the attributes of an entity are defined with functionally dependent atomic attributes, the entity is identified by a key, and there are no repeating groups of attributes.

OOSE—Object-oriented software engineering. A software-design methodology that was developed by Ivar Jacobson in 1992.

Python—A high-level programming language that was created by Guido van Rossum in 1990. It is based on dynamic type classification, and is available as freeware from the Python Software Foundation.

Second Normal Form—E.F. (Ted) Codd defined the steps for normalization of relational databases. His Second Normal Form (2NF) is the state in which First Normal Form (1NF) has been achieved, and in which the attributes wholly define the entity—that is, in which there are no partial functional dependencies.

UML—The Unified Modeling Language. The object-modeling language specification that is defined by the Object Management Group (OMG).

USDP—Unified Software Development Process, or Unified Process. A popular iterative and incremental software-development process framework. One variant of this is the Rational Unified Process (RUP).

XP—"eXtreme Programming." An agile software-development methodology that embraces the changing work statement with rapid feedback, programming in pairs, and daily walk-throughs.

About the author

Roger Hill, having engaged in software development since the mid-1970s, has embraced the evolution of software-development life-cycle methodologies (SDLC) and practices over three decades of study and development. He has developed systems for finance, retail, inventory management, and design engineering. Roger has written papers on reverse engineering, defining components, and strategic alignment of software projects. He continuously participates in learning opportunities, and has a Master of Science degree from Carnegie-Mellon University.


This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit