Introduction

Utah Valley University is digitally transforming. The faculty and staff are excited about the possibilities and are envisioning a better future for our students. Students should expect our transformation to yield richer experiences, enhanced learning activities, increased skill acquisition, and a less burdensome path to completion and success. Our faculty and staff should experience less administrative burden, allowing them to provide exceptional care, exceptional accountability, and exceptional results to our students and one another.

To facilitate digital transformation, the Office of Information Technology (OIT) and Academic and Student Digital Services (ASDS) must also transform. They must provide reliable and easy-to-use technology solutions that faculty and staff can use to enhance their interactions with others and improve the products and services they deliver. OIT and ASDS must adapt, modernize, provide existing products and services at a reduced cost, and provide new products and services with exceptional customer service. In general, products and services should be available 24/7 via self-service, and ample support should be offered to make technology consumers successful, satisfied, and even delighted. The remainder of this article describes architectures, principles, and philosophies intended to make these necessary changes and the dream described above possible.

Application Programming Interfaces

Application programming interfaces (APIs) make it easier for others to interact with applications, create and use alternative user interfaces, and use the available services for alternative and even unexpected purposes. When acquiring or developing an application, it must have an API, and preferably a RESTful one. Data, services, and processes needed to build an application are used to create an API. The resulting API is then consumed to deliver a user experience. Mashup Corporation by Andy Mulholland et al. is a short fictional read that illustrates these concepts and the enabling power of APIs.

To make them the most valuable, APIs must be exposed and consumed through API management tools. APIs should be more than simple JSON-based CRUD interfaces; APIs should expose appropriate business logic so that API consumers cannot violate required business processes. Enforcing this principle allows others to build delightful user experiences without institutional concern about policy, practice, or process compliance.

Domain-Driven Design

Everyone should read at least the first two chapters of the book Implementing Domain-Driven Design by Vaughn Vernon! Here is my super-short summary of domain-driven design (DDD) and those chapters: bring domain experts and developers together to create a ubiquitous language embedded in the application code itself. In addition, define or determine bounded contexts wherein this language is valid. This exercise helps software developers genuinely understand the business processes they are being asked to automate. It also helps the business participants understand the code being written and allows them to question decisions, test assumptions, and find bugs before deployment. This collaborative group of business leaders and developers is “the team;” success or failure is in their hands.

Microservices

Microservices are an architectural style that will be used at UVU to create larger systems. Systems built using microservices are loosely coupled; I would even go as far as saying they are highly decoupled, implement a single business capability, have well-defined interfaces, and communicate using only these interfaces. The size of a microservice is governed by the associated bounded context. Go and read the DDD book! At UVU, an essential part of a microservices’ interface is its ability to raise events. Go figure out why.

Event-Driven Architecture (EDA)

Systems that poll are inefficient! Build systems that raise events so other systems don’t have to waste time and resources. You can keep asking me if you must do this, but you can be assured that when I change my mind, I’ll let you know. If you didn’t find the humor in the last sentence, then reread the links.

Application Acquisition

When we purchase applications, we should give a strong preference to those running in the cloud. When we build services or applications, they should use the most abstract service offerings that make sense. In other words, we should not instantiate servers and consume storage and then build queues, notification services, etc. We should instead use services such as queues, notification systems, serverless functions, etc.

DevOps

DevOps is a culture and practice that we hope will result in rapid development, testing, and software deployment. We also hope this increases accountability by allowing those who develop an application to be responsible for running and supporting it. Nothing motivates a developer to fix a bug more than to wake them to fix it repeatedly. DDD teams are in charge and responsible for the functionality, performance, and reliability of “their” products.

If those in the hardware world think you’re off the hook, think again. Software is eating the world. The days of interacting with network switches, routers, firewalls, servers, storage appliances, AV equipment, etc., are over. Learn to program, learn to configure hardware devices using programs. Remember to use DevOps principles to configure, test, and deploy hardware platforms as rapidly as “other” developers—that’s right, you just became developers!

Where to Compute

