Demolition

jeffvand — Tue, 30 Jan 2007 10:26:23 -0600

I really like the way you compare the changes we make to demolition. It seems that far too many people are unable to embrace changes to help overcome the less-effective "old standards and methods that we used for providing services." Sometimes demolition is painful, but it is necessary if we want to move out of the 20th century. Just think how our lives would be different if we never embraced the technology we all use in our kitchen's every day. I think the same changes are taking place in education too. I already find myself looking back at the way I was educated and wonder how the teachers did it!

A Pattern Language for Technology

smiltenb — Tue, 30 Jan 2007 10:05:45 -0600

In 2007, I’m determined to put the finishing touches on the fixer upper house that I bought ten years ago. The good part about never actually finishing the work (like replacing the missing molding around a bathroom window) is that I have a more flexibility to make improvements that match my current needs. I’m no longer attached to my original notion of restoring the 1926 row home to as close-to-original as possible. Instead, I’m all about demolition – for starters breaking down the wall between the kitchen and dining room. Sure a 7x15 galley kitchen might have been all the rage in 1926; but once you add a fridge, sink and range to a space this size you’re virtually out of counter space…and I really like counter space.

This past Fall a friend lent me a copy of “A Pattern Language” (Christopher Alexander, Sara Ishikawa and Murray Silverstein) to help inspire my upcoming renovations. The book blew me away and as I continue to re-read it, I’ve been percolating on ideas about “a pattern language of technology”. Some really smart people have written about pattern languages in design and in software development and I did start reading “Design Patterns: Elements of Reusable Object-Oriented Software” but didn’t get too far as it did not rank very high on my readability scale.

There is such a shift happening in technology right now – particularly how it weaves into our physical lives and intermingles with (and replaces) our social interactions; and this shift has inspired me to come up with a new language and new models for how we manage technology at MICA. I'm looking for new patterns for how we evaluate solutions and design our technology presence across the institution. Each day departments across campus (including mine) are finding that the old standards and methods that we used for providing services don’t work very well. A few years ago facing challenges like this would get lumped under the heading of “business process redesign” and we would try to bring in some talented experts who could help tell us about better business models.

But we need new patterns and new designs for facing these challenges today. Something that is not specific to coding but that takes on the whole big thing – staffing, systems management, procurement, services, training, etc. And a significant challenge beyond articulating this pattern language is making it timeless – particularly when it comes to technology. How do we construct a pattern language that embodies the interconnectedness of technology, society and business but that also recognizes the distinctions between good code and productive workspaces?

One of the less-abstract applications for Christopher Alexander’s work and projects at MICA is the issue of space design. As we rev up for 18 months of PeopleSoft/Oracle upgrades, we’ll be bringing on some project help and we have absolutely no space for them to work.

We had an epic meeting yesterday that started off with the review of our organizational chart. The entire time that I’ve been creating the org charts, I’ve been bumping up against the logical grouping of staff based on function vs. the hierarchical reporting structure. In thinking about ways to create space for staff and constantly improve services it is so obvious that we simply cannot move forward if we continue to hang on to our old notions about private offices for everyone and keeping separations between staff based on reporting structure. Ted “master of the whiteboard” Simpson drew a great diagram that has helped to open up the discussion to one where we’re now thinking about communities within our department based on functions and services. [An article on the pattern language website captures some of the concepts Ryan, Ted and I have been trying to shape into our staffing model.]

This new approach will certainly require plenty of demolition (not just the walls in our offices, but the old concepts about how we work together). Good thing I have a sledgehammer and safety glasses.

“The more living patterns there are in a place-a room, a building, or a town-the more it comes to life as an entity, the more it glows, the more it glows, the more it has that self maintaining fire which is the quality without a name." -- Christopher Alexander

EDUCAUSE | EDUCAUSE CONNECT - A Pattern Language for Technology - Comments

Demolition

A Pattern Language for Technology