What makes a good Linux Architect?

A member of my LinkedIn network recently asked me what characteristics make a good Linux Architect and I found this to be a great thought experiment the results of which I've written out below. I think the domain is irrelevant and applies equally, with minor translations, to all IT Architect Roles.

• Solid understanding of the underlying operating system and it's external dependencies (network, SAN storage, etc.)
• Solid understanding of Linux's strong and weak points. Finding an innovative way to solve a problem with an ill suited tool rarely ends well.
• Good understanding of the strengths and weaknesses of the other operating system options available to a customer and willingness to tell your customer that there is a better way than Linux if one does exist.
• Excellent ability to envision complex system and application interactions both inside the Linux OS and with other systems, Linux and otherwise.
• Designing with trouble and change in mind. Be mindful of security, patching, availability requirements. Accept that the solution as your deliver it has a limited lifetime, will need to change and therefore must be amenable to change. Accept that something will fail and that when it does you will be grateful for the DR plans you created and test regularly. You do have a DR plan, don't you?
• An advanced case of depictosinanguliphobia (the morbid fear of being painted into a corner).
• The ability to rapidly assimilate change. Nothing in IT stays the same and the only consistency is the acceleration of the rate of change.
• Solid understanding of people, their communications styles and motivations. As Architects we must be adept at getting to the reality of what our customers (and their customers) REALLY need rather than what they think they need. We are not smarter than they are, we just see thing differently and need to help them navigate to a solution that truly meets their needs rather than what we like the most, what they or their supervisor read about in a magazine or what will make their leadership happy because of the included buzz words but will disappoint with the ultimate effectiveness, or lack thereof, of the solution.
• Willingness to embrace and rejoice in the trust our customers put in us even if they seem difficult or ungrateful. The fact that we have talents which they lack, in spite of the very real talents that they have, enables us to put food on our table. This characteristic might best be summed up as humility combined with gratitude.
• Excellent communication skills both written and verbal. All of the skills above are of little use if we cannot communicate our ideas to our customers and Project Teams. As Engineers we build things, as Architects we design and describe things. If we can't get the things out of our heads and into production we are useless.
• Confidence without arrogance. Once we (the individual Architects) know what we (the Project Team) need to do we must be able to communicate it in such a way that we drive acceptance and confidence on the part of the Project Team so that they will work forward without doubt. This confidence must be tempered by the humility to accept criticism and correction in the event that we missed something. Some of the worst Architects I have seen were arrogant bullies who drove their ideas relentlessly in spite of objection. Objection is great! It gives us the opportunity to drill deeper into things that others see which we may not have seen. If we need to correct our plan it's better to do so earlier than later (one of my favorite mentors was fond of saying "bad news doesn't age well"). If we are correct and the person bringing the objection is not then our receiving the objection with gratitude will make a friend of them and encourage future objection at a time when the tables may have turned and we truly need someone to point out the error of our ways.

What would you add to this list?