We built data centers and populated them with servers, storage systems, and network components in the past. As CPU performance increased, computers became more able to run multiple applications, but stability due to unintentional application interaction made this approach intolerable.
We found ourselves with many underutilized servers running single applications to maintain reliability. Along came server virtualization enabling us to instantiate multiple virtual servers on each physical server. Over the past several years, the number of physical servers has diminished considerably.
Well, we’re in the middle of another paradigm shift. We are continuing our journey that will result in our compute and storage being somewhere else. Acquired applications will also run in the “cloud.” in either case, they will not be housed here.

Networks

Unlike server and storage, I believe we will have a wired and wireless network on campus for the foreseeable future. However, the way we deploy, configure, and maintain these networks will change drastically. Remember, software is eating the world, and networking is not an exception to the rule. Network components will be physically installed in some generic way and then configured remotely via software. In a DevOps fashion, when a problem occurs, you’ll figure out what went wrong in the configuration script, you’ll repair the script, you’ll test the script, and you’ll redeploy.

Final Thoughts—For Now!

We have a great team! Let’s pursue all this FUN with great enthusiasm. Let us share our best thinking with others: share code on GitHub, answer questions on StackOverflow, blog about your experiences, publish papers, present at conferences, and participate in panel discussions. In short: learn, teach one another, and teach the world!

 

Around six years ago, we launched the first mobile app. Since its creation, the ideas and expectations surrounding the mobile app's purpose and functionality have rapidly evolved. The old app doesn't solve current students' problems or meet their needs effectively. In many respects, it is a glorified link farm; instead of letting customers complete actions natively in the app, it simply offers a link that points to another system. For example, you can go to the app to register for classes, but all it does is redirect to Banner Registration (not exactly a delightful experience). With all the redirecting to additional systems – many of which are not mobile-friendly – the overall experience was lacking. In essence, the old app has minimal functionality, and in most cases, the functions it does have aren't native to the app.

Ultimately, the old app came up short of expectations in enough ways that very few people used it, let alone knew about it. Over time, concerns about the app began to boil up to UVU's administration. When President Tuminez arrived at UVU, she and her administration agreed that it was time to create a new student app.

President Tuminez approached Kelly, Christina, and Troy almost upon their arrival and gave them the task of creating a new mobile app. It was first overseen by Troy, who began envisioning and planning what the mobile app should be. However, once Digital Transformation was reorganized into two divisions, Christina took on the project. Under her guidance, Web Development Services accepted the mission to create the new mobile app to be released during UVU's 2021 fall semester.

We officially started with ideas and wireframes in late November 2020. Because our WDS team had not been focused in the mobile app development arena and facing such a tight delivery timeline, Dx leaders allocated funding and resources for us to partner with a vendor. By the time the holiday break arrived in December, we had locked in SolutionStream as our vendor, and by January 1, 2021, the "real" work began.

Since then, SolutionStream and our development team have been architecting, designing, and developing this app side by side. SolutionStream is doing a phenomenal job with coaching and guiding us, and our developers are rapidly learning the mechanisms and protocols of building a mobile app. We greatly value this mentorship opportunity, but all good things must come to an end, and we expect to start to minimize our vendor involvement at or soon after the end of the year.

There will be alpha- and beta-tests performed during the summer prior to the inaugural release in late September. This initial version will focus on the essential pieces needed for students to progress and succeed at UVU. To do this, we identified the most critical functions that students need a mobile digital platform to perform natively, namely: registering for classes, viewing events, receiving notifications, paying tuition, completing enrollment tasks, obtaining financial aid, accessing Canvas, and building advisor connections.

Take the registration process, for example. We don't want to just replicate Banner; we want to rebuild the registration process as a mobile experience, giving students the ability to register for classes natively in the app. Before a student's priority registration becomes active, the app will allow students to select their classes and save them in a planner. That way, when it comes time to register, they can click one button and instantly register for all their classes. How delightful!

Through the app, we want students to be able to:

