The poisoned chalice of #EFSS and cloud shared drives

(Original article on LinkedIn June 29, 2017)

“Box can do what network shares do” claims a recent email campaign for Box Drive.

“Noooooo!!!!!!” echoes the collective scream of #ECM and #InformationGovernance practitioners, who have been trying to wean users away from the nightmare of network shares, for the last 25 years.

Just to be clear, my warning is not specifically about Box. Take Box Drive, Google Drive, OneDrive, DropBox, or any of the recent offerings that define the EFSS market.

The idea of replicating the functionality of shared network drives in a cloud environment is a really, really bad idea.

It propagates silos, lack of organisation, lack of governance standards, lack of consistency, lack of security and, ultimately, loss of control and accountability.

It’s not a technology issue. I know that Box Drive, for example, can offer much richer security and better document management capabilities than standard network shares.

But the users don’t.

And advertising these capabilities as a “better network share” which “allows them to use the same workflows they use today”, reinforces all the bad behaviours that we have been trying to eradicate all these years.

I get it: It makes sense to move your unstructured content from your expensive on-premises storage disks to a managed, scalable, and significantly cheaper cloud alternative, where you don’t have to think about backups and disaster recovery, and rack space, and air-conditioning, data-centre managers with night shifts, system upgrades, etc. I understand all that.

But taking your existing content mess and moving it wholesale to the cloud, is not the right answer. It may be quick and easy, but that doesn’t make it right. You are just delaying the inevitable. If you do want to move your content to the cloud, think VERY carefully about what you are doing and why you are doing it:

• How do you assess what content you actually have and what risk it carries?
• What needs to be preserved and what needs to be thrown away?
• Who needs access and how will you protect and monitor security and privacy?
• What do you need to encrypt?
• How are you going to organise and classify what you are keeping?
• How will you avoid unnecessary duplication and understand whose version is the right one?
• How will you teach your users to stop emailing 85MB PowerPoint files to each other for review?
• How will you teach them to stop downloading GDPR sensitive information into spreadsheets and sharing them out with partners and third parties over email?
• How will you ensure that when an employee leaves, his cloud drive does not become a black hole for critical business information?
• How will you apply AI and Analytics across your whole corporate knowledge base, if it’s scattered across thousands of personal silos?
• Etc., etc., etc.

The list is endless…

You can argue whether “ECM is dead” or if it should be called “Content Services” or “Intelligent Information”, or whatever. It will not make the problem go away. The reason ECM became a multi-billion software market, is because of companies realised the risks that network file-shares had created, and the need to add a layer of governance and control, classification, metadata, and automation, above the standard uncontrolled “file sharing” that the operating system offered.

Caveat Emptor – Buyer Beware!

Please don’t take us back 25 years by re-creating the same nightmare, taking one of the least disciplined Information Management practices, and replicating it to the cloud.

ECM vs. Content Services: The battle that never was

(Original article on LinkedIn March 20, 2017)

Gartner’s Analysts have set the ECM industry aflutter. Every self-respecting ECM pundit has expressed an opinion on the Big Issue: Is ECM dead? Should we be calling it Content Services? Has anything changed? Is Gartner correct? Is Gartner wrong?

Well done Gartner marketing! Mission accomplished.

In a recent post, Charles Weidman posed a question: “It’ll be interesting to see in six months or a year if the industry as a whole has followed Gartner’s lead”.

I’m sorry to say, but the industry followed Gartner’s “Content Services” lead, years before Gartner did. There is nothing new in this concept, as all serious ECM vendors have been exposing their Content Services APIs since the early ’00s, which is how System Integrators have been building bespoke solutions and integrating them into Line-of-Business applications.

There is no “vs.” in the “ECM vs. Content Services” conundrum: Content Services has been a key method of consuming ECM technology for years. CMIS (a common set of Content Services APIs, facilitating interoperability) was conceived nearly a decade ago (2008) and has been used extensively as a framework of “Content Services”.

