Mission Support

The real value of IT in higher ed lies in its ability to support the institution's core mission--quickly and cost-effectively. 

• By Stephen Laster
• 12/27/11

Supporting business functionality quickly is when a well-rounded IT organization shines. The faculty rely on us to help them translate what they need for teaching and learning into technology solutions that seamlessly weave into the fabric of what they do. They appreciate our skills as integrators and engineers, but what is of most value to them is our ability to translate their needs into creative solutions in a quick, cost-effective manner. It is this role that cements the relationship between faculty leaders and technologists.

A recent project at HBS epitomized the kind of supportive role that IT departments must play if we are to stay relevant and valued on campus. In late 2010, HBS set a new vision: Transform the first year of the MBA curriculum. The focus was on moving learning from the classroom into the real world and then back into the classroom. The goal was to blend the best of case-based learning with in-the-field experiences that would enhance student learning.

As the curriculum design evolved, it became apparent that--from a technical perspective--a standard learning management system (LMS) would not meet all the faculty requirements of this innovative pedagogy. HBS was looking for an LMS, plus a set of interactive collaboration tools to facilitate the extension of the learning experience outside the classroom. These tools were meant to increase student-to-student and faculty-to-student engagement--and were core to the mission of transforming the MBA program. These features included shared video spaces, areas for personal reflection, peer-feedback modules, and collaboration portals to share ideas, discussions, and documents.

In addition, it was critical that all the components of the new system be implemented under single sign-on to create a seamless user experience. It also became clear that the learning environment needed to be highly flexible so it could support new tools and services that might be required as the curriculum design evolved.

Supporting Pedagogical Innovation
The challenge in designing this model, which we call a learning ecosystem, was creating flexibility and choice while preserving uptime and reliability--all core to the needs of the faculty. At a technical level, this meant creating loosely coupled systems to easily support change. We also needed to offer technology that faded into the background so that learning became the focus.

As IT consultants, it is essential for us to build solutions that address the needs and desires of our community. To do that, we first have to understand what those requirements are. At HBS, we build cross-department working groups to establish needs, and meet regularly to review progress, discuss issues, and test solutions. With all major IT projects, our community partners are closely involved from start to finish. This has proved to be an essential part of the rollout process at HBS. Involving faculty and community partners throughout the process ensures expectations are mutually set and there are no surprises.

Working closely with our partners in the MBA program, we were able to build a centralized learning ecosystem in just six months. Based on feedback from faculty and administrators, we knew our approach had to support rapid development, change, and stability. At the same time, we could not compromise several key tenets. Our learning platform, like all solutions at HBS, had to possess the following characteristics:

• Reliability and fault tolerance: Planned downtime is no longer an option. Everyone has become accustomed to anytime availability of the tools they use for work. This becomes even more important given the role of learning technologies on campus. Nothing can interrupt the teaching and learning process.
• Support for a wide range of services/solutions: Our faculty and students use many different tools to teach and learn. The infrastructure has to support all of these, including many high-bandwidth applications that are essential to field-based learning. It is also important that we are prepared to develop and support new tools that might be needed by faculty and students.
• Future-proof flexibility: If the last 10 years have taught us anything, it is that technology innovation is unpredictable. If you do not create flexibility today, you will pay for being brittle tomorrow. Gone are the days of supporting one technology stack or one monolithic solution. It is also no longer realistic to run everything out of your own data center or outsource it all to someone else. For the foreseeable future, we will live in a blended world, where we must determine what mix of internal and external resources will create the most effective infrastructure.

With these tenets in mind, we built a learning ecosystem that would support the changing MBA curriculum and provide a valuable footprint for future projects. Architecturally, we knew that we had to decouple the infrastructure from the learning functionality and that we had to work in a small-system model. To that end, we pushed security, login, data integration, and other shared services into the infrastructure layer. This allowed us to focus on the functionality that students and faculty would experience, and leverage the benefit of shared services as we built, bought, or open sourced discrete features of our ecosystem.

At the core of our architecture is the delivery of single sign-on and consistent enterprise roles. We spent time gaining agreement from our partners on different user roles and what they meant from a business-process perspective. With roles in place, we implemented solutions that give users access to all elements of the learning ecosystem with a single set of login credentials. The user role travels from system to system, and the business rules associated with the user are respected by every feature and solution in the learning ecosystem.

In addition to defining roles and login, we implemented an enterprise data highway (enterprise bus) and defined HBS-specific (system independent) business objects. Using a publisher/subscriber model, we publish business objects from a system of record to consuming systems. For example, each time a faculty member creates a new student team, our solutions for student collaboration and feedback are made aware of it via their subscription to the data highway. This way, each system is aware of the highway but does not have to be aware of the actual publisher. By taking this loosely coupled approach, we positioned ourselves to easily change or swap elements of the ecosystem in response to changes in the pedagogy.

With a flexible, stable infrastructure in place, we were free to focus on what mattered most: the functionality that users need for teaching, learning, and collaboration. The key to providing great functionality is knowing when to buy or open source a solution--and when to build. Rapid development and adaptation are truly a blended approach. To respond quickly and cost-effectively, you should be able to tailor open source solutions instead of resorting to scratch development. This also requires working closely with vendors so that they integrate their solutions into your ecosystem effectively. Lastly, leveraging standards during this process will help you minimize future work.

We chose a commercial LMS and wrapped a set of custom and open source tools around it to support an innovative curriculum. With this loosely coupled architecture and blended infrastructure, we have crafted an adaptable environment for our community. It provides the right level of stability to ensure our campus always has access to the applications and tools it needs, while providing the agility to change and add solutions at a lower overall cost. The result is a learning environment that is true to the needs of our redesigned MBA program and possesses the characteristics we want to employ across all HBS technology services. It is seamless from the perspective of our users, closely aligned with their business needs, and flexible from a technologist's perspective.