Most institutions will, in the end, decide to develop an MLE by integrating a variety of systems  themselves, as have all the Building MLEs in Higher Education projects.  

Indeed, the Building MLEs in Higher Education were set up explicitly to look at the issues of  integrating existing and new systems to create an MLE, so it would be suprising if they had  chosen any other approach.

The reason for this is that all  institutions (except perhaps UfI and  UK eUniversities Worldwide)  have existing systems which cannot be replaced all at once, so an evolutionary approach is  required.  This approach also allows you to buy "best of breed" for each system that you need.  That is, the system which most closely meets your needs.  However, this cannot be done in  isolation as products do not cover identical territory and there is considerable overlap and potential  gaps if the wrong products are chosen.  As John Heap writes in UCISA Update "It's a mild rant ...  about the feature creep of software packages which insist on straying into the territory previously  occupied by others". But while that is a minor problem it is integrating the systems that is the real  issue in building an MLE is ensuring that the various systems and components can work together.

There are two approaches to this.  It can be done in a piecemeal fashion, tackling each set of  systems that need to be integrated, but this is like painting the Forth Bridge, a never ending task  as new systems are replaced and each time the work has to be re-done.  The alternatvie is to  develop an architecture and use a systematic approach to data excahnge.  Thus De Montfort used  an XML based approach building on the work of IMS, while the GIMIS project at is using a variety of  tools and techniques to achieve its integration.