As for ECM being “dead”, the annual lament of the ECM industry (see http://bit.ly/ecmisdead) is by now an established ritual.

What is new and differentiating, is to watch which ECM vendors’ Content Service APIs support modern, open and cloud-native architecture stacks, and which vendors can offer their Content Services in an agile development framework that accelerates innovation and Digital Transformation.

“Your baby is ugly!” – The schizophrenic world of overlapping software portfolios

No mother will ever say “My baby is the ugliest”. And no product manager will allow their brainchild to commit harakiri, following a software company acquisition.

I had the dubious pleasure to live and breathe this paranoid madness for over a decade, and I can tell you it’s neither pretty nor dignified.

Just look at our little ECM corner of the world:

• FileNet ECM vs. IBM Content Manager vs. Content Manager on Demand
• FileNet BPM vs. Websphere vs. Lombardi
• IBM Records Manager (Tarian) vs. IBM Enterprise Records (FileNet)
• Metastorm vs. Global 360 vs. Cordys
• Tibco vs. Staffware
• LiveLink vs. Hummingbird vs. Documentum
• Vignette vs. RedDot
• Etc. vs. Etc. vs. Etc.

Look carefully at the most acquisitive companies in the sector: It’s always a bloodbath.

Today the latest victims entered the fray: OnBase vs. Perceptive vs. Saperion or OnBase VNA vs. Acuo VNA, etc.

Naturally, the acquiring CEO – usually shoulder to shoulder with the incoming comrade – will issue reassuring PR statements to appease the acquired user-base: “Welcome to our happy family, we love you too! It’s going to be great!” (except in the case of FileNet and Lombardi where IBM’s message was more targeted to the existing user base: “Yes, we bought a prettier child, but we will never stop loving you”). Today’s example by Hyland is no exception…

And with the pleasantries completed, the gruesome reality starts to creep in: Innovators and Thought leader executives are either leaving in drones, or patiently waiting out their gardening leave or golden-handcuff term to expire. Marketing will talk about “coexistence” and “interoperation” and “unifying functionality” and “rationalising capabilities” and “ecosystems” across the portfolio. In the back room, skeletal engineering resources will be tearing each other’s hair out, scrounging for scraps of headcount to keep up with just the most basic bug-fixes on totally incompatible architectures, creating the QA matrices from hell. While salesmen in the field will try to pinch each other’s deals and upsell incompatible “extensibility” features creating Frankenstein implementation monsters that will never see the light of production, or another version update. Ever!

You think I’m exaggerating? Just ask any pre-sales support engineer who has had to live through these acquisitions… Pure madness!

The legend of ancient Spartans throwing their disabled and diseased children off a cliff, in order to maintain a superior warrior race, may have been disputed by archaeologists, but the software industry could take some lessons and apply some of the same rationale: less emotional attachment to the lesser products, and a more honest – if harsh – reality check for the customers: “Sorry, we cannot afford to maintain your ugly investment forever. Let’s come to an arrangement on how you move to our single, best, invested, up-to-date product portfolio, before you start running off to our competitors in despair”.

I sincerely hope that I’m proven wrong in my cruel cynical assessments, and I wish my Hyland and Perceptive colleagues a long and happy marriage, once the honeymoon period is over…

(VERY IMPORTANT: These are my personal opinions and are not necessarily representing the opinions of my current, previous or future employers. Phew, that was close…)

“Appification” Part 2 – What is the impact to ECM?

In my previous post (Part 1), we looked at the appeal of Apps, and why we grew to love them. Now, let’s look specifically at the impact that Apps have to the ECM software industry.

Impact to the ECM Industry

With over 25 years under its belt, the ECM industry (with its Document Management pre-cursor) is a relative dinosaur in enterprise software terms. It was established as an industry, about the same time as ERP, and before CRM, BPM or eCommerce.  So, as is the case with any other respectable octogenarian, we are pretty set in our ways. Yes, we may introduce new functionality or attach another technology segment under the ECM moniker every now and then, and we will endlessly debate if ECM, EIM or Process Services is the right name for it, but fundamentally we are still delivering software the same way we always did.

But change is afoot: Whether we like it or not, the “Appification” culture described in [Part1] is challenging the fundamentals of how the software market works, including ECM, and how relevant it remains to the enterprise of the future. And in Darwinian terms, we’ll have to either evolve to survive, or we will face extinction.

There are two main areas where “Appification” has profound impact to the way we operate today: The way we design products, and the way we take products to market.

Impact to ECM Product Design

“Appification” brings fundamental cultural change, to the way software is conceived, designed and delivered. Every core design element is challenged, as well as every classical development and delivery methodology.

• The “Apple” effect: Apple’s “Design Thinking” principle, threw the rulebook away when designing the first iPods and the first iPhones. They became icons of usability where less was more: who would have envisaged an electronic device with no buttons, just a glass slab? Where ALL functionality and behaviour is software controlled? Where accelerators, proximity sensors, hand gestures and voice command, would become the interaction controls, instead of a mouse, a keyboard, switches, levers and knobs. How many enterprise, and in particular ECM, solutions offer similar UI experiences?

• The “Singularity” principle: For years, enterprise software vendors prided themselves on the functionality breadth of their offering. The more features, the more capabilities, the better. Apps challenge that: What is the most critical element of software design? The User Interface and usability? The richness of functionality? The quality of information? Apps’ “task-oriented design” challenges that principle: “Do one thing, very well”. They are designed to remove complexity and isolate distinct elemental functions, and then deliver these in the most intuitive manner possible. What ECM functionality do you include or exclude from an App? How many Apps would you need to provide a complete “set”?

• The “EFSS” effect: “Enterprise File Sync & Share” has been one of the most disrupting apps in the ECM field. Even though there are clear overlaps, it did not set out to challenge the traditional ECM vendors, as such, it created a completely new market of its own by addressing just four fundamental requirements that traditional ECM couldn’t: Free and backed up storage space in the cloud; content accessibility from everywhere; ability to share larger files than email could, outside the firewall; and transparent synchronization of content across multiple devices (desktop and mobile). Box, Dropbox, Evernote, OneDrive, GoogleDrive, Picasa, iCloud, etc., all became a thorn on ECM’s side, because users liked the functionality they enjoyed in their personal space, and wanted to bring the same capability to their corporate environment. Now ECM has to step up and deliver that.

• The “Nightly Update” effect: I have about forty apps on my smart phone, and it seems that at least half of them get updated on a weekly basis. Some, more often than that. Updates just happen, without any involvement from me, without any need for IT support calls, without scheduled downtime, without any need for training. App users are not only looking for the same experience from their Enterprise software, but they are looking for the tools to offer this experience to their own customers. The days of the 18-month deployment cycles are truly over. ECM needs to support similarly fast, agile development cycles and continuous improvement, as apps do.

• The “Device” conundrum: Vendors can no longer dictate the device that their software will run on. Apps have completely transformed user expectations around being device agnostic: They expect the same App to behave appropriately, whether they are using it on a smart phone, a tablet, a desktop browser, or their hotel room TV. The name of the game is “Responsive Design”, where apps understand what device they are deployed on and adjust according to the operating system, the device format, the interaction capabilities, the connectivity bandwidth, security, etc. Enterprise software has a long way to go before it’s truly device agnostic, and introducing device independence in large suites of functionality, like ECM, does not come cheap.

Impact to ECM Go-to-Market Strategy

Whilst the ECM Engineering teams are grappling with the product design changes forced above, Sales and Marketing also need to completely re-think their approach to the market, in order to move into the Apps market space. Here are some of the key decisions they will need to make:

• Who is our “App” customer? ECM vendors have to consider two distinct App target audiences. One audience consists of the internal Enterprise users, for whom the ECM vendor will have to provide specific apps and UIs, in order to access the repository and its services. The second audience relates to their client organisations’ own customers. The ECM vendor will either have to supply App development SDKs and tooling for the organization to create their own customer-facing apps, or work with channel partners and integrators to deliver specific vertical line-of-business apps on top of their platform.

• Who is our buyer? IT is no longer the default target buyer for ECM platforms. The Apps culture has created a whole new set of buyers who are empowered to make purchasing decisions, outside the constraints of IT procurement. Human Resources, Marketing, Operations, Risk Officers, Compliance, etc., all have an expectation to choose their own tools, just as they choose to download a new app on their smart phone. Talking to these new buyers involves learning a whole new set of vocabularies, and a business outcome focused dialogue that does not rely on feature and function details. Few ECM vendors today have the capacity and the vertical domain expertise to carry these business conversations in a credible way. As a result, developing partner ecosystems with the relevant granular domain expertise, has to be a key component of the new go-to-market strategy.

• How do we license apps? Most ECM vendors, have grown in the era of perpetual, inflexible, buy-once licensing. App users are expecting significantly more flexible licensing terms, which are mostly subscription based. And, while it’s relatively simple to come up with a subscription-based licensing structure, it will still require fundamental changes around invoicing, revenue recognition, renewals, compensation strategy, etc. On top of that, Apps are not designed for the high-value low-volume models that Enterprise software was established on. That model will need to turn on its head, to keep ECM components relatively inexpensive, and finance the product through volume sales.

• Try-before-you-buy? App users are spoilt for choice: They are used to downloading an app, trying it out, testing it, and if it is perceived as adding value they may decide to license it. ECM vendors need to start offering wider choices, if they are going to compete: Free trial downloads (the Open Source market has a distinct advantage here); more Proof-of-concepts to get users to explore the value and complexity in business terms, Real live pilots that continue into production or can be safely scrapped; Agile development cycles that allow customers to fail often and fail fast.

• How do we scale down? Traditional ECM markets are all about scalability: ever increasing content, ever increasing user bases, ever increasing processing capacity. Of course you can buy more capacity, more storage, more throughput. Music to our ears. But that is a one-way street, they were never designed to support flexible scaling. The new market models, primarily established by the Cloud providers but also evidenced in Apps, expect the ability to scale up or down on demand. In ECM terms, it’s very unlikely that the content volumes will scale up and down (except in the case of major ROT clean-ups, or periodic Records Management dispositions). But scaling the processing capacity to accommodate seasonal fluctuations, scaling user numbers to accommodate temporary workers and 3^rd parties, scaling infrastructure to accommodate migrations, testing and consolidations, are all unpredictable usage-models. How will ECM vendors split their monolithic “All-in-One” pricing, to allow for “Pay-As-You-Use” revenue models? And how will they reconcile traditional investment and R&D budgeting, with unpredictable and varying revenue streams?

Adopting an “Appification” strategy

ECM vendors have some tough decisions to make, if they decide to play in the App economy. They need to decide, strategically, what their end-goal is and decide if this is a viable market model for them.

• Just because you can, does not mean you should! That’s the first step: Will vendors really commit to moving into the App market, or will they chose to remain a more “traditional” ECM vendor? There is certainly enough market scope for both, at least for the next few years, but the gap will get bigger and the window of opportunity smaller. To borrow a phrase from a colleague of mine: “You cannot be a little bit pregnant”, when it comes to “Appification”. It’s either all-in or all-out.

• If vendors choose to follow the “Appification” path, which App game do they want to be in? There are three fundamental variants, and they will have to decide which combination they will invest in: App Interfaces, requires them as a vendor to deliver their products to the end-users through apps. That typically means providing access to the ECM platform and functionality through a set of native “App” user interfaces. A lot of ECM vendors already have mobile interfaces to complement their standard desktop UIs. App Solutions, fits vendors that want to target specific with line-of-business apps. Few ECM vendors have been able to play that game successfully. It requires deep investment in vertical or horizontal domain expertise, it creates a very complex maintenance model since they have to keep a large portfolio of Apps in sync with changes to the core platforms, and they are in constant competition with System Integrators and customers’ own IT groups, who think they should have ultimate control of the business users. The final App space is App Tooling. Giving the market the services, development environments, integration capabilities and necessary tooling, to develop their own Apps on top of a core platform. This targets a more modern, microservices-based, component-based, architecture which supports agile development models, but it also creates a whole new ecosystem of buyers, mainly architects and mobile app developers, which does not represent the traditional sales market, or support infrastructure, of ECM vendors.

• Whichever App game they choose to play, ECM vendors will need to build an ecosystem of App expertise: User Experience designers, solution domain experts, agile developers and project managers, distribution partners, DevOps support, Cloud-first architects, digital marketers, SaaS finance experts, etc. Every segment in the business will need a set of new or complementary skills, and they are not skills that can be learned easily. They will need to be acquired.

• And the final strategy point is relatively unique to ECM vendors: The information we keep is hardly ever transient. It’s volume driven, regulatory controlled, security-sensitive and persistence-critical. None of these characteristics are native to the world of Apps. Which makes the separation of functional strategy and Information management strategy critical. – Any level of functional innovation provided at the App level, has to remain cognisant of the Information architectures it needs to access, reference and maintain.

Bottom line

There is no doubt that “Appification” is affecting not just ECM vendors but the whole of the Enterprise software market. ECM vendors have a choice: Either they will adopt an App strategy that fits their profile, or they will languish in the ever-decreasing pool of “legacy vendors”.

“Appification” is not a project, it’s a fundamentally different way of software life. The problem however for all of us in the ECM market, is that it’s a new, scary life, and it requires fundamental changes across the whole of the organization: Cultural, financial, and operational. Every department from product design to sales and marketing, to HR, to support, need to take a leap head-first into a massive transformational exercise. How many ECM vendors have the capacity, the investment capital, and are committed to undertake that transformation?

“Appification” Part 1 – Why did we fall in love with Apps?

I was privileged once again to participate in AIIM’s Executive Leadership Council in December, and this time the theme was “the ‘Appification’ of the ECM Industry”. Given that “appification” is not yet a word in the Oxford English Dictionary, that was always going to be an challenging discussion! I will leave it to AIIM’s paper (which I will link here once it’s available) to align the different interpretations of the theme from the multiple contributors at the ELC event, but I offer here my own contribution.

Definitions

Let’s start with the basics. The closest I found to a reasonable definition of “Appification” was provided by the IGI Global Dictionary:

“The replacement of Websites and Web pages with programs that run on mobile operating systems and mobile devises. With appification instead of the Web being a user’s primary user interface, it becomes an underlying service layer for apps, which become the new user interface.”

It’s an OK definition, but it does not go far enough for me. “Apps”, in the form of readily downloadable, simple task applications, mostly on mobile devices, have become a phenomenon that has dramatically impacted buying behaviours in the software market: Everyone who ever owned a smartphone, has downloaded an App at some point in time. This is not a phenomenon exclusive to the “millennials, or Generation Z, most of us use a smartphone. These same users are looking for similar experiences in their corporate environment.

So, for me “Appification” looks at the impact of the “App” cultural phenomenon on the software industry and, in the context of this forum, particularly to the ECM software market.

Why did we fall in love with Apps?

It’s difficult to understand the impact of Apps to the enterprise software market, without understanding first the reasons they became so universally successful at the personal market. What were the reasons that the mass population of smart phone and tablet users fell in love with mobile apps?

• Availability: “There is an App for that” is the defining slogan of the App generation. With over 2.5 million apps to choose from on each of the main platforms (iOS/Android), users are spoilt for choice. A simple search and one button, gives you access to exactly the functionality you need.

• Portability: We carry Apps with us all the time. From the handy units conversion app, to our banking services, to maps and GPS, to our digital darkroom. Everything is readily available wherever we happen to be.

• Self-service: We don’t need to ask permission from anyone, especially from IT, to install a new app. We just do. We don’t need any special skills, we don’t need training programs, we don’t need elaborate configurations. 30 seconds later, it just works.

• Price: We also don’t need permission from anyone, to spend $1.50 to buy an app, let alone install a free one. Not even our spouses would bat an eyelid at the typical App price. Contrast that with a typical IT budgeting and procurement cycle for enterprise software.

• Usability: App designers thrive on usability. The fact that most apps have no need for training, and intuitively deliver value through an interface that is constantly improved, has dramatically challenged traditional software design by putting the user right in the center of the design.

• “Ghost” contracts: When was the last time you read the terms & conditions of an App? We are so used to just clicking the “Accept” button, that the small print has completely disappeared from the App experience. Press the install button and use it. Acceptance of contractual terms & conditions is implicit!

• Provider vetting: There is an underlying assumption that when we download an App, someone has vetted that app for security and malicious code. Rightly or wrongly, we very rarely agonise about installing a new app on our phone of tablet. We just assume that it will mostly play nicely with the other apps on our device, and it will not suddenly take over the device to cause World War III on our behalf.

• Continuous improvement: The overnight, unsupervised, software update. Unlike enterprise software, it just happens and we mostly let it. No planned downtime, to regression planning, no trial runs. New features just appear on our little screens and we (usually) welcome them.

• Device proliferation: “I want it on my desktop / web / tablet / iPhone / Android / Xbox / TV / Fridge”. Apps are ubiquitous. Chances are that the app which securely holds all your passwords and bank details, synchronises them between your iPad, Android phone and your desktop. And you have instant access to your banking app from all three. And when you run BBC iPlayer or Netflix, you expect to continue your movie where you left off, even if you are watching it on your brand new refrigerator.

Appifying your fridge…

I don’t think anybody would suggest that these are the defining characteristics of the average Enterprise software suite. Enterprise Software, including ECM, fails on each and every one of these aspects. It just can’t deliver this experience today. We tend to attribute a lot to the “millennial” generation and their upcoming expectations from the corporate environment, but it’s probably fair to assume that all of us would like to enjoy this “App” experience in our working environment.

Following soon: “Appification” Part 2 – How do Apps influence the ECM market?

Why is voting so archaic?

This morning I went to my local polling station to put a cross with a pencil on a piece of paper which I folded and put in a plastic bin, for someone to open and unfold later in the day and count one (1). I didn’t even need to show any ID.

This is 2016, the age of mobile apps and digital transformation. This process baffles me! I have a National Insurance number and a unique on-line government ID, through which they accept my tax returns, my benefits requests, my passport application, even my driver’s license renewal. Why isn’t that good enough to vote with?

Just consider the costs involved with current voting process: sending out voting cards (card+printing+envelope+postage), the hiring of the polling station, the people manning it throughout the day and counting the votes at the end, my time wasted going there and back, the time to open and count votes, the cost of managing postal votes for people who can’t vote in person (more cards, special printing,several envelopes,postage X2), etc. etc. And then the plethora of people involved in communicating (drip-feeding) the results throughout the night. And God only knows what other hidden back-office costs that I’m not even aware of.

If this isn’t a solid business case for replacing a paper process with electronic, I don’t know what is! It would have been so simple to have another gov.uk page for voting. I would log in from any browser with my government gateway ID (they already know who I am) tick a box, and press submit. That’s it, instant voting results! And on top of everything else, it is a lot more secure and auditable as a process. And it would encourage more people to vote.

C’mon UK government, can we move voting to the 21st century and save some of my taxpayer money in the process? Pretty please?

IOS – A comet of Jurassic proportions

Every so often, an idea comes along that stops you in your tracks.

Innovation is happening at the speed of light all around us but most of of the time it consists only of incremental, evolutionary thinking, which takes us a little bit further in the same direction we were going all along. We have become fairly blazé about innovation.

And then you spot something that makes you sit up, pay attention, change direction, and re-think everything. I had one of these moments a few weeks back.

The name “EpyDoc” will probably mean nothing to most of you. Even looking at their existing website I would have dismissed it as a second or third-rate Document Management wannabe. Yet, EpyDoc is launching a new concept in April, that potentially re-defines the whole Data / Content / Information / Process Management industry, as we know it today. You know what happens when you mix comets and dinosaurs? It is that revolutionary.

I have lost track of the number of times over the years that I’ve moaned about the constraints that our current infrastructure is imposing on us:

• The arbitrary segregation of structured and unstructured information [here]
• The inherent synergy of Content and Process management [here]
• The content granularity that stops at the file level [here]
• The security models that protect the container rather than the information [here]
• The lack of governance and lifecycle management of all information, not just records [here]
• The impossibility of defining and predicting information value [here]

…etc. The list goes on. EpyDoc’s “Information Operating System” (a grand, but totally appropriate title), seeks to remove all of these barriers by re-thinking the way we manage information today. Not in small incremental steps, but in a giant leap.

Their approach is so fundamentally different, that I would not do it credit by trying to summarise it here. And if I’m honest, I am still discovering more details behind it. But if you are interested in having a taste on what the future of information management might look like in 5-10 years, I would urge you to read this 10-segment blog set which sets the scene, and let me know your thoughts.

And if, while you are reading through, you are, like me, sceptical about the applicability or commercial viability of this approach, I will leave you with a quote that I saw this morning on the tube:

“The horse is here to stay but the automobile is only a novelty – a fad”
(President of the Michigan Savings Bank, 1903)

 

P.S. Before my pedant friends start correcting me: I know that dinosaurs became extinct at the end of the Cretaceous period, not the Jurassic… 😉

CIP – The amazing power of Social Media

Just in case you have not followed the recent saga of the demise and reinstatement of AIIM’s CIP certification, read Mark Owen’s blog here, which has a good summary of events.

I am not going to dwell on the ins and outs of AIIM’s decision, which has been analysed enough. However, there is an underlying story to the events which is significant: In case anyone had any doubts, this is one of the best showcases of the power of Social Media that I’ve seen so far: From the original decision announcement, through the members’ rebellion, to the final reversal decision, took just 7 days, and that included a weekend.

Think about this process: Within hours of the original decision announcement, the twitter feeds were buzzing! (well, the ECM twitter feeds at least, let’s not get over excited…). Amazement, scold, sarcasm, and a genuine discussion on the relative merits of CIP vs. IGP and vs. other AIIM certifications such as ECMm. A great amount of very good content. Over the next couple of days, the blogs started appearing. Most of the vocal people in our community were up in arms and made their voice heard. Even more twitter traffic, while these blogs were disseminated. People at AIIM saw and heard the response, loud and clear. A few more discussions later, a new announcement of the reinstatement of CIP (through a blog and twitter) and a lot more twitter traffic and a lot more blogs. For the most part, congratulating AIIM for being active, listening, responsive and doing the right thing.

AIIM is a community of several thousand people. There is a core of a few dozen people that have been actively involved with AIIM for a long time and, by default, they are the biggest advocates the most ferocious critics. They also happen to be prolific Social Media users, particularly on Twitter and blogs. You could argue that the statistical sample of the people that complained about CIP is not significant, compared to the overall number of AIIM members, but that would be a very short-sighted view. When you consider who these people were, the communities that they themselves represent, and the influence they exhort into the ECM community (again through the power of Social Media…), it would have been very difficult for AIIM to ignore.

On top of that, when your best advocates become critics, you tend to pay attention…

Kudos to AIIM for recognising the issue and doing something about it. Even bigger kudos to Social Media, as a platform for change. I don’t think that this kind of dramatic unfolding of events, immediate and overwhelming public response to an unpopular decision,  and finally the winning over of the disgruntled masses to a successful outcome, all in the space of one week, would have been possible in any other era or medium.

Finally, a quote from a tweet by Lisa Hoover McGreevy (@Lisah), who summed it up beautifully: “Well done, #AIIM members. And, uh, remind me to never piss you off. ;)”

The rise and fall of CIP – by AIIM

I like AIIM. I’ve been a member since 1995, and I have enjoyed watching it grow from a semi-obscure huddle of microfilm archivists, to a substantial, international, Information Management industry body. I’ve also witnessed its transformation from an introvert “from the vendors, for the vendors” organisation to one that offers significant value to IM practitioners and end-users through education, webinars, market studies, etc. But AIIM has just irritated a lot of its advocates.

When AIIM introduced the Certified Information Practitioner (CIP) certification back in 2012, I found it a very astute strategic move. Unlike the ECMp, ECMs, ECMm style certifications that preceded it, which were little more than a verification that that you have attended the relevant AIIM course, the CIP certification carried a much more significant value: It demonstrated that its bearers had a good grasp of most technologies in the larger IM scope, and had a sufficient understanding of the value and the issues of ECM-related projects not to embarrass themselves. It wasn’t a trivial exam – even for some of us veterans of ECM – and it was sought after: A badge of honour.

Unfortunately it wasn’t sought after enough, so AIIM has just decided to terminate the CIP program. Apparently, some 1,000 people have achieved CIP certification in the last 4 years, which by any accreditation measure is a significant success. Any measure apart from AIIM’s, that is.

Laurence Hart (aka Word-of-Pie) wrote an excellent article today on the unfulfilled potential of the CIP program (“The CIP, A lost opportunity“), which I totally agree with and I will not repeat here. He hints however to a key problem that plagued CIP from the beginning, the same way it plagued MoReq 2010 and numerous other standards and certifications. Laurence writes: “the CIP needed to be marketed inside and outside the profession“.

To the best of my knowledge, there are only two ways that a standard or an accreditation can succeed: (1) It is mandated by a government, law, or regulatory body, or (2) there is sufficient demand generated for it, to make it a de-facto standard. Otherwise it whithers and dies. There was no plan to ever mandate CIP, so the only way to it would ever be successful would be to generate sufficient demand for it. I am assuming that AIIM used the number of practitioners requesting to be certified as a measure of demand, against its success criteria, before pulling the plug on the project. We can argue whether issuing 1,000 CIP certifications in 4 years should be considered a success of a failure, but that would completely miss the point. That metric is entirely wrong.

Requests for receiving the CIP accreditation is not a measure of demand. It is a consequence of the value (actual or perceived) that CIP practitioners saw in achieving the certification. And that value in turn is a result of two other drivers: The real demand in the market for CIP certified practitioners, and peer recognition. The first one of these is tangible and measurable: How many projects, RFIs, job specifications or Statements of Work, explicitly request CIP certified candidates. I am not aware that there have been many. The latter is harder to measure and I suspect the one that drove most of the 1,000+ CIP certifications issued todate.

AIIM did little to promote either.

I fished out of my archives an email that I wrote to AIIM back in March 2012, soon after I successfully passed the CIP exam:

I believe that, until such time as CIP is a widely accepted (and requested) accreditation, I think we can create marketing drive based on its exclusivity… At the moment it’s a bit of an “elite” club, so let’s make membership to the club desirable! Some ideas:

1) Look at BCS Chartered statuses. I think this extends significantly beyond just the UK: http://www.bcs.org/content/conWebDoc/18215.
If we could somehow get the CIP Certification accredited through BCS (something like “Recognised/Accredited by BCS”) or as a certification that is somehow contributing to achieving higher membership, you will have CIP advertised to a much larger IT community than AIIM can reach.

