A reference architecture is a resource containing a consistent set of architectural best practices for use by all the teams in your organization.
Many projects I encounter spend an inordinate amount of time researching, investigating, and pondering architectural decisions. This is especially unsettling when it's clear that if prior project teams had taken the time to document their experiences and build up a reference architecture, they could have spared the new project teams much of this research and decisionmaking.
In fact, the inability to learn from a cumulative project "history" probably puts a new project's timetable at greater risk than all other factors combined. A project that proceeds without reference information will not necessarily fail; it will just require considerable effort on the part of the project team that could be spent better elsewhere. Organizations can hope to get software into the hands of clients sooner only through realizing tried and true repeatable processes.
The RUP suggests that a reference architecture should be defined along different levels of abstraction, or "views," thereby providing more flexibility in how it can be used. Ideally, these views map to the 4+1 Views of software architecture outlined in the RUP and embodied in the RUP's Software Architecture Document.