I love magazines–big time–last time I counted I was regularly reading over 20 magazines. Visitors to Casa Strohlein have been known to ask “what’s with all the zines anyhow?” I know that I am definitively old school in actually reading magazines, so I have to admit a bias toward Alltop, Guy Kawasaki’s new venture, self described as being a “digital magazine rack of the Internet.”

Alltop is a hierarchical aggregator of web content that, at the top level, does indeed look like a digital magazine rack with topics ranging from ADHD to Yoga. Once you click on a topic, you are taken to a topical site that aggregates Alltop’s choices of feeds for that topic. Nothing fancy–just a quick way to find all the feeds that Alltop deems “important” for a given topic. Alltop claims inspiration from popurls, a creation of Thomas Marman that aggregates the latest and greatest web-based news and buzz.

One intriguing aspect of Alltop is that they are totally candid about how they select content for inclusion–how many aggregators would admit that they “take care of friends” (people who help them) as well as underdogs and unknowns. In fact, they shamelessly tell you how to become a friend. They also freely admit to a bit of sensationalism to garner attention. One caveat–Kawasaki is the master of tongue and cheek, so one never knows what is “live” versus what is “Memorex” in his comments. You may or may not “like” Alltop’s approach to content selection, but you definitely know what it is–no algorithms or software magic–just plain old human selection, adeptly depicted in this sketch.

Alltop is a great reminder that adding value to content doesn’t have to be rocket science–the mere selection and organization of quality information in the era of exabytes of “infosludge” can be hugely valuable to some audiences. Second, transparency is a good thing–let your audience know how and why you select content for publishing. Finally, on Kawasaki’s blog, a reader asked why the lack of personalization and other bells and whistles?–the response–”because we wanted to ship.” His blog is full of product ideas, suggestions, and comments from users that Alltop would never have heard if they were still laboring to make it “just a little better” before launch.

Particularly interesting are the posts where users ask for a change or addition and Guy replies with “done.” That is about as agile as it gets. Alltop isn’t a gamechanger or paradigm shifter, but I think it is illustrative of some core principles of product creation in the new era–focus; simplicity in user experience; listening to, conversing with, and responding to customers; and transparency in operation–good stuff.

Share and Send

When I wrote my recent post on bad marketing, I was concerned that I had used all the “good stuff” for examples–a drag since bad marketing is a favorite topic. But not to worry, Microsoft came to the rescue with a marketing debacle, called  , that is like watching a slow motion train wreck. Project Mojave takes what I call the “I can’t believe its Folgers” approach, taken from those 80’s era ads in which Folgers was swapped for “premium” coffee (actually there was no such thing in the 80’s) in high-end restaurants. The drinkers presumably thought that Folgers was swill (surprising–what’s not to like about dessicated, freeze-dried, crystallized coffee..) and were visibly surprised when told they were drinking Folgers rather than the premium coffee they expected. It’s a brilliant strategy–let the whole world know that you know that people don’t like your product, then dupe some rubes into stating that they actually do like it and play it up big time.

Not to be outdone by Folgers, Microsoft set up a marketing initiative called “Project Mojave” where a demonstrator showed a disguised version of Windows Vista to unsuspecting viewers who had not used Vista, but had negative opinions based on what they had read or heard about the operating system. The audience was told that they were viewing Microsoft’s next generation OS, code named Mojave (get it?). At the culmination of the demo, the audience gushed over how cool it was only to find out that they had been punked. After oohing and aahing over the demonstration they did the “I can’t believe it’s Vista thing.”

In one fell swoop, Microsoft made a group of potential customers look uninformed, proved that you apparently can put lipstick on a pig, and denigrated the people that write about their products–that is quite a coup. What is even more disturbing is that the whole production looks like a high school production–actually that’s not fair–I’ve seen much better high school productions.

If you are snickering at Microsoft right now–don’t. Creating and marketing technology-based products is hard and rarely done well, at least by my standards. Microsoft is frankly no better or worse than most of its competitors when it comes to marketing. What you should be doing right now is wondering what your own marketing departments have up their sleeves–what exactly is “Project Desert Rat” anyway? More importantly, if your product is not meeting your expectations in the market place, fix the product, don’t throw marketing “lipstick” at a “pig” product–you’ll only embarrass yourself..and the pig.