2) Are there other similar organisations around the world that we could engage with?

3) Add it to LinkedIn as a formal “Skill” – See http://www.linkedin.com/skills/skill/Certified_Internal_Auditor?trk=tyah. Not sure what’s involved in this.

4) Create a LinkedIn “exclusive” group for people who have passed CIP. This could be “by invitation only”. Not only it gives kudos, exclusivity and a community to the members, but it’s a great hunting ground for headhunters and HR people.

5) Negotiate discounts for CIPs for conferences, events, publications, training, etc. Not only with AIIM but with external groups and other communities.

The idea behind all of these, is obviously to create incentives for people to want to become CIPs, because they are getting something back for it.

That was just a starting point and I’m sure there were many other ideas to generate demand. We know that the “build it and they’ll come” principle does not work. Like any other product, CIP needed consistent and persistent marketing to generate visibility and create demand. It needed Case Studies on the value it delivered to practitioners and their clients. It needed nurturing and it needed time to grow. It needed word-of-mouth endorsement and it needed public recognition. It needed an opportunity to mature.

Alas, it received none of that and, by all accounts, it shall remain another great idea, poorly executed.

R.I.P C.I.P

P.S. The ambiguity in the title is not coincidental…

 

 

Cloud Computing – Happy 45th birthday!

I must have been about 8 years old, so this would have been around 1972. My father worked for BP in Greece at the time. In his office, was a giant (well, it looked giant to an 8-year old…) machine with a chunky typewriter keyboard and a paper printer in the middle.

My father typed some gobbledygook that I didn’t understand and the machine typed back some response. To an 8 year-old, this was magical! I’ve asked what that was all about. My dad explained that this machine was giving him access to some massive computer somewhere, where he could ask for certain problems to be solved and complex calculations to be performed. He would fire off the question and the computer (somewhere far away…) would come back with the answer.

I wanted to see more. My dad explained that every time he used the machine, the company was charged money. The more he used it, the more it cost. He also explained that many people from across the world would be sending these requests to the computer, and therefore there were sometimes delays while everyone was asking questions at the same time (that’s why it was called a Time sharing computer). And if we asked more, we might be slowing down someone else that needed the answer fast. But he ran a couple of more questions, just to show me and sure enough the response came straight back, a few seconds later.

It took me nearly 45 years to put 2+2 together: A massive shared computing resource, hosted off-premises, executing multi-tenant requests, and charged on a pay-per-use basis. That was my first experience of Cloud computing and SaaS.

Who says innovation is dead? Happy birthday Cloud!