October 23, 2011 at 11:39 pm
Comments posted to this topic are about the item The Cost of Architecture
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
October 24, 2011 at 6:53 am
We definitely should try to learn from our experiences - the decisions that work out well of time as well as those that do not. At the same time we should be mindful of the costs of 'analysis paralysis' and should not fall for the fallacy that we can predict the future. Instead we should follow sound architectural principles such as loose coupling (through a variety of techniques) and be prepared to change the system when it is warranted.
Commonly there is a cycle of failure that starts with the premise that we can predict the future if we do enough analysis. Building become so expensive, laborious and time consuming that we fear changing the system. Technical debt accrues and the upgrade burden grows. Change is deferred until it is no longer avoidable and we are forced to bite the bullet and rewrite the entire system.
When we build for change, we include automated testing and loosely couple components so they can be easily replaced or adapted. In this scenario, we can respond quickly and efficiently when change is needed and keep our system aligned with its purpose and market in near real time.
October 24, 2011 at 7:56 am
There are some very good points made. As usual, allow me to offer some contrarian views that help explain why there are sometimes poor decisions made.
First, we generally have limited decision making power. We can suggest best practices, better ways to do things, and things to stay away from. But the end users frequently decide they don't care what we think, and then override what we suggest. Yes, we can explain why we feel the way we do, but ultimately it is usually others who make the final decision. One example in building an ERP application for HR/Payroll was that the users saw no reason to use a badge number field. Later the decision to move away from Social Security number as the badge number was made. In addition to completely rewriting code to evaluate which field to use, the users had to back enter all the data (in a week) they could have entered originally (over time)! The reason the move was made is someone finally listened to concerns over having employees suffer identity theft!
Second, David posted about analysis paralysis. Frequently managers latch on to terms like this to describe something that is not working how they want, which is not necessarily the same thing as not working correctly. On one extreme, analyzing the o-ring design on the space shuttle should have been more in depth. Did anyone listen to the engineers who suggested from the start that it could be a problem? No. On the other extreme, data normalization can certainly be something we spend too much time on. The saying "normalize until it hurts, denormalize until it works" certainly is the "correct" way to handle it, but really, is it that important to get it perfect? We need to analyze the risk, determine likely and possible outcomes, and then go with what makes sense. If something isn't likely to occur, and the cost is small, don't worry about it.
There are many reasons why shortcuts are taken. There are many times when we could make a decision quicker and have substantially the same results. Knowing how to recognize which way we should go is valuable. The key is understanding that the experts have reasons for their suggestions, and as long as they can articulate the reasons, decision makers should take the time to listen, and then decide.
Dave
October 24, 2011 at 9:58 am
Stopped reading the linked story once I got to this gem:
Another candidate [for most expensive mistake] could be IBM's choice of Bill Gates over Gary Kildall to supply the operating system for its personal computer. The damage from this decision is still accumulating at breakneck speed, with StuxNet and the OOXML perversion of the ISO standardization process being exemplary bookends for how far and wide the damage spreads.
I don't have the experience or knowledge to assess the significance of the "perversion of ISO standardization" described, but when I read colorful attacks like that, I doubt the author's objectivity, even-handedness, and judgement.
Rich
October 24, 2011 at 10:16 am
Steve,
thank you for the thought and prep that this took. It is a very valuable understanding about how we do what we do.
IT Architects are numerous. Good architects are fewer. Great or excellent architects are almost impossible to find. And most would say that time is the only factor that tells the difference between the three. I have not agreed with this.
Many good architects have made very significant contributions to the future of the discipline of IT. They have taken time and thought it out. But they are prone as others have said to get into the analysis of the analysis and not keep in focus that they are required to make a decision.
An excellent architect does much the same analysis as the good architect but also keeps in mind that the best answer two years too late is worse than a good answer quickly. They balance probabilities and possibilities, options and limitations against previous experience and an understanding of the field as it stands today. Then working trends and projections they start to map out where certain decisions and technologies may take the industry while all the time looking at the technical expertise of the developers and users of the intended architecture or system.
Another are of concern is the complexity of thee strategy envisioned by the architect. A good or average architect can develop a very complex and highly challenging technical solution to problems. But is there staff who can write it and maintain it over time. Knowing that the TCO of a complex highly challenging solution is high can the architect simplify the solution down to a more manageable proposition. Some would argue that you should strive for perfection and who cares how complex. But they forget that the architect must share the future so that TCO is not so high as to bankrupt the project or company.
Thanks again for the topic very good to see and well done.
M.
Not all gray hairs are Dinosaurs!
October 24, 2011 at 10:20 am
Steve,
Great article. Like how you used the picture of Falling Water to set the tone.
Great example of how something can be done right the very first time it is ever done. Prior Planning Prevents Poor Performance.
October 24, 2011 at 5:38 pm
Steve
Much thanks for this one. I do appreciate how much thought went into this "small" piece.
I would just add one observation: being a database architect is a title but seldom a full time job. I have to also act as a tech lead and sometimes as a second level ops guy.
I just have to make sure my boss reads this, "coincidentally." 🙂
October 25, 2011 at 7:50 am
Revenant (10/24/2011)
SteveMuch thanks for this one. I do appreciate how much thought went into this "small" piece.
I would just add one observation: being a database architect is a title but seldom a full time job. I have to also act as a tech lead and sometimes as a second level ops guy.
I just have to make sure my boss reads this, "coincidentally." 🙂
You are welcome. Glad you liked it.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
October 25, 2011 at 2:52 pm
I believe the house in the picture is actually falling apart and is taking millions to keep going. I believe it was a Frank Lloyd Wright home. Aesthically beautiful yet it won't last long (at least with out millions to keep it going).
J
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply