Part 3 of my series on the new IMS Global Learning Consortium’s Learning Information Services specification:

Sometimes standards are needed when there are lots of people making arbitrary decisions.  But how does one judge when they are needed?  Take for example, whether people should eat their bananas stem side up or stem side down.  Different users can argue which way is better for as long as they want – either way, the banana gets eaten.  No standard really needed for that.  (By the way, it turns out that monkeys prefer to eat their bananas stem side down – that way they can hold onto the stem as a handle of sorts…see here for directions )   On the other hand, driving on the same side of the road – now that most would agree is a place where standards are important.   It doesn’t really matter which side people choose, but it IS important that we all make the same decision.  The same could be said of some of the decisions which went into the LIS specification.  We needed everyone to agree on the same convention for things like naming, data model representation and service methods.  If someone had an existing model which provided a good example and could be considered generic, we tried to include it whenever possible.  Similarly, if we had specified service methods or expanded part of the data model which vendors don’t currently have a need to implement, we intentionally removed it from the LIS profile definitions.

So what is the minimum subset of LIS needed for interoperability?  The consensus of the working group was to cover the core LIS use case, which is allowing an authoritative system to publish data about courses, people and enrollments.   Remember that the target or consumer of this type of data could be a Learning Management System, but it could just as easily be a wiki, blog or collaboration environment such as Google Apps.    Similarly, the source system typically would be a Student Information System, but it could also be a combination of systems such as a central Identity Mgmt system plus a master instance of a Learning Management system.   The goal is to establish a low barrier to adoption, while also formulating ways for vendors to achieve higher forms of interoperability at the same time.  This is accomplished through the Core and Addition Profiles for LIS:

• Core: the minimum set of service operations required to allow a source system to publish information about courses, people and enrollments
• Additions:
  • Final Grades – return of the final grades from downstream learning applications
  • Full Course Hierachy – a hierachical representation of the course entity including 3 levels: Course Template, Course Offering and Course Section
  • Combined Sections – representation of an additional Section Association entity, allowing different groupings of Course Sections to exist in the source system and downstream learning applications

The idea is to require vendors to implement the Core profile, with optional Addition profiles.  The Addition profiles can be chosen independently and combined in any way along with Core.  This allows customers to measure degrees of interoperability between vendor implementations, while counting on a minimum level of functionality for publishing course and roster information.

Defined in these concrete terms, vendor adoption can be clearly communicated -  perhaps delivered in phases over time – but more importantly, they can be independently tested for compliance, with certified results posted on the IMS website for the public to comparison shop.  This approach is already in use for standards such as Basic LTI and Common Cartridge.

One example of the benefit of clearly defined specifications and profiles was the work we did recently with Blackboard.   Blackboard’s latest release contains support for SIS integration using the new LIS 2.0 Core Profile specification.  Even though they had developed this implementation independently from our Oracle Student Administration Integration Pack, as soon as we linked up our test environments we were able to send and receive IMS LIS 2.0 messages without any code change on either side.  Furthermore, the testing exercise actually revealed one case in the LIS 2.0 Bulk Data Exchange Service where Oracle and Sungard made different arbitrary decisions, causing Blackboard to receive 2 slightly different bulk files.  This has now been addressed in the base spec by adding enumerated vocabularies.  Previously, this type of issue would have caused customers and vendors to spend countless cycles maintaining separate versions of code to support multiple “so-called” standard integrations.  There is even a IMS specification maintenance process (called the APMG, which stands for Accredited Profile Management Group) forming now to oversee the LIS specification and profile definitions.

So while software implementations can seem like a series of arbitrary decisions, I, for one, am relieved to know there are methods employed by IMS that can be used to clearly define a profile, or a set of profiles – thus ensuring cars or student datasets do not collide on the highway of education applications. 

Possibly Related posts:

1. Important News Regarding Learning Information Services
2. Is “De Jure” Out When It Comes to Software Standards?
3. Can Web Services Improve Student Life?

photo credit: Some rights reserved by dullhunk

It could be that for some, improving student life might mean better methods to obtain pizza – but for others, enabling seamless integration between separate academic systems might be just what many campuses today need.

The IMS Learning Information Services specification is poised to fundamentally improve the cost of integrating systems housing student and academic information for thousands, if not millions of students around the world.

As the co-chair of the LIS project group, I want to share some of my perspectives about the specification and some of the rationale that went into key choices.   Before we go further, however, here are several fundamental principles and concepts behind the LIS specification:

LIS is designed to exist within an ecosystem of loosely coupled systems. Schools today typically run their Student Information System or Learning Management System separately, housed within separate servers and administered by different groups.  Institutions may also have other systems on campus to support different functions supporting their community, i.e., iTunesU, GoogleApps or MyMathLab.  Each individual system may be administered with different schedules for uptime and service level agreements.  This means that core information typically needs to be accessible within a system independent of the availability of another system.

LIS presumes specific systems are designated as the authoritative source for key information. In most cases, for example, the Student Information System would serve as the “source of truth” for information about courses, persons and enrollment.  On the other hand, a downstream Learning Management System may serve as the Outcome source for Final Grades.  This does not preclude multiple sources of student data feeding into one or more learning system – however it is presumed that a given identifier (whether it be for a Person, Course, Enrollment or Outcome) will be associated with one and only one data “source”.

When the LIS project group was chartered back in 2007, the landscape of Enterprise Student System integration was scattered, with widely varying degrees of implementations of the former IMS Enterprise specification.   This included pockets of IMS Enterprise Services implementations throughout the UK, where adoption of the Learner Information Profile (LIP) specification was also slightly more established.   The group felt there was no reason to completely dismantle the existing Person, Group and Membership entities, which had previously been defined by various versions of IMS Enterprise.   Having said that, we knew we need to solve several key problems with the original specification:

• support for the exchange of unambiguously defined hierarchical course structure
• support for loose associations of course sections to allow student systems to maintain grouping constructs separately from downstream learning applications
• support reporting of outcomes information, both assessment item level as well as final grades
• support system bulk exchange/initialization

For services such as Person, we realized there were infinite possibilities to establish a definitive set of attributes, let alone to determine which ones would be considered required or optional.  Therefore, we employed a technique using vocabulary driven “type-value” pairs to define a common framework for Person attributes.  For each attribute “type” (name, address, etc.), a core vocabulary is defined and used to evaluate conformance, however it is recognized that local implementations are free to extend it with region-specific elements, for example.  (This also means that backward compatibility with the previous IMS Enterprise data model is not easily achieved, due to the extensive structural changes made to entities such as Person.)

Based on the primary use cases we set out to solve for Learning Information Services, the following are the resulting 6 services which were defined. As I mentioned, they consist of 3 original (though modified) services, and 3 new services:

• PERSON – refactored from the original IMS Enterprise model; used to represent students, instructors, administrators and other people associated with downstream learning applications.
• GROUP – this was largely retained from the original IMS Enterprise specification.  The GROUP structure is very flexible and can be used to model many different things, from institutions, organizations, academic departments, terms or academic sessions, and non-course groups such as project groups, committees, clubs or other organizations.
• MEMBERSHIP – this was also largely retained from the IMS Enterprise model; used to associate PERSONs with COURSEs or GROUPS.  In addition, a set of roles and subroles can be assigned for a given MEMBERSHIP.
• COURSE – this new structure allows a 3 level hierarchy to be represented for Courses.  At the highest level is the Course Template, which is designed to model a Course typically included in an Institutional Course Catalog.  The Course Template does not have an association with a Term or Academic Session, rather it contains attributes about a Course that hold true for all terms.  The next level down is the Course Offering.  This is where the Academic Session relationship can be established.  It is important to note that the Academic Session object is not itself an LIS entity – rather it is an LIS Best Practice to populate the Academic Session element with a Group SourcedId (where the Group entity is used to house the Academic Session details for that particular term).
• OUTCOME – the new Outcomes service can represent individual assessment items as well as interim or final results.  Specific flags are used within the Outcomes data model to indicate the “type” of Outcome which is represented.  The Outcome model is actually made up of 3 separate entities: Line Item, Result and Result Value.  The Line Item represents the definition of the Assessment – typically, this can be thought of as a column in a Gradebook.  Results for a given LineItem are the actual scores assigned to the Person (Student).  Finally, the Result Value represents the grading scheme used for the Line Item or Result, and can be associated with either or both entities.
• BULK DATA EXCHANGE – this new service is designed to support the bulk exchange of data between 2 or more systems.

Each of these services operates on the entity as described by the information model.   More detail about the definition of the individual LIS service operations will be discussed in upcoming posts.

Possibly Related posts:

1. Important News Regarding Learning Information Services
2. Is “De Jure” Out When It Comes to Software Standards?

• It represents vendors coming together to put a stake in the ground regarding interoperability between Student Information Systems and Learning Management Systems
• It allows authoritative data about courses, students and enrollments to be propagated to downstream learning applications without faculty or student intervention.
• It also makes possible, the return flow of outcomes (final and interim grades), from the learning environment back to the system of record for the student.

As my esteemed former colleague Michael Feldstein outlines in earlier posts starting with this one, vendors and institutions came together to work on v2.0 of Learning Information Services (v1 was formerly known as IMS Enterprise) to solve several significant problems.   This milestone marks the progress of what we set out to achieve: creating a broad base Service Oriented specification for Learning Information, together with narrowed core and addition profiles to meet specific integration use cases for today’s SIS and LMS systems.

And not only does this milestone mark public availability of specification documents (of which there are lots) , but we are also showing progress in real world vendor adoption.  Just a few weeks ago, at the 2011 IMS Learning Impact conference in Long Beach, California, Blackboard demonstrated their new integration capabilities with both Sungard and Oracle.  And while that may seem boring or obvious, the fact that the same integration worked without any additional product code, consulting solution or customization, would not have previously been possible without LIS.

In the next several posts, I will introduce the main concepts of the Learning Information Services specification, and provide a personal perspective from the viewpoint of one who was involved in the working group process.  I encourage you to take a look at several documents as they get posted to the IMS website and post any questions, comments or feedback on the IMS LIS Alliance forum.

Possibly Related posts:

1. Is “De Jure” Out When It Comes to Software Standards?

Over the past decade, software standards moved from the formal process to consortia based standards organizations.  This was especially true for web service standards, where organizations such as W3C and OASIS have emerged as the primary standards forums for web service messaging, reliability, orchestration and security.  Outside the US, the formal standards process was still important, therefore many instances of consortia based specifications were later brought forward to ISO.

In recent years, the proliferation of standards setting organizations has slowed down considerably.  Due to its importance in the global arena, the de jure standards setting process is experiencing a resurgence.  New subcommittees have been formed in JTC1 to address areas such as SOA, Web Services and there is also a Cloud Study group as well.

In the education technology space, the creation and adoption of standards is primarily discussed in the following forums:

• IMS Global Learning Consortium
• SIF Association (SIFA)
• And in the US, the Post-secondary Education Standards Council (PESC)

Organizations such as IMS, SIFA and PESC serve as the neutral convener for software vendors, service providers, government representatives and educational institutions.  Their success in defining and upholding standards allows institutions with disparate systems on their campuses to be free of vendor lock-in when choosing component-ized, a.k.a. service-oriented, solutions.  For example, standards around Common Cartridge, Learning Tools Interoperability, and Learning Information Services will enable schools with the flexibility to use a variety of learning applications provided by different vendors: Blackboard, Desire2learn or Pearson.  They can use all systems at once if they so desired.  Or they could move from one to another without having to rebuild custom integration points.  Oracle is active as a participant as well as in a leadership role in both IMS as well as PESC, and our products follow the standards as put forth in all three organizations.  Specifically, the Student Administration Integration Pack (SAIP) product is based on the ongoing work in the IMS Learning Information Services (LIS) group.  In my next post, I’ll talk a bit more about my perspectives on software standards from my own experience co-chairing the IMS Learning Information Services working group.

In whatever manner standards are developed and maintained, having interoperability standards means vendors spend less money building (and maintaining) individual, point-to-point connections to external systems.   Instead, these same vendors can focus on adding new features to differentiate their products, and ultimately, this is where the consumer wins.

Possibly Related posts:

1. SOA and the Case for Standards

Luckily, there is.

Let’s take the example of LMS integration. This is a gotta-have. You just can’t require students and teachers to manually create accounts and add themselves to their courses in the LMS. Nobody would ever use the system. You have to provision this information from the SIS. But what, exactly, is it that you are provisioning in order to make SIS-to-LMS integration work? It’s information about which students and which teachers are in which classes. In other words, it’s course roster information.

What other applications might need course roster information?

• The secondary LMS that’s run by your education school or business school
• Your library’s eReserves
• Your end-of-the-semester course evaluation system
• Your student portal
• Your emergency alert system
• Web 2.0 tools like blogs and wikis that are being used for classes
• Your campus bookstore

All of these systems need roughly the same data. And yet, when schools build their SIS-to-LMS integrations, they don’t typically think about all of these other, often unmet data provisioning needs. Instead, they typically take one of two approaches. Either they build out the cheapest, simplest batch provisioning that they think they can get away with, or they put a lot of energy into creating a system that satisfy all the various unusual requests that individual faculty members might put in for exactly how they want their courses to appear in their LMS. (Sometimes the first approach evolves into the second over a period of years.) The trouble with both of these approaches is that they tend to be dead ends in terms of their capacity to meet all those other course roster provisioning needs. Each integration is a one-off, which means that most of the integrations will never get built.

The alternative is to put some hard thought into how the ways in which these various systems need their data—the format, the scheduling, which details they do or do not care about, and so on—and design a service that can be consumed by all of these applications. It’s not a magic solution; somebody still will probably need to do some work with each of the applications that will be consuming the data in order to make all the connections. But it will be a lot less work, in the end, than doing each integration separately, which means that you just might get some of those nice-to-haves done. If you’re lucky, then your vendors will have done a lot of this work for you by designing and building the services for you and, in an ideal world, maybe even working with a standards body to get many of the vendors or support communities for those consuming applications to develop their piece of the integration for you as well.

This is exactly what we at Oracle did with our approach to LMS integration. Our product, the Student Administration Integration Pack (SAIP), implements a set of course roster provisioning services. When we started down the road of developing this capability, we went to the IMS standards body and co-chaired a working group, so that other vendors and open source projects would be encouraged to implement the same services. That standard, called the Learning Information Services (LIS), is in final review and expected to be finalized very soon. Many of the major SIS and LMS vendors and open source projects either have already implemented the standard or are in the process of doing so right now. And with that need-to-have SIS-to-LMS integration just about settled, we’re beginning to put more attention into nice-to-have integration for apps like iTunes University.

We believe that there are many opportunities like this throughout the university’s cyber-infrastructure. Some of them will be met through standards efforts like the IMS LIS, some of them will be met through product-specific services like the Peoplesoft Admissions Application Web Services (AAWS), and some will be built by individual colleges and universities themselves. Taken together, these efforts collectively amount to a game changer, enabling IT departments to meet many more previously unmet needs.

No related posts.

And when you think about it, the very reason that trucks and freeways need standards is because they are built by different people at different times.  Trucks and freeways can be considered components of a larger transportation system, designed to get people and goods from point A to point B.   So standards need to exist when any system consists of components.   Conversely, standards enable a previously single, monolithic sytem to be redeployed with components.   And why do we need components?  Because things change. And when they do, it’s usually easier and cheaper to fix or change one piece instead of the whole thing.   Think of a road that costs millions of dollars to construct – what if we were told only one type of vehicle could travel on it?  (I know there are cases where this actually might be useful for example in the case of high speed rail, however for everyday transportation needs, no one wants to feel locked in to a specific mode of transportation without the ability to choose how and when to travel.)  This is especially true in the case of Service Oriented Architecture – why?  Because software, like roads, can be costly to build and maintain, and what’s more, no one can predict how people will want to use the software over time.  So with standards and SOA, software can be combined in intelligent ways without predetermined reasons.

When you think about it, standards make ALL componentization possible – it allows me to type words on my keyboard (manufactured for use in different countries), visible through the display monitor, getting standard AC power from the wall outlet.  And whether or not Adobe Flash Player or HTML5 <video> tag ends up being used for video distribution on the web, YouTube relies on video format standards such as H.264 codec to be supported by all browsers .

So what types of software standards are relevant in the case of Service Oriented Architecture?  When referring to Service Oriented Architecture, standards exist at several levels:

• Web service standards around security, reliable messaging, orchestration, etc., produced and maintained by organizations such as W3C and OASIS.
• Standards specifically for SOA tooling such as Eclipse, Tuscany, SOA for PHP, etc.  These standards are still evolving and organizations such as Open Service Oriented Architecture are trying to create a neutral forum for collaboration and consensus.
• Industry specific standards regarding the exchange of data for specific use cases – for education, an example would be the IMS Learning Information Services 2.0.  Other examples include PCI DSS for the payment card industry, and the Chem eStandards for the chemical industry.  Industry specific data standards is a critical area ripe for more consolidation and is starting to be recognized widely, primarily driven by business-to-business use cases.

Strictly speaking, I should mention that systems that are service-oriented do not necessarily need to be implemented using web services.  However, today most practical applications of SOA do use web services, primarily because there is sufficient maturity around basic web service interaction (SOAP 1.1, WSDL 1.1 , UDDI 3.0.2, to name a few).  Moreover, part of the benefit (and promise) of SOA is the network effect created when applications register existing services for use by other consumers.  If enough services are built and maintained by the community, the cost to build each subsequent application will be lower – until someday, presumably, no new services will be needed for that next new application – the only cost incurred will be that of service orchestration.

Standards require communities of people, often competitors, agreeing to work together.  This is not always easy and sometimes results in fragmented groupings of organizations, sometimes resulting in competing standards (notable fragmentations include VHS vs. BETA video tape formats).  As the saying goes, “the wonderful thing about standards is that there are so many to choose from.”   In subsequent posts from me, I will delve further into the standards-making process, including historical background as well as perceived trends for creation and adoption practices for software standards in the industry today.

In the meantime, as you share the road with large trucks on crowded streets and highways out there, don’t forget to be thankful for standards!

No related posts.

We all know that a critical point of contact for many potential students is the admissions application that they can access and complete via a web site supported by the institution.  Most admissions offices know that the ease with which an applicant can access, update, and complete an application can be an important step in getting that student to attend.  A recent article in Campus Technology noted that 65 percent of students said a positive Web experience would pique their interest in a particular school and/or campus.   Because of its importance, admissions administrators are going to be extremely attentive to the design of that online admissions application for the following reasons:

• Applications vary between institutions and even within institutions.  They need to be  brand-able, and easy to manage when responding to cyclical or policy changes
• Because they are a primary source of data collection, they need to provide easy ways to enter often complex information
• Information that’s collected on the application form needs to be efficiently pulled into the student system regardless of how its collected

Because they vary so much and change fairly often, it is reasonable to expect that the self service data entry form might be designed and constructed with a software tool that is completely separate from the institution’s student system.  Getting the information from that data entry form  into your student system is where  SOA comes in!  Services allow disparate applications (remember Feldstein’s stereo system metaphor)  to connect and communicate with one another using standard protocols and do so by recognizing and organizing data at various critical points during a business transaction; in this case process of applying to college.

Web Services and an Admissions Application Submission

To understand what web services are at work requires a brief example of a simple admissions application self service scenario.

An applicant enters and institution’s web site and navigates to the section in which they are instructed to make an admission application.  Usually, the first thing they are asked to do is to create a user account or to enter their user name/password in order to access the online application process.  Having done so, they are asked to specify some information about what program of study they might wish to pursue and other pertinent information that will allow them to create an application.  Then, its time to “fill in the blanks”; a user interface will prompt the applicant to enter personal information (names, addresses, phones, residency), academic background and history, academic interests and intentions, and even answer various questions or require attachments that might support an admissions decision.  The applicant typically will save the application along the way and may even stop out of the process and  return later to finish and submit the completed application. As shown in the table below, each of these critical steps represents an event that a web service will recognize and provide a reliable response to the user interface.

In this scenario, which represents the simplest description of an application being created, updated, saved and submitted, we can readily see how web services can be located to recognize events and orchestrate inbound and outbound data between a user interface and a student system.

Considerations and Implications for the Self Service Admissions Application

If you work in an Admissions Office, you’re probably saying, “This looks like how our web based application process works already.  Why do we need SOA?”

Web services represent the bridging connections between a student system and various self service admissions applications.  These applications can come from 3^rd party vendors, your student system itself, or from separate technology tools that allow construction of data entry UI’s.  There in lies the componentization which is the true value of Service Oriented Architecture.  Instead of having to be restricted to a single technology stack, admissions officers who wish to ensure a quality web application experience can pick a tool (or tools) to create an admissions form; brand it, construct the sequence that data is collected, and customize it to the institution’s specifications.  It can be managed, changed and, if necessary, be replaced with a cooler, better, newer tool.  But the services on the left side of the table above are re-usable.  They recognize the messages regardless of their source and provide the required results.   The implications  that SOA provides for the future are significant and include:

• Agility to respond to internal policy changes or external demand.
• Reduced complexity by providing interoperability between disparate systems
• Flexibility to take advantage of alternative self service technologies at lower costs.
• Reduction of the risks of adapting systems to meet changing regulatory requirements

For further information

Oracle Campus Solutions recently introduced the Admission Applications Web Services feature which provides the framework described above. Current customers are encouraged to access the following references:

AAWS Developer’s Guide in My Oracle Support: CS Bundle #18 Functional Documentation for Campus Solutions 9.0 & Feature Pack 3 [ID 1155793.1].

AAWS User’s Guide in My Oracle Support: CS Bundle #18 Functional Documentation for [ID 1155793.1].

PeopleSoft Enterprise Campus Solutions 9.0 Feature Pack 3 Release Value Proposition [ID 1134435.1]

No related posts.

Like Michael, I like to use analogies. Some would argue that I overuse them – or one in particular – but so be it. The analogy that I overuse is that of a house remodel. We all know houses, and most of us are familiar with the pains and benefits of a house remodel – whether our own, a neighbor, or family member’s. When they are done, they can bring renewed comfort, flexibility, and joy of home ownership. They can be big or small, incremental, or a complete teardown. All are constrained by budget and time and all have options that home owners must ultimately decide; in consultation with an architect or not.

To these points, house remodels and SOA adoption share common ground. At the highest level, they share one that is usually overlooked on the technology side: the subject of architecture. Architecture by definition is a combination of science and art – I did look it up to be sure – and it’s this introduction of the ‘art’ that makes for some interesting, often, passionate conversations.

Ask an IT professional what is SOA and you might get as many explanations – or reactions – as if you asked is Kasimir Malevich’s Black Square really art?

Art discussions aside, the subject of architecture is subjective. Classic interpretations of architecture are easily recognized – both in buildings and IT – incremental interpretations not so much.

In a house remodel, is replacing windows a change in architecture? I would say no. Is changing the floor plan and the windows a change in architecture? Yes.
Where is all of this heading and how does this relate to adopting SOA?
Conversations around SOA become convoluted because SOA embodies two concepts: Web Services and the architecture to take advantage of them. In fact, often the concept of Web Service enablement becomes confused with SOA; folks think that with web service enablement, they have SOA. That is not necessarily true.

I sometimes describe web services as a “window” that applications can use to leverage other technologies: In that, one of the beauties of web services is that they are technology agnostic. They can be used to tie together seemingly disparate pieces without regard for the how those pieces were created, designed, or implemented – all they need to know is the signature that they present. We can discuss this more in future blog entries, but essentially Web Services become the connectors that Michael so eloquently described in his stereo analogy. The use of those ‘connectors’ though needs to have some careful thought and design behind it – otherwise, it’s just a different – albeit – new window in an old house; hardly a change in the fundamental architecture.

To compare it further to our house analogy, adopting SOA is more than simply replacing the old windows with the new, improved ‘web service’ windows. Simply doing a window replacement doesn’t fundamentally take advantage of some of the things the new ‘web service’ windows offer. For that, architects almost always need to change some aspects of the floor plan of the house. Making these floor plan changes may or may not be intrusive, they may or may not be expensive, and they can almost always be done incrementally: one room at a time, so to speak.
Doing remodels one room at a time, though, almost always requires the architect to make some tradeoffs. Sometimes, intermediate, non permanent work needs to be done to support the longer term design of the larger house. Whether that’s a temporary beam installed, or the addition of a supplemental electrical circuit before the previous one is upgraded or removed. There can be many temporary steps that are done room by room and each step must be balanced with the short term gains or pains and the longer term vision.

It’s exactly this incremental practice that systems employ as well. Piece by piece, or rather project by project, Higher Education systems that are looking to incrementally adopt SOA, need to look at each new project as an opportunity to adopt pieces of web service enablement in ways that support an architecture that is modular and agnostic (SOA). With each project – just as with a house – sometimes temporary beams are needed. These can take the shape of service enabling, or wrapping, an existing interface with a web service, or by any number of other modifications that support the introduction of new information into the process flow. By themselves, these do not create SOA, but they incrementally support the adoption of it.

As they incremental adoption proceeds, those involved need to be comfortable with the fact that reworks of temporary pieces will certainly be needed and refinement of the design will be needed as standards are refined and adopted more widely across the higher education community.

But that’s for a future blog entry…..

No related posts.

What SOA Is (and Isn’t)

Let’s start by talking about what SOA isn’t. SOA isn’t a product. You can’t tell your IT manager to go out and buy a SOA. SOA also isn’t a technology. It’s not a programming language or a particular interface or protocol. SOA is an architecture, by which we mean a set of software design principles. You can almost think of it as a design philosophy. And what is that philosophy? It’s that the functionality in a piece of software can—and should—be divided into separate components that communicate with each other via service contracts. That’s already a mouthful, so let’s make the idea a little more concrete with an analogy.

Back in the early days of electrically reproduced sound, the products people bought were completely self-contained. If you bought a radio, for example, it came with a radio tuner, a pre-amplifier, an amplifier, and a speaker all built-in. If you bought a phonograph, it came with a turntable, a pre-amplifier, an amplifier, and a speaker built-in as well. In the beginning, it was necessary that each product be completely self-contained, because the product manufacturers couldn’t assume that consumers already had other components. But as radios became more and more common, phonograph manufacturers began to think about whether they really needed to drive up the cost of the product by including pre-amplifier, amplifier, and speaker components when customers already had all of those components in their radio. So RCA invented the RCA connector, which was commonly referred to at the time as the “phono jack.” The turntable could then provide sound input as a service to any audio equipment that could take an RCA plug.

This was good, but it still wasn’t ideal. What happened if the radio amplifier died? The customer would have to throw out the whole radio, including a perfectly good receiver, pre-amplifier, and speaker(s). In addition, as high fidelity (“hi-fi”) equipment came onto the market, people became interested in upgrading to better speakers or a better pre-amplifier. In other words, people wanted these components separated from each other. And it turned out that they could be separated, as long as the manufacturers of those components all agreed to support the same connectors (or services). Today, you can connect a radio receiver made by Sony and a turntable made by JBL to an amplifier made by NEC. This gives customers choices for each component and minimizes their costs when they need to replace a broken component or want to upgrade or switch an existing one. As new components become available, you can plug your new Blu Ray DVD player or your iPod (for example) into your system just as easily as your old phonograph.

Notice that the kind of connector that’s used between the components is incidental. RCA jacks can be replaced with fiber optic inputs, USB cables, or whatever is the best technology at the moment. What matters is that the components are designed to be separated and to communicate with each other over some sort of previously agreed upon connection.

And that is the basic idea behind SOA in a nutshell.

Why You Should Care

SOA adds similar value to your software that component separation adds to your stereo. At a minimum, it can save you from having to buy and maintain duplicate components. For example, why should every application store it’s own copy of user identity information? Why should your software license and maintenance fees go toward building a separate identity store in every single application that you buy? Why should you re-enter the same data into every single application? Why not have a central store that acts as the source of truth and provides identity data to all other applications as a service?

Likewise, when you want to replace a component or add a new one, wouldn’t you like it to be plug-and-play? Why should you have to go through the trouble and expense of custom development to integrate your new LMS with your SIS when you just want to send over exactly the same course roster data that you were sending over to your old LMS? And why should you have to do yet more custom development to send the same course roster data over to your eReserves application, and yet again to send it to your course evaluation application? Shouldn’t there be something like an RCA connector for this kind of exchange of information? Shouldn’t all of these components support the same service interface for plug-and-play integration?

That’s the basic idea behind SOA and the value it can provide. There are lots of other benefits it can offer beyond these. Also, it’s important to understand the difference between providing any old services and providing standard services—a distinction that I have glossed over here. And, of course, retrofitting your existing infrastructure with SOA (as opposed to getting all new components that are built for SOA from the beginning) is often easier said than done. But these are other topics for future posts. For now, when you think about SOA, think about your stereo components.

1. By the way, every post on this blog will be categorized by the audience(s) that might find it useful. You can see a list of posts that are appropriate for you by clicking on the appropriate link under the “Posts by Audience” heading in the sidebar.

No related posts.