On Thu, Jan 6, 2011 at 15:14, Cat Okita <[email protected]> wrote: > I'm going to get up on my soapbox for a bit here. > > Design Patterns are a fine idea, but you MUST have underlying domain > knowledge that allows you to intelligently consider the application of > any pattern to your problem domain. > > IMNSHO, what distinguishes a senior system administrator (and for that > matter, a senior in pretty much any profession) is the ability to take > and apply their domain knowledge to particular problems, and come up with > good-to-excellent solutions. > > Blindly presuming that filling in ticky-box-A, ticky-box-B and ticky-box-Q > will get you what you want is ... disingenuous, at best, and the idea that > you can "just plug something in, and it'll solve all of our problems" has > been at the root of an astounding number of project failures. > > Cargo Cult computing is creating a problem, not a solution.
I agree that a central requirement for a pattern is that it must not be domain specific. But I still think there are some aspects of system administration that _can_ be readily codified into appropriate patterns. But when I discuss implementing a pattern in a system, I am not thinking of a system configuration "Mad Lib" sort of phrase template that just get's filled in and _voilà_! It magically turns into a flawless system. What I envision is perhaps a checklist, but a minimal checklist of considerations and requirements in order to design and deploy a particular service with a particular desired behavior. I.e., if you want to deploy service, $S, with specific desired behavior, $B, then _at a minimum_ you must have components that provide $X, $Y and $Z functions related to each other through specific patterns of communication. ...and the reason you must have coverage of those essential functions, based on combined system administration experience from throughout the industry, is to avoid these common design faults: $Q, $R and $S, respectively. This doesn't mean that _all_ design faults are then impossible. It just means that implementation guided by the pattern avoids the specified faults that are commonly encountered. It doesn't mean that the faults can't be avoided in other ways. There's a pattern for acquiring groceries. It starts with browsing the product selection, which could be browsing through store aisles, or browsing a web page. The groceries to purchase must be collected. The cost must be calculated. Payment must be processed. (Even if you are counting out cash money into the clerks hand, the payment is still being "processed".) The groceries then are transported to the home via motorized land vehicle. Let's look at the last bit. Does it have to be a motorized land vehicle? Let's rule out air, sea or waterway, unless you happen to live so deep in the back country that even sunlight has to be piped in. (If you do, then you do not have a common task with common problems that occur when trying to solve that tasks, so there are no patterns that are applicable.) Could you walk or use a bicycle? Certainly you can, but then you will encounter a common problem of limited payload capacity. Could you construct a conveyor between the store and your home? Certainly you can, but then you will encounter the problem of increased maintenance cost and effort. Can the store deliver the groceries to your home, for you? Certainly they can, but the motorized land vehicle component of the pattern is still part of the design, whether you "implemented" that part, or not. Still think you want to use a bicycle, anyway? That's perfectly fine. But now you make that choice knowing that you have to solve the limited payload capacity in your implementation. As quoted from a Christopher Alexander in the GoF book, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice." Perhaps system monitoring services are a bad example to start out with, but I still believe that after 40+ years, there are problems, solutions and patterns for those solutions within our profession which are sufficiently understood such that the core characteristics and organization of the best solution(s) can be collected and codified into a common body of knowledge. Yes, I referred to "design patterns". But I believe "design patterns" are just one type of expression of "best practices". It's likely that a common body of knowledge would include may other expressions of best practices, as well. _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