Share and Send

Technology for accessing enterprise information has gone through a steady evolution over the years, creating both big opportunities for enterprises as well as big headaches. In the early days, information was locked up in big transactional systems that required programmers to retrieve it. Databases were stewarded by database administrators who gravely intoned the need for entity relationship diagrams and standard naming conventions. Data was relatively clean, but you could only see it when it was doled out on green bar printer paper.

Next, vendors of so-called fourth-generation languages and later decision support systems (yes I am that old) came along, promising to hand the keys to the data cookie jar to end users. The result was a profusion of little data bombs charmingly called “extract files” that multiplied like rabbits. Then came PCs and office applications and the torrent of information became a deluge. Along the way, those of us in the technology business discovered a nasty surprise–as applications and data became more distributed, naming conventions went out the window creating a veritable potpourri of incompatible data. In effect, enterprise information access had evolved from rigidly controlled, but inaccessible to widely available but unusable–clearly not very Darwinian.

As this information Tower of Babel has evolved, semantic technology companies have struggled to find a toe-hold in the enterprise space, so it is perhaps, not surprising that the organization and integration of enterprise and other organizational information and knowledge appears to be that foot in the door (sorry about all the “pied nu” references). In effect, rather than going back and “fixing” all the data naming inconsistencies, one can apply a semantic “layer” to help systems figure out, for example, that a boot in the UK is the same as a trunk in the U.S.

I met with one semantic technology company, TopQuadrant, that is getting traction in enterprises, a few weeks ago in the NASA Ames Research Center to talk about their technology. Top Quadrant sells TopBraid Suite, a set of tools for building and deploying semantic applications. TopBraid includes Ensemble, for creating and managing controlled vocabularies; Live, a server for integration and access to information from disparate sources and a client that uses Flex for interface creation; and Composer, a graphical development environment.

Collectively, the tools can be used to develop applications for combining diverse structured and unstructured information, searching disparate content sources, creating and managing controlled vocabularies, management of policies and regulatory requirements, and probably a host of things that no one has yet figured out.

Projects that TopQuadrant has supported range from the true rocket science, creation of a data management scheme for the NASA Mars landing expedition, to the more down-to-earth, including integration and rationalization of information for aviation companies, pharmaceutical companies, and government agencies.

Selling semantic technology can be difficult–it requires a fair amount of time and effort to become conversant and it is frankly  hard to find many people that want to talk about ontologies and triple stores. Moreover, Tim Berners Lee arguably set back the market with his semantic web pieces as he set the bar almost impossibly high. On the other hand, post 9/11 intelligence and Web 2.0 developments have raised awareness of semantic technology.

What is encouraging about TopQuadrant is that it has taken the approach of creating an enabling platform for applying semantic technology to a variety of enterprise information challenges, and has tackled something that is both practical and doable. I think of tools like TopQuadrant as an enabler to solve both tactical “my data won’t talk to your data” problems, but also more strategic applications such as extracting meaning from complex, high volume information sources. Expect to hear more from TopQuadrant and other semantic tech vendors in the future.

Share and Send

I’m always on the lookout for interesting yet practical applications for XML, so I couldn’t pass up an opportunity to talk with Mark Logic about work they are doing with the Army, specifically the Battle Command Knowledge System, based on Mark Logic’s XML repository. In a nutshell, the BCKS enables soldiers about to embark on a mission to search the Army’s Warrior Knowledge Base, using Mark Logic technology to find very granular, pertinent, and trustworthy information. The system is a knowledge and information sharing tool that enables soldiers to quickly find information and compile it into virtual documents. While the term “mission critical” gets bandied about in the business world, in my book, this application is truly mission critical.

It turns out that the Army has actually had a metadata standard, Department of Defense Metadata Standard (DDMS) since 2003, so they are old hands at XML and were able to leverage that standard in BCKS. Even more interesting is that the BCKS also includes the ability for soldiers to rate or rank information as well as comment on it, making it a contender in the Web 2.0 category as well. In all, BCKS looks like a state-of-the art knowledgement management platform–an achievement that most enterprises would likely envy. Even more impressive is that BCKS operates in bandwidth-starved and otherwise challenging environments–not cushy corporate offices.

