One of the projects I have been following for a long time is Bedework, which I think is now in position to kill the learning management system (LMS). By this, I do not mean to imply that Bedework has superior teaching and learning tools, in fact, as an enterpirse calendar, it clearly does not even compete in the online education market: it’s functionality will not usurp those of the LMS. Rather, more specifically, I suppose my point is that Bedework will kill the idea of the “System” in the “Learning Management System.”

Currently when one assesses an LMS, the set of tools within the system is considered paramount in the selection process. Tied to feature analysis might be other related functionality issues, such as the pace of development of the embedded tool set native to the system, the roadmap for deploying new tools/features within the system, and/or integration between the system and other enterprise applications.

But consider what would happen to the “Learning Management System,” specifically the “System” if Bedework was integrated. What if Moodle and Sakai both deployed either Bedework in their native distributions or provided interfaces for Bedework integration. To the end users, it would appear that both Sakai and Moodle had just released an updated version with enterprise calendaring: ideal for comparing course schedules with campus schedules, integrating personal events with course or campus events, etc. But, what does this mean architecturally and even more interestingly, organizationally for each project, Bedework, Moodle and Sakai?

For Moodle and Sakai what does the system in learning management system mean now? How do all three projects manage development? What other services might be included in this model stretching the system until it pops: discussion forums, gradebooks, wikis, blogs etc?

Once two campuses or Moodle and Sakai themselves embed the same tool, the LMS is dead…

…maybe it already is: see this and this.

Ok, this is lame, but after reading Christopher Dawson’s “Windows 7 is the same as Ubuntu” it hit me like a no-duh,  Google has essentially met (?) usurped (?) surpassed (?) the idea of WS-*, and what I would have thought only achievable through a MS approach of standardization through dominance, established the web service protocol.

There are a variety of specifications associated with web services. These specifications are in varying degrees of maturity and are maintained or supported by various standards bodies and entities. Specifications may complement, overlap, and compete with each other. Web service specifications are occasionally referred to collectively as “WS-*”, though there is not a single managed set of specifications that this consistently refers to, nor a recognized owning body across them all. The reference term “WS-*” is more of a general nod to the fact that many specifications are named with “WS-” as their prefix. This page includes many of the specifications that might be considered a part of “WS-*”. -Wikipedia

Yes, web services are more than just the aggregation and presentation of widgets (oh, that’s gadgets now), but for all practical purposes WSDL is now “Add Stuff,” (or more appropriately, Gadget API’s and Designer) as well as the ever-growing list of internal Google services (g-mail, google apps, etc.). Not exactly analogous I know, but I guess I am just wondering how development of services might be affected. Will (how long before) folks primarily develop for Google, thus requiring a Google interface for accessing remote services?

So-now the lame part-I am going to coin g-* (pronounced like WS-* as WS star). Of course… “g-*” by Patrick Masson is licensed under a Creative Commons Attribution 3.0 United States License.

Forrester analyst Randy Heffner, has published a report titled “SOA Is Far From Dead—But It Should Be Buried.”

Sparked by a tinderbox of economic jitters and technology backlash, a recent thread of industry discussion cries out, ‘SOA is dead!’ Although many have had fun with the discussion, it is in fact quite misguided. No prior industry initiative for IT architecture has had an impact as positive and broad-reaching as service-oriented architecture (SOA). But SOA’s impact is only part of the story: You have many more technology initiatives besides SOA. You need a bigger architectural vision that encompasses SOA, business process management, event processing, Web 2.0, and much more besides. Although SOA is far from dead, it should be buried inside a larger vision.

As someone who has attempted SOA in the past, and who is working on similar initiatives in my current position, I am happy to see the emphasis on business process management and event processing. SOA’s detractors often complain about its complexity–the integration of disparate technologies and interoperability of a variety of tools based on unique or specific protocols, specifications and standards. However the difficulty (consternation) often attributed to SOA is really a manifestation of the complexity inherent to an organization. As SOA implementations are actually derived from business processes, understanding those is fundamental to an SOA architecture. Quite honestly, many organizations simply do not understand how they operate within functional areas, let alone across units. In my experience, when a systems architect undertakes an SOA project, it is actually the business analysis that proves most hazardous to project success, rather than any technologies or architecture.