• communicate easily with advisors and schedule appointments
• view all enrollment tasks and complete them (everything from clearing holds to getting a parking pass)
• connect to all academic curricula (e.g., see an updated class schedule and access Canvas for each class)
• access financial aid information (eventually apply for scholarships too)
• view their outstanding tuition balance with a specific breakdown of why that amount is owed (eventually maintain their GreenBucks account as well)
• pay tuition through the app (eventually parking passes, books, and all other University-related expenses)
• receive targeted push notifications on key issues (e.g., messages relating to registration and waitlisted classes, emergency alerts, payments, or important deadlines)
• authenticate against the new student login system
• login through Microsoft Azure AD once per semester and then use biometrics, facial recognition, fingerprints, or a pin to unlock the app each time

As extensive as this list is, it still does not fully capture all of what we are attempting to execute. It is a recurring joke among the development team that the only thing missing from the mobile app is a daily dad joke module.

Our long-term vision is for the app to evolve into a highly intuitive, hyper-personalized, digital assistant to facilitate student, faculty, and staff success. Joe Belnap has been designated as the “curator of possibilities” coordinating an architectural roadmap for this evolution. Over time, it will be voice-activated and become more sophisticated and broaden out its uses, possibly helping to give advice on admissions, tuition fees, accommodation & dining queries, health & wellbeing, parking & travel options, and even employment. The future – within reason – is limitless.

Not all of the features listed above will be available in September's iteration of the mobile app. After all, with so many improvements and possibilities to choose from, we can't do everything at once. However, all new ideas and requests are being noted and strategically integrated into a future release roadmap for the app. For example, a near future iteration will allow customers to customize push notifications. As new features are ready, they will be bundled into a regularly scheduled release. With all of the effort being put into this app, rest assured that we are also working closely with Marketing/Studios & Broadcast Services to put together a promotional video to introduce the app to students and the campus in general. We are certain that, once deployed, the new app will provide delightful experiences to every student each day.

 

Introduction

In many circles within Dx, we cooperate on tasks or conduct meetings "asynchronously" (sometimes we use the terms "digitally" or "electronically" instead). I think we all have a basic idea of what asynchronous communication means, but I don't think we have a Dx-wide understanding of how we can use it to increase our productivity.

The Problem

I always find it interesting to see what happens when we choose or are asked to make asynchronous communication (async) the primary mode of conducting business that we've previously done synchronously. It's almost as though we were told to stop working or collaborating on that topic altogether. I think we want to do async right, but we don't have the proper culture, systems, processes, and expectations in place to make it as efficient as it could be. If I were to count the number of async channels I try to keep track of every single day, the sum would easily number in the hundreds. The fact is, we are all busy, and trying to respond to every message across the myriad forms of async we have can be completely overwhelming. It's extremely easy to miss a message completely or to lose track of a message you intended to answer "when you have time to respond more thoughtfully." Nobody wants to be a flake, but it's hard to take care of everything when everything is coming at you from so many directions.

What is Asynchronous Communication?

I couldn't think of a better way to describe this than what I found here: https://blog.doist.com/asynchronous-communication/

"Simply put, asynchronous communication is when you send a message without expecting an immediate response. For example, you send an email. I open and respond to the email several hours later.

"In contrast, synchronous communication is when you send a message and the recipient processes the information and responds immediately. In-person communication, like meetings, are examples of purely synchronous communication. You say something, I receive the information as you say it, and respond to the information right away.

"But digital forms of communication, like real-time chat messaging, can be synchronous too. You send a message, I get a notification and open up [Teams] to read the message and respond to what you said in near real-time. Even email is treated largely as a synchronous form of communication."

The Benefits of Asynchronous Communication

If you Google "benefits of asynchronous communication" (which you should), you'll get page after page of content trying to convince you that async will improve your life. Here's just a few of the results to whet your appetite, assuming that the culture, systems, processes, and expectations are all in place to allow them.

• Time to think before responding
• Periods of time to ignore communications and do deep, focused work
• Control over the workday

Making Async Work

I mentioned above that the culture, systems, processes, and expectations must align to make async most effective. Let's talk about these requirements.

Culture

We can claim all we want that async is our strategy. Well, as Peter Drucker says, "Culture eats strategy for breakfast!" If our culture remains one where we have to meet face to face (even virtually) to make decisions or move forward on an initiative, our culture will not support healthy async.

