[
Lists Home |
Date Index |
Thread Index
]
> From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]
<snip/>
> There's a common fallacy that equates advocacy, strong opinions, and
> partisanship with bias. They're not at all the same thing. I don't
> know Sessions personally, and I often disagree with him vehemently,
> but I see little evidence that he is biased in a way that would
> indicate a hidden agenda. As far as I know Sessions is not paid by
> Microsoft, and has no vested interest in seeing that Microsoft
> technologies beat their competitors. He has the views he does and
> expresses the positions he does because he believes them.
Fair enough. However, I will note that I did not explicitly accuse Roger
Sessions of having a "hidden agenda", and I referred to ObjectWatch as being
an "unequivocal partisan", not of having a hidden agenda. In hindsight,
though, my use of the term "hidden agenda" in the next paragraph was an
unfortunate choice of words. I had no intent to demean or insult Roger
Sessions. I don't think it is a terrible thing, though, to say that he is
biased. I think that's clear from the things he has written in the past.
However, the term "bias" does have negative connotations, so perhaps I
should not have used that term.
From dictionary.com, there are a number of definitions of "bias". Here are
two of them:
A leaning of the mind; propensity or prepossession toward an object
or view, not leaving the mind indifferent; bent; inclination.
To incline to one side; to give a particular direction to; to
influence; to prejudice; to prepossess.
These definitions clearly apply to Roger Sessions, and this is what I had in
mind. But there are some more negative sounding definitions, as well, so
perhaps I should have stuck with the term "partisanship".
I would add that almost every article or publicly expressed viewpoint on
J2EE vs. .NET I've seen also expresses considerable "partisanship". More
importantly, those who seek an enterprise architecture have already started
off on the wrong foot if they start off asking whether they should be using
J2EE or .NET. And focusing on a technical solution to bridge the two is also
not getting you any closer to having a meaningful enterprise architecture.
The VITAL model I mentioned in my first post viewed enterprise architecture
as having 4 layers: business architecture, information architecture,
technical architecture, and systems architecture. The first is all about
people and processes. It has nothing to do with technology. The information
architecture is about the concepts relevant to the business domain, and
modeling them in a rigorous fashion. It is still not about technology. The
technical architecture can best be thought of as a sort of design patterns
for the enterprise. It doesn't tell you what technology to use; it tells you
what criteria to use in evaluating technology and making design decisions
about systems with regard to what happens at the boundaries. The systems
architecture uses the principles of the technical architecture to define
core technologies and tools to be used within the organization.
There are other models, but any sound enterprise architecture will address
these same areas. VITAL focused its detail on a generalized enterprise
technical architecture. The Zachman Framework defines a framework for
creating the appropriate layers in an enterprise. It is a framework for
defining enterprise architectures, not an enterprise architecture in itself.
The ObjectWatch seminar is about systems architecture, though it claims
otherwise. Before an organization asks whether they should be using J2EE or
.NET, they should be asking what problem they are trying to solve and what
do they expect a systems architecture to do for them. If they start by
asking the right questions, they may find they don't particularly need
either, right now.
Finally, since there has been so much REST debate, I'll toss that in here.
REST is a technical architecture for internet-scale systems. OO shines
within the boundaries of a single system. It stumbles as it tries to scale
across the enterprise. It falls flat on its face when it tries to scale
across the internet. Neither J2EE nor .NET solve the problems that REST
solves, but either one can be a great complement to REST. Those who failed
with OO in the past failed to ground their approach in a sound architectural
perspective. And there will be many failures with web services for the very
same reason. It's not all about the technology.
|
