Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

May 18 2010

Educational technology needs to grow like a weed

Why do so many well-conceived education reform designs fail in implementation? For the same reason that old-school top-down software development fails in today's rapidly evolving Internet-based marketplaces.

In both cases there is an implicit false assumption that the designers can accurately predict what users will need in perpetuity and develop a static one-size-fits-all product. In response to that fallacy, both software development and education reform have developed agile models of adapting to unpredictable environments. Independently, these have failed to scale to their potential in the real-world trenches of the U.S. educational system. Interdependently, could they achieve the results that have so far eluded each?

Traditional education reform, like traditional engineering development, invests heavily in up-front design. In engineering, this makes sense when dealing with deliverables that are hard to change, like silicon, or when mistakes are not an option, as with space flight or medical technology. However, when the deliverable is malleable, as with consumer software, once the market starts to change the implementer is trapped between the choice of piling modification upon modification until the initial design is completely obscured, or plowing ahead unswervingly only to deliver a product that is obsolete on delivery. The software developer is destined to be outperformed by more nimble developers who can adapt effectively to changing market needs, new information, and an evolving industry.

Similarly, education reform interventions are rigidly constrained. To prove a treatment's effectiveness, research needs to demonstrate that one particular variable in a messy human dynamic environment is responsible for a change in student outcomes. This means that an educator and his/her students must behave precisely as designed in order for the research to be valid. Tremendous resources are spent in these kinds of trials to ensure "fidelity of implementation." In this situation, the educator is trapped between the choice of corrupting trial data by changing the implementation to meet the changing needs of students and the environment, or plowing ahead only to limit the good he/she can do for students to the lowest, common, measurable denominator.

In the software world, we address this dilemma through an iterative development model. That is, we assume that when we are thinking about what users might need or how they will use our product, we will get some things wrong. So we code up some simple end-to-end functionality, throw it out for people to use, and then improve it iteratively based on feedback from our users. This feedback may be explicit, in the form of questions and requests, or implicit, based on our observations of how the software is used. It may well be automated, in the way Google instruments the applications we use and modifies them based on how we engage.

In the education world, there is also a shift away from rigid implementations to more scalable adaptive approaches. Alan Bain writes in "The Self-Organizing School" about how the metaphor of emergence mediates the tensions between top-down control and bottom-up chaos. Rather than designing and dictating the everyday workflow of educators and students, the self-organizing school identifies a small set of simple rules. These rules, in combination with multiple feedback loops, drive and iterate the work of teachers, students, administrators and others involved in teaching and learning. As with the emergent behaviors of ant hills and flocks of birds, the simple rules drive elegant, complex system-level behaviors that adapt to changing circumstances.

This model of education reform depends on real-time, effective feedback loops of information at a scale that is possible only with the support of technology. But the technology platforms to support a self-organizing school haven't been developed -- as with most educational use of technology they are likely to be pulled together on an ad-hoc basis with minimal support, making them clunky to use and difficult to modify. As a result, rather than enabling and supporting adaptation, they are just as likely to carve existing processes into digital concrete and become a force resisting change.

How do you get to a technology platform that supports scalable education reform? Perhaps the best option is to grow it. Plant it in the fertile soil of existing open source education software and open education resources. Seed it with some simple elements: digital content creation or assessment distribution or maybe collaboration spaces or online courses. Feed it with a few data flows: perhaps computer-graded quiz results to students, teachers and parents; homework assignments and recorded lectures in one direction, completed projects in the other; automated attendance data to teachers and administrators. Immerse it in an environment built on feedback loops that are nourished by the data that is generated on the platform. Adapt and evolve it in response to decisions and needs that are uncovered by those feedback loops.

In symbiosis, the platform and the practices it supports mature and reach a sort of dynamic equilibrium of continual, steady, incremental growth. As it matures iteratively, the technology platform becomes ready for transplantation to other environments.

Traditional education reform fails to scale because top-down designs don't survive the reality of the day-to-day classroom. Emergent designs adapt to real circumstances but depend on extensive data collection driving feedback loops at every level. Not only is this not well supported by existing technology implementations, but the functional requirements of those implementations are not yet well understood. Through a process of co-evolution, those requirements can be surfaced and technology platforms developed that can then enable education reform to scale.

March 03 2010

