Adherence to best practices is essential for successful configuration and deployment of complex networked systems. In such scenarios, experts rely on experience as well as repositories of best practice guidelines to proactively prevent any configuration errors while deploying a networked system in a data center. The reasons for such reliance on experience and repositories of best practice guidelines are listed below. First, the entities in a data center are associated via complex physical and logical relationships which may number an order of magnitude more than the entities themselves. Second, the diagnosis of any problem requires a huge amount of data to be collected, filtered, and correlated from various sources over different periods of time. Third, most data center deployments are not integrated enough to present a single, usable text or graphical interface to navigate through the problem diagnosis process. Instead, a system administrator must correlate data across multiple point tools using techniques that are tedious, time-consuming and prone to errors. Fourth, the technology in a data center is continually evolving primarily due to the need for product differentiation. This hampers the ability of system administrators to diagnose configuration problems because their expertise lags behind the state of the art. Finally, the standardization process that dictates inter-vendor interoperability may be immature and continuously evolving leading to hard-to-diagnose configuration errors. Conventionally, best practices are generated using a costly manual process. In most system domains, conventional best practice generation requires a large team to analyze large sets of configuration data using rudimentary tools to generate the best practices for that system domain. In the case of storage subsystems, best practices may reduce the time required to resolve configuration errors, but the generation of such best practices may be costly and time-consuming (e.g., requiring 20 man-years of data gathering and analysis to derive the benefit of reducing the time required to resolve configuration errors from two weeks to two days). Thus, there exists a need to overcome at least one of the preceding deficiencies and limitations of the related art.