If you are wondering why I’m writing about Army applications of XML, it’s because I view daily life in the business world as a series of missions–a sales person going on a call, an M&A person vetting a prospective purchase, a CEO headed to a board meeting, etc. etc. In most if not all cases, the “business soldier” wants and needs the best, most reliable information, and with all due respect, that isn’t likely to happen via Google without a lot of work.

So if you own a content base that supports the “foot soldiers” of the business wars, think about whether full text search is, in fact, good enough for the mission at hand. During our conversation, Mark Logic mentioned that they had leveraged knowledge gained from working with publishers in this project–now it’s the turn of publishers to learn from the Army.

Share and Send

Most business organizations have business plans and objectives and believe they are pursuing those in an orderly fashion. Yet, when you take a closer look, in fact, many are actually “muddling through”–a nice way of saying “making it up as they go along.” I learned all about muddling through while studying urban planning at University of Tennessee, and it recently struck me that there are some interesting parallels between urban planning and product and software development. At UT I learned that there were two primary ways of going about developing a master plan for a town or city:

1. Rational, comprehensive planning

2. Muddling through

The former is an approach whereby the planning organization defines comprehensive goals and objectives, evaluates alternatives, decides what to do, then implements, followed by feedback loops to monitor success or failure. If you are thinking it sounds suspiciously like waterfall software development, you are correct. Muddling through, (not to be confused with the creation of Mojitos), on the other hand, also called incremental planning, is a process whereby the construction of an urban plan is broken into smaller pieces, distributed out to multiple parties, then built using a process of negotiation among those parties and incremental creation. If you think that this sounds much like agile development you would actually be wrong. Why? Because you have fallen into the trap that many do in assuming that agile development involves starting with only a hazy notion of what is to be accomplished, then figuring out what is needed during the actual development process.

Interestingly, in recognition of the shortcomings of rational planning and muddling through, urban planners developed a third alternative called “mixed scanning” which adopted the rational approach for defining the plan, then used incrementalmuddling through processes to actually implement the plan–that is what “well formed” agile looks like (and why I like it–it borrows the best from both worlds). So save the muddling for the Mojitos and make sure you’ve got a product development process that blends rational and incremental approaches in the right mix.

Share and Send

I’ve been a long-time critic (and some times victim) of vendors who create proprietary, closed systems, but some recent developments are making me rethink my aversion to those systems. By closed systems, I mean those where a single vendor controls all of the components by making it impossible to use third party hardware or software (or content).

My earliest experience with closed environments came courtesy of IBM (actually the Pez candy dispenser was my first experience , but IBM works better for this post). Back in the early eighties, IBM’s various divisions delighted in selling systems that would not inter operate, no way, no how. Think System 34, 36, 38; MVS and VM; Displaywriters and 5520s, just for starters. Once you were stuffed to the gills with all this gear, you had to buy dodgy software like DISOSS and learn about things like LU 6.2 and SNADS to try to make it work together–I am not making this up and I have the scars to prove it. The penultimate moment was when I was invited to a big unveiling of IBM’s SAA (System Application Architecture)–the mother of all integrating software, a sort of “uberware” for all the disparate systems. Fortunately, I changed jobs in the nick of time and escaped to the relative tranquility of a Mac/DEC shop.

Fast-forward to the present, and most of us are too savvy to let ourselves get trapped into closed, proprietary systems and environments–or are we? Two of the better content purchase and use environments out there today are closed and proprietary, namely Apple’s iPod and iTunes, and Amazon’s Kindle. Both offer seamless purchasing, download, and use of content, but neither enables use of third party stuff except in the most tangential manner–in both cases you buy most everything from the vendor.

As a long time ranter about all things proprietary and closed (the mere utterance of the words “proprietary interface” send paroxysms of horror and revulsion through me), it is a bit unsettling to have to rethink my stance, but I reluctantly admit that closed environments do have certain advantages. One big advantage is that vendors can think holistically about all aspects of the user experience as Apple and Amazon clearly have. They don’t have to worry about another vendor dropping the ball on design, performance, support, or any other aspect of the experience as they own it all. They can also optimize all the components, put functionality where it works best, and otherwise fine tune the entire system in a way that open environment participants can not.

