Architecture Principles

  • Comments posted to this topic are about the item Architecture Principles

  • You make some interesting points Steve. As a consultant I take those architecture principles to my clients, and often it's the only way to maintain control of a big BI project. But there's always a need for vision and creativity. Those who only go by the book tend to produce a lesser result, even if it's a really good book. I would say that a consultant or employee who is 25% visionary but abides by a strong methodology 75% of the time has an ideal approach for the type of work we do.

    LinkedIn -
    Blog -
    Follow me - @carlosbossy

  • Ooooo - Principle-Based Architecture and Values-Based Design... have you been reading my unpublished posts again? 😉

    Great editorial Steve - again!

    :{> Andy

    Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics

  • Thanks, and you two are probably two of those "successful" people because of your principles.

  • Steve,

    I don't often find time to post but I noticed you used Wright's falling water as your graphic for today's post. There are two great analogies that your image invites.

    1. Wright was a minimalist, or the functionality of the tool or the space was the least required to accomplish the task. SSMS would not be a "Usonian" tool. Each room or piece of furniture that he designed had and met a specific purpose and nothing more.

    2. The home "Falling Water" sprung multiple leaks because it was not funded or maintained after the family moved out. As a location its beauty began to diminish the day it became a museum. The deterioration took time but it was constant.

    Falling Water has recently been repaired and reworked to bring it to modern standards and here is the basis of my analogy. Every tool that exists today can be outdated tomorrow. It is by consistent and diligent maintenance of databases and the tools associated with them that we avoid costly repairs later. If we ever get to the point where we have delivered the database product and move on without ensuring constant maintenance it will deteriorate into obsolescence. If a consultant or architect doesn’t architect the long term care and feeding of the product they are, in my opinion, more of a slash and burn architect.

    Falling Water is a great tribute to Frank Lloyd Wright in Western PA but it’s also a great analogy for building a super product and handing it off to a customer who is enamored with the architect but not cognizant of the requirements to maintain the product.

    Sustainability isn’t just a requirement for global energy products. It should be part and parcel of everything we do.

  • Love the analogies Bob.

    So very true regarding your second analogy. Not that I could find it in my heart to tear down a Wright building--that is another option a business is sometimes very hesitant to do. When it costs more to maintain, just let go of the past and rebuild it to meet today's needs.

  • I had the chance to tour Falling Water in 98, and heard about a number of the issues that came about over time. It is an amazing structure and this topic made me think about that piece and about how Wright designed things.

  • Steve,

    Here we have as team of architects who review all proposals and new system development project proposals. This review is for a series of areas from data, data integrity, application security, conformity to standards, use of enterprise components and more.

    This review is done as early as possible and in a way to not kill creativity, but to insure that those creative objects are able to fit into the architecture and direction of the business.

    It has been going on for years and is working well.

    Good article, and as usual we all out here appreciate your work!


    Not all gray hairs are Dinosaurs!

  • Steve, you always brings us great editorials. An excellent resource for knowledge, ideas and trends.

    I am your loyal reader and your editorials make me stay with SSC. Keep posting.

  • I can't say that I have well-articulated architectural principles, but I do have policies that I follow. I just haven't taken the time to write very many of them down. Should probably do so.

    My key principle is simply, "don't build something I'll be stuck with for the rest of eternity". Lots of implications and corollaries to that one. First corollary is, "don't build something I won't understand a year from now".

    Plenty of other rules. Just not articulated.

    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • I have formal education in architecure because I prepared for the IBM OOAD exam, it makes applying changes as needed to both layers of the application easy. In the Microsoft platform rich companies in 2010 can build very complex applications in six months or less because most components needed for complex application development are coming prebuilt. I use Craig Larman and Martin Fowler and the Microsoft architecture team who gets to most things architecture long before others even think of it in Microsoft, a new book is out and I have downloaded it.

    I am code first person so I have looked at what is coming in .NET 4.0 system.tuple, LINQ and SQL Server 2008 RC2 MDM makes distributed application development almost easy. Now if the people in MDM knows that MDM being developer tools must come in x86 and x64 2010 would be fun year.

    I was just getting ready to disassemble the service bus and Microsoft beat me to it, requirement must work for a rich company.

    Codeplex is down for maintenance so here is MSDN link where you can download the book



    Kind regards,
    Gift Peddie

  • Thanks SSCrazy for the link to the Architecture guide. I'm sure it will be a fun read.

  • Superb editorial.... thanks again Steve.

  • One of the problems I found when switching to agile development practises was getting the non DB development team to accept architectural principles from the DB perspective.

    The good architects tend to be experienced people who have trod on the turds and beartraps in life and learnt how to help others avoid them in future.

  • David.Poole (12/21/2009)

    One of the problems I found when switching to agile development practises was getting the non DB development team to accept architectural principles from the DB perspective.

    The good architects tend to be experienced people who have trod on the turds and beartraps in life and learnt how to help others avoid them in future.

    That is because the Agile people don't know most things relational one of the reasons their friends add their tools to Visual Studio and in most cases such methods seldom make it to production.

    Kind regards,
    Gift Peddie

Viewing 15 posts - 1 through 15 (of 21 total)

You must be logged in to reply to this topic. Login to reply