Naked Objects
By Richard Pawson and Robert Matthews
Case study: Retail marketing and pricing
Safeway Stores is the fourth largest supermarket chain in the UK, with over 480 stores ranging from hypermarkets to local convenience outlets. Over the last couple of years Safeway has enjoyed significant growth in both total revenues and profitability, triggered in part by the appointment two years ago of a new chief executive and a more dynamic approach to merchandising and pricing.
Business background
Although Safeway is committed to using software packages for various business processes, it is also prepared to develop its own systems where it sees an opportunity to innovate or differentiate. For example, Safeway was the first of the UK store chains to introduce self-checkout for customers, using handheld barcode scanners. And its handheld Shelf-Edge Computing system, which allows staff to check prices, monitor stock and place orders whilst moving about the store, won an industry award when introduced in 2000.
Although many of Safeway's existing systems must be maintained in Cobol, Java is the preferred language for any new in-house development and integration of interactive systems. There are Java developers in most of the application areas, and also a centrally managed Java Services Team, who determine best practice and guidelines, perform research and development, provide technical assistance, and act as consultants throughout a Java project lifecycle.
The management of this team became interested in Naked Objects at the start of 2001. They did not initially see Naked Objects as a development approach, but rather as a way to train some of their Java developers to think in more object-oriented terms. (Many development managers have found that switching to an object-oriented programming language such as Java does not automatically change the way people think about systems design). They felt that more commitment to object-oriented principles would help them see greater benefit from the investment in Java technology and skills. More than 30 developers received basic training in Naked Objects over the next 3 months - with the majority reporting that it had significantly improved their understanding of object-orientation. Moreover, the experience had created considerable enthusiasm for undertaking a realistic development exercise using the framework.
Opportunity
Still under the auspices of training, a candidate project was identified in the area of promotions management, known as 'deal nominations'. Safeway changed its pricing policy a couple of years ago. Now, instead of attempting to maintain a policy of 'every day low pricing', it competes through special promotions that offer up to 50% discounts on particular food and drink lines, designed to bring more customers into the store. Each week it prints and distributes some 11 million 4-page colour flyers to households in the catchment areas. To prevent the competition from matching these offers, the set of promotions is constantly being changed. Stores are grouped into clusters, and each cluster offers a different package of around 40 special promotions each week.
Implementing these promotions involves managing the supply chain to cope with big increases in sales of the promoted items, communicating the price changes to the EPOS systems in the stores, and printing and distributing the promotional flyers, in-store banners and labels. Systems exist to manage each of these activities individually, but the overall planning and coordination of these activities is intensely manual, as is the planning process. Promotions managers are constantly exploring combinations of special offers with the intent of attracting the maximum number of shoppers who will then go on to buy regular items from the store, without merely encouraging 'cherry pickers' who take the best offers and nothing else. Each special offer must be coordinated with the supplier for logistics planning and, in some cases, to share the cost.
Ideally, these managers needed a purpose-designed system to nominate new deals, forecast sales and availability, simulate their roll-out through the store clusters, and then coordinate their execution through the supply chain and price coordination systems. Previous attempts by the systems department to analyze the requirements for such a system had not gone well. The activity did not fit well into the strongly process-oriented perspectives that are required for, say, supply chain management systems. 'Deal nominations' was much more of a problem-solving activity: any particular deal might start with a proposal from a supplier, or it might be initiated to fill a 'hole' in a partly-assembled offering. What was needed was a system that would allow users to construct multiple offerings, simulate their effect, and cut and paste them until they felt right. Then make them so!
Approach
A team consisting of developers and business area representatives was assembled and given just four weeks to design a proof-of-concept using Naked Objects. To put this into perspective, previous attempts had taken much longer than that to do a paper-based requirements-gathering exercise, only to be abandoned because the users were unconvinced that the resulting document really captured what they needed.
The new exercise made no use of that previous work: it started from scratch. After just a couple of hours spent discussing the dynamics of the business in order to give the developers some familiarity with the domain, the team got straight down to identifying the set of business objects that would best model the deal nominations area. Around twenty candidate objects were suggested but by the end of the first day this had been whittled down to below ten.
By the second morning the developers were already translating the successful object candidate descriptions into Java, using the Naked Objects framework, drawing icons suggested by the business representatives, and assembling some realistic data for Products, Stores and so forth.
The next four weeks followed an iterative pattern. The whole team met once a week and reviewed the whole object model and the state of the prototype, deciding what the priorities would be for the next iteration. During the week there would be many smaller iterations. A particularly effective way of working was to have an individual business representative sit down with a developer and evolve the prototype in real-time: adding new attributes or associations, new sub-classes, and simple new business methods. For more complex business functionality (especially those that involved searching collections of objects or navigating long chains of command) the developers would work alone, or in pairs.
Throughout this period there was almost constant demand for demonstrations, both from members of the team, and from other parties that had heard about the radical approach of the project and wanted to know more. The project manager took on the role of chief demonstrator, recording and managing a set of demonstration scripts corresponding to specific use-case scenarios. Apart from engaging the team, the demonstrations thus served the important purpose of continuously validating the object model.
Additionally, on various occasions during this exploratory period, the team was asked to identify 'what-if scenarios'. These were not requirements, nor even likely future extensions. They were purely hypothetical scenarios, relating to future changes in the business organization, strategy and relationships, as well as technology-driven scenarios. Although these were not explored in detail, the team was asked to briefly explore what changes that new scenario might require in the model. Ideally, the answer would be that the changes would be limited to just one of the object classes, or perhaps to the creation of a new class that implemented an existing interface so that it could substitute for an existing object in any context.
Key business objects
Shown below are the principal business object classes identified during the exploration of the deal nominations system and crudely implemented in the prototype.
User The user object knows the roles that a user can fulfil, how to communicate with that person, and various HR-related information.
Product There is one instance of product for each product that Safeway stocks (there are more than 40,000). As well as storing supplier data, Product holds one or more images of the product for use in advertising/marketing. The Product object could also know how to interface to the supply chain systems.
Deal A Deal (such as a temporary discount or two-for-the-price-of-one promotion) can be nominated for any product. Deals are initially hypothetical whilst the impact on supply chain and revenues is simulated, after which they may be formally proposed. A Deal knows how to manage its own approval process.
Offering An Offering is typically composed of multiple Deals. As well as knowing how to implement the price changes at the locations it is to be applied to, the Offering should know how to produce the printed promotional 'flyers' that will be distributed to local homes, and the in-store promotional display materials. Offering has various sub-classes. The 'Hero' offering, for example, is typically a collection of heavily-discounted items that would be shown on the front page of a promotional flyer.
Cluster Store locations are managed as regional clusters. Offerings are typically rotated between clusters so as to spread the peak in demand for a particular product.
Location A Location models a particular store or sub-store such as an in-store coffee shop or a petrol filling station. As with Product, Location would know how to interface to other systems that provide location-specific information or functionality.
Supplier Holds supplier details and knows how to communicate with the supplier, and to interface to supplier management systems.
Role. Knows which object classes, and which methods on those objects that someone fulfilling this role can access.
Evaluation - the business perspective
All those involved in or with the exploratory project expressed delight at what had been achieved in the short time. The user representative said that the mock-up had the right 'feel' - meaning that it gave them a great deal of operational flexibility to nominate deals and assemble Offerings in different ways, matching the reality of how they work. All commented positively on the way in which Naked Objects facilitated the dialogue between developers and business representatives. The latter had no difficulty adopting much of the object terminology.
At the end of the exercise the capabilities of the prototype were compared to the prioritized requirements produced by the previous (unsuccessful) attempt - and which had not been consulted this time. All the high priority requirements had already been addressed, and much more besides. In fact, when asked which of the prototype's features they would consider to be the highest priority for implementation if the project were to proceed to Specification and Delivery, the highest priority features had not originally been identified as requirements at all in the first exercise. For example, an Offering object contains a number of Deals - viewed as a collection of icons. During the first couple of weeks, someone had asked whether the generic icon representing a Deal could be replaced with an individual photographic image representing the actual Product to be discounted. This capability was added to the Naked Objects framework with the net result that any Offering could now be viewed as a crude form of the colour flyer that would eventually be printed. The marketing people reported that this early visualization was very helpful in evaluating the attractiveness of the offering as a whole.
Evaluation - the IT perspective
Developers reported that they found the Naked Objects framework easier to adopt than those they had previously used for developing web applications. Naked Objects allows them to concentrate on the business problem, and on the disciplines of good programming, rather than simply on how to use the technology.
Prior to an introduction to Naked Objects in 2001, the newly promoted Java Services Manager was "having difficulty justifying a migration to Java from CICS/Cobol", to himself, his peers and the IT executive. He could foresee Safeway repeating CICS/Cobol with a "nicer front end", but with no significant design and cost advantage for future development, maintainability and support. Naked Objects has changed that perspective.
The Deal Nominations system is now awaiting a decision to proceed; but there seems no question that when it does proceed, the Naked Objects approach is the best way to implement it.
The second project
Meanwhile, another group at Safeway had seen the Deal Nominations prototype and thought that the approach could help them with another difficult business problem. Naked Objects was initially seen as a way to facilitate the modelling of requirements rather than as the eventual architecture for the system. As the exploration progressed, however, it became clear that the users liked the concept very much. IT management also recognized that this system made an ideal candidate for a full-blown trial of the Naked Objects framework: the system offered high business value but had a small user base.
At that time, the Naked Objects framework lacked the enterprise services needed to implement real systems. However, Safeway made available its best Java developer to explore possibilities. It soon became clear that the object/relational mapping required between Naked Objects and Safeway's existing mainframe databases could be achieved using Enterprise Java Beans (EJB) and XML. The result was the creation of the EJB Object Store.
The Exploration phase took four weeks. After a further three weeks of Specification, the Delivery phase commenced. Only the object definitions were carried forward. All the Java code needed for the release was now re-written from scratch, adopting a more rigorous approach to testing. The first release was ready for user testing after 90 days, which is remarkable given that this included developer training, Christmas breaks, and delays caused by changes and teething problems with the framework and the middleware. Initial performance was poor. However, this was because the EJB server was operating on a separate machine to the database. When the former was ported over to the mainframe, the whole system ran as fast as "anything we are used to on the mainframe running under CICS". Safeway has subsequently incorporated the testing features of Naked Objects and is assisting with development of new features for the framework.
Copyright (c) 2002 nakedobjects.org You may print this document for your own personal use, or you may copy it in electronic form for access within your organisation, provided this notice is preserved.