myCoreDump

Introduction

I hope you enjoy this core dump! The thoughts are so interrelated and connected it is difficult to optimize the presentation so you may need to apply your own defragmentation to get it. In addition, the order is not intended to indicate priority, it is all freaking important!

University API (UAPI)

When acquiring or developing an application it must have an API, and preferably a RESTful one. If the function of the application is core to university business then it should be exposed through the UAPI. If it is not a core function of most, if not all, educational institutions, we should expose the API through our API management tools, but it shouldn’t be part of the UAPI.

Personal API (PAPI)

When we build a system that will store personal / individual information we should consider how we might leave the information in the hands or possession of the individual and access it for our use through their personal API. Since no one yet has a personal API, for the time being we must provide that as well. This will require you to stretch your imagination and creativity, but that’s good for you.

Domain-Driven Design

Everyone should read at least the first two chapters of the book Implementing Domain-Driven Design by Vaughn Vernon! The super short summary – bring domain experts and developers together to create a ubiquitous language that is embedded in the code itself. In addition, define or determine bounded contexts wherein this language is valid. Without this you won’t understand how we’re going to build solutions and you won’t have a clue what is in and what is not in a microservice. Read it!

Microservices

Microservices are an architectural style that will be used at BYU to create larger systems. Systems built using microservices are loosely coupled, I would even go as far as saying they are highly decoupled, they implement a single business capability, they have well defined interfaces, and communicate using only these interfaces. The size of a microservice is governed by the size of the associated bounded context, go and read the DDD book! At BYU an important 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 have to 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 go read the links again.

Application Acquisition

When we purchase applications we should give preference, strong preference, to those that run in the cloud. In fact, before we choose an application that is not available as a service choose someone in your group you don’t love and care about to come get my approval.

When we build services or applications they will run at Amazon and use the most abstract service offerings that make sense. In other words, we should not instantiate EC2 servers and S3 storage and then build queues, notification services, etc., but instead should use services such as SQS, SNS, Lambda Functions, etc.

DevOps

DevOps is a culture and practice that we hope will result in the rapid development, testing, and deployment of software. We are measuring the number of deployments / week, failures / week, and time to recovery. We are promoting small changes, thorough automated testing, and deployment to production often. Your team (the DDD team) is in charge and responsible for the functionality, performance, and reliability of “your” product. 

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

Where to Compute

In the past we built data centers and populated them with servers, storage systems, and network components. 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, it is time for another paradigm shift. We are now embarking on a journey that will result in our compute and storage being somewhere else. We will take advantage of Amazon to deliver what our applications and services need to run. Acquired applications will also run in the “cloud”. in either case they will not be housed here. Resources used previously to purchase servers and storage, and maintain them will be redirected to this new endeavor.

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 figure out what went wrong in the configuration script, you repair the script, you test the script, and you redeploy. Remember, we’ll be watching how often you deploy, how many failures occur, and how long it takes to recover.

The days of hugging these devices are over. If you want one to hug, you can have one of the old ones and keep it in your office – disconnected from the network of course.

Domain of Ones Own (DoOO)

As we embark on this new path it is a great time for you to consider contributing to the content of the Internet. Let your light so shine by getting a domain of your own and sharing your goodness and skills with others. get one at domains.byu.edu. Here you can blog your greatest thoughts, post content that you syndicate to Facebook, Twitter or other services. Go learn, learning is fun!

We are offering this service to all students because we believe they should understand more about how the Internet works. We believe they have much to offer the world and they need to know they can share it with little help from service providers. What they build is transportable to other hosting services and is theirs! In the future a DoOO will enable an individual to have a portfolio and expose this and much more through their personal API (PAPI).

Final Thoughts – For Now!

We have a great team! Let’s pursue all of this FUN with the greatest enthusiasm and Heaven will shine down on us. 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, participate on panels. In short, learn, teach one another, and teach the world!

myDoorbell: A Learning Adventure

Introduction

After being a university chief information officer (CIO) for more than a decade, I decided to refresh my technical skills acquired through formal education and practice as an electrical engineer. I learn best by doing, so I picked a project I was interested in pursuing with the end goal being the learning, and not the finished product. I intend to share several posts that I hope illustrate the things learned and hope they are of value to the reader.

My Project

