Developing E-Learning Content Developers

A posting from Clark Quinn points to an interesting work from Clive Shepard, The 30-minute masters. Clive is developing "a curriculum to train subject-matter experts in the design of rapid e-learning materials for use in the workplace".

The session design is directly applicable to environments where a training organization needs or wants to enlist subject matter experts in the creation of online training material. The scripts are still under development, but seem sufficiently complete for others to adopt to their needs.

It's also intriguing to ponder its use as a tool for Architects as Educators.

The 30-minute model makes it easy to insinuate into a variety of situations. For example, it seems a good fit for an in-house Lunch & Learn session. One could also shanghai a meeting with an "unplanned learning session".

For what it's worth, Clive's work seems an ideal candidate for SlideShare. Perhaps he can inject a call to action for contributions. It would be interesting to see different interpretations of the work.

The Teacher in us All

PLEs are what?, from Tim Hand, has a nice set of reminders regarding the Personal Learning Environment (PLE) space.

Among other things, Tim reminds us that a PLE is a concept rather than an application. It is a way to frame the vast array of information gathering, transforming, and transmitting tools into a framework for learning and growing. He also ponders whether discussions surrounding PLEs will fade, at least under the term 'PLE'. Viewing our information tools as a platform for learning can hardly be a bad thing, so one would hope the PLE concept continues to evolve.

To evolve the PLE concept, it seems worthwhile to consider a couple possibilities.

The first is the possibility that the big idea behind PLE is not that one can co-opt communications and social interaction tools as education tools. Rather, it might be better to concentrate on the idea that education tools can be crafted to take advantage of communication and social interaction tools. Put another way, there is a difference (however intertwined) between the transport mechanism and the content.

Another possibility is to extend the focus of the concept beyond learning. Rather than a personal learning environment, it seems more appropriate to focus on a personal education environment. While considerable focus is placed on ideas for delivering content to learners and on techniques for using our environment as a learning experience, the discussions often seem to lack a focus on ideas and tools for injecting material to be learned.

This leads me to another, potentially more controversial, possibility. If the PLE concept personifies the democratization of learning, is it equally fair to extend to concept to teaching?

Is it heretical to want SCORM packages (or their future equivalent) created by citizens delivering their own learning content? Is it insane to imagine a Flickr/YouYube/Blogger for learning content?

We discuss the learner in us all. Are we ready to discuss the teacher in us all?

EOS - Elvis Oriented Architecture

In To Understand SOA, map it without technology, Joe McKendrick summarizes an interesting article by Dan North, A Low-Tech Approach To Understanding SOA.

Dan uses a fictitious 1950s company to illustrate the basic concepts. It's a wonderfully simple idea.

Dan's explanation is interesting, however, it's still a bit long for the attention span of most business people. Is distilling it down to a PowerPoint bullet list necessary to complete the transformation of SOA into a design pattern. We seem so close.

It costs how much?

Bob Sutton points out Evidence-Based "Asshole Pricing" at a UK Consulting Firm.

The mind reels with possibilities.

Hmm... so how to implement...

We'll need to propose it to management, but terminology might be an issue.

Ok, so let's try a few euphemisms, just in case some folks wince at the wording.

• Cost-plus pricing
• Tractability pricing
  
• Customer-centric pricing
  
• Boutique pricing
  
• Heterogeneous market segmentation
• SLA (Sanity Level Agreements)
  

We might need to do some field trials...

Technology Plays a Bit Part

In Adoption, rather than Architecture, is the high order bit for Architects, Gabriel Morgan reminds us that being a change agent is probably one of the most important responsibilities of an Architect.

I'll go one step farther.

Technology is quite possibly the low order bit.

While technology typically forms the foundation for our entrance into architecture, part of our value stems from our ability to put it into proper perspective. Perhaps great architecture is merely evidence of passing through Dante's Inferno and living to tell the tale?

Even the requisite sound architecture Gabriel mentions is more an expression of form, structure, and flow than of technology. Well, in least in theory - there's still that ugly part about riding elephants to deal with...

Vendorprise Architecture

Mike Walker compares vendor architecture concerns with enterprise architecture concerns in Do Your Vendors Have Enterprise Architecture Efforts?.

Having worked in both realms, Mike's side-by-side comparison made for an interesting read.

For my $0.02, I tend to believe the differences are smaller than they appear. My view could be based on having passed between the two worlds a couple times. It could also be a based on my own biases. Regardless, reviewing Mike's list makes it easy to see how architects could benefit from experience in both realms.

