Home > Architecture > Code, data and metadata in the light of Shearing Layers

Code, data and metadata in the light of Shearing Layers

I haven’t written anything on my own in this post. I have just quoted Brian Foote and Joseph Yoder ‘s Big Ball of Mud essay. As someone building and maintaining metadata driven applications / frameworks, this article was a slap in the face for me. A clear reasoning behind metadata.

The notion of SHEARING LAYERS is one of the centerpieces of Brand’s How Buildings Learn [Brand 1994]. Brand, in turn synthesized his ideas from a variety of sources, including British designer Frank Duffy, and ecologist R. V. O’Neill. Brand quotes Duffy as saying: "Our basic argument is that there isn’t any such thing as a building. A building properly conceived is several layers of longevity of built components"…

  1. Site (geographical setting), they say, is eternal.
  2. Structure (load bearing elements, such as the foundation and skeleton) may last from 30 to 300 years.
  3. Skin (the exterior surface, such as siding and windows) lasts for around 20 years, as it responds to the elements, and to the whims of fashion.
  4. Services (the circulatory and nervous systems of a building, such as its heating plant, wiring, and plumbing) succumb to wear and technical obsolescence more quickly, in 7 to 15 years.
  5. Commercial Space Plans (walls, flooring, and ceilings) may turn over every 3 years.
  6. Stuff (lamps, chairs, appliances, bulletin boards, and paintings), is, of course, subject to unrelenting flux

In a software system,

  • Different artifacts change at different rates.
  • Therefore, factor your system so that artifacts that change at similar rates are together.

"separate that which changes from that which doesn’t"

  1. In object-oriented languages, things that will change quickly are cast as black-box polymorphic components.
  2. Elements that will change less often may employ white-box inheritance.
  3. The abstract classes and components that constitute an object-oriented framework change more slowly than the applications that are built from them.
  4. Languages change more slowly than frameworks.

Wide acceptance and deployment causes resistance to change. If changing something will break a lot of code, there is considerable incentive not to change it. For example, schema reorganization in large enterprise databases can be an expensive and time-consuming process. Database designers and administrators learn to resist change for this reason. Separate job descriptions, and separate hardware, together with distinct tiers, help to make these tiers distinct.

Code changes more slowly than data, and is the realm of programmers, analysts and designers.

Part of the impetus behind using METADATA [Foote & Yoder 1998b] (data about data) is the observation that pushing complexity and power into the data pushes that same power (and complexity) out of the realm of the programmer and into the realm of users themselves. Metadata are often used to model static facilities such as classes and schemas, in order to allow them to change dynamically. The effect is analogous to that seen with modular office furniture, which allows office workers to easily, quickly, and cheaply move partitions without having to enlist architects and contractors in the effort.

from Big Ball of Mud

Categories: Architecture
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: