The Fat Controller

In the wonderful "Railway Series" of children's books by the Rev. W.V. Awdry there is an officious character named "The Fat Controller". He is in charge of the railway and is often involved in activities that perhaps would have been better delegated. So, moving on many years and I have embraced the MVC architectural pattern (from my early Smalltalk times) and am actively involved in building a web application that uses Rails.

My own history is that I tend to work outwards from the model - after all the domain is where the interesting rules are enforced, and I can figure out how to implement those without stretching my lousy artistic design sense. After all who needs more than a command line to test a domain model?

Taking this inside out approach certainly isn't typical in many of the Rails books that I have been reading of late. I see crazy statements from "experts" like "the only things that are models are wrappers for ActiveRecords" If it doesn't inherit from ActiveRecord it should not be in the Models directory. So where do these soi-disant experts recommend putting such logic? Ahhh, in the Controller of course. How they reconcile that with DRY (Don't Repeat Yourself) principles defeats me. Oh, and what if we want several different ways of receiving and managing the same data (maybe a b2b feed, an email message, a web form, a tweet, a txt message, an iphone app...), where should that logic reside.

The cognoscenti imply that there should be a single controller for this, so we now have a soup of concerns not a separation of concerns. Putting all the above into a single controller results in creating a Fat Controller of whom the Rev. W.V. Awdry would be proud.

Just say no to fat controllers

Controllers don't have to be activated by views.
Models don't just wrap active records
We don't want fat controllers gumming up the works with their officiousness.

Sir Topham Hatt, please don't teach my controllers to become overweight!

Hijacking of Architecture

In the beginning there was Zachman, three columns and the "Framework for Information Systems Architecture." This was originally published in 1987 in an IBM Systems Review, I believe.

There was much wailing and gnashing of teeth as it was realized that the three columns weren't enough. It needed to embody the 6 questions, "Who, What, Where, When, Why, How" at the 6 levels, so we have a 36 cell matrix. This matrix described what the "Information Systems Architecture" was all about - but didn't offer any prescriptions. How do you create a Business Logical "What?" (data) model? And how is that different from an Application Logical "What" (data) model? And while you are about it, how do you get traceability from one to the other?

Meanwhile the technologists got hold of the word architecture and immediately subverted it into the technology layers - essentially taking on the dimensions of design. So we have architects instead of designers, so those of us at the overall business and IT dimensions were left without a word to categorize ourselves. Job titles such as Java Architect start to cop up - and we immediately get pollution of the name space - or if you prefer overloading of the architect term. So when I would rock up and say to the business, "I am an architect and I am here to help you", I would get about the same reception as someone from the IRS - not very popular. The sorts of things I would hear are, "We aren't ready for programming yet." or "Has osmeone designed how this system is going to be put together?". In other words architecture became tactical, project based and confined to the technology realms.

So we look to other terms/phrases and 2 jump out. One is "City Planning" and the other is "Enterprise Architecture". Well it is hard to sell city planning to a company that makes shoes - not the sexiest term there is. And Enterprise Architecture? Well, that's another term that has been taken over by IT. Even frameworks like TOGAF (The Open Group Architecture Framework) have been more heavily focussed on the technology realm - but that does appear to be changing with version 9 (released Feb, 2009).

Enterprise Architecture Forums on Linkedin and Google seem also to be focussed on keeping track of physical artifacts and dealing (again) with the technology realm.

So it appears to me that the arcchitects are out of luck again. The technologists have coopted architecture at all levels.

So we perhaps should not be using the term architecture at all when trying to have sensible dialog with our business colleagues. We have done such a good job (as an industry) of confusing the term that it is time for a new one. No sooner have we coined it than it will become another victim of grandiloquence. Maybe we should use a term universally despised by the technology community (Analyst anyone?) because then it won't be coopted.

My friend Nigel Green talks about some of these issues in his blog http://bit.ly/1xrMTL. What those of us who straddle the Business/IT divide have to do is facilitate the communication across that divide. Using the language of business - using a framework like VPEC-T