A Process for Applying 'Modeling in Color'. Peter Coad's 'Modeling in Color' technique uses four class archetypes to build understanding of a problem domain quickly. Jeff De Luca's Feature-Driven Development approach defines a collaborative process that works beautifully with 'modeling in color'.

Building an initial, overall domain object model is an extremely good way of helping a team gain a good understanding of the problem domain for a piece of software they are developing.

Modelling in colour is the best technique I know for doing this and the first process in Jeff De Luca's Feaure-Driven Development(FDD) approach is the best process I know for doing this.

Invented in 1997 for a very ambitious software development project, with a complex problem domain spanning three lines of business, from front-office automation to back-office legacy system integration, FDD combines the key advantages of agile methodologies with model-centric, and quality-focussed best practices that scale to much larger projects and teams than traditional agile approaches.

FDD comprises five processes, each described on no more than two sides of letter-sized paper (without resorting to a very small font size, of course). The first process of Feature Driven Development builds an initial, overall domain object model for a project using interactive, iterative, workshop style sessions.

The overview section of Process #1 of FDD says:

A initial project-wide activity with domain and development members under the guidance of an experienced object modeller in the role of Chief Architect.

A high-level walkthrough of the scope of the system and its context is performed. Detailed domain walkthroughs are then held for each area to be modelled. After each domain walkthrough, small teams are formed with a mix of domain and development staff who then compose their own models in support of that domain walk-through. The teams each present their models for peer review and discussion. One of the proposed models, or a merge of the models, is selected by consensus thus becoming the model for that domain area. A merge of the domain area model into an overall model is performed, adjusting model shape as required.

The object model is then iteratively updated with content by the Design by Feature process #4.

The rest of the process description goes on to describe the tasks performed in a little more detail. The process description is designed to be concise and well bounded (not too specific and not overly generic). Quite rightly, the process description does not include why the process defines the tasks and responsibilities that it does. Neither does it supply many hints or tips on performing the process. This article seeks to provide a little of that 'why' and 'how'.

Note: This is based on an old issue of the CoadLetter (an old technical newsletter from Peter Coad et al) and chapter 7 of my book, A Practical Guide to Feature-Driven Development. The related CoadLetter issue is among those archived by Embarcedero on their edn.

Why build a domain object model

A domain object model is like the road map that guides the journey; without it your team can very quickly end up driving around in circles, continually reworking and refactoring the same pieces of code. In this process, the map makers (developers) explore the land (the problem domain) with people who live in it (the domain experts) and together they produce that road map to follow for the rest of the project.

For a business system, the domain object model defines a set of business concepts, and how they relate to  and interact with each other to provide the function required by the system's users. The domain object model does the same for industrial process monitoring and control systems. In other words, the domain object model provides a conceptual framework within which developers can implement the desired software features.

Eric Evans in his book, Domain-Driven Design, explains why a software development project needs a ubiquitous language. He says "With a conscious effort by the team, the domain model can provide the backbone for that comon language...".

Jill Nicola et al in their book Streamlined Object Modeling, claim that "For understanding a problem and modeling it in a form that supports software development, there is no better technique than object modeling.' They go onto explain that, "Object modeling, when done properly, extracts client knowledge and represents it in a format that is recognizable by the client and profoundly informative to the developer."

Both of these books present additional benefits and arguments fro building a domain object model, as do my notes on Object Modeling.

While process modeling using notations such as BPMN and UML activity diagrams can be very useful, it only forms part of the picture - the flow and sequencing of events and activities. Similarly, modeling data schemas in XML schemas or database definition language (DDL) only provide part of the picture - the structure of the data that the system needs. Domain object models typically constructed from UML class, sequence and state diagrams provide a broader, higher-level view of the structure, key interactions and behavior required.

Benefits of building an object model as a team

Often one or two elite analysts develop an object model and pass it as a large volume of documentation to a  team of programmers to implement. In traditional waterfall-style software development approaches this modelling activity is often lengthy and can overrun, impinging on the time set aside for lower-level design, implementation and verification.

In traditional agile development, these upfront activities are spurned in favor of highly iterative development with continuous input from customers or customer representatives. While having the benefit of producing working code almost immediately, there is the danger that a critical misunderstanding or bad assumption about how the problem domain works results in large amounts of rework or refactoring later in the project. This is somewhat akin to the imfamous charge of the Light Brigade during the Crimean war when a calvary brigade thought they understood what was required and disastrously charged the wrong guns.

FDD Process #1 recommends building a domain object model but using an accelerated workshop style approach. This approach involves people from both sides of the business analysis/development divide, working together as a team to produce the object model.