Heffner offers, “These types of misconceptions and limited strategies give SOA a bad name because their focus on technology separates business value and SOA,” He continues, “These strategies portray SOA as a technology savior rather than a tool (and a very important tool) in a business value tool box. Even worse, when the difficulties occur that are a natural part of introducing something new, a technology-focused model for SOA provides limited thought processes and models for resolving those difficulties.”

Data warehousing only works if an organization understands how data is collected, associated and accessed and service buses and messaging require an understanding of an organization’s business services, processes, actors and the events/rules that drive them.

Finally, Heffner offers a few strategies for implementing a SOA environment (note the operational, not technical slant):

1. Treating SOA as a business design concept.
2. Using lightweight strategy to guide delivery of today’s business benefits (street-level strategy).
3. Doing integrated, simultaneous design of both business and technology (concurrent business engineering).
4. Using a coherent business service portfolio management process to drive reuse.
5. Approaching all aspects of SOA maturity with an evolutionary mind-set and strategy.
6. Having a variety of strategic and tactical investment approaches for SOA.

Business analysis, in my experience, has been the greatest barrier to SOA, not the technologies.

What’s the prevailing business management strategy of the day (i.e. governance, decision-making, planning, change management, leadership, visioning, etc.), not just for Higher Education or IT?

As most know by now, Blackboard has announced that they will purchase Angel. Of course this has sparked all sorts of responses from folks, covering everything you might expect – unfortunately most still misrepresent open source.

Rather than offer any thoughts on the buy-out and what it might mean to Blackboard users, Angel users or even the entire LMS industry, I’d like to focus on how the discussions align with current ideas, perpetuate/counter misconceptions, or, have evolved from traditional views on the viability of open source.

With things moving so fast, or at least the comments through blogs and twitter (#auc09, #bbplusangel), etc. (the announcement was made on May 6th and the Angel Users Conference was just this week), I am sure most folks are reacting rather than assessing, but I am struck over and over by the comments being made by those on the ground working with an LMS and those reporting on the acquisition: everything from misconceptions to downright ignorance regarding open source projects and adoption.

Jeffery Young, of Today’s News in the Chronicle of Higher Education reported in an article titled, Blackboard Buys Another Rival, to Customers’ Dismay, “Some experts predict that more colleges will now turn to open-source alternatives that give them greater control over their own destinies (but which often require more effort by campus employees to run).” Requires more effort by campus employees to run? This is simply untrue. Running Sakai or Moodle out of the box does not require greater resources than running Blackboard or Angel. The infrastructure (hardware, supporting systems, networking, etc.) of running these systems are comparable. The skills needed by staff to install both the hardware and software (systems administration, programming, etc.) is comparable. If a campus chooses to extend the functionality of their LMS then, yes, they might need more (or different) staff than if they were running that same LMS natively. But this would be applicable for any campus, whether working with Sakai or Moodle code or developing Building Blocks for Blackboard or Nuggets for Angel.

If the point of this statement is that an open source option requires campuses to support these systems themselves, this too is untrue. Longsight, rSmart, Unicon and others provide technical and end-user support for Sakai. Campus Management, Classroom Revolution, Moodle.com, Moodlerooms, Remote-Learner and others provide the same for Moodle users.

Importantly, this argument–often used by those either ignorant of, or opposed to, open source options–has never been true. What is true is that open source deployments have traditionally been supported by alternate models that most campus decision-makers are not familiar or comfortable with. But now, even traditional service agreements through commercial providers are available, making this comment–once arguable in the past – simply false today. Mr. Young, please correct your article.

Later in the article, Blackboard’s president and chief executive, Michael L. Chasen, is quoted, “In the end, he said, colleges will choose Blackboard over open-source options because buying software works better for most colleges than being part of a do-it-yourself project, which he said takes more staff time to customize. ‘I really don’t believe it makes sense,’ he said.” Really? Let’s take a look at what makes sense for Blackboard…

Netcraft reports (see graphic) a website’s operating system, web server, and netblock owner together with, if available, a graphical view of the time since last reboot for each of the computers serving the site. I used the Netcraft “What’s that site running” service to see if Mr. Chasen’s observations regarding colleges, also applied to companies, again, that buying software works better than being part of a do-it-yourself project. Apparently not. According to the Netcraft report, which included 51 Blackboard hosted sites (where Blackboard Inc. hosts the campus’ LMS as a service), 41 instances are running the Blackboard LMS in a Linux/Apache environment, 6 are running on Windows and 4 could not be determined. Apparently, open source “makes sense” for Blackboard but not campuses. In addition, the report also lists another 25 sites hosted by Abovenet Communications, Inc. which are all hosted on Linux/Apache servers: I guess Abovenet’s hosting environment doesn’t make sense either.

Mr. Chasen also noted that using open source, “takes more staff time to customize.” Again, as stated above, running open source does not require any customization. I wonder what customizations Blackboard has had to undertake to run Linux/Apache, or run Blackboard on Linux/Apache? With 41 instances, I would suggest Blackboard hosted campuses call and request to be migrated to a Windows platform so that costs associated with the required customization can be reduced and thus their hosting fees.

I just saw an article in The Register on the creation of an Action Plan for the adoption of Open Source by the UK Government. While this action alone is impressive and inspiring (I have been trying with limited success to move the State of New York and SUNY in this direction), what is even more significant is the process through which they are developing their policy.

Included in the Action Plan is :

To help bring together the online debate around this Action Plan, we’ve set up a public page which contains links to blog posts, news stories and tweets about UK government, open source and open standards. If you write about this online, please use the tag #ukgovOSS to help us find your comment.

The approach used by the Council is completely in line with the the open source methodology of collaboration, many eye-balls, iteration, etc.

In addition to promoting the use of open source software, the new policy also emphasizes open standards and encourages the re-use of IT solutions in the public sector.

Among the 10 points of the government’s action plan are the following:

Something to shoot for…

I just keep ignoring this blog as I have been spending more time on the SUNY Delhi blog. The whole department is contributing so the conversations just seem to flow. So few hours..

It should be, “Why IT projects get started.”

CIO Insight just published the top five reasons why IT projects are killed. According to the a survey of 167 IT executives, conducted by The Information Systems Audit and Control Association, the reasons were:

1. The Businesses needs changed (30%)
2. The project does not deliver what was promised (23%)
3. The project is no longer a priority (14%)
4. The budget was exceeded (13%)
5. Does not support the business strategy (7%)

I can’t help but think how traditional project planning processes may have contributed to the failure of these projects, raising the point that it’s not why the projects were killed, but how come folks did not know that the projects were doomed and thus, why did the IT project get started?

To me, this is evidence for the failure of upfront project planning process. Now, there is no indication of which project management approach was undertaken, and it is possible that the projects reported that failed included a variety of traditional and more progressive methods. However, I am assuming these projects were managed through traditional means. It’s also interesting to note that project management was not mentioned (a question I’ll post to the article). That is, no one (or at least not a statistically significant amount of IT executives) pointed to their own processes as a cause for failure. What does that mean?

Here’s a great post that touches on much of the above reasons for project failure and offers a solution.

I was recently invited down to Penn State World Campus to discuss Delhi’s move toward Agile for the enterprise. Here is the audio and the slides to click through (sorry no bell included to tell you when to turn the page).

This was the first run for a upcoming NERCOMP presentation, so it’s a bit rough…

“No Five Year Plan, No Advisory Board: How do I still Have a Job”
[Slides] | [Part 1 Audio] | [Part 2]