L5: Past Lessons

Lagrange Point 5 (L5): Looking at past tech developments to learn, grow and avoid mistakes

Web 2.0: It feels like 1999 all over again

A refresher on the state of Web 1.0 in 1999

I was one of those lucky few to be a part of the explosion of the Internet (not just the dot-com boom but also the earlier DARPA-driven R&D at MIT, CMU, Stanford and Berkeley the 80s). For those of you who do not remember (or — I am sad to remind myself — may be too young to remember) here are some things that were going on in the Web 1.0 world in 1999:

  • The Horsemen of the Internet (Cisco, EMC, Oracle and Sun in the B2B world, Amazon, AOL and Yahoo! in the B2C one) had introduced “new models of doing business that would change everything” to millions of people
  • These models were very technology-centric and focused on “new measures of value” such as click-thru’s, eyeballs, audience, etc. (discarding traditional EPS and PEG values)
  • Lots of “traditional” companies were racing to adopt these models — instead one core to their businesses. (Remember all those tracking stocks like NBCi and Borders Online?)
  • Technology vendors were rushing out tool boxes to build web sites,
  • As same time, analysts were heavily questioning if these models had staying power (the stocks of the horsemen actually dipped heavily at this time — just before rising as part of the last-minute Y2K Technology Gold Rush

The Web 2.0 parallels of today are eerie

This sounds a little familiar what is happening today in the Web 2.0 world (minus the overtones of the current world recession):

  • Thanks to Web 2.0 Horsemen (Facebook, MySpace, LinkedIn and Twitter) millions of people now roughly understand what Web 2.0 means — at least in the consumer space
  • Like 1999, the business models in the Web 2.0 space are still largely in the formative stages (just a few minutes on TechCrunch or Silicon Alley Insider will highlight this)
  • Lots of “traditional” companies were racing to add Web 2.0 offerings — with varying degrees of success. (At least we are avoiding Web 2.0 tracking stocks for now)
  • As the analyst reports attest, the Web 2.0 space is becoming filled with companies who offer “toolboxes that can uses to quickly stand up communities”
  • At the same time, many are asking if “there is any there there” in the Web 2.0 business model (and the valuation of Web 2.0 companies have crashed — ahead of the recession)

What happened after 1999 to Web 1.0

Within five years, the Web 1.0 world have moved to a very different place than it was in 1999. Essentially, it integrated with (instead of disrupting) the rest of the business world. Web technology moved from being an end-to-itself to becoming a means to create value. This significantly changed the market space: web-only companies diminished or disappeared (web hosting, domain name services and email are now commodities) while companies who could use web technology to create value-added Business Solutions created whole new markets. Examples easily come to mind:

  • Content Management systems replaced the build-your-own-website tool kits (and pushed these companies aside)
  • eCommerce platforms became a core purchase for every major CPG company
  • Advertising and creative agencies became Interactive Agencies, providing holistic advertising and brand service across all media channels (pushing the ‘webmaster’ back to the IT department)
  • CRM moved from a back office function to an real-time service to manage revenue creation
  • Digital music replaced the experience of going to the record (or CD) store
  • Searching for information online (instead of going to a library or buying a “List of…” book)

We are now ready for this in the Web 2.0 world

I believe Web 2.0 will follow a similar integration path that Web 1.0 did. Those companies who can figure out how to create value-added Business Services using Web 2.0 communication approaches (be them technology firms of consulting and creative groups) will expand and develop new markets. Those enterprises who fold these services into the day-to-day execution of their mission will realize the most benefit.

If you disagree, the perhaps you can answer the following question for me: what is the value of a blog or a forum? I do not think blogs or forums have much intrinsic value in themselves. However they can create value when integrated into a higher value business service or process.

On the other hand, what is the follow of the following services?:

  • Leveraging your customers to tell you what you need to invest in to sell more (would save a lot on Product Development and increase product success rate)
  • Harnessing citizen input to shape more efficient public budgeting (would save a lot on public referenda)
  • Using the the contributions and input of your customers to drive advertising traffic and urge new customers to buy your product (saves on advertising costs and increases sales)

Not only are these services valuable, they are also broadly applicable, easy to understand (from both a business model and end user perspective). The firms that can create these will become the Vignettes, Crispin Porters, Salesforce.coms and Apples of the Web 2.0 world.

Addendum 1: I am not the only person who thinks this

McKinsely & Company recently included a segment “Six Ways to Make Web 2.0 Work” in their last McKinseyQuarterly publication. This article discussed a very similar evolution of adoption of Web 2.0 “tools” that will overlay existing infrastructure to encourage engagement and participation. They included a graph that shows the same ten-year repetitive cycle:

MckinseyQtr-560px
Credit: www.McKinseyQuarterly.com

Addendum 2: Here we go again

IoT is the third big technology ‘wave’ in the last 50 years — and perhaps the biggest

 

What it takes to successfully implement COTS enterprise apps

That dreaded failure number and its root cause

As soon as you start planning for an enterprise program you will almost immediately begin to hear some variation of the following quote:

“You know, X% of [enterprise vendor name’s] implementations fail or are canceled before they ever make it to production.” (Where X% is usually around 50% or 60%.)

I will leave communication of the exact number to groups like Gartner. Nevertheless, many enterprise programs fail. Nearly all exceed their recommended budget and time allowances, even for their scoped-down first phases (I will get into scope control in a whole other series of posts). The single most important reason for this I have seen is the following:

Program sponsors (and their program teams) forget to include much of the work required to implement a successful off the shelf product

As a result, they need to come back to Capital Review Teams or their CFO to ask for extra money to complete their programs. In good times, they get this money (but reduce or eliminate their IRR), in bad times they can see their programs severely cut back, delayed or killed outright. Most companies are not in good times right now.

Buying off the shelf and integrating does not eliminate as many costs as you might think

My last post outlined everything you have to do to built applications in-house. Buying off the shelf and integrating eliminates many of these (in lieu of licensing and integration costs). However, it leaves many tasks that are often underestimated in the traditional “build vs. buy” analysis. It is easiest to highlight these by directly comparing the tasks for each:

Activities by project discipline area (i.e., not a Waterfall plan)

Key: Struck-out = Eliminated by purchasing and integrating an enterprise application. Red = added to successfully integrate the enterprise application. Italics = Clarifying note

  • Scoping (About half the time vs. building it yourself)
    • Negotiating contracts for acquisition
    • Negotiating contracts and Statements of Work for integration
    • Defining Concept of Operations or Vision Document outlining how the application will work at a high-level
    • Negotiating scope and phasing of capabilities over time
    • Estimating cost and time for this
  • Requirements Management (About one third of the time vs. building it yourself)
    • Capturing Use Cases, translating these into technical feature configuration and integration requirements
    • Determining non-functional requirements – performance, reliability, scalability, availability
    • Negotiating sign-off and prioritization by phase
  • Design (About one quarter of the time vs. building it yourself)
    • Designing an top-level architecture
    • Designing the logical data model. Specifying the configurable meta data for the application.
    • Designing the object model.
    • Designing the software architecture (what is internal vs. external, what is the software vs. the database, etc.)
    • Designing interfaces with external systems
    • Designing the User Interface – a huge one from determining style conventions, wireframes, mockups, usability analysis, Section 508 compliance and lots more. Specifying configuration settings for the User Interface (much easier than designing “frem scratch”)
    • Specifying the business and workflow rules to configure in the system
    • Designing the systems architecture – how you will handle maintenance, scaling on-the-fly, backup and recovery, disaster recovery, elimination of SPOFs (Single Points of Failure) – this task is so large that I built a whole portion of my career doing this for utility-class systems (always-on systems with reliabilities exceeding 99.999% and scales exceeding 10,000 transactions per second)
  • Infrastructure Management (Often LONGER than building it yourself as your infrastructure team will have to learn how the application is architected)
    • Capacity planning – how much hardware to you need, where should it be, when do you need it
    • Hardware acquisition – Selecting and ordering your hardware
    • Systems Integration – Installing the operating systems, patches, and base middleware. Integrating hardware into your network (configuring IP settings, adding to your routers and switches, much more)
    • Setting up your monitoring and production support teams and systems
    • Doing this for EVERY environment – development, integration, certification and production (your environments will multiple post-launch as you will have systems under development AND in production)
  • Construction (About one-third of the time vs. building it yourself)
    • Setting up the code repository
    • Setting up your continuous build process
    • Defining your interfaces and configuration management files. Defining exactly how existing systems will integrate with the new system
    • Building your databases
    • Building your database scripts and stored procedures
    • Building software modules
    • Building hooks for monitoring and business intelligence
    • Defining and executing your unit test cases around configured metadata, business rules and work-flows
    • Integrating and verifying the integration of your software modules with your databases and external interfaces the application with the rest of your environment.
  • Certification
    • Tracing your configuration requirements (functional and non-functional) to Test Cases
    • Building Configuring your Test Harnesses
    • Conducting verification testing, sending configuration builds back for repair, integration and certification/regression testing
    • Optional – usually done for highly-integrated mission-critical applications only: Conducting load and performance testing, including analyzing and repairing performance and scale bottlenecks
  • Training & Support
    • Developing training documentation and curriculum (for end users)
    • Setting up your Help Desk – including your knowledge base of how-to resolve expected questions
    • Setting up a Center of Excellence to manage the application after implementation (you will need to build or rent as your internal staff will not have the expertise to do this)
    • Training end users
  • Project Management
    • Developing the plan (tasks, durations, assignments, critical path, etc.) to do all this
    • Managing and resolving all those issues that come up with something this complicated
    • Estailishing governance for decision-making and issue resolution – requiring lots of time from your executives
  • General Management
    • Getting approval for the money to do this – Capital and Expense (often requiring you to in front of your Board of Capital Review Committee)
    • Managing the RFI, RFP and contact negotiation process for your Integration Vendor
    • Getting (or reallocating) the staff to do all of this – usually this is now external staff such as Integration Vendors (pro: you do not divert as many of your staff, con: they are more expensive than internals)
    • Managing the staff for requirements, design, development, integraiton, testing and installation (acquiring resources, approving vacation, backfilling departures, etc.)
    • Managing the capital and expense expenditures, including all the invoices for purchases and services and weekly or monthly reporting to your Finance organization
    • Handing all those items like staff departures (people quitting, not performing, getting sick, etc.) – This is reduced as you have “outsourced” a good fraction of it to your implementation vendor

This is still a lot of work — and a lot of time you could instead focus on the core of your business. Some will be done by internal staff. Much will require you to hire an external integrator (as your internal staff will not have the expertise to do this). The good news is that this frees up more internal staff than building it yourself. The bad news is that external implementation staff often cost 1.5x to 2.5x as much as your internal staff (making schedule overruns very costly). The cost of these overruns increases exponentially based on your degree of under estimate – this is known as Parkinson’s Law. Using a SaaS model avoids many of these costs.