Beautiful Architecture Chapter 2

This paper seems to argue that one SHOULD focus on functionality initially when designing the architecture of a system as given in their Design Town example,

"Early in the design process, we established the main areas of functionality (these included the core audio path, content management, and user control/interface)"

but that you should "defer design decisions until you have to make them". Since there's only so much you can know upfront, I think a general understanding of the functionality would be sufficient to commence a simple architecture. Because of its simplicity, you can then focus on adding the quality attributes that were discussed in Chapter 1 of Beautiful Architecture. Assuming these first two steps were done correctly, you've now created a superstar architecture that could tack on new functionality with ease. Sounds like a cookbook recipe, doesn't it? But aren't we all trying to come up with a recipe for architectural design that works? At the very least, this provides a reference to work off of when you don't know where to begin or which paper's recipe to follow.

An interesting aspect of the Metropolis that I can relate to is when it said,

"the Metropolis started out as a series of separate prototypes that got tacked together when they should have been thrown away. The Metropolis was actually an accidental conurbation. When stitched together, the code components had never really fit together properly. Over time, the careless stitches began to tear, so the components pulled against one another and caused friction in the codebase, rather than working in harmony."

I'm at a company that has the constant habit of buying other small companies. Business leaders think you can just combine their software solutions and they'll somehow "magically" work together. The problem is that interoperability in some industries, like Healthcare, is harder than others (which explains why we don't yet have an integrated, National Healthcare System). Then I'm put in a situation where I'm adding new functionality in 5 different places from 3 different products using C++, C#, Java, and some other weird language. What a mess! So how can a business invest in the future through software reconstruction and, at the same time, deliver short-term products to keep itself financially healthy?

In Design Town, they mentioned that developers would mark technical debts on "fudges" that would be scheduled for correction at a later revision but how likely is that to happen in a business where everything is a priority that needs to get done now? I would expect most teams to ignore these fudges.