Apps for Army Launches - The Hybrid Enterprise?

This week the U.S. Army announced the launch of Apps for Army. It is modeled on the Apps for Democracy contests in the District of Columbia and is being run by the same indefatigable Peter Corbett and his iStrategyLabs. It looks to uncork the Army's cognitive surplus and let soldiers start solving their own problems in code without the personal risk of going off reservation to do it.

An overview of the program can be found here; or in video form here. Army Deputy CIO, Mike Krieger, discusses the Army's goals for the program here and Lt. General Sorenson, Army CIO, will discuss the program at 1:30pm EST on March 3rd during a round table. You can listen in here.

Now that the obligatory fact dump is out of the way, I want to delve in a bit more. While Apps for Army looks a lot like Apps for Democracy, the similarity is only half the story. The differences are interesting too, as is the path the Army took to get here.

What Apps for Army and Apps for Democracy share is an explicit attempt to harvest latent intellectual capacity toward emergent rather than planned outcomes. They are intentionally establishing the conditions for emergence by making data and platforms available and essentially saying "if you have a good idea, and you can execute on it with this stuff, please do." The big difference is who they are saying it to. D.C. said it to citizens effectively external to the "enterprise" while the Army is bringing intentional emergence inside.

The Army has always had innovation in the field, they just couldn't bring themselves to completely sanction or acknowledge it. It's the simple reality though. When the unmet needs of mission-oriented soldiers in the field build up enough, innovation starts shorting to ground with whatever tools are at hand. Terms like "county options" and "drive by fieldings" express the enterprise's grudging ambivalence toward these difficult to integrate and support local developments. The Army and other services have long wrestled with the reality that these local options are critical to the mission, but that they are expensive and inefficient (pdf). Also, they just aren't readily provided by a Big Army centrally planned acquisition system which is focused on shepherding the big stuff through the process and has little bandwidth left for big volumes of little things.

short to ground.png

Apps for Army is a first step in a long term effort to reconcile enterprise control with local initiative. Apps for Army might not claim such high goals for itself, but in effect it is the Army's attempt to have its cake and eat it to. Open platforms, source, and data should greatly increase generativity and the potential for innovation inside the enterprise. However, by supplying and certifying the platforms and code that runs on them, the Army hopes it can do it without sacrificing enterprise controls or security the way it does with today's unmanaged local point solutions. This makes it look a bit more like Apple's app store processes embedded inside the enterprise than like the original Apps for Democracy. It also partially explains why it took six months to launch rather than the two months originally planned. Apps for Army simply couldn't happen before the platform provisioning and application certification stuff was worked out. The processes behind Apps for Army are necessarily more complicated than those involved in the outside the firewall Apps for Democracy.

Some Background

In March of 2008 I wrote a piece here on Radar that talked about the need for generative systems inside the Army. I wrote it as sort of an orthogonal response to Noah Shachtman's talk at ETech. I got a bunch of things wrong in that post but the best thing that happened was that Paul Lin, a California National Guard soldier left a comment about his experiences in the Iraq theater. Paul and his good friend Carlos Castillo had deployed together and quickly got frustrated dealing with manual processes that could be easily automated using skills that they brought with them from their civilian careers. They set about the process of getting a linux server certified on the network (it took six months for one box) and then once it was available, began solving a wide variety of problems for an unexpectedly huge swath of users. Essentially they brought the generative web with them into the enterprise and once that server was established on the network it became a platform for rapid cycles of local innovation. These guys are my fatigues-wearing coder heros.

I was fortunate to be able to arrange a meeting in the Pentagon between Paul, Carlos, and Lt. General Sorenson, the Army CIO in December '08. Their story seems to have stuck as a powerful example of what is possible and should be encouraged (and also of what is wrong - since once they rotated out of theater there was no one to take care of the stuff they built). I've heard both General Sorenson and his Deputy Mike Krieger re-tell this story many times. It's only a small part of the bigger picture, but a seed had been planted and along with it a really great propelling narrative.

At about the same time I was circulating a paper inside the Army that talked about enabling the long tail of emergent development inside the enterprise. I proposed that they build a "battle command innovation platform" (BCIP) that would intentionally enable the emergent end of the enterprise development continuum. One part Google App Engine, one part content API strategy, and one part social coding with App Store like deployment processes it would support innovation at the edge. The goal was to intentionally enable non-traditional developers to build things they hadn't thought of yet which would improve the Army's "maneuverability in code."

