For years, I’ve been telling IT folks how to shorten the duration of their projects: Make the upfront investment in getting the architecture right. Evidently, this idea hasn’t sunk in. I continue to hear complaints from the business side about IT project’s long duration, only to find that there is no architecture step in the IT project plan. I don’t understand it – it’s like leaving money on the table.
Rework causes the delays – not getting it right the first time. Without an effective investment in architecture, rework in large projects that span multiple systems approaches 100%. That means for every hour spent doing something, another hour is spent fixing it.
Investing in architecture significantly reduces the volume of rework. What the architects do (or should do) is examine the end-to-end business processes and the end-to-end systems dialog that supports them. From that perspective, they determine the changes required of both the business processes and systems to achieve the project goals. The alternative – the one leading to 100% rework – is to let the groups responsible for the individual systems figure it out. This turns out not to be particularly efficient.
These findings, shown in the graph above, are taken from 160 real projects, as reported by Barry Boehm in his article, “Making a Difference in the Software Century.”[1] They show how investments in architecture correlate with the amount of rework that occurs in the project, measured in terms of the project delay. Adding 35% to the project duration for architecture reduces rework to less than 15%. The overall project delay is cut in half, yielding a net 25% reduction in project duration.
This result is not magic – it’s common sense. In examining the end-to-end business process dialog and the end-to-end systems dialog that supports it, the architects are creating a paper model of the proposed changes that will achieve the desired business results. They then evaluate the proposed design, finding and fixing mistakes while the design is still just a schematic on paper and still easy to fix. Their focus is on the big picture – the pattern of interactions between systems and between people and systems. Mistakes here are expensive to fix later in the project, but inexpensive to fix upfront.
Of course, to pull this off, the architects need to be active participants – or to be exact, leaders – in the project. For an in-depth discussion on architecting solutions in this manner, see Implementing SOA: Total Architecture In Practice.[1] For a discussion of the organizational and management issues surrounding these architecture efforts, see Succeeding With SOA: Realizing Business Value Through Total Architecture.[2]
[1] Barry Boehm, “Making a Difference in the Software Century,” Computer, IEEE, March 2008, pp. 32-38.
[2] Paul C. Brown, Implementing SOA: Total Architecture in Practice, Addison-Wesley (2008)
[3] Paul C. Brown, Succeeding with SOA: Realizing Business Value through Total Architecture, Addison-Wesley (2007)
