Key takeaways
|
In the book “Designing the Requirements: Building Applications that the User Wants and Needs”, the author Chris Britton proposes an alternative path that goes from understanding the requirements to deliver spot on solutions.
The strategy described throughout the book is rooted on the fact that, according to Britton, many IT implementations failures are related to requirements identification process. He suggests that these should be the output from a requirements design exercise, not from a requirements gathering exercise. The author details a Context Driven Design approach and a Hierarchy of Designs that will help on consistency and completeness of the delivered solutions.
InfoQ spoke to Chris Britton exploring not only the details of the approach proposed but also on how it fits into the actual fast paced world in which organizations need to embrace change very quickly and efficiently.
InfoQ: From the problem perspective, what made you write this book?
Britton: I thought I had something useful to add to the debate about application design. It was clear that in spite of years of study and experience, many IT application implementation projects were failing and I thought that I knew why. In a nutshell the reason is that the requirements for an IT application should be the output from a design exercise not a requirements gathering exercise. If you simply gather requirements, it is very easy to miss something important or introduce inconsistencies. Many IT professionals will shrug their shoulders and say “well if it is, it’s their look out” to which my first answer is you could at least tell them how to do it properly. But more than that, sometimes the best way to fix an application design or implementation problem is to change how the business will use the application. Thinking of the whole business/IT application as single design problem gives you the framework to handle this kind of feedback. Finally, watch out – the business will hand you the blame for any failure even if you implemented precisely what they asked for.
InfoQ: The book is about design, a broad term. How do you define “Design” in your book?
Britton: In the book, I define design as “A design is a conceptualization of the thing or system you wish to build.” It is a very general definition that covers the design for anything. It covers the cases where the design is an idea in someone’s head, the design is a series of drawing, or indeed the design is a clay model of the proposed finished product.
Obviously the book is about design of IT applications but I have long felt that it is very odd that IT design should be so different from other kinds of design like designing a building. For instance, you would never incrementally design a house; start by designing a wall say, showing it to the customer and asking if that was what they wanted and then, when they were happy with that, showing them another wall and so on. When starting on this journey many years ago, I wanted to know exactly how IT design was different from “normal” design and why. And the first point I noticed was that design of buildings or machines was hierarchical. It’s the hierarchy that gives you traceability – if something is changed or breaks, you go up the hierarchy to understand the ramifications on the rest of the design. Every experienced programmer will tell you that there are occasions when you change something and, totally unexpectedly, another part of the application breaks. This made me think that perhaps there is a hierarchy but somehow we are not seeing it. The solution to this conundrum is discussed further in the answer lies in the hierarchy of design discussed below.
Another question that I gnawed away at was why is IT design not really engineering design and what is engineering design in any case. I came to the conclusion that there are three approaches to design which I called:
- Ad hoc design. There is no formal design – in other words, the design is in your head).
- Planned design. The design is drawn or described.
- Engineered design. The design is analysed for errors. Engineers analyse designs for load, balance, earthquake, whatever, at the design stage before building the thing.
This led me to wonder how we could analyse the design of IT applications. The benefits are obvious – better design, fewer nasty surprises and less rework.
I have talked to engineers and architects about design, and this kind of navel-gazing on the nature of design is foreign to them. Instead, what they do is ingrained in them. Given the many different approaches to design, that clearly is not the case in IT. What I have done in regard to IT application design can be seen as taking several steps back before finding a new way forward.
InfoQ: Regarding Design of Applications, many different approaches may be followed. Can you describe your proposal?
Britton: The first difference between my approach and others is that it starts high up, so to speak, at the business level. IT applications don’t exist in a vacuum; there are there to support the business. The key to my approach is the design of the business processes and services and how they are supported by IT tasks. The reason why this is important is that the business design is top of the hierarchy of designs and without capturing this design you cannot work out the consequences of changes to the design.
The second difference is that even at the top level I describe both the actions (the doing if you will) and the data. In particular I want to understand how the business gathers and uses data. This is a difference verses Use Case which concentrates on the actions.
The third difference is that I want to analyse the designs to eliminate design errors as early as possible. For instance, Because I describe the data as well as the actions in the business design, I can ask the questions – does the data support the process and does the process support the data?
Another big difference is the approach to technical design. You should think about the technical design in terms of frameworks. I think you should build the framework of the application early and test it to destruction early. This is especially important in complex multi-tiered implementations. I have heard of large projects that have almost reached completion only to discover they don’t meet the performance goals. Also other aspects like security and resiliency need to be considered early not bolted on late.
In practice, the actual implementation is more or less like agile development but instead of dealing directly with business management you have the higher level designs and their designers as go between. The higher levels of design don’t usually take long (unless it is stalled because the business has problems reaching agreement.)
InfoQ: At some point you argue that “stating what a business wants is rarely complex”. Can you please explain some of the techniques you use to ease this task?
Britton: Imagine you are a fly on the wall in the CEO’s office overhearing a discussion about a proposed IT application. The objectives of the application will be stated in simple terms like “if we do this, we should reduce costs”, “we want to know more about our customers so we can sell them more services”, or “if we can provide this service online there is a huge opportunity to be first in a new business”. It is the implementation of these desires that are complex, and as noted in the answers to the previous question, the complexity is in the business as well as the IT application. Put another way, the CEO-level requirement is the requirement to the top level of the design hierarchy. You have to ask your stakeholders to find out what is the CEO-level requirement for your project. The difficulty is that if you ask many managers what they want, they will tell you about their preferred solution (at the business level) not the problem and you may have to push them to describe the problem as well as the solution. Knowing the CEO-level requirement is important because when you talk to another manager they are likely to tell you of their preferred solution which may be incompatible with the other manager’s solution. The CEO-level requirement helps you persuade the two managers to agree.
InfoQ: You have an entire chapter on “Hierarchy of Designs”. Can you share your thoughts about this topic?
Britton: The Hierarchy of Designs is how engineers approach design. It’s very difficult to imagine designing an aircraft carrier or a tower block without having the notion of a hierarchy of designs; it is how they handle complexity. In engineering design at every level, the designs can be analysed for errors. Requirements for each design can come from the outside but mainly from the higher level design. For instance, the requirements for the design of a pillar in the context of the design of a bridge is largely defined by the high level design of the bridge. There is feedback, for instance when developing the pillar design, you might find it is too difficult or too expensive because of the geology and you need to go back to the higher level design to put the pillar somewhere else. The notion of a hierarchy of designs is a powerful idea and begs the question – why can’t we apply it to IT application design? Now look at traditional IT application design. It is “flat” – there is no hierarchy, and often some hidden complexity is revealed late and is an awful surprise that throw the project into a spin. I realised that IT application design isn’t flat but that the top part of the hierarchy was missing because it lay in business design not in IT application design. A major problem with IT application design is then persuading business management to engage in a design exercise not a wishful thinking exercise. I recognise this isn’t easy. For the business managers, I am often that annoying person who is always finding problems.
That said, IT application design is different from classic engineering design. Engineers use engineering drawings not only to describe the high level design, but also to describe the component design and the sub-component design. I found that the best way to build an IT design hierarchy was to have distinct layers of design that described the problem in different ways. Thus the high level design – called the Context design – has process and task diagrams while User Interface design has a description of the screens and screen flow. The output from the Database design is a database schema (or similar for non-database persistent data) and the output from the Technical design is working code for the Framework. The Context design is thus transformed into three designs each showing a different aspect of the complete system. One reason why I took a whole chapter to describe hierarchical design was to show that this approach to IT application design could still support traceability and analysis.
InfoQ: What makes you feel that “User Interface can be left until late in the project”?
Britton: I can see that this is a contentious topic and I should make clear that I was talking about the detailed look and feel design (the colour, the size/position of the buttons, etc.) rather than the identification of screens, the data input and output, and the flow between screens. In my ideal world, it would be possible to design what the user interface does without worrying about the layout of the screens, etc., and in one project for a web application that is precisely what we managed to do. The user interface designer took the web page sources and the css file I had created and worked with them without changing the logic of the application. That said, in my latest project ironically, the user interface designer seems incapable of making the split and sees the application entirely in visual terms and keeps on adding new features to the application.
InfoQ: Going forward in the design of an application, can you describe the proposed “The Six-Box Model”?
Britton: The Six-Box model is the hierarchy of designs for IT applications. At the apex of the hierarchy is the Context design for outlining how the application and the business work together. Below it comes Integration design for outlining how this application fits with other applications. The Integration design is a logical – not a technical – description of how applications integrate. The reason for this step is because you may realise what you have designed in the Context design already exists somewhere else and it is better to integrate with what exists rather than redesign from scratch. Naturally when you do so, you may find you have to make compromises and these need to be reflected in the Context design. The next three designs take the Context design and refine it along three dimensions; the User Interface design for describing the information in and out of the system and how the screens hang together, the Database design for persistent data (all persistent data not only data implemented in traditional databases), and the Technical design to describe what technology to use and how to use it. Finally, there is the implementation.
These designs are meant to show how to think about application design. They are not necessarily steps in a project. The User Interface design, Database design and Technical design can be done more or less in parallel, albeit with communication between them. In the hierarchical design model, designing may give rise to feedback changing the higher level design. For instance, you may find during Technical design that the application is too expensive so you loop back to the Context design and do something a bit different.
InfoQ: Providing that the world is moving fast, the requirements are constantly changing, what techniques and approaches do you propose to guarantee accurate designs over time?
Britton: The first point to make is that many changing requirements are actually a consequence of the lack of “designing the requirements”. In other words, they are fixes to flaws in the business design that have been discovered late. Having a fully analysed Context design should make such changes less frequent.
But of course it does not eliminate them. Handling change is much easier when you have traceability from business design to code and from code to business functions. This is discussed more in the topic related to handling change requests.
In theory there is no difference between the process of handling change after a project is finished and handling change while a project is being implemented. In practice of course, you may have lost the expertise about an application and lost – or never had – the Context design to tell you what the application does from a business perspective. You may therefore have to understand one or more existing applications, and building a Context model (like a Context design but for an existing application) is a good way to start.
The point to emphasis is that the techniques for handling change helps prevent unintended consequences.
Another aspect of handling change is the overall application architecture. One of the reasons why Integration design is done so early in the project is so that there is an opportunity to ensure the new application plays a constructive part in the portfolio of applications. For instance, we want to ensure that across the whole portfolio there is no unnecessary duplication of functionality and that there is a strategy to ensure that there is one consistent value of data.
InfoQ: How do you assess impact of change requests?
Britton: An important feature of the Six-Box model is that it helps you assess the impact of change because you have traceability from business task to user screens and to database fields and records. For instance, if you want a new field in a database record for management reporting say, you can quickly figure out which screens need to change in order to input the data and display the data. Knowing the screens makes it possible to identify which business tasks might be affected by the change. If the business task is affected does it have any knock on effects to a business process. You can easily figure out the consequences of the change. Once the design changes have been made, the analysis techniques for each design can help you check that the new designs are consistent and complete. Finally, the scope of the change helps you decide which parts of the application to retest.
InfoQ: What are your thoughts about design quality and approval? You suggest to check for completeness, check for consistency and traceability. Can you share some techniques to implement those?
Britton: Most of the vast literature on quality and approval applies to the implementation of the application and there is little I can add to this knowledgebase except a nod of approval. But the quality of the design is a subject that I think is foreign to most IT application developers. A business process can be analyses to ensure all paths reach an end and don’t loop forever. There may also may have business process integrity constraints. For example, a process that handles online purchasing and delivery has an integrity rule that a customer only pays for goods that are actually delivered in good condition. When you consider breakages, being out of stock and other snafus it is easy to see that this isn’t such an easy constraint to implement. The Context design describes how the business processes and services are implemented by tasks. At the task level you need to ensure all elements of the business processes or services are implemented. Tasks need data – business applications are largely about storing and using data – and thus an important question is – where does the data come from and where is it used? With follow on questions – does the user have the information to input the data and how do we ensure the data is accurate? One good analysis technique is to consider the security questions – who is allowed to see each item of data and what are the consequences of the data falling into the wrong hands? This makes you think about the different sorts of users and what each of them does. From a user perspective there is the question – do they have the information to make the decisions they need to make? There is a great deal of analysis of functional requirements that can be done and I suspect I have not found them all.
InfoQ: You suggest that “With Context Driven Design you are in a better position to understand where you truly are in a project”. Can you explain us why?
Britton: There are two reasons. One is simply that the Context design is checked for consistency and completeness. This means that you are less likely to stumble upon issues that cannot be resolved without substantial rewrites. The other is the approach to technical design. As noted above, I suggest you think about technical design in terms of a framework then build the framework and thrash it to death before you have gone too far with the functional implementation. This approach makes it much less likely that your application will have to be rewritten for performance or resiliency reasons. I find the code for testing the framework can usually evolve into code for testing the application as it emerges.
InfoQ: You end-up the book with a chapter regarding the future of application development. How do see Context Driven Design influencing it?
Britton: I hope that the ideas in Context Driven design become mainstream and I hope design tools are developed to support it. I would like to see businesses publish and share Context designs. That would greatly help businesses starting to develop a new application. At a technical level I think the notion of frameworks can be developed more and development tools built to support it. If the higher levels of designs are captured in a repository it may be possible to analyse the designs automatically – at least in part – and generate tests for the implementation.
InfoQ: From the solution perspective, can you summarize how “Designing the Requirements”, will help people “Building Applications that the user wants and needs”
Britton: In a nutshell, this book is about how to build a more co-operative relationship with the business managers by asking them to engage with the IT application designers in a shared design exercise. This forces people to think deeply about the application before it is implemented leading to better business decisions and a more thoughtful selection of features to implement. The actual implementation phase is also quicker because there is less going back and doing it again.
About the Author
Chris Britton is a long time IT professional. For the last five years he has - rather to his surprise - found himself designing and implementing web applications for business start ups. Prior to that he worked as a consultant mainly in IT architecture and application development. Before that, for many years he worked for Unisys where did a variety of jobs - system software design, architecture consultancy, fixing large, broken databases, program management and even marketing. It was while at Unisys he wrote his first IT book "IT Architecture and Middleware: Strategies for Builiding Large Integrated Systems."