Summary
After reading many texts, both in print and online and many discussions on the Internet a realisation slowly crept over me
Advertisement
I remember once my teacher said in one of my CS lessons -"if people built houses like some people built computer programs, we'd all be sleeping under the stars"
But getting back to things proper.....
That realisation was that most of the time, a lot of people talk about things in terms of this theoretical architecture, but they apply (and intend you to apply) them to the real world as they are.
One presentation server, one application server, one database server....(and one server to rule them all! No just kidding!)
But it's this constantly projected idea that really annoys me - that one conceptual tier should equal one physical tier. Where does this come from? Well, apart from Dan's discussion on TheServerSide, about the nature of distribution and the lack of understanding of that nature, my frustration at this, lies in the fact that (Note: I don't work for a large multi-national company) we have a number of databases as well as a CICS Mainframe. So we don't have one data store. More importantly we have very little data in one system that is replicated from the same 'viewpoint' as in another system, if the data is replicated at all between systems.
We have a number of programming environments running on many systems, so we don't have one all powerful application server, and we also don't have just one single way of presenting data and getting user input (as a matter of scope this ranges from CICS 3270 screens to Client-Server DB apps, from Microsoft Office to JSP's)
So my issue is that I realised a long time ago that the Theoretical Architecture was just that, and when I go from one system to another tier I have to think a whole lot more than in the GTA - I might not just be going from app-server to database, I might also be going all the way to the mainframe, to a database, to another application server and service, and on it goes.
And to go back to my point at the beginning about my teacher - one of the things he taught me about computers in my very first lesson - "Computers consist of input,output and process - that's it" and when you apply it to the GTA, "Any tier can present, process and persist". That's why I like Service Oriented Architectures - "this is my service it does X, and when you tell it to do X with this data, it does something and gives you this back". Simple.
Many of you may think I'm talking stupid - 'conceptual architecture equivalent to phycical architecture'. But how many texts actually make this rather sweeping assumption? Well, let's think about this example - in all the books you may have read and all the articles you have seen - Should I change a stored procedure that returns HTML straight out to a client, and when run process and formats data from the database?
Some of you will say yes - MVC. But some of you may say no - for reasons of performance or similar.
Already you have a choice, and this is only a simple example. Let's make the example a little more complex - what happens if for some data matching a certain condition, you also add in some data from a mainframe, and for some data matching another condition you update a workflow system or automatically create documentation?
Special cases are what create real systems. Without special cases everything would be handled by a single generic function.
The people who refer to what you call GTA have no way of knowing your specific details so all they can discuss is the theoretical. Most often they want to discuss that particular theoretical concept because they care about it (open source developers) or are getting paid for it (commercial developers) so of course they focus on that, especially given that they cannot know your particulars. Your particulars are your requirements that cause you to implement your systems the way that you choose to do so.
The other problem with textbook examples discussing real world situations would be that it would require consent from whomever owned the real world system in question, something that most authors don't generally spend doing and which most companies probably would not allow. ("You want to make my inventory control system a textbook example? What? And let my competitors know how I do this?")
Simply put, I am not sure I see your point unless it's simply a revelation to you that these discussions occur in the abstract rather than the concrete.
> Special cases are what create real systems. Without > special cases everything would be handled by a single > generic function. > This is absolutely, and undeniably, correct - however I seem to find that many authors concentrate solely on the GTA, without even a passing consideration for the special cases, because it applies to the broadest audience
> Simply put, I am not sure I see your point unless it's > simply a revelation to you that these discussions occur in > the abstract rather than the concrete.
My point is in the observation that many people talk about these abstract things as though they were concrete because all the scenarios and examples point to such a thing, and for some people, if I can't get my solution to fit this view, then I must be doing something wrong.
As a case in point, I remember once talking to someone, a project manager (from another company, I might add) who, when I said we were having to do distributed transactions between databases and a mainframe, asked me, quite seriously "Why don't you just migrate all the data and function from the mainframe to the database?" - it didn't matter that the design for such a migration would be herculean in proportions, (nevermind development and testing , and the costs for it all) - what mattered to him was that the end result matched this utopian idea of one database. Even after telling him the drawbacks of even attempting such a thing, he still remained to be convinced.
My issue is that the GTA is, in many texts, the only architecture considered, so many people naturally believe, because of a lack of information to the contrary, that it is the only solution.
Knowing that there are special cases, and understanding them is the difference between being a programmer and being a developer/architect.
I understand the fact that people discuss the theoretical, because of a lack of hands-on understanding of your problem, the issue comes when this generic architecture takes on this whole other meaning of 'ideally this is what you should strive to make your architecture look like'
And you mention "competitive advantage" - in many ways the antithesis of "sharing knowledge"
Well actually that GTA is probably what you should make your architecture look like in the best of all possible worlds. Unfortunately very few of us live in that best of all possible worlds, at least in regards to the work we do. :)
I agree about people mistaking the GTA for the be-all and end-all. I consult and give advice about where and how to proceed and my clients appreciate that because I also always point out costs and that they don't have to get all the way over there to have a useful system. But when they choose to not go all the way I also remind them of whatever choices they've cut themselves off from without much more additional work later.
That approach seems to work well as it lets the idealism of the academic ivory tower be tempered by the cold waters of reality and it does appear to make my clients think twice about whether they want to stop halfway on some solution or really carry it through to its logical conclusion.
Much of what you mention though is simply someone without sufficient grounding in the field trying to make a decision that they probably are not qualified to make. The most significant thing for me in 24 years in this business has not been technical material or learning new technology. No, it's been learning how to communicate with non-computer people about making decisions related to building and maintaining their computer systems.
The > most significant thing for me in 24 years in this business > has not been technical material or learning new > technology. No, it's been learning how to communicate with > non-computer people about making decisions related to > building and maintaining their computer systems.
I agree communicating with non-technical people in terms that you both agree has to be a key goal in any system, because generally it is the non-techies that are acting as Project sponsors, and they really need to know about the pros and cons.
You also mention that many of my gripes relate to people with insufficient grounding in our industry, but I would further that by saying, it specifically relates to people who not only have insufficient grounding, but they don't see that you can't make the majority of problems fit to a given solution - "Square peg, round hole? Well let's shave some bits off this peg....and there you go....sorted!"
They seem to have this notion that because some person said 'this', then it's right and there's nothing you can do about.
As the old adage about Perl goes - There's more than one way to do it.
And if a person can't communicate the costs and the benefits of a particular way of doing things, then, yes, then that person probably isn't qualified to make a decision on architecture.
I'm not entirely sure I understand the main point largely, I think, because I didn't think most people actually did mix up the physical and the conceptual views of architecture like that. I don't think I do it, anyway, and I'm pretty sure many others don't or I would have gotten into very confusing discussions with them at times, given our different viewpoints.
What I really want to say is about the example (either the simple or the more complex one). You talk about "stored procedure". Does this imply a single unit of code, as in a function or such? If so, then it's pretty easy to analyze the requirements as stated and immediately say that a single procedure is not appropriate. There would be too much coupling, too little cohesion.
I find most architectural questions can be resolved much more simply by just looking at coupling and cohesion. In the first example, you've got the following involved already: HTML, the processing, some other kind of formatting, access to a database and, at least implicitly, an interface with the client (by returning the results). Way too much for one procedure! Okay for a one-off tiny thing, perhaps, but if that's all we're talking then the word "architecture" need hardly enter the discussion.
> I'm not entirely sure I understand the main point largely, > I think, because I didn't think most people actually did > mix up the physical and the conceptual views of > architecture like that.
My issue mainly lies around the fact that people are sometimes willing to 'massage' a problem into a solution that they understand - look at the billions wasted on badly architected systems ( I won't get into the why's and wherefores) - thus my point regarding the project manager in my main post. Because many people use the three-tier architecture as a basis for discussion, and quite rightly so, some people think that that is either
a) The best thing to do (in all situations) b) The right thing to do (in all situations) c) The only thing to do (in all situations)
And some people are unwilling to look beyond this.
> What I really want to say is about the example (either the > simple or the more complex one). You talk about "stored > procedure". Does this imply a single unit of code, as in > a function or such? If so, then it's pretty easy to > analyze the requirements as stated and immediately say > that a single procedure is not appropriate. There > would be too much coupling, too little cohesion.
The wording of the example was perhaps a little too involved with details, but to paraphrase it more generically - there is one piece of processing that does multiple things within this unit that can be said to be within the domain of different tiers.
> Okay for a one-off tiny thing, perhaps, but if that's all > we're talking then the word "architecture" need hardly > enter the discussion.
But unfortunately this does happen - you have everything in one unit, just as much as you have systems that have been forced into using one database, one appserver (clustering counts as one appserver, because all processing is replicated locally across all machines), etc. Even Fowler ascribes to this philosophy - keep it all local (one appserver), O/R mapping patterns that tend to run only against one database. Also look at Oracle's PL/SQL Pages.
Must rememeber not to write weblogs at half-eleven at night! ;)
Previous Topic