As analysts and developers learn of requirements, they start forming mental pictures of the desired system. Unless they are very careful, they make assumptions about this imaginary system. These unspoken assumptions can cause inconsistencies between different peoples’ work, ambiguities in requirements documents (yes, even in use cases), misunderstandings, miscommunication, and the omission of important details. Developing an overall domain object model as a team forces those assumptions out into the open, misunderstandings are resolved, holes in understanding are filled and a much more complete, common understanding of the problem domain is formed.

Instead of a large number of people sat around a table with conversation dominated by a vocal few while the rest disengage, the group is split into teams of two or three that work concurrently on the same area of the problem domain in short iterations. These multiple small teams attack the problem from slightly different angles and pursue different lines of thought. After a short time, the results from each small team are compared. There are multiple solutions to choose from, all with their own strengths and weaknesses. The result is multiple minds fully engaged and applied, and different solutions explored and considered concurrently - more enjoyable work and better results.

The model produced from these sessions is a team effort and you immediately have buy-in from the developers because they helped build it. There is no more need for meetings with analysts aggressively justifying and defending their object model to critical developers trying to understand it properly.

Communication between the business and development, between users and analysts, and between analysts and developers is often poor in a software project. It is frequently blamed for many projects delivering results that do not match the client's expectations. Working together in small groups, and as a whole team in the same room, helps the modeling team members learn to communicate with each other; a skill that can be used throughout the rest of the project.

The result of the modelling workshop is not just a better object model but a jelled team ready to take on the rest of the development. The energy and enthusiasm generated by the creative activities raises the morale of the team.  There is a real sense of achievement as a team. The first one of these activities that I participated in still ranks as one of the highlights of my career and, as Tom DeMarco points out, "Once a team begins to jell, the probability of success goes up dramatically" (DeMarco & Lister, Peopleware, Dorset House).

At United Overseas Bank, TogetherSoft, and Borland, I saw this workshop approach work extremely well, time and time again. The old TogetherSoft service offering called How To Build Better Object Models (HTBBOM)  was designed specifically to enable our clients to experience this while learning better object modelling techniques and strategies. Over a period of 4-5 days an experienced consultant takes the role of Chief Architect and takes a team through FDD process #1 three times; twice on simple problem domains and then through part of the client's own domain. Not only does the team learn through listening and doing together, they get the chance to apply the principles to their own problems with guidance from an experienced object modeller.

 I have also presented the same material in a shortened format as pure training workshops and even shorter seminars (most recently at Agile 2009 with Dan Vacanti). While these do not provide the same team building experience or generate the real results that a workshop with a real project team does, the attendees do come away with a set of new strategies and patterns to try out.

Hints and Tips

Forming the team

A skilled facilitator is required during the object modelling. A skilled chief architect is also required to ensure the resulting object model is the best possible. A person that can play both of these roles is a great but rare commodity. If required, pair the chief architect with someone with good facilitation skills to lead the workshop as a team.

An ideal team size is between six and twelve people in addition to the chief architect/facilitator. This allows the team to split into multiple smaller teams of two or preferably three. Any more than twelve becomes hard to facilitate and we are into diminishing returns for each additional person participating. Any less than six and the splitting into smaller groups gets rapidly less effective.

For larger teams, keep a core team and rotate the other development team staff through in ones or twos so that they get a feel for the process, the domain and the object modelling techniques. If the room is big enough others can also sit in and observe (no participation allowed).

The core members of the team should include the lead developers, domain experts and some of the better analytical developers. A mix of two thirds developers and one third domain experts seems to work well because, when working in threes, each pair of developers has a domain expert to provide domain guidance. Domain experts can be users, clients, sponsors, business analysts or any mix of these. We need them to be good team players, enthusiastic about the promise of the new system and above all, patient as developers ask basic questions about their business.

Mix the small group membership up every now and again to ensure everyone works with everyone else and to change the dynamics if progress is becoming stodgy. Do not encourage small groups of more than three; the fourth either becomes a 'manager' of the group or has to strain to hear and see what the others are doing.

Setting the Rules