At this point, I can hear the content providers out there salivating over the prospect of end-to-end ownership of their customers’ content discovery, acquisition, and consumption, but hold on for a moment. I forgot to tell you that there are three conditions that a vendor has to meet in order to be successful with a closed environment:

1. They have to be capable of creating a simple-to-use, elegant device for reading, listening to, or viewing content. And it helps if the device has a serious “cool factor”.
2. The vendor’s content has to at least appear to be infinite in breadth and depth and unmatched by competitors. Apple doesn’t provide every recording ever made via iTunes, but now that we have debunked the Long Tail, it doesn’t really need to does it?
3. The vendor has to be able to price the offering at a level that is competitive with lower quality competitors to counter the “good enough” syndrome.

If you can answer “yes we can” to all three, then strike up the band–if not, keep pounding the open API and partnering pavement…

Share and Send

Why indeed–perhaps because “innovation” may not be what you think it is. Like many people, I am guilty of sometimes using “innovation” and “invention” interchangeably, but John Seely Brown (and others) would argue that they aren’t the same. He defines “invention” as the creation of new ideas, while “innovation” is about the commercialization of those ideas–taking an invention into the market. There is more than semantics here–Brown argues that you can’t manage invention (you can nurture it) but you most certainly can (and must) manage innovation. Clearly, failure to distinguish between the two could lead to frustration and misguided efforts.

Brown commands an audience for these notions as his former day job was the head of Xerox PARC–the hotbed of many a cool invention (graphical interface, mouse, personal workstations, etc. etc.) that led to many important innovations–unfortunately mostly by others–notably Apple and Microsoft. What is interesting here is that the oft-heard charge that Microsoft isn’t innovative, is, by Seely’s definition dead wrong. Microsoft has done a dandy job of bringing others’ inventions to market and making a whole lot of money in the process. What Microsoft isn’t, is inventive–Windows, nope; SQL Server, nope; Exchange, nope–you get the point.

Paradoxically, Google, on the other hand, could be called inventive, but hardly innovative. While Google has created (and bought) a bunch of nifty ideas for applications and products, their cash cow remains their ad-serving search engine. In other words, they flunk Seely’s innovation test as they have not been able to innovate around very many of their cool ideas. So the epic “clash of the titans,” Google vs. Microsoft smackdown could, in effect be seen as a test of whether invention trumps innovation, or vice versa.

Regardless of whether you buy Seely’s definitions or my application of them, if you’re interested in innovation you owe it to yourself to check out Outsell’s Signature Event, targeted to CEOs, COOs, presidents and managing directors in media and information. The September conference agenda is all about how information providers can drive innovation.

Share and Send

Having lived with, written about, and suffered through over 20 years of information technology evolution, one challenge that never seems to go away is that of gauging when a technology is mature enough to be viable. Jumping on the wrong technology bandwagon (anyone remember client/server computing) can be costly and hazardous to one’s career.

I’m a big fan of models, so I set off to create one for assessing the maturity of various technologies.  My model was to be called the Market Maturity Model (3M) but I could smell the lawsuits so it became the Strohlein Market Maturity Model (SMMM). By now you’re likely groaning that you finally reached level 3 in SEI’s CMM and now here’s another one with yet another M no less–bear with me–this is easy.

What is cool about this model is that one merely needs to attend a conference on the chosen technology to assess market maturity. A quick perusal of the attendee list, a spin through the exhibit hall, and a sprint through the agenda is all that is needed to “feed” the model. Here’s how it works.

There are three stages to the SMMM–the first is the most perilous and can be identified by conferences in which there is a preponderance of vendors talking to vendors (to convince each other that a market exists). Actual users are scarce and wary, and vendor bloviation is high. Technologies at this stage of market maturity usually fit the description “if it works, it isn’t state of the art.”

At the second stage, we see vendors pitching to potential buyers (to convince them that a market exists). Technologies at this stage of maturity are less perilous, but still not a guaranteed success. Vendor pitches tend to be along the lines of ” our symmetric, multi-flixulated flabogaster is exactly what you need to leverage your IT assets and drive IT/Business alignment.” Caveat emptor…

Finally, a mature market is indicated by a conference in which actual users are talking to users (convinced that a market exists). This is the “rubber meets the road” stage where we finally get some tangible evidence that the technology not only works, but has value. Vendors can finally point to customers that have used their products without destroying their businesses.

