Higher Education – Page 2

Freedom via Abstraction

At Brigham Young University (BYU) we have been developing a University API to expose the functionality of a reasonably generic educational institution, while consuming a very specific set of underlying technologies. Our generic institution has instructors, students, courses, classes, and locations. These resources and available HTTP methods are being combined to expose acceptable business processes such as registration, adding and dropping classes, etc. We will continue to add resources and appropriate business processes as necessary to meet our institutional needs.

Our intent is to develop future applications by consuming the University API and will encourage others to do the same. We will no longer consume the user interfaces or APIs of underlying systems. This layer of abstraction will enable us to replace the underlying technologies with new technologies that provide similar functionality. Regardless of the tools or technologies used, those consuming the University API will be unaware of the underlying change. This will give the IT organization the freedom to make changes to reduce cost, modularize monolithic applications, move to microservices, etc. without impacting application developers or end users. This will bring them freedom via abstraction.

I’m writing about this today because in my mind this is an important general architectural pattern that should be followed more often. David Wheeler, a British computer scientist, is credited with saying, “All problems in computer science can be solved by another level of indirection, except of course for the problem of too many indirections.” While most often quoted by programmers in discussions about pointers and similar constructs, I think abstraction layers, like the one discussed above, are perfect examples of additional layers of indirection that help us solve problems.

While APIs make this work easier, the approach is more generally applicable. For example, imagine you have an ERP system that is aging and the thought of living through another ERP transition scares you to death, or at least adds one more reason to consider early retirement. Imagine you add a user interface layer between the existing ERP and its users. This could require consuming an API provided by the ERP vendor, wouldn’t that be awesome, or screen scraping or via other less exciting means. When this is complete the new ERP system can be installed and connected to the user interface developed above. The two systems can be brought to a consistent state and the connected user interface can be used to keep them that way. Transaction responses can be compared until you’re confident in the new system. At this point the old ERP system can be retired. You have transitioned to a new ERP system and the users are unaware, that’s success!

There are two main points I think are worth noting. First, an additional layer of abstraction can free an IT organization to make changes without impacting end-users. Second, end-users shouldn’t use the provided user interfaces of institutionally important applications, but rather be provided with screens and applications we develop on top of APIs we control. Installation of a new application is not complete until an API we control is designed and used to create an abstracted user interface that exposes the desired functionality. When applications are installed using this model, they are more easily replaced. Freedom via abstraction!

Techniques for Teaching Others

Over the past several years I have been a member of several executive leadership teams. While in these environments I have witnessed leaders using several interesting techniques to teach others. I share two of these techniques because I believe others can use them successfully.

The first technique was used by an executive to teach his superiors without “teaching” them. Here’s what happened: The executive called me a few days before a meeting that I was unaware of, and asked me ten to fifteen technical and business questions that were within my area of expertise. I answered the questions, the phone call ended, and I felt good about the interaction. A couple of days later I was invited to a meeting with this individual and three others senior to him. After we dispensed with pleasantries, the first executive steered the conversation in the direction of our previous phone call and began asking me the same questions he had asked a few days earlier. I was a bit puzzled, but simply regurgitated what I had said previously. Since the three other executives considered me expert in this area, they nodded, asked a few questions, drew conclusions, and thanked me for helping them better understand. When the meeting ended, the first executive walked me to the elevator and simply stated, “you just witnessed how you teach your superiors without ‘teaching’ them”. I saw that he had gathered the information he needed prior to the meeting, invited the ‘resident expert’ to talk—already knowing what would be said, and used that expert to drive home principles he felt were needed, but which may not have been accepted if they came directly from him. I remember feeling that not only were his superiors taught, but I was masterfully mentored.

The second technique was used by an executive who was senior to the group being taught, but was not their line leader. In this case I was brought in to make a presentation on a topic I was convinced no one in the room was interested in. At the conclusion of my presentation I asked if there were any questions. The executive asked, “Will you tell us the difference between a need and a want?” Well, my assessment of the interest in my presentation was proved correct, but now my mind raced to come up with something useful to say. I spent five to ten minutes describing our organization’s strategic planning process and how it resulted in us filtering the organizational wants down to real needs. The executive responded by letting me know that I did a bad job of answering his question and asked me to try again. I was invited to try two more times, after which I was told to take a seat. I sat, feeling rejected, and believing that I had completely failed the task given me. At that moment my boss put his arm around me and whispered in my ear, “great job”. I was tempted to respond, “what meeting were you in?”, but resisted. The meeting wrapped up and the executive and a peer of his thanked me for the great answers. It turns out that my explanation of the strategic planning process was exactly what the executive wanted. I was used to teach these important principles (in three different ways) to other executives without their line leaders being present or needing to be involved. The others could now adopt the techniques discussed as their own, impress their line leaders, and accomplish the organization’s goals. I was used, but I learned a lot and felt great about it!

These two techniques were effective in these specific cases, but are more generally applicable. I hesitate sharing them because it might make them less effective in my career, but I think sharing them for others to use is worth that risk.

Blog Moved to Domain of One’s Own

At Brigham Young University we are experimenting with and piloting a Domain of One’s Own experience for students, faculty, staff, courses, and who knows what other uses we’ll find. To experience this environment I have chosen to move some of my content to my new blog at kelly.flanagan.io with the associated site being hosted by Reclaim Hosting.

The main focus of this experiment is to educate, encourage, and facilitate students in taking control of their digital identity. Instead of placing their content on social media sites where others drive how their content is displayed, what security policies exist, and how long their content persists, we are hoping to give students a place they can call their own and control the way their content is shared with others of their choosing.

However, we also hope to use this environment to implement a personal API for each of our participants. Imagine that when a domain is created and hosted, a subdomain is also created, perhaps api.domain. This URL points to an application implementing an API for the individual. This personal API would have resources pertaining to the individual that would be created, retrieved, updated or deleted using appropriate HTTP methods. These resources would be protected by Oauth, or some other mechanism, allowing the individual the ability to protect their information from others while authorizing those they desire to access it.

In the end, perhaps this sort of architecture will result in institutions, like BYU, not having to hold onto individual personal information, but rather asking students, staff, faculty and others for permission to access the needed information from the individual’s personal API. This would allow individuals to control the use and spread of their information and reduces the amount of personal information the institution needs to protect; as a CIO, I really like that last bit!

There are others working in this area including Kin Lane, Jim Groom, Phil Windley, and others. If you want to participate, learn more, contribute or just listen in, please join us at the next University API and Domains (UAD) conference to be held again in early 2016.