The first time a team attempts to work in this workshop style, take fifteen to twenty minutes after initial introductions to explain the Lessons Learnt from Fred (see CoadLetter #40) and as a team agree on the norms to use during the modelling sessions.

Setting the Environment

I have tried a number of different environments and found a conference room style setup to work best. The room needs to be big enough for the modelling team to sit comfortably around a central table. A good mix of windows and wall space gives plenty of natural light and space to hang the results of the work as it progresses. It's hard to feel creative in a classroom atmosphere especially if that classroom feels like a cave because it has no windows.

Recommended materials include:

  • Flip chart pads and stands. Ideally we want one stand for every three people in the modelling team though this is not critical. The modelling team will demolish two or three standard size flip chart pads in a week.

  • Post-It notes. Here we want the standard 3 inch square size. The ‘modeling in color’ technique uses the usual four pastel shades of pink, yellow, green and blue. Other colors are distraction, do not use them.

  • Permanent Marker pens. These should not be too thick; the Banford Sharpee Fine Point Permanent Marker are the best I have used to date. Beware marker pens that bleed through paper (like some whiteboard markers); their contribution to the d�cor may not be universally well received.

  • Pencils and Erasers are useful for thinking aloud until a group is ready to ink in names and associations.

  • Masking Tape is needed for hanging flip chart sheets on the wall. The Post-It note style flip chart pads that stick to the wall on their own reduce the need for the tape. However, it is still needed if you want to hang the sheets in landscape orientation. Something lie blutack can be used instead but again can mark the wall if not used carefully.

  • Correcting tape to 'white out' those 'inked in' names and associations that were not quite right.

  • A party-style whistle for the facilitator to use or some other fun contraption for attracting attention of the team when working in small groups. Yes - the small groups can get so immersed that it is hard to pull them out of it without having to raise your voice.

  • A soft ball to use a token during intense team discussion; only the person with the ball may speak.

  • A CD or MP3 player to provide background music during small group work. This is especially useful for playing some lively music in sessions just after lunch.

Setting the Scope

For a team new to this process, a very useful and simple warm up activity is to break into groups of three and prepare a statement of purpose for the project. Set a time limit of 10 minutes and a word limit of 25 words or less. Keep the statement high level and avoid technology terms like scalable (sounds like a characteristic of a fish or a rock face); the purpose should communicate to the domain experts.

Get each small group to read out their result. As a team, compare and contrast the results, highlight good words and phrases in each, and then volunteer two or three people to merge the small group statements into one statement while the others are on the next coffee/tea break.

In doing this, the team gets some initial practice at splitting into and working in small groups, presenting results and comparing them. The facilitator sees the group in action for the first time and can note the initial group dynamics and personalities in the team. The result provides a focus for the team and the project. The team may tweak the statement occasionally as requirements become clearer but the team can now answer, in a couple of sentences, the question, “What does this system do?”.

Working With Domain Experts

Let Domain Experts break up the domain into the chunks that they present. The chunks will frequently represent the natural break down of the domain into key business or functional areas. This in turn can be informative when trying split a large model into loosely-coupled components or Eric Evans's 'bounded contexts'. Although, the initial walkthroughs may need to be a little longer, a domain expert should constrain their walkthroughs to about 15-20 minutes typically. This generally provides enough for the team to model and fits within most people's attention spans.

Be ready to add a topic that takes a domain walkthrough off into an unproductive direction or discussion to a list on a whiteboard or flipchart. Just as in Scrum, such a question, issue or obstacle needs to be addressed outside the session if the people in the room do not have the knowledge or authority to deal with it there and then. We usually call this the Rat Holes list but the name is not important.

Beware Domain Experts with a technical background presenting preconceived ideas or making assumptions about the design. It is all too easy to, with the best of intentions, to present artificial domain concepts and constructs if you have a background in software analysis and design.

Domain Experts should feel free to sketch informal diagrams on whiteboards and flipcharts but there is no need for PowerPoint-style presentations.

Actively look for users' and clients' points of most pain - the tedious, difficult, time-consuming, and repetitive work that drives them nuts or gives them sleepless nights. Also try to distinguish between the way the fundamental  business works, corporate policy and legal/regulatory statute.


Finally do not treat Domain Experts as if they are responsible for any perceived stupidity in way the business works. They are the messengers. Do not shoot them.

Working in Small Groups

Apply the colour modelling technique, identifying Moment-Intervals and the Roles, Party-Place-Things and Descriptions that fit around them.

Reuse concepts from previous iterations as much as possible but do not artificially bend existing concepts to fit new ones.

Beware getting bogged down in the detail of attribute types and operation parameters, etc.

Bringing it all Together

One team may 'get it'. If this is the case add their result to the overall model. Often multiple teams have good insights and their results so pick one and merge in the good points from the other. If the team cannot decide between two different models, the Chief Architect makes the call.

It is not a sin to spend some more time in small groups if none of the teams feels they have cracked this part of the domain, or it is clear that there is something not correctly understood about the domain. Obviously, in the latter case, seek clarity from the domain experts before working in groups again.

Conclusion

The tips and tricks, people skills, group dynamics, model patterns etc, etc, for FDD Process #1 are probably endless. This article has presented a few and discussed some of the key benefits of the activity. There are more in A Practical Guide to Feature-Driven Development.

Follow me on Twitter...