There has been a very interesting (imho) multi-part <strong>interview</strong> with the author of <strong>Beyond Software Architecture</strong> where he discussing various aspects like the relationship between Architecture, Culture and Goodness. Also goes on to discuss the social role of an architect, conceptual integrity and the importance of domain knowledge. I particularly like the quote … “ An architecture is like a dirt road. The first time a car drives over it, the road looks about the same. By the time the 10,000th car drives over it, though, there will be grooves in the road. As an architecture mature, it gets grooves.”. Some other interesting responses that I personally have learned from over the years and I can relate to are below.
How do you measure a good Architect? - How well the architecture responds and adapts, and how well it goes through that construction process, is a measure of whether that architecture is any good.
What is the difference between maturity and completeness? - In its first version, an architecture should be like a baby. It is whole and complete. It has ten fingers and ten toes. It has all its systems, but it is immature. You wouldn’t expect it to do certain things that you might expect a mature system to do. Of course, the definition of what is complete and incomplete, mature and immature, is subjective. But it is really important to distinguish between incompleteness and immaturity. I see the people make the mistake made all the time of building an incomplete system. It’s actually not a mistake that’s correlated to a development process, near as I can tell. You can have iterative, agile projects that produce incomplete results, and you can have waterfall or traditional kinds of projects that produce incomplete results.
“… explore alternative architectures to see what works best…” This is sensible advice. It is also virtually useless.
“… An architecture is like a carefully designed garden, and needs care and feeding….”
What is Entropy Reduction? - Entropy reduction means I am going to make whatever compromise I need to make to get the release done, and then I’m going to give the team the opportunity to go back and respond or recover from the compromises they made. It is a very different concept than refactoring. I think of refactoring as non-architectural, but rather very much in the context of normal work.
This is so true of one of my previous projects we were implementing in the New York office of the company I work for. Some of my colleagues who are reading this (and proving they don’t have anything better to do) are probably grinning ear-to-ear from this:
Another aspect of matching architecture to human needs is matching roles and responsibilities of the people building a system to the appropriate parts of the architecture. Some pundits say that everyone likes to do everything, but that’s not true. I suspect that a lot of people who write about architecture, although they are very smart, have never managed large teams. I’ve managed a 60-person team, and I personally know UI guys who would never get near a database, because they think databases are “stupid”. And I know many database developers who would never go near a UI. The last thing these database people want to do is the full architectural stack. They’ve spent their life becoming an expert at Oracle. And you know what? They are an expert at Oracle. They aren’t going to be an expert at UI design, and given what they would normally design for a UI, you wouldn’t want them to be touching the UI anyway. When you look at the stack in your architecture, and then you look at this mass of people on your team, the architecture and the people have to match. Otherwise you’ll have problems.
Determining the Appropriate Granularity of the Design? - When people talk about architecture, there’s rarely a corresponding discussion of the granularity of the architectural metaphors, components, or descriptions that are being employed. The appropriate granularity is a function of the number of people working on the software and the complexity of the software itself. If only two or three people are working on the project, then they can get pretty granular. As the software and team gets bigger in size, the granularity must become more abstract.
Overall, like I opened this post with, this more or less reflects my experiences and pretty much on the dime with the issues, suggestions and analogies discussed. What are your experiences? Do you disagree with something?