Software Architecture in Practice: Chapter 4

I'm not sure if conceptual integrity is a good phrase for describing consistency in a system's design, but I absolutely agree that it's better to have uniformity that to have "certain anomalous features and improvements"; and it seems that most people agree. The difficulty with this is that you can have a situation where several team members will aggressively hold on to their ideas that will cause a debate for hours. In which case, an assigned architect would be helpful to make the final call. So I would also add to expect wasted hours in effort to the quote,

"make the architect available. If no one is identified with that role, it is a sign that conceptual integrity may be lacking"

If Buildability is the quality that, among other things, measures how much parallelism can occur in development, then conforming to the object-oriented principle of designing to interfaces is crucial. I've been a part of several projects where teams don't do this and we end up with spaghetti code that takes several hours to make a small change.

Finally, the author states that buildability also has to do with how much knowledge the team has about the problem.

"A design that casts a solution in terms of well-understood concepts is thus more buildable than one that introduces new concepts"

Although I agree with this, a team has to start somewhere. A company can buy another company that has the expertise of a domain, or they can gain it through years of experience of selling solutions of this domain. In which case, their ability to deliver a solution should be expected to be delayed. It seems that when companies invest on pet projects to get expertise on some domain is when they're most successful (think Google). It might be because they're not pressured to release a product any time soon and, therefore, aren't forced to compromise architectural qualities that will come back to haunt them later. Any thoughts?