Tweet If You're Human

James Governor covers the topic of Twitter banality in You can keep your "Business Language": that's not meaningful conversation.

He reminds us that business meetings are often no more compelling than Twitter tweets on what was consumed for lunch. He also invokes the Cluetrain, reminding us that the marketplace is ultimately a conversation.

I have an additional observation regarding the value of these sometimes trivial conversations.

Humans have an amazing aptitude for extracting information from covert channels. Our daily conversations provide valuable information not normally acceptable via direct questioning. The trivial chatter of daily conversation is one of the basic ways we establish trust for the people around us.

To put it bluntly, any psychopath can mimic the ritualistic protocols of business. It seems to take a real human to sustain the gamut between relevant and trivial interactions over an extended period of time. We use conversation to confirm the humanity and credibility of the people around us.

... whether they come from Twitter or from the water cooler.

(oh, and I didn't have lunch today)

Architecture tweets? arch.icio.us? ArchMoodle?

Gardner Campbell provides an intriguing vision for digital education in The Future of Online Education. It is nicely summarized in the following quote.

"... learners will arrange their own “cognitive apprenticeships” by means of RSS feeds of content generated by a personal suite of trusted and inspiring experts, and they will build their reputations through certifications, testimonials, and a body of their own online work that generates persistent, sophisticated commentary."

If this is indeed a picture of the future, it seems Architects have a golden opportunity ahead - an opportunity both in the positive sense of the word and in the euphemistic MBA sense of the word.

In the positive sense, we have the opportunity to directly participate in the education and training stream, articulating our models and strategies as educational material. We can capitalize on the viral properties of networks to spread key concepts, allowing us to focus on delivery to key influencers. We can clarify misunderstandings by directly participating in the conversations spawned when clarifications are needed.

In the euphemistic sense, we have an opportunity to improve our ability to connect directly to problems and conversation streams. Architects are prone to the ivory tower syndrome. We get embroiled in frameworks and strategies, often lagging in our ability to connect theories to practices. We must continually check ourselves to avoid the darker tendencies of the job.

James Governor recently posted Some Enterprisey Use Cases for Twitter. He references a blog posting that enumerates uses from the Marketing community. He then goes on to describe how he uses it as a research tool with a direct connection to practitioners. James McGovern chimes in from a slightly different angle with Enterprise Architecture: When was the last time you had a meaningful conversation?, in which he comments on the value of direct conversations.

How many Architects use twitter to tap into their network? How many use del.icio.us as a way to pass along interesting web sites to their constituents? Are we using these tools to their full potential, or is this the PC to our Mainframe?

Do we find ourselves using 'skip-level' influence to overcome obstacles to adoption? If so, are there communication mediums we could be using to reach deeper into organizations, touching a wider range of alpha geeks/influencers? Would our effectiveness as leaders improve if we were capitalizing on those mediums?

Should we be articulating some of our ideas in a SCORM-compatible format and distributing them as enclosure links via RSS pipes?

Does anyone else see the huge potential for Architects to participate in "personal suites of trusted and inspiring experts"?

A Herd of IT Elephants

Andrew Clifford recently posted The root of all evil, another in his series Journey to the sixth circle of hell.

In this latest article, Andrew provides his list of the Big Problems in IT:

• The high failure rate of large, expensive projects.
• The growth in unmanageable "legacy" systems.
• The shortage of skilled staff

I imagine each of us has our own BPiIT list.

Here's mine:

• Everybody wants to have "rode an elephant" on their resume
• Nobody wants to have "cleaned up after elephants" on their resume
• Training elephants is hard

IT Impedance Mismatch?

I stumbled upon an interesting slide deck, Information Technology Team Dynamics. It summarizes some work sponsored by the Defense Systems Management College in the US Department of Defense.

The deck provides a reasonably detailed picture of work done to analyze team dynamics in IT organizations relative to several personality classification methods.

It's an interesting read for those interested in the topic.

It presents some thought provoking findings. A few in particular caught my attention.

• Preference for intuition was 40% higher in the study group than the MBTI national sample
• Preference for thinking was nearly twice the percentage found in the MBTI national sample
• Feeler and perceivers were underrepresented relative to the MBTI national sample
  

Put another way, the study group seemed to have a higher concentration of people that exhibited an

• increased preference for abstract theoretical information over concrete sensory information
• increased preference for rule-based decisions over consensus based decisions
• decreased comfort with changing course when new information is available
  

These are at direct odds with situations in which

• previous working theories are disintegrating under new market conditions
  
• new information is capable of arriving at ever increasing rates

It would be inappropriate to apply these to IT as a whole, particularly given that the application of Myers Briggs requires some subtlety and care. The basic analytical process can, however, provide some interesting food for thought when mapping out longer term strategies.

How many IT organizations are fundamentally mismatched to the problems they face?

Remembrance of a Blind Spot

Will the consumerization of IT be the PC to your mainframe?

Will it be open source?

Will it be SaaS?

Will it be cheap labor from developing countries?

Will it be something else?

Arrr!chitecture

Ahoy ye Brethren of the Coast,

'Tis Septembree 19th.

Talk Like A Pirate Day

Guard yer letters o' marque if ye be havin' them.

Mooer's Law

No, not cows..

An information retrieval system will tend not to be used whenever it is more painful and troublesome for a customer to have information than for him not to have it.

Calvin Mooer - 1959

The single quote hardly does the topic justice. Should this be an obligatory test question for technology job candidates?

Here are a few links worth perusing
Mooer's Law: In and Out of Context
Mooer's Laws
Mooer's Law

Software Archeology Food: TRAC

MOA - Magazine Oriented Architecture

Andy Blumenthal vents some healthy steam in SOA - Does the Emperor Have Clothes?

He's spot on with his reminder that the focus should be on alignment and relevance, not on SOA.

Once again I ponder the topic of SOA. Once again I ponder the underlying issues.

Then it hit me.

Before I go any farther, let me state for record - I believe SOA has an important place in modern IT. Having said this, it has become corrupted in/by the ecosystem.

I submit a modest proposal for resolving the current state of SOA affairs.

The proposal has two parts.

First, we should reclassify SOA as a pattern. This should help put it into a healthier context, virtually erasing the current list of issues surrounding the topic. There is little glory in selling a pattern.

I am not anti-ecosystem. In fact, I think they play an important role. To ensure the ecosystem is allowed to prosper, I propose a second part - an alternative to SOA.

Magazine Oriented Architecture (MOA)

In broad terms, it is an architectural style designed to align IT with vendors, consultants, and methodology mavens.

In anticipation of the inevitable detractors, here is a brief list of its key benefits.

• It provides a balanced solution for all invested parties.
• It abstracts several existing behaviors into one tidy architectural style.
• It is predisposed for wide scale adoption by IT
• It seems relatively impervious to ecosystem corruption
  

This is by no means an exhaustive list. I leave it as an exercise for the MOA ecosystem to elaborate as they see fit. I serve only to light the spark.

P.S. I almost forgot... I dare not take credit for the term Magazine Oriented Architecture. I'm merely reusing it. The honor of nomenclator seems to belong to James McGovern (What kind of enterprise architect are you?). I'm sure this is no surprise. :-)

