In the typical business organization, there are departments which specialize in specific business areas - HR, IT, Marketing, etc. To me this seems to be a benefit due to the specialized nature of each. There may be individuals in each department who have a knowledge and passion of another area and there may be some crossover, but by and large the units are siloed in their work - especially at larger institutions. Since the structure of systems have a tendency to model the structure of the organizations that create them (see Conway's Law) and many systems that tend to the needs of these units will provide some similar capabilities, it is up to the system designers at the enterprise to go against the natural tendency to design the systems along the same lines as business structure and design the system along the lines of capabilities. There are several benefits to doing so as described in this writing.
Reason 1: DRY - Do Not Repeat Yourself. This is a mantra of software development. This practice of not repeating yourself is commonly declared as a time saver as well as a defect deterrent, especially when there is a change in requirements for a feature. Consider a number of systems who have users and a user admin feature. During the course of development of this feature for each application a considerable amount of time was spent gathering requirement, doing mockups, designing, implementing, testing for this feature in EACH system. And when a defect is found, or security requirements change each system must be updated in turn. However, if DRY were applied at the enterprise level, there would be one user admin capability. That user admin would have behaviors designed to provide common functionality with respect to administering users - add/remove, assign role, change role, reset passwords, etc. The immediate benefit is that the features wouldn't have to be developed for each application. Other benefits are centralizes administration of all applications for system admins. Additionally, this enables "One level up" features to be developed where users can have access to all their applications centralized. One thing to consider with this design is the impact on individual applications due to changes to core features. Additionally, the system must be robust but flexible enough to allow extension by other systems. For example, a canned(packaged) solution may offer an API to its user administration. An idealized core user admin would be able to adapt to it so that it could also be administered centrally.
Reason 2: User Efficiency. Users are able to access actions, tasks and tools from a common location. Potential for more efficient interaction with technology.
Reason 3: Change. Centrally managed change. Changes happen in one place. Easier to find what is impacted by a change.