We hear regularly from our Higher Ed CIO clients about the accelerating complexity associated with maintaining legacy applications and IT service delivery processes. Doing this while quickly moving in parallel to support on-line learning platforms, an increasingly mobile student population and a rapidly changing application portfolio is an even greater challenge. (Exhausted yet?)  And by the way, all of this needs to be accomplished with a diminished pool of funding. Now more than ever, you need a structured approach to bring order from complexity. We think the Transformation Roadmap approach works well in these circumstances.

Developing an IT Roadmap that is well aligned with the University’s objectives creates a platform and process for prioritizing objectives, implementing change, assessing the daily barrage of alternative tools, applications, and devices along with emerging  cloud-based platforms and open source applications.  SAI’s approach for Roadmap development (honed over many projects) involves four phases:

  1. Quickly document  existing processes and related technology services
  2. Rationalize the technology stack
  3. Envision required services
  4. Develop IT transformation roadmap

In this blog, we address some key points in the first, “documentation” phase. 

An important starting point for Higher Ed IT teams is to define a common framework or business architecture.  A life cycle view of a typical on-line university and the integration points with IT is captured in the illustration below:

Working within this functional framework, the team will identify and document key processes (not all of them!), particularly those which enable significant student, faculty and staff productivity and those that differentiate the effectiveness of the learning environment. 

For example, the focus may be on increasing candidate student applications or improving the % of conversions from accepted students to enrolled students.  In that case, the team would document the processes within the “Attract/Recruit” and “Application” functions. Activities such as Communicate to Prospective Students, Screen Applicants, Process Applications, will be defined using standard process modeling approaches and notation/tools.  The resulting process diagrams will show both the workflow (with inputs and outputs) and the “services” or functional requirements provided by technology in navigating each process to its goal. 

It’s a good idea to establish your metrics at the front end of the project.  These metrics provide an important baseline of current performance levels.  They also enable you to project, and later measure, the financial and performance benefits of your program.   This will give you the key ingredients for your business case (and for your bragging rights PPT down the road).

There are numerous approaches to process mapping.  The following diagram illustrates one that has worked well for us; simple and to the point.

process mapping diagram

The unique feature of this approach is that it isolates, for each key process, what capabilities your systems give you now and what they need to give you to reach your change goals. Of course the team will stitch together several of these diagrams in covering the scope of the project.  It’s best to document target processes at a high level, resisting the temptation to broaden the functional scope beyond processes critical to the change program.  Laser like focus is critical here.   Avoid the “analysis paralysis” and “boiling the ocean” traps at all cost.

Once you have completed review of your applications and the technology services they provide, the team should continue down the technology stack, documenting the supporting infrastructure platform.  It’s important to complete this step as many important technology-enabled process improvements require “full stack” solutions.  We find that the line between applications and infrastructure is becoming increasingly blurred, especially with the increased use of cloud computing.  Solutions are becoming more holistic.  You can capture the important details of your enabling platform with a simple diagram of system components.  Here’s a reference architecture we use:

reference architecture diagram

If you can reach team consensus around these baseline analyses, you are well positioned to begin the second phase, “rationalize the technology stack.”  In our next blog, we’ll take on this second phase in defining your Transformation Roadmap… stay tuned.