What is the emerging competency-driven technology ecosystem? Why does it matter for CBE?

Guest post by Gary Gilbert, Software Architect at Unicon.

On a given campus, a technology architecture supports the day to day systems and applications that are used to support student learning and engagement. Also known as technology infrastructure, some form of technology architecture exists at each institution and has become essential for implementing a CBE program.

While there is not a “typical” CBE technical architecture yet, one way to understand this infrastructure is to group technology systems into buckets. For a CBE technical architecture, you could think of the buckets as: 1) foundational systems, 2) systems that support teaching and learning, 3) systems that support skills evidence, and 4) systems that map skills evidence to the workforce. There is, of course, some fuzziness as some systems may overlap groups. Nor do the buckets imply any kind of roadmap or timeline. Just think of the buckets as a way to group like systems with some priority given to the foundational systems.

Let’s start with a few things we know about existing technology:

• No complete CBE technical solution is available on the market. Partial solutions exist and complete solutions may be coming, but, at least today, a comprehensive solution will need to be pieced together via integration. Therefore, technology choices must be modular and interoperable.
• Traditional technical architecture design considerations like extensibility, maintainability, security, and cost still apply.
• Data will be critical to the success of the program. You’ll need to have a well-formed data strategy, and a robust data infrastructure, and your technology choices must align with the data infrastructure vision.
• Systems set up for traditional courses use credit hours and time-bound sessions, while competency-based courses use competencies and are unbound, time-wise. The transition to CBE will be a long-term, multi-phase endeavor for most institutions. This is especially true for institutions that are attempting to run CBE programs alongside traditional programs, as the systems that support traditional courses do not easily accommodate competency-based courses.

Just like there is no one “right’’ analogy for a CBE-focused technical architecture, there is no one “right” way to construct technical architecture for CBE program delivery. Like any system, expect the technical architecture to evolve to fit the changing needs of the CBE program. With that said, here are some core tenets to consider when putting together your technical architecture:

• Think of the technical architecture as a long-term effort (years not months) that you can break up into phases. Focus on the foundational systems first as they are critical to success, and are much more difficult to replace.
• Look for solutions that can fill multiple functional roles within the architecture. These types of comprehensive solutions can be implemented more rapidly and will likely have a lower overall cost of ownership.
• Interoperability is critical. Look for solutions that support standards so that you can swap components without the need for costly, one-off integrations.

To learn more and discuss, we hope you join us on Tuesday, September 27 for the CBE Huddle focused on technology. You can register at cbenetwork.org.

— —

Gary Gilbert is a Software Architect at Unicon (www.unicon.net). Gary has 20 years of professional software design and development experience with an emphasis on standards-based systems integration, learning analytics, and cloud development. He is particularly interested in the intersection of open learning technology standards and open educational resources.