OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] RE: A Two Day Workshop for Software Architects

[ Lists Home | Date Index | Thread Index ]

All too true although I am not a big fan of enterprise 
process reengineering because, (old quote here), one 
can't re-engineer what one hasn't engineered.  Many 
of the fiefdoms really are structured around the 
human equations of who slept with whose spouse, 
who went to school where, and so forth.  I've seen 
massssssive waste because a good idea didn't come 
from the "right kind of person" and the longer 
I've done this, the more I am convinced that is 
why DARPA does what it does the way it does it. 

Goals?  Whose goals?  Is she dysfunctional or is 
she just surviving?  Should I write software guaranteed 
to make her obsolete?  Should I write software 
that exposes the overhead or the incompetence? 
What if the incompetence comes from the very 
top or the person signing my check?

Quick Test:  how many of you out there have 
software departments that document relational 
schemas in WinHelp derived by RoboHelp from 
Word files?  How many of you use a program 
to extract it from the code and output a 
hypertext? How many of you use entity-relationship 
diagrams or demand them?  Do you actually use them 
or are they a contract-item?  If so, does the guy
who contracts for them use them or did he get 
his instructions from a book on the subject?

Building human goals into the software, sure seems 
like a hideous idea.  Then it becomes your neck 
or their neck and all the niceties can go poof. We'd 
like to think we are courageous, but courage is 
what one does in the face of fear and fear is 
the mindkiller, as Herbert wrote.  Could you have 
stood up to the CEO of Enron and said, "it's wrong, 
Boss, and I won't go along"?

"The gift lovingly given" is "made in due time 
in due place to a meet (worthy) recipient". That 
is the middle ground between objectivism and 
vedanta:  the worth of the receiver in the judgement 
of the giver.  Whose goals?  Mine.  They must be 
mine or else I have no moral compass, no means 
to judge.  And if they are mine, then so is 
the reward and so is the fault.  Nothing else works.

But corporations don't work like that.
That is why notifications go to roles, not names, 
policy is centrally defined and locally 
administered, and so on.  But corporate goals are  
just as conflict ridden and that is why 
industry-wide common vocabularies are hard 
to produce, may be why Web Services are based on APIs, and 
are why orchestrated processes shouldn't go below or 
even sometimes to an id'd desktop (hierarchical 
decision making).  Sometimes we go to these 
meetings with a Bible; sometimes with a sword. 
Sometimes both.  Pathological but real.

No REST for the wicked, either.

len the barbarellian

-----Original Message-----
From: Michael Brennan [mailto:Michael_Brennan@Allegis.com]

> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]


> Ummm.... "a series of self contained, mutually suspicious, 
> marginally cooperating" customers is a perfect 
> description of the enterprises some of us build 
> software for.  In my case, cops and lawyers, the first 
> of whom work in fortresses and the second of whom 
> live in them. :-)

Yeah, it is a good description. But then, many of the enterprises some of us
build software for are dysfunctional. I don't think imitating that
dysfunctionality in the techniques for modeling the enterprise provides a
rich enough framework for *successful* efforts at enterprise-wide
integration. But to be sure, many of the techniques that do point to the
right way don't offer enough real-world advice for addressing the political
and cultural challenges that can kill a project. The enterprise architect
needs to be both a politician and an engineer.

Of course, I may be coming at this from a different angle from you. The
domain of my experience is that of corporate IT, not governmental agencies
(though I did work for a pharmaceutical company, at one point, that needed
to contend with regulatory agencies such as the FDA).

This ObjectWatch seminar seems to offer an approach that views the diversity
within the enterprise as a sort of warlordism, rather than as a federation.
In practice, that is often the case. But more enlightened and mature
enterprise learn to act more as a federation. I would think a sound
enterprise architecture would want to base its lessons upon best practices.
Indeed, a sound enterprise architecture can provide a basis for business
process reengineering, not simply building systems, by putting light on
those aspects of the enterprise that are misaligned with its goals.

In one slide, there is a picture of what it terms "the traditional view of
the enterprise". What it presents is a three-tier *system* architecture, not
an *enterprise* architecture. It then offers a view of systems as autonomous
islands that interact with each other -- with no overarching holistic view
of the enterprise to provide context for these islands. So it *still* is not
presenting an enterprise architecture. 

> I just thought the idea was hilarious.  Maybe not....
> Where is your SES neighbor bunkering down this week?

Yeah, it is hilarious. But I couldn't resist the opportunity to use it as a
segue for pointing people to some resources I've found very useful in the
past in understanding *real* enterprise architecture. It still seems that
few people really understand this stuff, and there is a lot of snake oil out
there that can mislead people.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS