Blackboard can be an overwhelming environment for any user when they first login, and it can be the same for administrators. Many administrators find the Blackboard environment assigned to us with little training and lots of documents to read. When family and friends ask me what Blackboard is, I normally compare the software to a virtual community. We as administrators play dog catcher, city plumber, master planner, police officer, garbage collector, fire fighter, and even the mayor. With all these different hats that we wear, it's time that we spend time learning more about how we can improve the ways in which we serve our virtual community.
In this chapter we will work to become familiar and comfortable with what Blackboard is and how we are going to set up our new Blackboard Learn instance.
Blackboard Learn is an enterprise-level learning management system similar to other products such as Desire2Learn, Canvas, Moodle, and Sakai. The software uses web tools to create content-based web pages that allow for a secure online environment for users to complete training or courses via the internet. Many organizations use Blackboard Learn for government entities, private companies, along with K12 and higher educational institutions.
Over the past few years, Blackboard has acquired many competitors including WebCT and Angel Learning. While both these product lines may be used within some organizations, Blackboard plans to end these product lines. We will spend this book concentrating on the product line entitled Blackboard Learn which combines Blackboard's WebCT line and the Blackboard Academic Suite line.
The heart of Blackboard Learn is made up of multiple components. When installed on the Windows operating system, Blackboard uses the IIS web server. While on Linux and Solaris, Blackboard uses the Apache web server. Apart from the web servers, Blackboard Learn runs its own version of Tomcat, a web container that uses Blackboard's servlets to dynamically create web pages (called JavaServer Pages or .JSP files) to deliver course content and complete tasks. Tomcat creates these pages by accessing information stored within a database.
Blackboard also includes a collaboration server. This server creates a text-based environment which allows interaction between users in a basic form. Most administrators will initially have the collaboration server run beside Tomcat, however it can be installed to run on a separate server.
Blackboard Learn's databases run within Microsoft SQL or Oracle depending on some internal factors, such as if our organization contains a majority of Windows, Linux, or Solaris servers, database administrator experience, or application cost and support. The specific versions required by our Blackboard instance can be found in the release notes that accompany the Blackboard Learn installer. Each Blackboard Learn version may change what operating system and database application it supports.
Earlier we used the example of a community, having good streets along with enough power and water will allow a community to support many residents. In this case, we need to examine the hardware and software requirements along with the different architecture options for our Blackboard Learn instance or virtual community. After we review our options, we can create a decision diagram that can help us decide what architecture options are right for our plans.
A one server architecture is the simplest installation of Blackboard Learn for an organization. A one server instance means that your database, application, and collaboration servers all reside on the same server.
This can be a great option if we only have a few classes and a limited number of users. It's also ideal if you don't expect increased class or user growth in the near future. Many small organizations or developers use a one server architecture.
The drawback of a one server instance is the one point of failure. If any hardware or software issues occur, the Blackboard Learn environment is down for users. This environment also creates issues when your organization needs to expand their environment for growing users and course offerings. If the instance grows too big for the hardware and software it operates on, then it will require a move that will bring more server downtime. More downtime means users' work and course development is delayed.
A two server architecture is very similar to a one server, however the database has moved to a new server. This allows our server to use more processor time on Tomcat and our IIS or Apache server. The issues we brought up earlier in a one server architecture still remain the same.
A multiple server instance offers the best starting point for any organization. Multiple servers split Blackboard services into a server for our database, multiple servers host our Tomcat and IIS or Apache servers, and even a server that hosts our collaboration server. This architecture requires additional hardware. All the servers will need to put course and user files in one central location for every server to have access. We can accomplish this with the use of a network storage device or SAN.
This design also requires a load balancer to be added as well. It creates a single point of access, so when our user types
http://blackboard.myorganization.com into their browser, the load balancer will direct the response to one of our application servers, bbapp1, bbapp2, or bbapp3.
Most Blackboard administrators would recommend an organization with plans to expand users and course offerings to implement this type of instance. When the organization grows, additional application servers can be added to meet increased load with little effect on the experience of our users. The diagram below offers us a view of how a two server instance can grow into a much larger instance:
While the multiple server structure does allow the easy expansion of Blackboard Learn, it doesn't completely address issues with a single point of failure. If the database server or storage device fails, the system will be down. Some organizations may turn to adding another database server or additional backup storage devices. We will address planning for a disaster and disaster recovery in Chapter 12, Logs, Troubleshooting, and Disaster Recovery in Blackboard Learn.
While Blackboard Learn instances can be created using different types of configurations, the one thing we should also examine would be where those configurations thrive. When we think of any web service, we think of servers in a rack that do one or two different things. However, with the increase in hardware loads and costs, many organizations are looking to use the latest technology options to meet their needs and stretch their budgets.
The first option that many organizations use would be virtual servers. These software created servers reside on a hardware server; however, multiple virtual servers can be on one hardware server. This option allows for the maximum use of purchased hardware to meet the needs of the organization. Blackboard Inc. does support the installation of its product on virtual server software. The two main manufacturers are VMWare and Microsoft's Hyper V.
While most of the organizations I have worked with have used some type of virtualization, we may need to convince administration to use virtual servers. One of the biggest reasons I have shared with administrators is the ease of duplicating the server and the ability to bring the system back up. When built correctly, you can bring a virtual server back up in another location within minutes instead of hours. While we won't cover the installation and setup of virtual servers in our discussions, it is important that we understand that it is an option when planning our Blackboard Learn architecture.
Blackboard does offer managed hosting for clients. This service has Blackboard's engineering teams to take care of your instance. However, according to some clients, the service does limit the amount of control administrators have to the backend.
Now that we reviewed the types of instances and options for our Blackboard Learn instance, let's discuss what instance we should build. If we currently are looking to have a small user pilot to test our Blackboard Learn, we can start with a single server instance that can make it easy for us to collect helpful data on how instructors and students will use Blackboard Learn. If we are migrating from another LMS product, we can use course and user storage amounts, user activity, or any other data to provide additional insight.
In Chapter 9, Security, Reporting, and Configuration in Blackboard Learn we discuss the collection of different types of data to improve the performance of our Blackboard Learn environment and the use of the
BbStats tool that can greatly help collect data from within a Blackboard Learn pilot. When collecting our data we should work to find the averages based on multiple weeks when our environment has peak usage.
If Blackboard Learn is replacing another learning management system (or LMS), and how many users were there in the previous LMS?
How many users do we expect will be in the LMS three years in the future?
Now we should look at course growth:
How many courses will be on this instance?
Will Blackboard Learn be only used for online courses or both online and supplementing face-to-face?
If we are moving from another LMS, how much disk space did an average course use?
Will instructors actively use the tools within Blackboard Learn?
Do we plan to allow video and multimedia files?
Will our instance also host the organization's internal committee and communication groups along with courses?
How quickly will your organization be developing new courses and how many will there be in three years?
Then we look at what requirements come from your IT department:
How mission critical is Blackboard Learn to the organization?
How much has the IT department/organization budgeted for a Blackboard Learn implementation?
Now that we have covered all these questions and hopefully collected some data from our previous LMS or pilot project, let's look at some tables to help us analyze our information:
This table will help us review the current data sets that we have. Based on that information we can understand what type of instance we currently need. The first row, Current Active Users, compares the number of users who have logged into our system or we expect to login to our system over a 90 day period. The second row looks at the combined file storage for course and user files. These files are normally associated with courses and student submitted content within them. Our third row discusses the growth or adoption rate over the next five years of the Blackboard Learn environment.
The next two rows review the number of courses created and kept on the system for an instructional term and how long these courses are kept within our environment. Some courses may never go away or some institutions create new ones each term. Our course retention normally follows a set institutional policy. The next row asks about the use of Blackboard Learn's assessment tool with face-to-face or on campus courses. The assessment tool is the heaviest process on our Blackboard Learn environment. If the tool is used to give an assessment to over 50 students at once in a lab setting, our architecture may create an unacceptable experience for users. Now let's review the broader questions we mentioned earlier by using this table:
While our first table reviewed the current data we have, our discussion here is about the expected use and growth. Select answers to the questions in our form. If most of them are classified in the Small and Stable or Large and Stable columns, our environment will probably not see any growth so planning for expanding the Blackboard Learn instance is not a high priority. Our organization might look at a one or two server instance due to this fact. If most of our selections are within the Small and Growing or Large and Growing columns we will want to plan for some expansion and may want initially implement a multiple server architecture that will allow for the addition of application servers when needed.
While deciding the architecture of the Blackboard Learn environment for our organization we have many variables like server types, processors, memory, and organizational budgets. Even with these variables, this discussion should offer some clarity. In Chapter 9, Security, Reporting, and Configuration in Blackboard Learn we will learn how to improve the current architecture by tuning the Blackboard Learn, Apache or IIS, and Tomcat settings to get the most out of our architecture.
In this chapter, our initial discussion introduced us to Blackboard Learn and gave us a broad overview of its components. We also discussed planning the architecture of a Blackboard Learn instance. We can build our instance on one, two, or multiple server architectures. These servers can be hardware based, virtual, or even in the cloud. When we plan to create a Blackboard Learn instance, we must look at multiple factors around our organization including its use, the number of users, and how it may grow in the future. Once we create a plan on what type of instance we need to build, the creation of our Blackboard Learn instance can begin.
Our next chapter takes the planning we have done for our virtual community and puts it into motion. We will learn how to install Blackboard Learn and how to prepare our server or servers for it. Our discussions will also address how to upgrade and patch our instance to fix problems or security issues. Our construction team has been given the green light. Let's get to it!