The Gen-Y Folks Will Know What To Do With It - Not

Yet Another Technology Adoption Myth:

Our "digital natives" are immersed in technology and therefore predisposed to efficiently adopt all-digital systems and processes.

Put another way, we seem to be on the verge of having a student/user/population base that no longer needs remedial coaxing to overcome technology angst. We will no longer need to exhort the benefits of adopting modern technologies. Its value proposition will be a foregone conclusion by virtue of the fact that it's already in wide-scale use. Our problem will have been distilled down to a simple plumbing exercise.

While the basic concept seems reasonable, it seems to be missing a critical component - empirical evidence.

Are we, in fact, on the verge of a population comfortable with technology? Let's check with the students.

I stumbled upon a wonderfully simple approach one Australian academic used to assess the degree to which her students were ready to adopt online technologies for learning.

In How Digitally-Native are Gen-Y?, Kate Foy relays the results of an informal survey she did with one of her classes. The article also references another post where she discusses online technology angst. Interested readers should definitely take a look.

Here are a small number of takeaways:

• Advanced features like mobile web access are becoming commonplace but often go unused due to cost. The mLearning crowd will probably need to lean on podcasts a bit longer if they want any appreciable market in the short term.
  
• Don't assume the Gen-Y folks 'live' on the net. This is a feature.
• We're still not to the point where lack of paper won't prompt anxiety. This is probably a feature as well.
  

None of these should too surprising...

Alarm Clocks, Coffee, and Enterprises

It's Saturday. My alarm clock woke me up at its regularly scheduled time. It's earlier than necessary, but I don't dare turn it off on weekends, lest I forget to turn it back on for Monday morning.

