Paul Dyson

Given an example problem we decided to take the following approach to solving it: try something out and see how well it works, try something else out and compare, reflect on the process and see what worked and what didn’t, perhaps apply a more formal process to a third possible solution.

We started off using CRC cards to flesh out a logical design (although Tony called it an analysis I thought it was more like a design without implementation-level detail). As this was intended to be the first of a number of attempts at solving the problem we arbitrarily chose to ‘view the world through service-tinted glasses’ and so opted for objects that looked like services every time we needed something new to fulfil a responsibility. In about 30 minutes we had a complete logical design for the system.

For the next stage of our experiment we produced something I’ve used before in architectural reviews, something that might be called a ‘collaboration map’. Basically we looked at each CRC card and drew an arrow (using an artistic combination of spoons and bulrushes!) from it to each card it collaborated with. This gives you a picture something like:

Here, A collaborates with both B and C in order to fulfil some responsibility or responsibilities. C collaborates with everything and E collaborates with no one but is required as a collaborator by C and D. [Aside: I think there’s a lot of useful info that can be picked up from analysing this sort of view but that’s for another day].

Having produced our collaboration map with Order, StockManagementService, InvoicingService, etc. we did a bit of design ‘normalisation’, removing direct collaboration paths that duplicated indirect paths, etc, to give us an ‘optimised' logical design. This formed the basis of the second phase of our experiment which was to look at how the system might be distributed (remember that no distribution was one option for the system’s architecture). We chose four non-functional characteristics of the system: performance, robustness, scalability and extensibility; and evaluated how good the system was for each of these in four different physical architectures:

• The entire system in London with manual messaging between London and Leeds
• The warehouse-related stuff in Leeds and everything else in London with things like Order and Invoice remaining in London
• The warehouse-related stuff in Leeds and everything else in London with things like Order and Invoice migrating between the two locations in a number of different ways (including pass-by-value, replicant synchronisation, etc.)
• The entire system replicated between the two sites.

[These are the same architectures that John’s group proposed in the first section of the day but what we did was to look at the collaboration map and draw the distribution boundary in some arbitrary place (initially outside the logical system). We then moved the distribution boundary gradually into the system to see what the effects of partitioning the system were.]

Using this process gave us an optimal solution to the problem given the logical design we had initially chosen and the four non-functional characteristics we decided to evaluate the physical architecture against. The last stage was to look at how we might ‘componentise’ the system by looking at objects grouped along two dimensions: physical location and ‘functional cohesion’ (the objects all collaborate to achieve a wider identifiable purpose such as managing customers or invoicing). We also looked at what we might buy in (customer management, accounting, stock control) and what we’d probably have to build ourselves (the components that co-ordinate the other components according to the rules of the business process).

What we didn’t have time to do was try another logical design and go through the same process with it. We also didn’t evaluate the logical designs on the whole range of non-functional characteristics that we might have, including: cost to buy or build, compatibility with supporting technologies such as CORBA or EJB, risk to build, etc.

What I like about what we did is that we took a ‘clean’ view of the problem and didn’t bow to the pressure of pre-conceived notions. We worked with a spirit of experimentation and quickly found out a lot about the problem from both the logical and physical perspectives. Normally I would say that you can’t produce a logical design and then add in distribution as an afterthought, but given that no distribution was one possible outcome its wasn’t clear how else to start but with producing a logical design. [Another aside: Kent Beck’s stated solution to solving hard distribution problems is not to do distribution]. By trying to fit distribution into an initial logical design we learned something about the distribution characteristics of the system which would have informed the next two or three logical designs: we would have ended up producing a logical design that considered distribution from the outset. And not distribution in general but distribution as relating to this specific problem.

I also like the fact that we concentrated on getting to the heart of the system (what Kevlin called: ‘understanding the stuff of the system’) before looking at possible component models. Rather than seeing what we could buy or what we could build we looked at what we really needed. We were then in a position to shop around, perhaps buying something that did much more than we needed, or much less with extension possible, but fully aware of that when we made the decision.

Something we could have done better was to consider component models earlier on. When we evaluated distributed physical architectures we should have thought about what supporting technologies we could have used (because we wouldn’t want to do distribution without some platform bought in, even if the platform was DCE) as this would have influenced the other characteristics such as performance, robustness etc. We also looked very specifically at the technology we needed to produce to solve the problem rather than how the problem might better fit available technology. Whilst I’m rather suspicious of the principles involved in re-engineering the business, there has to be realism on the parts of both the user and developer: we need to give the user what they want but they have to be able to work with what we’re capable of giving them.

I’ve decided that it must be quite a good thing that the three groups came up with similar solutions despite rather different approaches to solving the problem. One possibility is that we’re all crap at building distributed systems and so produced the same naive solution that couldn’t possibly work in the real world. Given the people in the room I think the contrary is true: we’re all pretty good at building distributed systems and we have an instinctive appreciation of what a good solution looks like. This gives us a solid basis to work from: at least we’re examining processes and approaches to building good systems, not bad ones. We’re also coming from common ground even if the approaches were very different. This is great: given a core of understanding we’re exploring a wide range of processes, activities and attitudes that may well help us to expand that core of understanding.

I’m both encouraged and disappointed by the professed reliance on patterns ("we now go and look up the patterns that tell us how to solve X…" was a phrase that seemed to cropped up a lot). I’m encouraged because I like patterns and I want to see them adopted into the mainstream, I do believe they are fundamentally for the good and are beneficial to those that can use them. But I’m discouraged because phrases like these are indicative of a search for a silver bullet; if only we had some patterns then this would be easy. As far as I know, no one is writing these patterns. Even if the patterns existed I don’t believe patterns are just handbooks of problems and solutions. A good pattern resonates with the reader’s own experience and using a pattern ‘blind’ can lead to as many new problems as it solves (just ask me the story of the Student and the Null System). If we want these patterns then the only thing to do is to write them ourselves, which means we have to do the stuff before we can say: "we now go and look up [some of our] patterns that tell us how to solve X…".

I’m rather disappointed that we all started with the premise that you must have services to do distribution. Our group was going to try an entity-based solution but, personally speaking, I expected it to be an also-ran that proved the worth of the favourite rather than a valid solution in its own right. The main reasons I can see for entity-based solutions being second favourite to service-based ones are: performance of ORBs is tuned more to course-grained than fine-grained objects; data replication is hard, expensive and slow; and its harder to add new services to entity-based architectures. But it occurred to me on the way home that we were assuming performance meant very fast response times. Suppose the system was one for ordering furniture and assembly meant actually building a sofa out of component parts rather than putting stock elements in a box. Here, delivery to the customer is ~10 weeks (or more as I’m currently finding out!) rather than the next day so system response times are not really an issue. But adding new types of furniture, to be built from new types of component, possibly is an issue: an entity-based architecture is a better fit and the performance issues go away given the time from placing the order to fulfilling it. Obviously the example was (deliberately?) missing a lot of context but we are did ourselves a disservice by assuming performance (in a scale of seconds) to be an over-riding concern.

… is to build the system. We profess belief that the devil is in the detail but we only really took a high-level view of how we might build the system. Also, understanding the relative merits of MTS, EJB, CORBA, etc. means building with them (or simulated versions of them). I’d also like to involve a few people who know how to do the distribution element of the system even if they’re not so familiar with objects and ORBs. If there are any ‘ready made’ patterns to be had then these are the people that have them.

…. I really enjoyed the day. I am encouraged by what we did because I don’t think there could be a much better group to solve these problems. Perhaps it would be better if someone could solve them for us, but perhaps not -they’re pretty interesting problems after all. Cheers guys, P.