Cart
[Home] [By Thread] [By Date] [Recent Entries]
> From: Elliotte Rusty Harold [mailto:elharo@m...] <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.
|