long tail.png

I spent a lot of time in meetings suggesting to incredulous Army researchers and acquisition people that they go play with Scratch and imagine an environment like that grafted on top of Git (to give a layer even simpler than Github). Such a layer would not only enable development at the edge, but would also provide the kinds of social support and learning that would be needed to really make it flourish. Eventually we got to build a small prototype of the idea for Army CERDEC.

There are lots of other people advocating similar ideas in the Army (and throughout the DoD - for example, Dan Risacher and the DoD Storefront initiative). Back in 2005 Carol Wortman and Rob Pitsko, two Army civilians working on Battle Command systems at Ft. Monmouth, wrote a paper called "Toward an Information Management Framework" which described a platform concept to "enable warfighters to build their own capabilities on a common managed foundation." By the time of this story Carol had become part of the CIO staff focused on enterprise architecture where she continued to advocate for the adoption of these ideas. Now she is involved behind the scenes in Apps for Army.

The fact that the Army was fighting two wars and the acquisition system simply couldn't keep up with all of the needs in the field added to the growing sense that something had to change. The deployed soldier has to be enabled to solve at least some of their own problems. Besides, a two million person force, even if it didn't explicitly staff for it, was bound to have some people in the field who could code.

General Sorenson spoke at the Web 2.0 Summit last Fall and in the process cemented a relationship with Tim O'Reilly that ultimately led to plans to introduce him to the other service CIO's in the Pentagon. In the Spring I shared my BCIP paper with Tim and, as it resonated with his ideas for Government as a Platform, he passed it on to General Sorenson with the suggestion that it might be a starting point to harmonize Army efforts with the kinds of things that Vivek Kundra was promoting more broadly.

At the same time Apps for Democracy was still generating buzz as a model for innovation in government and Tim suggested to Peter Corbett that it might be possible to apply the same model to the military. In June of '09 all the ducks lined up and General Sorenson arranged a meeting in the pentagon with the other service CIO's, Tim, and Peter Corbett to discuss an Apps for Defense contest. I attended as a kind of web-military translator and because there was some thought that the work we were already doing might be able to support the contest. It was perhaps a bridge too far for DoD-wide contest at that point and Apps for Army was born under General Sorenson's sponsorship.

General Sorenson first announced his intent for Apps for Army at the annual LandWarNet conference in August '09 where he repeated Carlos' and Paul's story. With repeated tellings, it had started to sound like folklore so I arranged for them to get on stage together at the Government 2.0 Summit in September. Lin Wells, General Sorenson, and General Justice (at the time PEO-C3T) discussed their goals for "innovation at the edge" (video) and then officially announced the Apps for Army contest. They were followed onstage by Carlos Castillo telling the details of his and Paul's story (min 25'ish of the video). After Carlos finished, Gunnar Hellekson relayed the story of a reservist RedHat employee who had also built some really innovative local solutions while deployed.

I wonder what Peter Corbett would have thought if, walking out of the Pentagon last June, he had known it would take till now get Apps for Army launched. I give him tons of credit for staying with it this long and wrestling the DoD contracting issues to the ground. I have no doubt the process was much more difficult than he imagined when this started.

A lot of people reading this will probably wonder "how could it take that long?" Well, there are a lot of answers for that but not many of them all that good or even very interesting. Mostly good intentions implemented in bureaucracy. The awesome thing though is that General Sorenson sponsored it the whole way through and his staff stayed with it until it was done. Through the legal details to platform provisioning to security and etc. This is a tough thing to pull off in the DoD and I'm just thrilled to see it launch and can't wait to see what comes out of it.

The Hybrid Enterprise

I see this exercise as much bigger than a contest. Naturally, I hope that it delivers some cool and useful apps, but what I'm really hoping is that a successful first phase of Apps for Army will encourage further experimentation in emergent development across all of our military services. As these "super-enterprises" of massive scope demonstrate the value of intentional emergence at their edges, I hope it will cement the idea of the hybrid enterprise by demonstrating the effective combination of planned systems development in the core with emergent platforms to serve the edge. If it does, don't be surprised to see Apps for Yourco coming to an enterprise near you.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!