the Stamford Research
Business Technology Journal

Don't Try to "Out Wal*Mart" Wal*Mart

Great advice from Tom Peters in "Beating Wal*Mart (Starbucks, etc) is a lark!"
I would translate this as well to technology companies (my primary clients). Don't try to "out consult" IBM Global Services, "out-ERP" Oracle or SAP, "out-CRM" Siebel. Don't compete on price - compete on being the best solution in your niche, then expand your niche.

I sit on the board of a Chicago-based software firm. The last few days we were wrestling with the "positi0ning" of the company - Who are we? How do we want to be perceived in the market? On the one had, we could position ourselves as an ERP company for the "mid-market" company -- but we have solutions for large corporations as well. Should we position ourselves against SAP and Oracle? Or, as Tom Peters suggests - should we find our unique strengths and position ourselves in a unique niche?

The answer, of course, is not to try to compete with SAP and Oracle on price - but to find our unique attributes, and position ourselves as "A software services company focused on extending ERP suites with unique Content Management, Management Reporting and Commerce solutions - either custom developed or pre-packaged." This would allow us to "co-exist" with the big players by filling gaps in their offerings, while "upselling" our entire suite to mid-tier companys that would prefer a less-costly or easier to manage solution.

Sometimes having the "integrated solution" is the best product strategy, but not the best marketing strategy. Having the integrated solution allows you to upsell - but selling the integrated solution is like trying to "out-Wal*Mart Wal*Mart".

Break your solution down into its component part. Sell to the niches, then upsell the clients.

posted by AFC @ 9:28 AM |

The End of Corporate Computing???

In 2003 Nicholas Carr wrote a Harvard Business Review article, IT Doesn't Matter, now he's followed it up with an MITSloan Review missive, The End of Corporate Computing. Stamford Research chief executive Albert F. Case, Jr. asks, "Are you kidding?"

We believe that there are certainly huge shifts afoot in the IT industry - from "softaware as a service" to grid computing. However, we believe that we are viewing somewhat disruptive evolution, not necessarily revolution. We side with Vinnie Mirchandani, in his recent dealarchitect,inc. blog post, The end of corporate computing ... the beginning of chaos, where he poses six valid questions.

Our Take on the Issues
We do not believe we're witnessing the end of corporate computing. We do believe that we're witnessing an age of extinction for many CIOs that do not adapt to the changes that the computing and information environment will enable in corporate IT.

IT will continue to be a viable corporate function that oversees the delivery of business information to users - but their roles will change, and more and more fixed IT cost will be converted to variable IT costs based on usage.

1. Corporate IT is here to stay: Corporate IT will evolve from a hardware/software intensive function to a collaboration management/design/change management function. The mission of IT has always been to design the transformations from data to information and deliver that information, on a timely basis to business managers, customers and other end-users.
2. The work IT performs will change: Here we see the greatest paradigm shift - away from acres of fixed-cost programmers (and their associated acres of flexible-staffing counterparts who spend years in client organizations) sitting in cubes writing and modifying code - to dispersed internal-consultant style analysts and designers who constantly probe to see what information is needed, how it can be assembled, and what resources, internal or external, can be used to deliver that information to its consumer. Internal IT will continue to evolve its focus on information as a strategic business weapon. The implementation of solutions will continue to be increasingly outsorced.
3. The computing platforms will change: There will always be computers and networks on the business campus - someone needs to manage them, and manage the "total cost of ownership", as well as assure the security of corporate data. However, more and more data will be stored on computing platforms outside the ownership domain of the enterprise.
4. Increasingly, enterprises will purchase services, not software licenses. Specialized applications will remain in-house, but increasingly, business processing applications will be run as services, outside the organization, rather than internal processes. The charge will be led by end-users who are tired of waiting for the acres of programmers and go out and buy the services on the open market (e.g., salesforce.com).

So we are clearly in a period of change and flux, and the IT executive must adapt to these externally driven trends or become obsolete.

posted by AFC @ 2:18 PM |

Why Open Source Isn't an Enterprise Solution (But it Could Be) - Part III

Al Case of Stamford Research kicks another open source hornet's nest by espousing the concept of "commercial open source" (aka, transportable source).

Excuse me for a moment while I pull the arrows out ... Ouch! I think I've discovered that many Open Source advocates, pundits and consultants either don't read - or don't like to be offered advice. I feel like a pin cushion - but, masochist that I am, I persist. And now, I think I shall go kick a open source hornet's nest, just for fun!

OK, So There Could Be Open Source Enterprise Applications After All
Yes, Virginia, there could be an open source enterprise application in your future, despite my dire predictions of the death of the software business at the hands of open source programmers - and the related death of viable, non-custom enterprise applications as well. However, as the "dot bombers" needed a viable business model, so too do the open sourcists who intend to storm the enterprise application beach head.