So I'm up early on a Saturday. It's a good time to make a pot of coffee and read some blogs. One of the articles I read this morning was Alarm clocks, by Seth Godin.

In his article he posts some thoughts on why products often lack the features most people actually want to buy. His comments center around the idea that alarm clocks should be capable of differentiating between weekdays and weekends.

This catches my attention. I grab a cup of coffee.

He attributes the problem to the idea that people are too busy doing their jobs to create compelling products. (I'm paraphrasing - his article is worth a read to get his version)

Despite the coffee, I'm foggy from rising early on this cloudy Oregon morning. My mind starts to explore the topic of why products often fail to meet our true needs and desires. This warrants another cup of coffee.

The problem of creating compelling products is obviously not limited to external products. My current interests lean in the area of improving the ability for IT to create compelling products and services. It's all in the same problem space.

Seth lists one reason compelling products tend not to get created. I think we can expand this a bit.

• Too busy
  
• Too myopic
  
• Too skeptical
  
• Too apathetic
• Too scared
  

Which items in this list contribute to the problem in your organization?

I might not have written this article if my alarm clock had a weekend feature. On the other hand, it might not have been necessary.

When Success Requires Failure

• When success would result in failure

Disrupt Then Reframe

In Disrupt-Then-Reframe Selling: How to Close a VC, Guy Kawasaki references research on social influence from Barbara Davis and Prof. Eric Knowles.

The basic idea is to introduce a non-sequitor into a sales pitch and immediately follow it with a reframing statement. The non-sequitor tends to disrupt critical thinking, which increases the general effectiveness of the reframing.

Two reasons for understanding the technique spring to mind.

1. Recognizing the technique when on the receiving end
2. It might be useful tool in one's bag of persuasion tricks

The second point might sound a bit mercenary. On the other hand, applying this simple technique could save thousands of seconds, which seems a real bargain.

Is Specialization Babel Our Punishment?

Andy Blumenthal has posted an interesting take on the topic of language multiplicity in Tower of Babel and Enterprise Architecture.

Tower of IT Babel focuses on the phenomenon as a byproduct of our natural inclination to compress communication combined with our tendency to branch into specializations.

Is specialization our punishment for losing sight of the bigger picture?

Friendly Reminder

People, processes, tools

(in that order)

Engineering Necessity Pathology?

Andrew Clifford has an interesting series of articles working through some of the big topics in IT.

By big topics, I don't mean SOA, BPM, ITIL, PMBOK, and whatnot. I'm referring to the relationship of IT to the rest of the business environment. I'm referring to the deep structural questions many of us ponder.

The series starts with Journey to the sixth circle of hell. It provides fertile ground for thought.

Not surprisingly, Andrew appears to be presenting the situation as a basic consequence of our nature. Is it premature to think the EA community is converging on consensus regarding this point? Whether it's a systemic behavioral disorder or a natural consequence of societal shifts is yet to be determined.

SOA Isn't About Software

It's about services.

Does IT Hate Itself?

James McGovern poses another round of IT introspection questions in Enterprise Architecture and Holistic Diversity.

His questions provoked a question in my thoughts.

Does IT hate itself?
(and no, I don't mean James - I mean IT :-)

Is hate characterizing it too harshly? Possibly, but it's hard to escape the observation that IT as a whole persists in a variety of self-destructive behaviors.

• Creating processes that predispose the organization to technical and political silos
• Systematically devaluing personal contribution and self worth
  
• Chasing initiatives as if on some whirlwind tour of self-help programs
  
• Listening raptly to vendor sermons and emptying wallets into the collection plate
  

If this were a person we would probably be concerned.

So why the self-destructive behaviors?

• Is it the result of abuse during formative years?
• Is it guilt for past indiscretions?
• Is it a symptom of some form of Borderline Personality Disorder in IT culture?
  

Is this the key to formulating a strategy for an increased focus on people rather than processes?

Governance Marketing

In Replace SOA Governance with SOA Marketing, Nick Malik proposes taking a different approach when motivating developments team to follow SOA standards.

I'm not completely convinced development governance can be replaced with marketing, but I'm also not convinced it's impossible. Regardless, it can significantly decrease resistance to standards.

It seems each of the categories of governance mentioned in Nick's article would be greatly simplified if marketing principles were applied. At the very least, it could help minimize a variety of unhealthy organizational reactions to governance activities. I submit that much of the burden associated with governance is related to managing the reactions to governance.

MTBF: Fear and Loathing in the Datacenter

In Service Level Automation in the Datacenter: Fear and the Right Thing, James Urquhart discusses the FUD surrounding the topic of shutting down servers.

I am conflicted.

I agree that most IT shops have an unhealthy aversion to shutting down servers. Naive uptime metrics don't help, neither does the tendency for mistakes to get baked into our cultural DNA.

Having said this,

MTBF - ouch - I made the mistake of believing these numbers once upon a time. I know of one sysadmin that gave a whole new meaning to the term "reboot" - literally, give it a good swift kick, then scramble like mad to write it to tape.

I doubt many server managers will be swayed by quantitative evidence that devices can survive power cycling.

Here's my modest proposal,

Don't hesitate to reboot any machine under warranty if the repair time won't put an SLA in jeopardy. Rejoice if it results in a warranty repair. Rejoice because it create the necessary feedback to vendors. Rejoice because it increases leverage in future vendor negotiations. Rejoice because failing during a scheduled reboot is better failing at 3am on Sunday during that big production cutover.

25+1 Questions a Chief Executive Should Ask About Software

In a recent CIO Article, 25 Questions a Chief Executive Should Ask About Software, Capers Jones provides a host of statistics and general opinions on key aspects of software as it applies to companies.

First came a quick scan of the article. At first blush, the statistics were quite impressive (I know - I know - there's that S* word). The mapping of software function points to timely delivery, budget performance, and project cancellations caught my attention.

I decided to make a second pass. This time through, I was surprised that many of the numbers didn't match my own experiences, particularly those related to perceptions of quality and service.

No matter - statistics, opinions, etcetc... It's all good. At the very least, it does provide an interesting overview of some of more interesting high-level numbers regarding the relationship between a company and its software. I bookmarked it before finishing the article.

Then I read the last couple paragraphs. One of the leaps of logic goes something like this: if you can't get these types of numbers out of your organization, maybe you should consider outsourcing. Well ok, maybe it's an option. Having said this, what confidence do you have that you can execute an outsourcing maneuver?

Perhaps we should add another question for the CEO to ask.
What am I doing that is impeding the ability for my organization to provide these numbers?

Just a thought...

"CXO" - Error: string too short

In Does the World Need Another Chief?, Tom Davenport writes about a Chief Analytics Officer position. He asks if there aren't alternatives for driving analytics short of creating another C-level title.

A 2005 article from Computerworld, CIOs say ciao to CAO and CPSO, attempts to provide a rationalization for this type of position.

Not surprisingly, Wikipedia has an entry for the title. A Google search for "Chief Analytics Officer" yields 217 hits. I'll let these two data points speak for themselves.

I won't debate the relative merits of the title. I'm interested in a much larger question.

As we flatten organizations, should we be considering an initiative to expand CXO string buffers?

The three character limit is obviously inadequate. We have a few instances of four characters, but these seem more like short-term fixes. We can hold out a little longer if we allow numbers and punctuation characters, but this too seems like a sort-term fix. Resorting to Unicode doesn't solve anything - we're still faced with the need to expand the buffer.

I'm open to ideas...

Qualitative Evidence Matters

An article by Bob Sutton, Evidence-based Management Doesn't Mean Just Quantitative Evidence, provides an interesting reminder of circumstances where qualitative evidence is warranted.

1. When you don't know what to count
   
2. When you can count it, but it doesn't stick
3. When what you can count doesn't count

These seem worth reiterating in the world of IT.

Bridge Building and IT Failures

In Enterprise Architecture and Why Do Things Fail..., James McGovern ponders failures, methodologies, competencies, etc...

In the article he asks what would happen if engineers were asked to build buildings like we're asked to write software (or anything else in IT for that matter). He lists several factors that, if applied to bridge building, would cause the bridge builders to fail. I submit that many bridges have been built under the constraints listed.

• Limited budget - all budgets are limited
• Political restrictions on tools - try using non-union labor in certain states
• Short schedules - ask the Army Corp of Engineers about building bridges during wartime
  
• Things that have not really been done before - all bridges are different
  
• Requirements changing on the fly - all requirements are imperfect, therefore change
  

Don't get me wrong - it's sheer insanity sometimes. Likewise, my counter-examples are overly simplistic. Nevertheless, it's unlikely these conditions will change. We will always be constrained by budgets, schedules, tools, and whatnot.

I don't think these constraints construct our failure. There seem to be sufficient examples of success under these conditions. We should probably look elsewhere for solutions to failure.

BugLabs - because I need another gadget

Bug Labs BUGBase

Make Progress

or it will be made for you...