[
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]
<snip/>
> 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.
|
