As described by SEI, architecture forms the backbone of successful systems. An architecture largely permits or precludes a system's quality attributes. If you are responsible for making product choices or developing new software in support of a business, having an predefined architecture, with established goals and decision criteria, can speed time to market, improve integration, reduce costs, and enhance your ability to service your business partners. Consider first the alternative. Let's say your approach to architecture resembles the following statement; "We will select the best solution for each and every opportunity or problem identified by our business unit(s). We will not be constrained by goals of technical purity." These statements are not at all uncommon; they are spoken frequently by CIOs in the attempt to provide the most responsive technical organization for their business constituents.
However, these same statements when taken out of context, or to an extreme, are largely destructive to any business that relies on technology. First and foremost, the goal of any architecture program is to support and grow the business. Medical students are often told, first, do no harm. (BTW - these words do not actually appear in the Hippocratic Oath). This is a good philosophy for an architect. So a balance must be achieved that allows the business to dictate timetables, functionality, and costs, while the architect tries to encourage simplicity, synergy, and sanity.
The topic of how to develop a comprehensive architecture program is not the point here, rather, that having one will benefit your business. For instance, let's say you know that your IT function prefers to buy products rather than build, that most of your purchased application are web-based, multi-tiered, .NET, and of the Big 3 constraints, time to market is favored slightly more than quality or cost (yeah, yeah, everyone wants all three, but there's that whole reality thing).
Immediately you know what skills you need to hire; Integrators with a background in VisualBasic.Net or Visual C#. You know what operating systems to deploy on your next server purchase, what training to schedule, and who your tools vendor is. Equally important you know what you don't need; large teams of Computer Science majors, robust/comprehensive coding and documentation standards, JDBC expertise, other artifacts associated with hard-core programming.
Knowing what you need and don't need enables an organization to rapidly dismiss unattractive options, thus allowing decision-makers to focus on acceptable alternatives more quickly and deeply. This in turn means faster decisions (time to market), deeper analysis (higher quality decisions), better integration ('cause the environment is well-known), and lower costs. The 'lower cost' thing is not quite so direct, but the logic says that unfamiliar technologies will cost more as a result of learning curves, mistakes, and sub-optimization.
Pro-actively understanding your architecture will support business by enabling improved time to market, and quality, while reducing costs and complexity.