Preface

Emily’s Rebellion presents a new method of removing the complexity from business processes and information systems. The Transaction Pattern applies pattern thinking to designing and specifying transactional processing requirements. The method is especially suitable for digital transformation initiatives.

Our readers are business people, most likely middle managers who have operational responsibilities. We wrote Emily’s Rebellion for these people, often called ‘subject matter experts’, who are required to inhabit the space between the everyday operations of their business and technology ‘improvement’, ‘refresh’, and ‘digital transformation’ projects. Too often, we feel, these spaces seem like a war zone, with the business often ending up with little real business improvement, and ‘transformation’ that exists more in the mind of a leader who wants to be known for keeping up with the latest trends than in reality. IT specialists will also benefit from this book by learning about a method that could improve their ability to work with their business peers and to deliver systems that truly improve the business.

Emily’s Rebellion will show you how to methodically specify business requirements, work tasks, workflow, and data requirements, using the Transaction Pattern as a framework. In this book, we use the persona ‘Emily’ to represent any business person (not a computing specialist) who may find involvement in an IT project to be a miserable experience.

Emily is feeling rebellious. A clever 30-something wanting a change, Emily is dismayed that her boss has given her the ‘challenge’ of being the subject matter expert for a new IT project. Her friends have told her that IT projects always seem to be an exercise in disappointment, frustration, and missed opportunities. Her job is to specify the business requirements for the new system. Emily knows her part of the business well and she can see that there are inefficiencies in the way the team does things now. The system contains dozens of screens used for data-recording, but it is not oriented towards stepping through a transaction from beginning to end. In fact, there is no clear delineation between the different types of transactions that the business deals with.

Emily hasn’t been closely involved with an IT project before. She feels intimidated by the IT guys who demand to know her requirements, and talk of ‘functional specifications’ and ‘user stories’. She doesn’t understand all their jargon about object orientation, unified modeling, data-driven design, etc. She feels inadequate for not understanding what they are talking about and what they expect from her. The business analysts on the project team confuse her even more by showing her their previous work – one person shows her a document that lists requirement after requirement for a hundred pages and more. Other analysts show her their one-sentence constructions they call ‘user stories’ which they say the IT guys could use to develop a system function. Writing a few user stories seems like easy work, but Emily is awestruck by the magic that is promised by this new ‘agile’ approach. Emily can’t understand how the IT analysts and developers could ever hope to develop a coherent system that meets all these individual requirements in a joined-up way. There seems to be an unspoken assumption that a new system supporting a better way of doing business will emerge, as if by magic. After all, an improved business operation – not just a new system – is the point of this investment, isn’t it?

Business operations revolve around transactions, which all follow a similar path. When a customer chooses to use a service that Emily’s business offers, they first submit a request for that service, like a shopping order, or an application for a permit. The business must deal with this request and eventually provide a response back to the customer – the fulfilment of the order, or a decision on granting the permit. Each business exists to process such transactions, no matter what kind of business it is.

Emily begins to think about her business needs using a new structure. It strikes her that most of the transactional processes are quite similar, it is only the content (the data, the workflow, the output) that varies. There are lots of transactions, but one type of transaction goes to one team and another type goes to another team. Data needs to be captured for each transaction but the data for an order, say, is different than the data needed to process a change of address. But every type of transaction has a similar need for data that tracks where the transaction is up to in the business process, who is dealing with it, and so on. Also, the tasks that the staff perform to process a transaction generally include receiving a customer request, validating it, assessing the request, and deciding how to respond, followed by notifying the customer of the response.

Emily thinks that an approach structured around straight-forward patterns like these might simplify how she specifies the business requirements. Looking at each business task in turn, she could focus more on the business workflows, data needs, and business rules, and less on system functionality and screens. She would be able to retain a holistic view of how the business could work more smoothly, processing its transactions like a clock ticking over the minutes from one state to another.

But could the IT team consume her new way of specifying requirements? Would her small rebellion succeed?

We offer this book as one solution to help Emily and her colleagues to achieve better outcomes in their IT projects. Walk with Emily through its pages as she discovers a better path.