I have interest in the Internet of Things (IoT) movement and wanted to make strides towards making this practical, simple, and secure. I believe connected devices should be simple and consume little power. This likely requires devices that wake periodically, connect to some sort of network, and then go back to a low power state. After some experimentation it was clear, at the time, that WiFi was a real power hog and wasn’t a likely candidate. However, this realization led me to believe that another router, hub, or coordinator device would be necessary. I recall the effort required to convince homeowners to acquire WiFi routers and looked for an approach that would make this palatable.

I decided the answer was to create a product that homeowners would want to purchase because it excited them, and by the way it contained a network router / coordinator. Once acquired on its own merits, the product would facilitate the inexpensive and simple acquisition of other devices that connect to it. Products worth considering would be interesting to households and would connect to household power:

  • Lamps
  • Televisions or other audio / video (AV) equipment
  • Thermostats
  • Doorbells

Lamps seem simple and boring. However, after implementing my first choice, I know I should have chosen a lamp because it would have been boring, simple, and done! I decided embedding anything in televisions or other AV equipment would require skills and resources I didn’t have. Nest took the thermostat direction and while I disagree on the approach of putting so much technology in a tightly coupled system, I didn’t want everyone to judge my work against a commercially available product. I chose to implement a doorbell because they are ubiquitous, simple and meet my requirements:

  • They are in nearly every U.S. household.
  • Power is available where the indoor ringer is found.
  • They do one thing and no one cares if they do anything else.
  • They are in a good physical location for a network router.
  • They are out of the way, aren’t moved, never unplugged, or inadvertently reconfigured.

I chose to create a doorbell that would function as a replacement doorbell, would act as an IoT network router, and connect this network to the Internet by also connecting to an existing WiFi network. A quick trip to Home Depot revealed that an inexpensive doorbell cost about $13. Even with no experience in product development, I knew I wasn’t going to be able to build a doorbell that also acted as an IoT to WiFi gateway for $13. To be compelling enough to get households to acquire my doorbell it would have to be feature rich:

  • This doorbell would play ringtones uploaded by the user to celebrate seasons, holidays, birthdays, etc.
  • Each time someone rings this doorbell the time and date should be logged.
  • The owner can configure the bell to text them when someone rings.
  • The bell should be easily configured not to make noise when babies are sleeping, pets shouldn’t be disturbed, or the owner just doesn’t want to know you’re there.
  • When the bell is rung it should be configurable to access other Web resources such as APIs, webhooks, etc.
  • The system should be controlled and configured using a mobile app.
  • The doorbell must be a simple replacement of the original doorbell ringer.

While these features increase the likelihood of making it compelling enough to overcome the necessary price point, it certainly eliminates any chance of it being simple.

Summary

In this post I declared my intent to refresh my technical skills through the development of an IoT product, an amazing doorbell, myDoorbell. In the next few posts I will describe how a typical doorbell works, illustrate the general system layout for this new doorbell, describe how to create it so it fits into existing doorbell systems, and discuss many details of the techniques and technologies that make this possible. It will be a fun journey with many twists and turns, but that’s how learning happens!

Domains, Personal APIs, and Portfolios

Introduction

In addition to the traditional educational experience students at Brigham Young University receive, we want them to acquire skills, techniques, and tools that facilitate their current and future learning. We believe students should learn how to control and own their digital identity, content, and personal data. With this goal in mind we have initiated a pilot program using a concept known as Domain of Ones Own. We hope to accomplish several goals using this concept and associated training:

  1. Teach students, faculty, and staff why they should care about owning, controlling, and appropriately sharing their online identity, the content that defines them, and their personal information.
  2. Help individuals understand how to choose a domain name that accurately and professionally represents them to others.
  3. Encourage members of our community to not simply consume, but contribute to the body of knowledge through the use of blogs and social media.
  4. Support individuals in publishing a Personal API (i.e. api.example.com) that allows the owner to authorize others to interact with their personal information and revoke access privileges as desired.
  5. Support students and faculty in creating a portfolio (i.e. api.example.com/portfolio) as part of their Personal API that is owned and maintained by the individual owner, and yet enables the owner to authorize others to consume, contribute to, and evaluate their collection.

Domain of Ones Own

Many members of our community share their pictures, memories, thoughts, insights, and writings on social media sites that are controlled by others. The privacy policies of these sites change over time, access privileges may change, copyright ownership is a concern, and the look and feel desired by the content owner may change without their knowledge, input, or control. Contributors have no control over the amount or type of advertising placed around or even over their content. In many cases they may not be able to easily move their content to other providers, remove content they no longer wish to share, or even pass ownership onto others as desired. We want members of the BYU community to understand that there is a better way.

