I love all things beautiful… My house is beautiful, not expensive, but beautiful none the less. The design of the exterior reminds me of a mountain top retreat. I really didn’t have anything to do with that except that I selected it from all the other houses on the market at the time. The interior is a totally different story.
I love color and I use the color wheel and the laws imposed by it to make my selections. I chose the triad of orange, green and purple in similar hues and varying intensities. As for furniture selection and placement, I selected smaller/modular pieces and use design principles learned from decades of design magazines and HGTV so that your eye flows seamlessly from room to room. I purposefully, deliberately designed the interior of my house to produce a feeling of welcoming coziness. And it works. Everyone who comes to visit me says the same thing, “Your house is so cozy!”
I also love beautiful architecture.
I scored a 20 on Optimize Application Architecture and a 15 on Optimize Technical Architecture. What is the difference between Application Architecture and Technical Architecture? Rather than get into a heated discussion about that (just search the internet for all the various descriptions) let me just be specific about the system qualities that I attempting to categorize with the terms.
I use the term Technical (or System) Architecture to categorize the practical qualities of a system such as security, scalability, availability, and performance that are usually achieved with COTS components. Therefore someone scoring 20 in Optimize Technical Architecture would have thorough knowledge and extensive experience with COTS components and/or frameworks that provide qualities such as these. I use the term Application Architecture to categorize the softer qualities of a system such as reusability, modifiability, extendability and the like. More of an art, design principles/patterns are creatively applied to conform architecture to the unique aspects of a business domain. The outcome – if you understand the business then you understand the system. I am of course concerned with the practical aspects of the system and enlist help from qualified persons to make these quality decisions – I care! But I am truly motivated to set the mood. I want everybody who works on my systems to say, “Your software is so cozy! …It is so easy to understand. …It is so easy to fix. …It is so easy to extend!” But cozy architectures take planning and time which is why I enjoy RUP. I hold dear the RUP best practices to Model Visually and Use Component Architectures. I also hold dear the Lifecycle Architecture Milestone that postpones Construction until the architecture is proven stable with the implementation and testing of architecturally significant use cases (now, user stories).
“But this is not agile,” you complain. What about the Agile principals “The best architectures, requirements, and designs emerge from self-organizing teams” and “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”? But what if the self-organizing team in question has an influential member that scores high on Optimize Application Architecture that is motivated to create “cozy” architectures? What would you do? Ostracize them? Kick them off the team? Make sure you don’t hire them in the first place?
Thank goodness for Agile Architecture.