Notes by Stephen R. Palmer
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 at edn.embarcadero.com/article/29674.
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 does my Object Modeling knol.
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.
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.
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.
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.
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:
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?”.
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.
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.
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.
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.