Consequently, we have chosen to use and teach a concept known as Domain of Ones Own. We first herd about Domain of Ones Own from Jim Groom when he was at the University of Mary Washington. After a visit we were hooked on the idea of freeing our community and using the tool to rethink content ownership, Personal APIs, portfolios, and Learning Management Systems.

Our implementation of a Domain of Ones Own consists of a simple hosted server configured using cPanel and pointed to by the end-user’s chosen domain. We are using the service and tools provided by Reclaim Hosting who provides the tools, hosting, and the process for acquiring domains. With the default, initial configuration domain owners have a blog driven by the Known blogging tool. While this is a great introduction that allows domain owners to contribute immediately, the system is open and can grow as the domain owner’s sophistication increases. The system allows users to set up subdomains, email servers, database servers, and install and run many LAMP stack based applications. The tools and services have been chosen carefully to allow users to move their domain and associated content to other providers easily. Tools were chosen to be immediately useful, provide future flexibility, and help users learn introductory system administration skills that are critical to understanding the world they are in and will inherit.

Domains

We believe every individual should own and control their domain. Choosing an appropriate domain is important. In many cases the domain will be used in a professional capacity for years, perhaps for life. We are creating instructional material, including short video segments, which will give advice on how to choose well. We intend to create these materials in a way that minimizes branding and IP protection so others can easily use them for similar purposes at their institutions.

Personal API and Portfolios

Imagine a world where other sites on the web don’t hold your personal data, but instead request access to the data they need through your Personal API. Perhaps you grant them access to only the portions they actually need and restrict them from others. They use the resources they’ve been authorized to access, perform the business functions you desire, return results, and their access is revoked.

For example, imagine you work for weLovePrivacy.com and it’s payday. The payroll system springs to life and determines how much you should be paid this month. However, it needs to know how much should be withheld for taxes, how much pretax contributions to make, where these should be made, where you want your money deposited, etc. In a traditional system all of this information is centrally held. This centrally held information compels the institution to create systems to enable you to manipulate it, and makes the company liable for any loss of this data. On the other hand, you are depending on the institution safeguarding your personal information and not using it for nefarious purposes, a dangerous assumption.

However, there is a better way. Imagine the payroll system interacts with your Personal API to obtain your social security number, the number of exemptions you are declaring, the name of your 401k vendor, 401k account number, your checking account provider and account number, etc. The institutional system does the computation and disbursements, and your Personal API revokes access to these resources until the next time they are needed. While the institution could store the collected information it may not be in their best interest to do so and could even be released to them with the understanding it is to be used for the sole purpose disclosed to the user.

While it may be a while before ERP administrators are comfortable getting employee data from their personal API, there are plenty of other scenarios where a personal API is useful. Portfolios is an example of such a scenario. An instructor at an institution requests authorization to place assignments into your Personal Portfolio, their request is granted, and the assignments are deposited. You perform learning activities that generate solutions to the assignment, and deposit these in your portfolio. You have authorized the instructor to see them and place their critiques back into your portfolio. Since this is your portfolio it moves with you from one part of your life to another, from one institution to another, etc. It is yours to use and share as you choose.

Summary

It is time for learners to take control of their content, artifacts of education, and personal information. Our desire and intent is to teach these principles to our community and give them the necessary tools. We hope to do so in a way that others can easily use and benefit from.

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 LaneJim GroomPhil 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.

Domain of One’s Own @ BYU

At Brigham Young University we’ve noticed the work at Mary Washington University on the Domain of One’s Own.  I’ve been thinking for some time about providing each of our potential, matriculated and former students with a portfolio where they could deposit their application material before arriving, school work while here, and other contributions to society throughout their lives.

Students could then explicitly permit the institution to access and evaluate their work. They could permit potential employers to view samples of their work, and could interact with others through shared access, etc.

The  MWU Domain of One’s Own initiative may be a great start at such a tool. I love their concept that in addition to a tool to facilitate student learning it also teaches students to take control of their own data and to stake out their own digital identity. In addition to learning traditional college disciplines, they learn to interact and communicate in the virtual online world.

We’re going to learn from these pioneers and bring the knowledge to the students at BYU. This should be an interesting and fun experience.