So how do we change our culture? That change is underway! In their book School Culture Rewired, authors Steve Gruenert and Todd Whitaker explain, "The culture of any organization is shaped by the worst behavior the leader is willing to tolerate." Our new leadership expects us to work asynchronously by default, switching to synchronous only when it makes sense. Are we ready to follow along?

Systems/Processes

As a technology organization, we often think of systems only from the perspective of the technology they are implemented in. But the basis of all technology systems is processes and frameworks that define how things (especially people) work together. The processes we design (and improve over time) come first. If we limit our systems and processes to those we inherit when we implement a technology, we lose our ability to find efficiencies in the ways we work.

We have plenty of technology. With Teams, Email, JSM, and the like, we are up to our eyeballs in async technology. But is it helping us to gain the benefits I listed above? Sometimes, yes. Sometimes, no! The systems and processes I want us to focus on are not the technologies; they are the "social" interactions that compose our systems for getting things done. Sure, I can send a Teams message or submit a JSM ticket, but if our "social" system doesn't define how we handle those, we don't really have a system, do we?

Like with culture, I think we are starting to develop these systems and processes. We use terms like service level agreements (SLAs), workflows, and checklists to describe how we handle some of the things that come at us every day. A lot of these systems are being developed—but many are not yet even under development!

Expectations

I see expectations as an essential part of the systems and processes that we develop. Likewise, I see them as part of the culture we create and work within.

What kinds of expectations should we have? Too many to write here! Here are a few to think about:

• When do I expect to receive a response to my email? To my Teams message? To a JSM request?
• What form of response should I expect after requesting something via JSM?
• Are my responses expected to be formal or informal?

We developed some of these expectations over time. In fact, we developed a few in the last year. For example, in early 2020, we published the UVU IT Meeting Manifesto and the UVU IT Guide to Virtual Meetings as expectations for those in IT at the time. COVID-19 changed our world and, with it, many of our expectations. I think it's time to start defining expectations related to how we work now—especially around async. Some things should be done synchronously, and some things should be done asynchronously. We can collaborate via either method. Let's define what fits in each category.

Responsibility for Async

I believe there are multiple levels of responsibility for doing async right. Each organization and each individual has a part in this. Async is not unique to remote work. It applies to people who work centrally, too. We will be in a hybrid environment for the rest of our careers, so we need to determine now how that should work.

Organizations/Teams

From the top of Dx to the most ad hoc team, each organization has to define the culture, systems, processes, and expectations they will work under. That's optimally done when the org or team initially forms, but if that wasn't done at formation, do it now! Some organizational leaders will define them for everyone. Others, especially teams, can define them democratically or some other way. It doesn't matter how they are defined; the key is to define them so that everyone understands the async environment they all share.

Individuals

Every individual already has a value system that drives how they work in an async environment. Have you figured out what your values are? Don't wait for the org or team to define them for you. What are your expectations for yourself? What are your expectations for others? Are they different for different async methods? If you can't define them, you should; doing so can help you define them for every organization and team you are a part of. That said, be willing to adopt async standards that the org or team has agreed to when we work with that group.

Conclusion

Like it or not, we're in transition toward more asynchronous work. Agile environments like ours are iterating toward perfection. Our current state of async is our MVP (Minimum Viable Product), and we're experimenting and iterating our way to more productive and effective async every day. Don't be afraid to try something new! Experiment with a new method and determine if it adds value; if not, try something else. Let's all work to get better at async communications.

A few years ago, we started introducing a couple of Atlassian products on campus to boost change management and monitoring. Since then, our use of Atlassian products has expanded into service management, and we are utilizing a lot more of Atlassian's product line, including a full ITSM suite. The more Atlassian products that we implement and introduce to the campus, the more complex that environment is becoming and the greater the need for governance to prevent that environment from failing. 

Jim Condie has been asked to provide governance and leadership for all Atlassian products and owners of those products so that we can keep them working smoothly. Troy Martin has commented that Jim is in a challenging role because everyone is his customer and that he will succeed in this role if he can service everyone else instead of himself. Thank you, Jim, for taking on this challenging responsibility!

