Hi Peter, you are lucky 100th posting on this thread.

However what you say is ringing alarm bells for me.

To me using the word 'architecture' is misleading, Frank Lloyd-Wright is one architect that famously never consulted with his clients, he just gave them a design and asked for payment, as a result many of his houses are actually bad to live-in, though visually charming (to me).

In my view, the only 'architecture' in software is the structure that you build into your software, either in terms of your classes using object-oriented programming, the modules in procedural, or the entities of your data-model.

Your building reorientation analogy misses the main issue, namely was the house, once built, fit for purpose? Did the change in orientation destroy its carefully calculated heat-balance, such that it dropped out of rating 5? Could people find the front door? Was the sewage system always getting blocked as there was not enough fall on the pipe from house to street? Yes, a show-stopper issue was solved, but what were the long-term consequences?

Aren't enterprise architects actually business analysts doing systems-analysis? In the context of an 'Enterprise' they can design processes that aid in maximising profits or other measureable goals. But this to me is a separate specialisation, actually one where a different use of the word 'model' applies than to that in software, its something that is used to test the *likely* impact of changing something in the real system, kind of like economic modelling and forecasting.

My thinking is that the process of creating software that extends the capabilities of humans and organisations must be primarily concerned with the link between humans and computing devices, such as: is what people think is happening actually happening,  is the information obtained in a human-device iteraction reliable, as a new user how do i learn about software efficiently (hopefully by interation with the system itself rather than having to read manuals) etc. I believe that the means to achieve this does involve iteration and refinement with user involvement, and lacking this is a major cause of problems, thinking that a optimal solution can be 'procured' (or imposed). Users 'cope' with this approach nothing more, unless what is procured is so defective that the whole thing comes crashing down (ala ACA).

My fear is that the business analysts want to be software designers (forget the word programmer) as well.

Steve

I don't think we are disagreeing greatly, I am asking for a change of perspective.

On Tue, Dec 3, 2013 at 2:11 PM, Peter Hunsberger <peter.hunsberger@g...> wrote:

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