The Fly Wheel Adoption Pattern. Now that’s a funny name!

I’m still thinking about design patterns for business intelligence.

A pattern has a funny name.  It has a description, a solution and consequences.  OK, if you check Wikipedia you’ll see that there’s more characteristics to patterns, but do I look like Martin Fowler?  The Gang of Four?  No…no I do not.

The name (which has mainly been in my head) for developing a BI competancy that drives business performance is the Fly Wheel Adoption Pattern.  Obviously, I have the funny name thing down!  It is also a nod to Good to Great, by Jim Collins.  The consistent persistant pursuit of improvement based on the numbers (which he describes in this book) really resonates with my ideas on why BI rocks.  (By rocks I mean delivers measurable top and bottom line benefits.  By rocks I mean that just yesterday 350 new business intelligence jobs were posted on Monster.com.)

Anyway, that’s the name of the pattern I use to describe best practices for the adoption of BI as a competancy.  Next I’ll try and outline the problem that this pattern addresses.

Architect Center, a Professional Community for IT Architects

I’ve been priveledged to be involved in a small way in the creation of a new on line community (which is still only an alpha release) known as the Architect Center.  Check it out and the article that started it all.

My favorite quote (from the aforementioned article) made it on the landing page:

“Defining and designing complex structures is a common activity performed by almost every discipline, profession, and artisanship throughout the centuries. All the disciplines of old discovered that skills and knowledge required for the composition of large complex systems don’t match the skills that are required for small bottom-up assembly activities. In IT, the same problem became noticeable about 10 years ago, and the gap between core engineering and high-level system design has grown ever since. Grady Booch’s aphorism, you can’t build a sky-rise the way you build a doghouse, encapsulates the common dilemma facing high complexity, high interdependency, and low transparency projects: The sheer amount of detail required in complex compositions is so overwhelming that a function of analysis, decomposition, and abstraction becomes vital for the success of such endeavors.” — Miha Kralj