An RA has a number of benefits for the enterprise:
Shows system architects the recommended way to structure systems.
Shows how systems tie into the larger enterprise infrastructure and put system architecture decisions in context with respect to the enterprise-wide system.
Shows how enterprise components, like directories, should be used.
Captures best practice information for system architectures.
Makes training easier because new developers can be educated using the RA. Moreover, developers transferring from project to project come up to speed more quickly because the architecture is familiar.
In addition to the benefits, RAs pose a few pitfalls :
RAs can be overkill for some projects.
RAs may stifle creative and innovative solutions to problems.
The most effective way to mitigate these downsides is to remember that an RA should never be followed by rote. A reference architecture should be evaluated for each use and proven in practice. As a component of the IMA, the RA should be subjected to the same feedback cycle shown in Figure 14-1 as other IMA components. The feedback may change the project, or it may change the RA. Feedback on how well a particular RA worked in a project is likely to affect foundational components in the IMA such as the interoperability framework (IF) as well.
One way to use an RA in a project is to adopt it piecemeal and iteratively as needed. In this practice, the project uses the RA as a reference, but only implements a subset of the architecture because of specific project needs. For example, the RA might contain multiple servers and a load balancer to create a high availability environment, but in practice, the project leaves out the load balancer and uses only one server, because high availability is not a critical factor in this particular application.