By now, you are probably thinking that I’m counseling you to wait until stage three to jump on board with a given technology, but there is one big problem with that–if you wait that long, your competitors have already eaten your lunch by jumping in earlier. Now do you see why CIOs and CTOs look haggard and stressed? Not to worry–I’m putting the final touches on my new model–this one helps you calculate the probability of getting fired when you implement a technology at stage one or stage two of the SMMM. Don’t you just love all this great technology!

Share and Send

I’ve run across mentions of India’s dabbawalas several times in recent years, most recently in the July 12th issue of the Economist, and remain fascinated by what this collective has achieved without technology, fancy business models, or any of the other trappings of modern businesses. Imagine an organization with 5,000 workers that makes 170,000 deliveries a day with 6 sigma accuracy (that would be 99.9999%) using almost no technology– computers are used only to enable customers to place orders via a website or SMS.

The collective dates back to the late eighteen hundreds, and involves an intricate system where the dabbawalas (translation: one who carries a box) pick up lunches prepared at office workers’ homes or by dabbas (”box makers”, a sort of caterer), take them  to central sorting locations from where they are then transported to the office workers’ place of work. The boxes (actually usually cylindrical containers) are marked with a coding scheme that indicates those going to a similar location.

As a long-time fan of simplicity and lowest-tech-possible solutions, I can’t help but be impressed and enthralled. As the Economist points out, while most modern businesses focus on business processes, analytics, and computers, the dabbawalas have achieved their remarkable success by focusing on what Columbia University’s Richard Nelson calls “social technologies:” the rules, structures, and processes that humans use to organize themselves.

Nothing succeeds like success, and the dabbawalas are finding themselves in hot demand as management consultants and business gurus try to figure out how to extract and sell the no-tech, high accuracy DNA. My guess is that most of the “wannabe dabbawallas” will not find the magic elixir that promises to turbocharge their businesses, as the lure of applying just a little more technology, a smidgen more data, and a dollop of analytics is just too attractive, and the work of assembling a manual system such as the dabbawallas use is, well, hard and not terribly sexy, at least not until now…

Share and Send

A while back, I chaired a panel on agile corporate cultures and in preparation for the event, the panelists and I all talked about how we each did agile product development. What was surprising was that we all used different approaches–different iteration lengths, different approaches to creating and managing stories, different stand-up formats, etc. etc. In effect, we all went to the “agile store” and picked out the practices that worked for us. In contrast to this mix and match informality, I can point to any number of forums in which debates rage over Scrum versus XP versus Adaptive Software Development–versus whatever–in effect, a continuation of the decades-old methodology wars. My advice–don’t listen–find your own way.

I’ve always considered agile development to be a collection of practices and more importantly a state of mind that embraces customer-focused, iterative product development and continual improvement–think philosophy, not methodology. The beauty of agile is that you can create your own approach–actually using agile to refine and evolve your way of creating products. In a really good agile project, it is likely that the later iterations will be done differently than the earlier ones–in fact if they aren’t, you are either really, really good, or you aren’t practicing continual improvement–a key tenet of any form of agile.

I think one big barrier to going agile is the perceived lack of a identifiable process–it feels like the wild west when you first get started and it is really different than the waterfall methodologies that you may be used to. But in reality, the dirty little secret that many agile evangelists don’t like to talk about is that agile actually incorporates most of the things you learned while “going over the waterfall” (sorry–couldn’t resist–don’t blame me, I didn’t pick the name). Agile includes all of the components of waterfall projects–contrary to popular belief, you do create requirements–they are just done iteratively not all up front where you will inevitably get them wrong. Ditto for coding, testing, and launch–again, they are just done iteratively. The key, again, is assembling the pieces what will work in your organization, then continually refining them.

If you are sitting on the fence on agile, there are a couple things you can do to try to make a go/no-go decision. First, read a good book on the topic–O’Reilly’s The Art of Agile Development is a really good, grounded explanation of how agile works–it tends to focus on XP but provides a well-rounded view of agile practices. Second, find an agile development consultant–not the big bucks guys in suits, but a down-on-the ground developer who has used agile successfully in a number of projects. Finally, before you hire the consultant, have them read this post. If they think I am full of beans because they have a “tried and true methodology that always works”, don’t hire them.

Share and Send