Through Knowledge Services, there is now a state contract that allows Dx to hire from a list of over 400 different contractors and consultants. These individuals and companies are preapproved to work with us and do not need to go through an additional Request for Proposal (RFP) process. Typically, an RFP process takes months to write a project scope, give that to purchasing, put out a public bid, wait for proposals, review those project proposals, and interview the best candidates. But through the state contract, all of that has been streamlined. 

If anyone in Dx wants to hire a contractor or consultant through the Knowledge Service state contract, contact Eddie Sorensen. He has been walked through the process and is ready and willing to help others use it. Eddie is also currently writing documentation on this process, but until that is finished, here is a fast overview: 

1. Start by writing out the project's scope. The information in the scope of work will be slightly different depending on whether you are hiring an individual contractor or a consulting company.
1. For an individual contractor, a scope of work should include the job definition or description, a list of skills needed, expected duties, and how long the contractor will be needed. 
2. For a consulting company, a scope of work should include what the project criteria are and what milestones you want the company to meet. 
2. From there, send the scope to Knowledge Services. 
3. Knowledge Services will evaluate the scope and send back their highest recommendations from the state contract. 
4. Review Knowledge Services' recommendations and conduct interviews to hire a final candidate.  
5. Send a requisition to purchasing, referencing the state contract with Knowledge Services as the vendor, and attach the scope of work and the name of the consultant or company that you’ve selected.

This state contract makes it a lot easier to augment our workforce and complete the projects with expedited help. When we hit significant peaks of work, let's take advantage of this resource to increase our capacity. 

Tim Stanley, Director of Institutional Research 
Geoff Matthews, Associate Director of Reporting, Analysis, Data Mgmt.

There are times when campus leaders ask broadly stated questions that need to be answered in clearly defined ways. One of these questions is, “Why are women under-represented among our graduates?” 

For 2019-20, 46% of award recipients at UVU were women. On the surface, this appears like a disparity. However, UVU’s Fall 2020 enrollment was 49% female. If you exclude high school students, it is 47% female. If you only count continuing students, 43% of students are women. When you take these enrollment numbers into account, the initial disparity in awards seems less concerning. 

https://www.uvu.edu/ir/performance-indicators/inclusion-diversity/women.html#obj3

The obvious question here is why fewer women are enrolled at UVU. When you look at enrollment by age, it becomes apparent that our younger students are more likely to be women, while our older students are more likely to be men. 56% of students 18-21 are women, but 58% of students 22-24 are men, as are 69% of students 25-29. Women aren’t a majority within an age group until 40-49 (67%), but students that fall within this range are a minority at UVU. In short, the reason for UVU having more men enrolled than women is a function of age.

We have selected WS02’s open source API tool as our first official standard in our middleware infrastructure. Having this as our established standard will make it easier for us create repeatable processes, integrate projects more seamlessly, and maintain integration across our systems moving forward.  

Superb team performance begins with selecting one or two Wildly Important Goals (WIG). Otherwise, teams tend to get lost in the whirlwind of the day-to-day. Most teams have multiple goals and hesitate to narrow their focus. However, we shouldn’t worry about the consequences of choosing the wrong WIG or even whether we fail to achieve it. The reason for narrowing the focus was stated best by one of FranklinCovey’s many clients, “When you work on that many goals, you actually work on none of them, because the amount of energy you can put into each one is so small, it’s meaningless.”

The real challenge is to rank the team goals in terms of impact on the overall organizational WIG(s). Avoid the trap of selecting WIGs that improve the team’s performance but have little to do with achieving the overall WIG.

Perhaps the most important step in the process is to actually test the team’s WIG as follows:

• Is the Team WIG aligned to the overall WIG?  If not, pick another WIG.
• Is it measurable?  If you’re not keeping score, you’re just practicing.
• Who owns the results – our team or some other team?  Your team should own at least 80% of the result.
• Who owns the game – the team or the leader?  A team WIG should depend primarily on what the team does, not just the leader.

Once a team WIG passes this test, you are ready to properly define the WIG. Remember to focus on the What that will be achieved, not the How.