More pragmatic advice from James McGovern, this time about top-down versus bottom-up IT initiatives. In other words, CEO mandate versus workers-know-best. Both are needed, but when is which one appropriate? My favorite quote:
One of the more interesting things is that a person debating top-down vs bottoms-up needs to take into consideration is historically which one has had better results. Of course, top-down has the advantage that even mediocre delivery will be declared success while bottoms-up mediocrity will probably result in throwing daggers.
Consideration? Sure, OK. That's the politically expedient thing to do for bottom-up... but it misses a vital point: is the technology something that people will absolutely love? If so, mediocre implementation will be forgiven, and the top-down criticism will eventually be won over. As I always say, its easier to get forgiveness than permission.
I was a part of multiple skunk works projects at Stellent, some of which got me into a teensy bit of trouble with executives. Some of these projects languished, but many of them took off like gangbusters because people loved them. In the words of Cathy Sierra, these systems helped people kick ass. In the words of Clay Shirky, they were systems where people took care of one another, and that more than anything else guaranteed their existence the next day.
James feels that Outsourcing, CMMi and/or PMI, and Identity Management are best done top down... I agree with everything but Outsourcing, unless its on a large scale. There's nothing wrong with giving your middle managers a budget to outsource. Heck, I see nothing wrong with giving every developer a $5,000k budget, and let them "outsource" some tricky code to another developer who can do it in half the time. Or buy a awesome monitor. As long as there's modest oversight, and your developers aren't idiots, there's very little harm that can be done.
James also says Agile, SOA, and Open Source are best done bottom-up... whereas I agree its easier from a bottom-up perspective to sneak-in cutting edge technology, I'm not sure if its best. This problem is by no means unique to the software world. Its the same age-old question: when should I let my employees take the initiative? The same rules apply across the board, whether the "initiative" is a software methodology, an innovative marketing plan, or sales incentives. The two most important questions are:
- How does this decision affect the rest of the organization?
- Do the people making this decision fully understand its risks and benefits?
No matter what you're doing, the answer is always the same: unless your employees are bound by a genuine shared purpose, bottom-up initiatives will do more harm than good! In a typical company, you'll be OK if your IT department sneaks in Agile techniques... but in a dysfunctional company, you run a significant risk of making things worse. This is bad, because in dysfunctional companies, bottom-up initiatives are sometimes the only way to get anything done.
Unless you have some folks at the bottom who have a 50,000 foot view of the entire company, or are genuinely dedicated to helping your customers kick ass, then bottom-up initiatives are just spinning wheels on systems that go nowhere. If your IT department wants to take the initiative, they better be keenly aware how their changes effect everybody else. They had better understand that all change has positive- and negative-effects, and keep track of them all. Finally, they had better have a plan to roll-back the changes, should the negatives dominate for too long.
This way, you're more likely to have bottom-up initiatives that kick ass! Also, you'll have a nice paper trail of successes to prove its value to your inevitable critics.
Its news like this that makes those with the future of the race at heart despair...
According to John Battelle, two burglars broke into Mr. Bigg’s Family Fun Center to crack open the safes. However, they ran into a bit of trouble. Lucky for them, Google was there to help:
The burglars tried to disable a security camera by repeatedly spraying it with WD-40 — it only cleaned the lens — and spent an hour and 15 minutes trying to open three safes...
They finally did a Google search for “how to open a safe” and “how to crack a safe” on a computer in the next room...
...the Google query apparently worked; they haven’t been caught, and they did get about $12,000.
Lucky for them, they used Google. Previous would-be-safe-crackers used Yahoo search, but were unsuccessful.
I would laugh, but I'm just so utterly stunned...
Update: If you got here from James McGovern's blog, you should read this as well.
OK, Mr. Process Perfection (and File Net user) Mark Masterson has responded to my anti-standards screed, and raises some interesting ideas. Instead of following the RSS hype, skip to ATOM for an ECM standard. I have to say, ATOM plus the REST-based ATOM Publishing Protocol is an interesting idea. If only I didn't dislike REST so much I might endorsed it.
But I still sense danger for these reasons:
- A resource-oriented interface to an enterprise content management repository may not be the best approach... especially when you need to do things like workflows, subscriptions, conversion, multiple taxonomies, or basic business process management. You need a service-oriented interface that focuses on the action, not the back-end implementation. See my anti REST rant for more info.
- The response that search doesn't matter, and to just "Use Google" to find content is beyond glib... using Google means losing metadata. Instead, the interface should make it brain-dead easy to discover lists of items based on metadata, as well as "related content" in nice little buckets. If we're just going to kick metadata in the head, we might as well just use ZFS over iSCSI, and call it good.
- I can't say for certain yet, but I'd suspect it would be tricky to embed multiple content items in one feed item, as well as binary data... Can APP be used to "chunk" files larger larger than 2GB? Since APP is so resource-based, what if I want a batch check-in of multiple resources for better performance? What about syndicating secure data out of the repository? Again, I sense danger...
For the record, its wasn't tough to get Stellent to output RSS feeds. That only took a few hours... What was a royal pain was discovering how rotten most RSS readers are, and trying to tweak the output just right so that everybody could consume it.
Switching to ATOM may be a tiny bit tougher because it supports more metadata... its an obvious replacement for RSS, but I think a few more pieces need to be added to the "ATOM Stack" before it could do as much as WebDAV. Search, specifically... and I'd push towards a service-oriented publishing model.
Regarding the security layer... you could "punt" and rely on wacky XCAML/SAML, but that just seems to complicate things beyond necessity... and that ain't good for anybody except security consultants. A simpler idea would be an ATOM and LDAP Mashup, and make every single resource identity aware. If done right, you can authenticate with the enterprise LDAP server, and authorize with the department's federated LDAP server. Seems pretty simple to me...
And thanks Mark, for not turning this into a Nerd Fight.
From the don't-tick-off-Zeus department...
A door-to-door religious book seller was struck down by lightning in South Florida yesterday. This is despite the fact that it was a clear day, and hadn't even rained. He's recovering in a local hospital, but hasn't yet regained consciousness. Hopefully he'll be OK in a few days.
The phenomenon is called dry lightning... which means that the air is so dry that rain from higher elevations evaporates before hitting the ground. Thus, people don't know its raining, and don't take the normal precautions they would during a storm. Unfortunately, lightning doesn't evaporate...
The entire airline industry is facing serious management problems... union trouble, aging pilots, bankruptcy, canceled flights, and the like. Their software is woefully outdated, and the latest security laws are causing people to check twice as much baggage... which naturally leads to significantly more lost luggage...
Now, logistics ain't rocket science, but I am sympathetic that it's difficult to get right. However, there are dozens of industries that have made a significant profit by simply getting things from point A to point B reliably... so I'm mystified why the airline industries are struggling.
Ask around... it isn't easy being a Northwest Airlines customer... just talk to anybody who has to travel through Chicago. A lot of their pilots are nearing 60, which is bumping up against the mandatory retirement age. There are also strict rules about how many hours a pilot can fly in the month. Therefore, if you want to minimize chances of a canceled flight, book it no later than the 15th of the month.
You'd think that Northwest could have seen this coming five years ago and hired more pilots... sadly no.
Seriously, it could be a good move. FedEx already has all the software and a good chunk of the infrastructure. They have a brand name that screams "reliable," and relationships with airplane manufacturers. They just need a handful of the best and brightest execs from Northwest so they can learn the nuances of the travel industry... then they could be the 100% business infrastructure solution.
They'll print out your reports, ship a crate of them to your destination, and even pick you up from the airport in one of their stylish trucks! And if you can fit into their one-size-fits-all travel pod, they can guarantee delivery.
Like I said... not fully baked. Just the rantings of a frustrated customer.
Just a brief rant before this gets out of hand...
James McGovern and other are back talking about Enterprise Content Management standards... his latest advice is to take a closer look at RSS or WebDAV as a standard. Others chimed in that there may be something there...
If I may offer some advice: HOLY CRAP, NO!
RSS is a nice model for consumption of streams of text, but it has many many problems. It doesn't have revisions. It can't handle large binary data streams. Even by jumping to ATOM and adding metadata, you still can't do searching, editing, or contribution for crying out loud. In a word, NO!
WebDAV is good for quick changes to web files on a shared filesystem... but authentication is a mess, it cannot handle dates properly, nor metadata-based search, nor metadata-based contribution without massive kludges. AIIM says that Records Management will be a huge factor for why people purchase ECM... and WebDAV just doesn't have the metadata muscle to keep up. In a word, NO!.
Also, I believe Laurence Hart completely misses the point of Billy Cripe's comment. Standards only enable business if they have sufficient features. The entire point of a standard is that you lose functionality by standardizing, but you gain flexibility. The question is, does that help more than it hurts? At present, it hurts more.
I totally disagree that a standard -- or anything else for that matter -- is inherently good. If they were, then everybody would stop whining about the lack of ECM standards, and freaking use one of the four existing standards. Stop worshiping technology for technology's sake, and make something useful.
The four existing standard are crap, and the next 4 will be as well... unless:
- The analysts stop letting Microsoft get away with calling Sharepoint an ECM system,
- The top 5 (or 10) ECM vendors get together and decide what a real ECM standard needs to be useful, and
- All these niche repositories either write an interface, or go away.
Like I said, probably not before 2009. Those niche products are still pretty useful, even if they aren't ECM.
Alternatively, a large neutral company -- like BEA, Sun, or Sybase -- designs a "universal connector" for each specific ECM system. Several small firms have made these, but they were bought up and shut down by Documentum. IBM used to have a good one for WebSphere, but it also has languished because it means people could dump Content DB or FileNet whenever they wanted. Great for the WebSphere team, but bad for their ECM team.
And forgive me if I find Microsoft, EMC, and IBM to be completely disingenuous when calling for decent ECM standards. Those 3 companies either blocked decent open standards, or shut down universal connectors.
Many time vendors try to sell Business Process Management (BPM) along with Enterprise Content Management (ECM) as a means of helping companies get their information process under control. However, there's a huge disconnect in both the buying habits and implementation schemes for these two systems.
After many years, organizations finally admit that they need to get their content under control, and support ECM as enterprise infrastructure. They even feel good about using hosted solutions for their content management -- good news for 3 of my clients.
However, BPM is still stuck in the fiefdom stage. Very few implementations are company wide: they are highly departmental. Despite management believing BPM is highly useful, there is a strong problem with lack of ownership, which may be a big cause of the percieved lack of success.
Whereas individual departmental groups will find BPM highly useful... but without enterprise-wide owners, you'll be unable to get enterprise-wide information process under control.
Also, three answers in the original idiot test are wrong... how deliciously ironic... Snaps to the first commenter to find all three, and explain why they are wrong.
Update: There are now five versions of The Idiot Test, by Ryan Curtis:
- The original Idiot Test
- Idiot Test 2
- Idiot Test 3
- Idiot Test 4
- NEW: Idiot Test 5, aka The Ultimate Idiot Test!
- Idiot Test 6? Not available yet, but will be up on ryancurtiscreations.com some time soon...
Thanks to Ryan Curtis, the creator of these tests, for keeping me updated.
Note: The idiot test 4 is a bit trickier, so I put together a official answer guide for the Idiot Test 4 with all the answers... I also put together the official answer guide for the Ultimate Idiot Test. Naturally, its cheating to use them... but if you're stuck, have at it!
UPDATE: Several commenters below claim that this technology never existed. Also, the man who invented it -- John Pereless -- took money from investors, and never gave them anything in return. I cannot speak to either claim... but I usually urge caution when it comes to products "too good to be true."
Called the Hawk-10, it uses an array of finely tuned microwaves to precisely break the hydrogen bonds in the long hydrocarbon molecules of solid plastics. This breakdown yields simpler, smaller hydrocarbon chains, such as oil and natural gas.
In their tests, you could grind up one steel-belted tire to yield a gallon of diesel fuel, two pounds of natural gas, two pounds of steel, and a bit of carbon ash. It can easily strip insulation off of wires, leaving scrap metal behind. Its value in the automotive recycling field is obvious... its less obvious if it makes sense to do this for all recycled plastics.
No word yet on the toxicity of the byproducts, but its possible that with a bit of tuning they could alter the molecular structure of the plastics more carefully.
I think I found my favorite Flickr photo set, Flickr's 100 Best. A sample:
Look at the mathematical puzzle below... in it you should be able to move one single matchstick to create a mathematically correct statement with Roman Numerals:
Single slanted sticks are not allowed: there must be 2 slanted stick in a V to represent 5, and a single non-slanted stick to represent a 1. You have 3 minutes... GO! The original blog article has the answer.
Next, try this one:
A bit tougher, huh? In studies, only 43% of people could solve the second puzzle in under 3 minutes. However, 80% of people with lateral prefrontal damage to their brain could solve it! Mental patents get all the fun...
In theory, that part of the brain is important for determining how to solve a problem, which is called cognitive guidance. It's essential for doing ordinary math quickly, but it hinders problem solving when you don't have a rigid framework to help you. In other words, a healthy brain makes it difficult to "think outside the box".
Thus, some brain damage patients are better at letting their minds wander and solve problems in any way that seems to work for them... which on occasion helps them see things that other people do not. In other cases, it makes it extremely difficult for them to solve problems within a framework with apparently arbitrary rules. I bet Kafka would have nailed the second puzzle...
So, chime in, folks! Who else here solved the second puzzle quickly, and might need color-coordinating tips for their tin-foil hat?
There's something not quite right about this video...
Actually, there's something not quite right about this band...
and yet I cannot look away...
Its like a fusion of DEVO and Napoleon Dynamite.
Over the weekend, James McGovern complained about the lack of Enterprise Content Management (ECM) standards. He was brutally criticising one EMC Documentum blogger for his general lack of enthusiasm on the subject. Many customers don't care one iota about the standards, other than as a "checkbox feature" to be fully buzzword compliant. However, McGovern saw it as ECM's responsibility to push customers in the right direction.
Now, I can understand why an enterprise architect would be screaming for an ECM standard. After all, its their job to make sure their portal server can easily interface with the half dozen repositories in the organization. Its not unusual for a large company to have many ECM systems -- due to mergers, acquisitions, or departments that hate each other -- and it would be nice to have one standard way to interface with them all.
However, I totally disagree that a useful ECM standard will be developed any time in the near term. Why? One simple reason... there are already four separate ECM standards, none of which are much used.
First, there was ODMA, which some used for content management. Then BEA came up with the Service Provider Interface. Then came WebDAV, who's biggest supporter was Microsoft. Then the Java folks chimed in with JSR170. Now, we are awaiting the fifth: JSR283. Guess what? They all suck.
Why??? My opinion is that its because there are 40 different organizations who claim to be "Enterprise Content Management," and they all have a different definition of what that means. Some have limited metadata, some have extensive metadata. Some use a file and folder structure, others realize that an ECM system with findable content must have multidimensional metadata taxonomies which render a folder structure obsolete. Some have workflows and business process management, others barely have revisioning. Some can render a Word document into thumbnails on the fly, others barely support files. Some have compound documents, others don't.
Thus, any standard will be forced to be the lowest common denominator between all 40 systems. Any customer limiting their enterprise to just those basic ECM services will be horribly disappointed at the lack of features. I know of one major customer who was extremely gung-ho about "standard" ECM interfaces, until they realized that the standards lacked vitally important features. Now they never use them. Other customers were more extreme: one actually banned WebDAV across the entire enterprise.
A true ECM system is vastly more interesting than the search/edit/save model that standards bodies would have you believe... A fully-featured "standard" ECM interface won't look anything like SQL. Databases are about structure, ECMs are about semantic and context as well.
Now, there is some value in a highly simplified interface to an ECM repository, but we must all acknowledge that this is the goal, and design a highly simple interface that everyone agrees is barely useful. We should stop wrapping everything in rigid and obtuse XML like WebDAV, or in over-engineered and under-useful standards like JSR-everything. One reader suggested a ReSTful API to simplify things. Now, I'm not a ReST fanboy, but I see the merits of a resource-based interface like ReST for "dumb" content access... as long as the hype acknowledges it's uselessness, it won't cause much harm.
Until the market defines the minimum requirements of an ECM system, there's not much point in making a beefy interface. Almost everybody agrees that such a definition would leave out Sharepoint because of its wretched metadata engine... everybody, that is, except Microsoft... if the analysts continue to support Microsoft's claims that Sharepoint is ECM, then a decent standard will never get traction, because there's no way Sharepoint could support it. Jeez, Sharepoint barely supports WebDAV... what are the odds it will support JSR283???
So until Sharepoint gets its act together, some more consolidation happens in the market, and some of these niche players stop calling themselves ECM, I don't foresee efforts towards a decent standard ever bearing fruit. That might happen by 2009, but don't hold your breath.
Well, THAT was weird...
This book is an interesting follow-up to Information Architecture for the World Wide Web by the same author. This time, instead of focusing on the nuts and bolts of IA, the author spoke about the nature of findability itself.
Morville shares research and anecdotes from business, history, library science, anthropology, and neurobiology in his quest for the perfect system where everything in the world is instinctively easy to locate. Can we ever achieve ambient findability? And what would the world look like in such a place? What are the social and political ramifications of findability? Will it be big brother, or will the very concept of unquestionable authority wither and die?
Recent manifestations such as Google, Wikipedia, and blogger watchdogs suggest the latter is more likely...
Ironically, the more information we have, the less likely anybody is to use it. Obtaining information is very painful, even if the data is easy to find. The relatively unknown Mooers law states:
An information retrieval system will tend to NOT be used whenever it is more painful and troublesome for a customer to have information than for him not to have it.
Meaning, if I have a problem, I can either look up the answer, or ask somebody for help. If I ask somebody, then they might do all my work for me, which is good for me. However, if I look up the answer online, then I have to read it, understand it, and implement the solution myself. Not only must I confront my own ignorance, but its a lot more work. Stupid Google.
Along the same lines, it's insufficient for information merely to be available and findable... it must also be believable, useful, and tailored to the audience so its easy to absorb. That's the top-to-bottom challenge, and very few people understand it. This book doesn't give much practical advice about absorbability, but it covers findability needs and existing technology quite well. The rest is up to you.
This book bangs the old drum about how successful networking is about giving, not getting. Most people who claim to network are looking for something from you... whereas master networkers focus on trying to immediately give you something you value. The value could be anything: a book, a website, a contact, or a job for their kid. Ferazzi has a long list of what value to give to people, and when, and how to go about it. I found the goal setting section alone worth the price of the book.
For the most part, being friendly and helpful will come back to you tenfold. However, freely sharing your network with every spammer and slimeball who asks is a sure way of losing friends and contacts...
Ferrazi sends mixed messages here... He shared several anecdotes from when he was just getting started in business about difficult people who refused to share their network. Clearly a big mistake, because Ferrazi is now a very useful person to know. Even if this wasn't the case, its vital to use the connections you have instead of hoarding them. If you cannot provide value to your network, your connections wither and die.
However, later Ferrazi complains about people who call him out of the blue asking to network. His claim is that they have no value proposition. Fair enough, a good chunk of them probably are slimeballs who care about nothing but their own needs. If these kinds of people don't know or don't care to know how to add value to me, then maybe I shouldn't waste my time.
Some of the folks without a value proposition may be connection vampires... on the other hand, they might be extremely valuable and just not good at understanding or communicating this fact. So how should we deal with these people? The big question that he doesn't fully answer, is how to be a lightweight gatekeeper? Yes, we should share our knowledge and network, but we also have the responsibility of protecting it.
I'd like to see his take on this in a later article or book...
This was an idea I discussed with Alec and Pete on occasion... the concept of vertical farms. In essence, by using hydroponics, artificial light, and sterilized wastewater, a city can grow all of its food needs in skyscrapers. They are less prone to droughts, heavy rainfall, pests, or weeds. Plus, being so close to the city, you get to take advantage of all of the existing infrastructure for distribution.
It Just Makes Sense©
Its not as crazy as it sounds... many fruit and vegetable farms are grown in indoor greenhouses, and can grow much more food in the same amount of space. Sky farming would probably be less feasible for staples like wheat and potatoes... at least until sky farms get the subsidies that standard farms get!
Another nice side effect is that less land is needed for food production... which we can then turn into national parks.
Of course, this will only serve to increase the speed at which people are leaving small towns and moving to the city... but the world was always a dynamic place!
CMS Watch has recently released their Web CMS Kudos and Shortcomings, where they reviewed the top 40 open source and commercial Content Managament Systems (CMS). A kindly reader make a spreadsheet of the scores. For some reason, they ranked the Python-based Plone 2.0 the #1 CMS. It was the only CMS to have a positive score of 2, the rest were negative.
Huh, one positive score, and 39 negative scores. That speaks volumes about their methodology.
I like Plone 2.0, but a #1 rank? No freaking way... It doesn't have nearly the performance, features, usability, flexibility, or simplicity of Drupal 5.x... which is the best open source CMS, IMHO. Don't believe me? Then ask Google why they keep funding Drupal so much... this is despite Plone being written in Google's favorite language (Python), whereas Drupal is in dirty, dirty PHP. Because of my Python bias I tried really hard to like Plone, but it never quite stacked up.
That said, I'm glad to see Oracle/Stellent ranked as the "least sucky" of the major market players, with a mere -5... or "second least sucky" if you include Day at -4. IBM, Documentum, and Microsoft scored -12 or worse. Alfresco was dead last with -16. Curiously, Interwoven scored only a -8...
I bought this book on a whim at a bookstore because it claimed to include "quick reference" info on performance. I found that area seriously lacking...
I thought it odd to have sections on installation and planning in here. Hopefully one does not make such decisions with only a pocket guide as a reference. That section could be shortened to a few pages of warnings and a few URLs. The backup and recovery section was great, but it could be shortened up about 5 pages. Same for the security section.
With the extra space, I would put in at least 15 pages on performance tuning.
The data dictionary quick reference is very useful, and if it weren't for that I would probably have given this book away.
According to the AIIM Blog, the latest AIIM State Of The Industry Survey is available... One of the questions was what were the top 3 obstacles encountered during your Enterprise Content Management (ECM) implementation? The results are below:
- 44%=Underestimated process and organizational issues
- 32%=Lack of knowledge or training among our internal staff
- 30%=Project derailed by internal politics
- 29%=Uneven usage due to poor procedures and lack of enforcement
- 21%=Underestimated the effort to distill and migrate content
- 20%=Excessive "scope creep"
- 19%=Failed to address taxonomy and metadata concerns
- 18%=Low user acceptance due to poor design or clumsy implementation
- 16%=Failed to think or benefits/issues beyond our business unit.
- 16%=Poorly defined business case
- 13%=Lack of knowledge or training among our external staff/suppliers
- 13%=Budget was overrun
- 12%=Failed to prioritize "high-value" content
What I found interesting, was that very few of these issues can be tied to failures in the technology... its seems to be a failure of the organization. Lack of training/resources/knowledge could possibly point to an overly complex product... "scope creep" could be due to inflexible technology, or inflexible project managers... but bad taxonomy was blamed more often than the "clumsy implementation."
This kind of reinforces what I always believed about ECM... its not really about the technology, its not even about the content; its about people. I always hated those snake oil salesmen selling coblaberation instead of collaboration. A hunk of technology isn't going to make all your process problems go away. If you have good processes, technology will make your life simpler. If you have bad processes, technology will amplify your problems.