“Exemplars provide safe models for new designs”

 It was interesting reading “The Design of Design: Essays from a Computer Scientist” by Frederick Brooks after having recently read “The Last Place on Earth” by Roland Huntford.  Captain Robert Falcon Scott tried to design new contraptions and use technology to help him get to the South Pole first.  However, his designs failed time after time.  The reason his designs failed was the same reason Mr. Brook’s highlights in his book; Captain Scott did not thoroughly understand the Exemplars of his day.

“Exemplars provide safe models for new designs, implicit checklists of design task, warnings of potential mistakes, and launching pads for radical new designs. Hence great designers have invested great efforts in studying their precedents… Jefferson carefully studied not only Palladio‘s books, but the buildings around him in Paris… Bach took a six-month unpaid leave from his job and walked 250 miles to study the work and ideas of Buxtehude… Bach proved to be a much greater composer than Buxtehude, but his surpassing excellence came from comprehending and using the techniques of his predecessors,not ignoring them.”

Whether it was hubris or something else, who knows?  But if Captain Scott had intensely studied the exemplars of his day and the tools of previous Antarctic expeditions like Amundsen did, rather than recklessly designing useless contraptions, he would have likely arrived at the South Pole first and made it back to England alive.

So what does this have to do with information technology?  Well, before trying to design new, wild, innovative technology solutions, first study and understand the advantages and disadvantages of existing works.  That is one of the advantages of today’s open source movement, it allows us to thoroughly research exemplars and frequently use what we learn to build solid frameworks for future innovation.

Related Posts

What if Antarctic explorers were system administrators

Thoughts on “The Design of Design: Essays from a Computer Scientist”, by Frederick Brooks

I recently finished reading “The Design of Design: Essays from a Computer Scientist”,  by Frederick Brooks

Yes, it is the same Frederick Brooks who wrote “The Mythical Man-Month: Essays on Software Engineering” and same Frederick Brooks who was the design architect behind the IBM System/360, reference I.B.M.’s $5,000,000,000 Gamble.

It begins by analyzing various design theories:

• Decision Tree
• Herbert Simon – Decision Making and Problem Solving
• Verein Deutscher Ingenieure – Rational Planning Model
• Winston W. Royce – Waterfall Model
• Pahl & Beitz Method
• Barry Boehm – Spiral Model
• Co-Evolutionary Methods in System Design and Analysis

One interesting observation that Mr. Brooks points out over and over throughout the entire book is that most great inventions have had only one or two chief architects, they were not designed by a committee.

Thinking back through the many projects I have been involved in or witnessed, this observation certainly rings true. Those projects that were compartmentalized with various specialities glued together by a business manager rather than a chief designer/architect had a higher rate of failure. I have observed brilliant ideas ignored because business managers lacking technical expertise weighed the merit of ideas on individual reputations rather than the value of the ideas themselves. A good chief designer/architect can see through this and has the vision and technical expertise to capitalize on new ideas that might otherwise be discarded or dismissed by traditional business/project managers.

I have read some material outside the book where Mr. Brook’s observation is challenged, claims have been made that design teams are often successful on a regular basis. After reading the entire book, I don’t honestly believe Mr. Brooks is suggesting that design teams can’t be successful. He is merely stating that without a chief technical designer/architect free from company procedures, corporate meetings, politics and tampering by business & process managers, the chance of project failure is higher. A chief designer/architect needs to be equally respected and set aside as a separate position from the business/project manager.  One position without the other doesn’t usually work well, one position with more power than the other usually doesn’t work well, nor does it usually work well when both duties are combined into one position. He also states that design by committee creates unnecessary delays & encourages compromises resulting in sacrifices to overall design integrity and project ingenuity. I think these are all very fair observations and there are many more great observations throughout the book, I highly recommend reading it.

Application life cycle management tips

We are nearly done retiring a group of 30-year old legacy inter-agency applications; fortunately we planned and budgeted for the phasing out these applications during our new systems’ planning process so it is going extremely well.  Many people groan at the thought of retiring old applications – perhaps I’m just wired weird, but despite the long hours and heavy workload I am finding it to be challenging and rewarding.  I thought I’d take some time to share my thoughts and observations on the subject:

Legacy applications can be an extremely costly proposition…

“IT budget pressures are forcing many organizations to abandon plans to replace their antiquated but critical applications.”

- Source: Living with legacy apps, by Kenny MacIver

And how many of us have seen organizations move to new systems, but never completely wean themselves off their redundant legacy systems?

“According to Phil Murphy, a principal analyst with Forrester, a big part of the problem is that neither the business nor the IT department knows how to keep the information in a legacy application available to users without keeping the application running. This not only prevents retiring the application, but the legacy infrastructure on which the application runs never goes away, either.”

-Source: Why Enterprise Applications Never Retire, by Michael Vizard

