Accelerating the delivery of new or improved solutions is one of the key sources of IT value and the importance of application development. Methods and techniques for building solutions has also been the subject of intense focus from the original creation of structured methods to current innovations in agile development. While there has been significant advances, there is often a deep thought that limits solution delivery cycle times. That deep thought is:
We build the solution in the same order as the solution works.
If that sounds like common sense, then you share that deep thought.
Building a solution in the same order as the solution works is an outcome of the way business people think, the way we gather requirements, and the programming restrictions of COBOL. Some background:
- The way the solution works is often defined by the steps in a business process required to complete a transaction.
- Business people think about what they do first, then second, then third.
- IT gathers requirements in that way often asking about what has to happen and in what order that make up our requirements. Finally,
- Early programming languages like COBOL required you to build step one before you could build step two or three.
While technologists will argue that none of these things are required or absolute — they do represent common practice across IT organizations.
The way we build the solution refers to the way we break down the project scope, assign resources and schedule those resources. The way the solution operates is often the default approach for making these decisions. We breakdown a solution along the tasks users have to perform, ala set-up, authorization, etc. We assign and schedule resources according to that sequence. You can see that if you look at a project GANT chart.
Building the solution in the order it operates reflects an approach that makes intuitive sense, but is no longer technically required. Taking a sequential approach organizing build units tries to mitigate a limited analysis and weak design as we allow build teams to figure out the parts we did not get to, or did not have time to get right.
The problem is that matching the build order with the solution’s operational order creates bottlenecks that extend delivery cycle times and can compromise functionality and quality.
Its time to consider building software solutions the way they make Hollywood movies — out of sequence and concurrently.
Movies provide a good example as they ‘work’ sequentially but they are rarely filmed in the sequence they are shown in. You know this by sticking around for the credits and you see things like second unit director, continuity, etc
So how do you build software differently than the way you use it. Simple, you design the build program to support greater concurrent engineering. In the case of software applications, one approach is to look a the solution in terms of decisions and business rules that have to be applied. You can divide development along these lines opening the door for greater concurrency of development. See figure below for an illustrated example.
Concurrent development can also be broken down it terms of ‘events’ provided that the events are not dependent upon one another. In either case creating independent build units opens the door to concurrent scheduling and cycle time reduction.
This approach does require more analysis up front, to identify the independently acting decisions and processes. The time spent there by a small analysis team is readily recouped as larger build teams work faster and with greater efficiency. At the back end of the build process, fortified validation and testing capabilities can deliver additional efficiencies.
CIOs and IT teams face an increasing backlog of projects. Adding a level of concurrent development is one approach for addressing this backlog.