One of the built-in features of Drupal that has made it so popular as an enterprise CMS is its support for multi-site installations. Everyone from government to publishing to online communities has taken advantage of this. Drupal's open architecture lets it be extended to support any number of multi-site models. You can run two entirely separate and distinct websites on separate domains, but sharing a common Drupal installation or you can run 'minisites' with unique themes and content beneath a parent site's domain. Alternatively, you can generate uniquely themed expressions of a white-label template site, run closely related sites on geographic subdomains that share content or you can create a sitemill that instantiates subsites with the click of a button.
The issue is not whether you can create a particular type of multi-site platform with Drupal (and by "multi-site" we're not talking specifically about Drupal's native multi-site capabilities - we're talking in general about systems that support multiple sites); rather, the question is how you determine what type of multi-site system you need? This is entirely dependent on the needs of the client. These are some of the factors that will inform your architectural decisions.
Domain, subdomain, or subdirectory? Or all of the above?
If a client needs to enforce corporate indentity across a multitude of platforms they may require that all sites or subsites be subdomains or subdirectories off of a parent domain. In some cases there are particularities specific to the hosting, network, or security environments that may impact Drupal's multi-site capabilities, and which may impact Drupal's ability to use server-side configuration to manage multi-sites on subdomains or separate domains. You may not have access to the server-level config files, and you may be limited to subdirectory multi-site. The environment in which you are operating, and your ability to manipulate and reconfigure it, will dictate the degree to which your platform can express multiple sites.
Will the sites be sharing content?
From the client's point of view, one of the primary reasons to build a multi-site installation is that it allows content to be shared across sites. When you are running dozens of related sites - or even a couple - being able to 'write once, use everywhere' saves your organization time and money, and when there are legal implications to having multiple versions of the same content out of sync - like privacy and other legal policies - content sharing becomes even more attractive. There are a number of ways that content sharing can be built and there are a number of factors that will dictate the form that the sharing will take.
Who maintains the content? If it needs to be centrally edited and maintained, then the multi-site installation will need to be able to silo content permissions by site, and be able to recognize when content originates from a central repository rather than the local site. In this model, local administrators will be able to create and edit content locally, but content served from the central site will be read-only.
Who edits the content? In some cases, the content that is shared needs to be adapted for the local sites. There are several scenarios, and several different solutions. If the content is intended to be a starting point with considerable leeway for customization, then cloning a centrally created 'template' document can work. Alternatively, if the customization is limited to locally-specific variables - the name of a school, for example, or local contact numbers - then inserting tokens into the text to be replaced with pieces of information (or larger chunks of text, including full nodes) is an option.
How does the content get shared? Drupal multi-sites can share tables completely or partially, so fairly robust sharing schemes can be managed using functionality well within Drupal's core capabilities. If a more robust system of central content management is needed - for example, if extremely large amounts of content need to be moved to dozens of sites efficiently - then setting up a central 'feed engine' might be best. In this scenario, a separate application (which may or may not be Drupal) is responsible for aggregating content into feeds that are ingested by the local sites.
One thing to keep in mind is that content sharing schemes can become complicated rather quickly, and tracking edits, versions, and permissions across sites is not to be taken lightly, especially since the client is likely to have some high-level requirements in this area that may be non-negotiable.
What design and layout commonalities exist?
The look and feel of the multi-sites can be managed centrally as well. In many ways, the considerations here are similar to those relating to content. The overall layout and identity may need to be tightly managed to keep them in concordance with the parent organization, but there may be leeway for the local sites to undertake some amount of design customization.
Again, the techniques used will depend on how tightly coupled the local sites are to the central authority. Subsite administrators can be given access to subthemes that are centrally-managed variations on the primary corporate theme. Additionally, contributed or custom modules can be used to allow certain specific customizations, such as colors, usage of imagery, and other defined stylistic and visual aspects of the theme.
How do these sites relate to users and administrators?
Are users siloed within a single subsite, or would they be users of multiple subsites and needing a common signon? Would administrators be responsible for a single site, a collection of sites, or would all sites be centrally managed?
It will be important to establish what the long-term goals are for the platform. The system may not need to be built to support functions that will not needed until later, but because the costs of refactoring the system to support a different multi-site model are high, you should make sure that the architectural choices you make now do not preclude required functions later.