In order to achieve projected ROI with new improved automated systems, it is often imperative that we retire our old redundant applications, common sense, right?  So why are redundant legacy applications so prevalent in the industry?  I believe some of this can be attributed to a lack of proper planning and general human psychology.  New applications are exciting, they create a buzz, like new high-powered ski boats; old legacy applications are viewed as dull and boring; they are the row boats with anchors dragging behind them.  As a result, when planning budgets, timelines and calculating ROI, it is easy to subconsciously cheat ourselves – it is easy to ignore the real costs associated with fully retiring legacy applications because there is nothing new, exciting or snazzy.  It’s also easy to inadvertently under-estimate resources and time required unless we pad those estimates to account for unknown gremlins that lie in wait; after all it’s a legacy application, typically built before we were hired at the organization.  Bundle that with tight budgets in a tough economy… ouch!

Proper planning is paramount:

• Top 5 Considerations when Retiring Legacy Applications

ITIL application life cycle management:

• ITILv3 Application Service Library – Sound Guidance 

Legacy applications don’t have to be boring, tearing into your legacy applications and weaning people off them is a great way to expose and learn about otherwise unidentified processes and about past practices that may unknowingly still be going on in your organization.  It is a peek under the hood, an opportunity to expose those inefficient, quirky processes, and to architect and implement more exciting automated processes.  Keep your application retirement projects under-budget by retiring them as early in the process as possible, i.e. while you still have the chance to engage  resources with in-depth knowledge of the inner workings;  these resources may be able to explain idiosyncrasies in the legacy applications and help speed up conversion & retirement.  There is no guarantee that these same valuable resources will be available in the years to come, many of them will likely move on to other jobs, retire, etc.   In summary, I think it goes without saying that the lack of key resources with an in-depth knowledge of the legacy applications can dangerously increase project costs, length, and risk.

So anyway, to cut to the chase – with proper planning, budgeting and attitude legacy application retirement can be fun, progressive, and rewarding… Without? … We’ll, don’t close your eyes now, it might become your worst nightmare

Would Antarctic explorers make good sysadmins?

Part 1 of 5…

When we hire our system and network administrators most of us look for experience, references, certifications, and schooling. We typically have in depth technical questions to test for knowledge and problem solving skills, but there are many other more subtle traits that separate the truly great system administrators from the average Joe…

“By the late 19th century, Antarctica was the last unexplored continent on earth…” Three men raced to be the first to reach the South Pole. This contest to become the first human to set foot on the geographic South Pole is an exciting and controversial chapter in the history of leadership under adversity. Set in the most hostile environment on Earth, the race to the South Pole shows how leadership style, personality, strategy, and openness to innovation interact to determine success or failure…” – BBC, British History In-depth, The Race to the South Pole, by Sian Flynn

Numerous case studies conclude that these men would have been great business leaders, but would they have been great system administrators? Stay tuned and find out…

Reference Material

Shackleton in Business School, Case study examines how exceptional leadership saved Endurance crew”, by Beth Potier, Harvard News Office

Encylopedia of Leadership, by George R. Goethals – Williams College, Georgia J. Sorenson – University of Maryland, University of Richmond, James MacGregor Burns

Shackleton’s Leadership of the Endurance Expedition, by Charles Chappell, Wharton Executive MBA Program

Leading at the Edge: Leadership Lessons from the Extraordinary Saga of Shackleton’s Antarctic Expedition (Kindle Edition), by Dennis N.T. Perkins

The Last Place on Earth (Kindle Edition), by Roland Huntford

The Endurance: Shackleton’s Legendary Antarctic Expedition, documentary directed by George Buttler (2000)

Comming up next …

How do you explain cloud computing to people who buy into vendor hype?

“… a lot of things you will see will have cloud annotations. Why not? When something is not clearly defined and mostly misunderstood, it becomes one of god’s great gifts to marketers.”  – John M Willis

“We’re marching out yesterday’s services as cloud services…it ends up blurring the lines and making adoption very difficult,” – Hamid Ouyachi, Labor Department chief technology officer.

The term “cloud computing” is so ridiculously overly used, and no pun intended - very nebulous. Marketing folks have had a field day with this buzz word, they have twisted the definition beyond repair – this in return makes it very hard to talk with certain folks about cloud computing.

• What cloud computing really means
• Wikipedia Definition – Cloud Computing
• Cloud Computing Slide Show – From Myth to Reality
• Larry Ellison Nails Cloud Computing

I.T. Department Management Tools

The following is a list of essential tools for running efficent, highly effective I.T. departments.  Most of these tools apply to both medium and large business:

http://bit.ly/9jXSTs

How do you ensure your IT departments have all of these tools available without breaking the bank or eating your project resources alive?  In an upcoming series of posts I will cover possible avenues, drill-down, and share first-hand experiences.

Do you have ideas for other useful IT department management tools?   I’d be interested in hearing ideas and experiences in providing highly effective IT department tools without heavily impacting project schedules.