Martin Mickos in his December 30, 2004 AlwaysOn post, "Open Source: Is It Time to Sell Out?" is headed in the right direction with dual licensing. But along with a licensing model, we also need a comprehensive, and viable, business model.

Elements of the Model

1. The model must allows open source to remain open and available - preferably without license fees.
2. The model must encourage adaptation and inclusion of elements by disparate contributors
3. The model must allow open source technology to be embedded within and linked to commercial software without forcing the entire commercial package to be placed in the public, open source domain.
4. If money changes hands as part of a commercial transaction (see #3), some of that money needs to go back to the appropriate open source community ... even back to the developer.
5. As Martin Mickos says, there must be a quid-pro-quo ...

Then we can have a viable model.

How a Transportable Source Model Works

The concept is relatively simple in design, but not so trivial to implement. The first step is the need for both paid and unpaid licenses for the same product. However, this is a potential nightmare - so we suggest a modified GPU license with provisions for the inclusion of open source software within commercial software solutions.

There would be no up-front license fee for this, since that could eliminate small players (exactly the type of innovators you do not want to alienate).

There needs to be a clearinghouse, similar to the copyright clearinghouse, for payments for open source software included in commercial solutions.

Software developers "register" their open source with the clearinghouse, and license under the clearinghouse terms and conditions.

Software developers, registering with the clearinghouse may patent their software - and may have both free and paid licenses to the patents.

A "price range" is specified when a license is issued for a commercial product that contains embedded open source using the new license structure. The range contains a "minimum" price, and potentially graduated prices as the license price of the embedded software increases.

The commercial organization makes payments to the clearinghouse within 30 days of collecting the fees for the license. All embedded open source payments may be made in a single payment to a single source.

The clearinghouse keeps a small fee (say 1% to 5% ) of the fee paid by the commercial software company and remits the rest to the developer/developer organization.

The clearinghouse fee is spent on promoting the libarary and on auditing the commercial software firms that use the service.

Win ... Win ... Win ...

posted by AFC @ 12:50 AM |

The Open Source Time Bomb - Infected Commercial Software

Commercial software publishers and distributors, as well as end-users, run a risk when using commercial software that may or may not have open source modules embedded.

What's the Problem?
For end-users of commercial software, there is little to no risk that they will not be able to use their software. The risk is the stability of the vendor from whom they licensed their commerical applciation.

Some commercial software vendors have begun to incorporate open source modules or content into their application software. The danger lies in the type of license terms under which the open source was made available to the commercial software vendor. There are, broadly, three types of licenses:

1. GNU General Public Use (GPU) like licenses which state that any software product which contains embedded must be free software (i.e., you can't embed GPU licensed software inside a commercial application that is sold for money).

2. GNU Library like licenses which are applicable only to module libraries, and state that the library modules may be embedded within commercial products, but the libraries are freely distributable. (more on GNU-GPU licenses).

3. Berkley like licenses which state that the software is distributed freely, is not warranted, may always be distributed freely, and may be embedded within commercial products, as long as the user of the commercial software can freely distribute the "Berkley licensed" components. (More on Berkley or BDS licenses)

Of course, there are a semi-infinite number of variants on these licenses. For a good overview, you can check out the GNU site.

What's the Risk?
To vendors who are not cautious, the risk is enormous. A $50,000 or $100,000 or even $1 million in license fees could be forfeit if the commercial product contains a GPU licensed component because the GPU license clearly states that software into which GPU licensed software is embedded must be free. The only permissable charges are consulting services around the software and fees for actually distributing the software - but not for the IP itself.

The risk to the vendor is complete loss of any related revenues plus damages.

The risk to the licensee of commercial software containing GPU licensed modules is financial collapse of the vendor. When my firm evaluates vendors, we consider both the vendors strategy, and the vendor's abiilty to perform against the strategy. Improper licensing of open source scores a zero in the performance category.

Risk Mitigation
Ways to mitigate risk include:

1. Due diligence by users on licensed components of commercial software products.
2. Inclusion of a "distribution license clause" and separate packaging of the open source product(s).

posted by AFC @ 11:36 AM |

Why Open Source Isn't an Enterprise Solution - Part Deux

Consultants are economically dis-incented from building products software companies are dis-incented from giving it away and open source organizations get the support of techies but not end-users

In my previous open source post, I said that one future scenario of the rise of open source for enterprise applications was a future devoid of either open source or commercial applications (other than those build by programming chimps) and populated by customer applications built by consultants for end users. The other scenario is that there will be a few "narrow" open source application niches - and the continuation of commercial software companies selling licenses and buying consultancies.

Problem One: Consultancies
Consultancies made a killing on SAP, Oracle/Peoplesoft, JDEdwards, etc. etc. My previous post was also carried on the AlwaysOn Network, and member lef4 challenged my assertion that consultancies can't build software. Actually, lef4 was right, but for the wrong reasons. Consultancies can (i.e., are able to, technically) but may not (as in will not have permision of their shareholders) or will not (as in the priorities of the partners/executives/owners) dis-incent them from doing so.

I maintain Consultants can and will install, customize and maintain pre-existing solutions. They will not build them, nor will consultancies contribute to the body of open-source code. Why? Because consultancies are loathe to make capital investments. Originally, it was because the partners, at the end of the year divvied up the left-over cash and paid themselves with it - to buy the new Benz, vacation home, or pay down the mortgage they held on their partnership units. Money invested in product was money not in their pocket - and like most people - money not in their pocket that was already committed. Sure, the consultancies tried. Peat Marwick (forebears of Bearing Point) tried to build transportation related applications and got out of the buisness (I was director of MIS at Ryder's Auto Carrier Divsion at the time), E&Y tried to get into the Healthcare Information Systems business -but just kept doing systems integration work, E&Y(now CapGemini), PWC (now IBM Global Services) and Arthur Andersen/Andersen Consulting (now Accenture) all tried to get into the software development tools biz with products like Navigator, Knowledgeware and Method/1 - and failed. (See, lef4, there is a history behind the claim that consultants don't build software products).

After the partnerships gave way to publicy traded companies, the investment trend continued because of the quaretelry metrics - billability ratio, revenue per head, profit per head, by which these companies are valued. Product developers are zero income heads that wreck the ratios for future income ... Not happenin' on my stock exchange!

Problem Two: For Profit Software Companies
An interesting dilemma - they must make a return on the investment they make in the product. Hmmmmmmm... PayPal-like "donate" buttons could work, but I think Oracle and Microsoft would be hard pressed to make the Street's whisper number if they rely on that revenue generation method. Computer Associates, the company users love to hate, would be out of business over night. They aren't giving it away.

Also, only someone getting paid for the effort of herding cats, excuse me, I mean running focus groups, user groups, requirements teams, etc. will do it. MySQL, Linux, PHP, CVS, etc. are all driven by programmers building products for programmers. They are the developers and the users. Content Management Systems LOOK and SMELL like user applications - but they aren't. They're ways for programmers to manage content on web sites without having to program all night long on boring HTML/Java?PHP stuff that looks a lot like maintenance work, rather than the cool development stuff they enjoy. Successful open source today is a group of users who build their own free products.

Now throw in shop floor managers, HR executives, investment relations managers, accountants, internal auditors, production expediters, marketing executives, sales people and all the other "cool cats" that make up the user base of enterprise applications. Who will herd them? SAP herds them and Peoplesoft herds them because they extract so much capital from the enterprise for their solutions that management FORCES the cats to be herded. Pays the cats to join the herd, and then pays the software vendor to herd them. Without the board-level expense to worry about, there would be no board-level edict to be herded (can you imagine a commission driven sales person voluntarily getting on a committee to design a CRM system in his spare time???? Let's see - Winner's Circle in Maui or focus group meeting in Milwaukee ... hmmmmm.....). Are programmers and designers going to herd them? Yeah. Right.

Problem Three: Who can eat Whom?
Softaware companies, used to heavy investment in non-billable manhours can digest consultancies because consultancies are cash-basis businesses and (aside from Goodwill and HUGE legal fees that drive up the acquisition price) are rapidly accretive to the software company's earnings. That's why Oracle, Microsoft, IBM, etc. buy consultancies.

Consultancies can buy other consultancies because it just drives up billable bodies and revenue, accretively. However, consultancies cannot invest in product (see above) and cannot manage or buy software companies.

The bottom line?
Open Source groups can't herd corporate, non-tech cats. Consultants can't build commercial product. Software companies can't give away software. Commercial enterprise software is here to stay. However, the subject of my next post ... commercial software will begin to incorporate open source modules.

posted by AFC @ 5:51 PM |

QUICK ANALYSIS: U.S. Supreme Court E-Business Ruling

Today, the United States Supreme Court ruled that states could not prohibit out-of-state sales of wine over the Internet - and more broadly - could not prohibit online sales of alcohol - where the product would be shipped to a prohibiting state.

The implications to e-business could be huge. It prevents states from regulating businesses outside their jurisdiction. Who could be next? This could be the big break needed for online gambling! How can a state prevent its residents from purchasing any product or service from outside the state's jurisdiction?

Read more about this on cnet news.com.

posted by AFC @ 2:26 PM |

QUICK NOTE: Standard Functionality Frameworks for Business Process Management & Content Management

As you may know, we've been recruiting for our Multi-Client studies on Business Process Management (BPM) and Content Management Systems (CMS). As part of our studies, we have been developing Standard Functionality Frameworks which help our clients determine:

• Which software products and services in which they should invest; and,
• What level of implementation they need to meet their needs.

Our Standard Functionality Frameworks contain a hierarchical taxonomy of features or functions that may be included in this type of automated solution, with definitions and descriptions of each item.

We have just published two "Standard Functionality Framework" drafts on our home site - Anyone interested in Business Process Management or Content Management is encouraged to download the frameworks, (links to the two framework drafts are at the top of the page) and to send us their comments

As these drafts become fleshed out, we will publish updates.

posted by AFC @ 1:28 PM |

IBM & Open Source: The Good, The Bad & the Questionable

Bob Sutor, IBM's vp for open source and standards told eWeek that IBM intends to focus on open source solutions for vertical markets - initially automotive, education and health care. However, according to the eWeek quote, there are no limits on what IBM intends to "open" with.

Analysis

A huge proportion of IBM's revenue and profits come from the IBM Global Services (the computer giant's consulting arm). As evidenced by the 2002 acquisition of PriceWaterhouseCoopers Consulting by IBM/GS, it is an ongoing and huge part of CEO Sam Palmisano's strategy. Therfore, the move to open source should surprise no one. IBM hopes to give away software in hopes of moving more iron ... and most importantly, more billable hours for its consultants.

The Good, The Bad and the Questionable

Is this "good for business"? Well, its another, inexorable shift in business models. Software is becoming commoditized. But it's not necessarily a good thing. You see - software has historically been a high gross margin business - develop the software, and ship out distribution tapes/disks/CDs/DVDs and downloads, and collect perpetual license fees - without much labor (once the product has been developed). Enhancements, bug fixes and the like are covered by the 17% to 20% maintenance surcharge.

However, firms like SAP and PeopleSoft (now part of Oracle) saw consulting firms like Accenture, BearingPoint, CapGemini and IBM Global Services generate revenues of 3x the software licenses for the installation work. With the robust adoption of LINUX, and open source technologies like MySQL, a trend seems to be forming ... give away the software to get the services.

The good news (for consultants) is that the services are easy to sell once the product sale has been made. The consultancies ride on the coat tails of the software vendors - reaping rewards the rewards of the sales-cost borne by the software companies.

The bad news is that the open source trend may severly impair the innovation, development and deployment of new softaware solutions. Open source solutions are "free" (until you start paying the consultants) - but their release cycle times and functionality often lag commercial solutions.

The questionable issue is the future. There is far less leverage in consulting services. Consultancies are labor intensive - billing by the pound of flesh per hour. Consulting firms a notoriously hideous at producing commercial product, because a body in development is a body "on the shelf", earning nothing today on the promise of something in the future - and hence a cost item. Bodies in motion at client sites are moneymakers now. When the bodies in motion run short - the developers are pushed into the market place.

Propaganda

Industrial strength Open Source as "free software" is propaganda. Someone pays for it - and if the market's not paying license and maintenance fees, it's paying consultants. If the market is paying consultants, it's promoting short term revenue (bodies in motion) over longer term development (bodies in development). Given the historical proclivities of consulting firms to shy away from deep pocket investments - the market tendency toward the latest open source fad could lead us down a slippery slope.

The Ultimate Devolution

If the industrial strength open source movement gathers momentum - here's the prognostication:

Devolution Phase I: Big software firms channel resources into services and away from new development. "Consulting" grows from 10% to 20% of software company revenues to 50% or more.

Devolution Phase II: The revenue from bodies in motion at software companies starts to surpass 60% - the companies announce that their putting their code under GNU-like General Public Use licenses (or the more commercial friendly "Berkley Copright License"). Sure, the existing maintenance dollars will go toward the development pool of second-class developer citizens (the consultants have the keys to the kingdom now).

Devolution Phase III: The developers have all but died off as has maintenance revenue. "Public Contributions" are supporting the software frame - which is getting pretty rickety.

Devolution Phase IV: The industry has now made a 180 degree turn back to the 1960s - all software is now essentially "custom" software because there's no stable code base and the consultants have customized everything (or created so many parameter driven tables that setting parameters is, in itself, a programming language).

Devolution Phase V: A new concept arises - "packaged software". 5 guys in a garage launch a new CRM/ERP/BPM/CMS system. The selling point is that the software is "standard", can be installed without consultants, and has a perpetual license at a fraction of the cost of what consultants charge to build all this stuff on-site. And ... they'll maintain the code base for only 15% of the then-current license price.

Planet of the Apes Scenario: Genetically engineered chimps with wireless brain implants are taught to write and debug the current 9th generation language - the 5 guys in the garage hit the road as consultants!

posted by AFC @ 12:16 AM |