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. href="http://www.thetibcoblog.com/wp-content/uploads/2012/04/Paul-Brown_Rework-04.13.12.png"> class="alignright wp-image-3056" title="Paul Brown_Rework

04.13.12"

src="http://www.thetibcoblog.com/wp-content/uploads/2012/04/Paul-Brown_Rework-04.13.12-300x235.png"

alt="" width="300" height="235" />

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 href="http://www.informit.com/store/product.aspx?isbn=0321504720">Implementing

SOA: Total Architecture In Practice. title=""

href="http://www.thetibcoblog.com#_ftn1">[1] For a

discussion of the organizational and management issues

surrounding these architecture efforts, see href="http://www.informit.com/store/product.aspx?isbn=0321508912">Succeeding

With SOA: Realizing Business Value Through Total

Architecture.

href="http://www.thetibcoblog.com#_ftn2">[2]

No related

posts.