Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@A...] > From: Bullard, Claude L (Len) [mailto:clbullar@i...] <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.
|
