Most of us can agree that there is always more than one way to achieve a given piece of functionality.  Consider getting a phone number for a person from a Sql database.

• You can connect with integrated security, or pass in the username & password, or maybe implement application roles within the database.

• Once connected, you can pass in a fully formed SQL statement, execute a stored procedure, or make a direct http get against a named template file.

• Finally, how will you package the return? An out parameter? A single row in a dataset (or datareader)? Or a typed return from an execute scalar call?

So many possible combinations.  Is it possible the developer creating that "quick start" example had your particular circumstance in mind? Seems unlikely doesn't it?  It is our responsibility to have a broad understanding of the various approaches and a well defined grasp of the requirements & constraints of the target environment.  From these we need to distill the most appropriate combination of technologies, apply the most effective tools, and support our customers’ business needs without burdening them with the side effects of our choices.  At the enterprise level, our customers are the aaplication development teams.

Like most things it starts with scope.  An enterprise component may be created to constrain or enable its consumers. The important part here is the emphasis on multiple consumers.  An enterprise needs to create both massively re-usable parts and multiple interfaces to parts so that one consumer could use it in a web service running on a server while another uses it in a windows form on the client.  The additional burden is inescapable and absolutely necessary to support the multiplicity of unknowns.  

Sticking with the data access possibilities, the enterprise might define policy explicitly prohibiting passing user name and password in connection strings.  It would be kind to backup such a policy with implemental libraries which securely store and retrieve the user name or better yet, append the policy with examples showing exactly how to implement the preferred method(s) which solves the secure data connection problem.  

By comparison the application architect has a significantly narrower scope.  Constrained by the sweeping policies of the enterprise the application need only identify a single means by which to solve the problem.  The application might choose to implement a custom encryption / decryption scheme.  Doing so may not create a reusable solution but they comply with the broad enterprise policy (and hopefully achieve the immediate goals of their particular application).  It is equally likely that they would adapt some aspect of the current application so that they can use an existing component from the enterprise repository.  

At the application level they are free, and strongly encouraged, to choose based on the most expedient and appropriate way to deliver their application.  Application architecture simply doesn’t have the luxury of creating and managing highly reusable components.  Time pressures, shifting customer requirements, and limited funding drive choice.  It is the burden of the enterprise architecture to make compliance something that applications will freely choose to do.   If the enterprise architecture (policy, guidance, and binaries) isn’t making it easier the application has every right to ignore it build as they see fit.