The architecture and building construction analogy is useful at an IT architecture level.  At an implementation level it is may be more questionable. However, consider an house architect and foreman working hand in hand; the construction crews are scheduled iteratively in a sense if you consider  framing, wiring, plumbing, dry-walling,  finish carpentry, tiling, painting, etc. all as different development requirements that build on prior results. In the end successful IT projects still need good architecture whether they work with Agile or waterfall implementation methodologies.  The alternative is that requirements are gathered without guidance, from whomever the development team wants to talk to (maybe multiple times on each dev cycle) and the result may be a directionless mashup of 100 or 10,000 conflicting requirements with no real end point ever recognized, least of all met.

When introducing architecture to development teams who fear they may be overly constrained I sometimes relate a story from a summer job in construction in high school.  I was working on high end house construction with a local crew and we arrived at a new site ready to begin.  The very experienced foreman surveyed the site and examined the plans from the architect and made a call to the owner.  He explained that if we built the house as designed any significant rainfall would flow into the garage and flood the basement.  We ended up building the house flipped on the site, holding the plans upside down to figure out what went where.  Some mistakes were made as a result, but waiting on a new architecture iteration would have been more costly than fixing those mistakes as we went...  We couldn't have built the house without the plans, but practical implementation was not pre-ordained by those plans.

A lot of what is being discussed in this thread, is in my experience, preventable with good IT architecture.  The analogy to construction holds at three levels: city planning, neighborhood plans, and individual buildings. The business equivalent being enterprise architecture, systems architecture and application architecture. Real enterprise architecture is rare in my experience but the best way to tackle disparate organizations with conflicting goals. At the Enterprise level I prefer the Zachman Framework: fill out who, what, when, where, why and how at the business goals, conceptual and logical design levels and you know you have plans for all aspects of the all the systems, people, geographic areas, etc. Drill down into physical design and implementation plans as needed. Doing that _is_ costly and time consuming.  Not doing it is what leads to the problems discussed in this thread.  If you know what you are doing you can skip filling in the entire grid, but that should be a decision that has buy-in from all the parties involved.  Note that at this level Enterprise architecture is more than just IT, it looks at what people are involved in all parts of  the business, in what geographic areas, when they need to be involved etc. and lays out the products they should deliver and the rational for doing so.  IT may not even be involved in some cases (but those are not the projects that interest me!)

There are also Agile equivalents for Enterprise architectures. In particular, I like the "Scaled Agile Framework", which uses things like Scrum and Kanban type push / pull methodologies at the architecture level and details how to couple them to the implementation process in a traceable and iterative fashion.  I'm not yet sure it works when you are trying to couple things like Amazon like planning horizons (5 to 10 years) to next weeks dev push, but I am starting to examine how to bridge that gap...

Peter Hunsberger

On Mon, Dec 2, 2013 at 9:52 AM, Michael Sokolov <msokolov@s...> wrote:

On 12/02/2013 10:24 AM, Thomas Passin wrote:

On 12/2/2013 2:09 AM, Stephen Cameron wrote:

I think you are getting to the heart of it, but the analogy I like is
making a movie, the final result is very open-ended and coordinating the
activity of getting a result very complex, also, whether the end result
is a success is very much dependant on intimate knowledge of the humans
who will view (use) the outcome.

I think that a better analogy is a large construction project like an office building or a large bridge.  They often run over budget and schedule, and often develop unforeseen problems.  Some of them are almost exactly like previous ones, and some have many new elements. During construction, unexpected problems arise, and once completed, usage patterns may turn out to be quite different from those anticipated.  Many of the implementation details are routine and implemented by tradesmen who don't know much about the overall architecture.

I've operated with that idea for many years, but I'm coming to believe it's actively destructive because it leads to pure waterfall thinking: design, architect, engineer, build.  Where is there a place for an iterative design, build, test cycle in building construction?

-Mike

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l....org
subscribe: xml-dev-subscribe@l....org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php