Re: [xml-dev] Re: XML As Fall Guy

From
Thomas Passin <>
To
"" <>
Date
2013-12-05T02:53:29Z
ID
<>
Thread
Re: [xml-dev] Re: XML As Fall Guy
On 12/4/2013 8:44 PM, Stephen Cameron wrote:
> Thanks for this detailed response. Just a few thoughts in reply.
>
> I don't claim any great expertise, this is just something that has
> interested me. I liked the idea of UML as a design/architecture tool,
> but once I started to investigate it I found a completely contrasting
> point of view about its usefulness for such, and one that I have moved
> across to, specifically that 'the code is the design'.
>
> I have no argument on the need for planning to coordinate the activities
> of many people with different expertise in large projects. I do question
> the use of the terms 'Enterprise Architecture'  and 'Software Architect'
> to describe it. I am much more happy with the concepts of a
> 'Business-Analyst' as someone concerned with people and process
> (workflow etc) and 'Software (Systems) Engineer' or 'Information
> Technologist' as someone concerned with managing information and how to
> build IT systems to do it.

No matter how you label the different players or roles,  all of the 
things people talk about, for example in the Zachman Diagram - or any 
other such tool - all of those things actually get done.  If they aren't 
done formally then they are done informally, often in the minds of a few 
people, often not consciously.

Without documentation, on a complex system different people will have 
different ideas about each of these aspects - for example the mission. 
With too much formal documentation, everyone gets completely bogged down 
in the details and the documenting until nothing much gets done.

What's hardly ever documented are hidden motives of the players.  These 
could range from a desire for more profit, to a psychological need to be 
right, to an unwillingness to stand up to those in power, to you name 
it.  I'm sure we can all extend the list.  But they are not documented 
even though they can play a large role in the system development.

That's one of the many problems in large system development.

[As an aside, Stephan, if you really want to get into Zachman diagrams 
and the like, I've spent a lot of time working on reconciling various 
approaches and have distilled them down to a fairly simple model that 
can be recursively applied.  The model is fairly compatible, at least 
deep down, with Zachman and several others.  If you like, contact me off 
line and I'll send it to you with supporting context.]