Enterprise Computing

April 26, 2006

Kim Clark on Modularity

I attended a UTC (formerly UITA) breakfast this morning where Kim Clark, President of BYU Idaho and former Dean of the Harvard Business School, was the featured speaker. (photos)

Pres. Clark talked about harnessing the power of modularity. I reviewed his book, Design Rules, in January. Design Rules is about modularity in IT and the advantages that it gives. Design Rules was hands down the best book I read in 2005. I think anyone interested in infotech should study it.

He begins by pointing out (with a graphic) the staggering dominance of IBM in the IT industry in the 60’s and how that dominance has dissipated over time. IBM and others were vertically integrated. DEC did it’s own injection molding to create computer cases. Now, the industry has reorganized in modular clusters that are more horizontal. This change has also caused value to migrate from the vertically integrated companies and it more spread out.

These changes were made possible through changes in the underlying design architecture. What makes a design architecture industrially powerful, and unmanageable. This unmanageability means that it can’t be contained inside a single company.

Modularity is on the key change in the design architecture. Modules are highly interdependent internally, but independent of each other. The power of modularity is that the system can be decomposed and designed independently. The design rules allow these independently designed modules to work together in an integrated way.

The Design Structure Matrix (DSM) is a tool for gauging the independence of modules. You can use DSM to determine at design time the modularity of the system you’re building. Once a system has been modularized, complexity becomes manageable and groups can work in parallel. Modularity welcomes experimentation.

Pres. Clark goes into the IBM 360 example. IBM understood the first points: managing complexity and working in parallel. They misunderstood the last point. Once a system has been modularized, you can conduct many more profitable experiments on a module. IBM missed the fact that they could profitably invest more R&D in it’s modules. Disk drives were the first. In 1967, Alan Shuggart and others left IBM to essentially found the entire disk drive industry.

Modularity creates options. You get the right, but not the obligation to use a new design. Before modularity, you have a single option: design a new system or not. With modularity, there are thousands of options. Each of those options can become a new company. These companies are formed around modules.

Option value can be high or low. Some systems have very high option value. This value can be seen in products where there are lots of versions and innovation happens very quickly. Where you have high option value and modularity, you get an explosion of industry.

Pres. Kim Clark, BYU Idaho (click to enlarge)

One key factor in option value is physics. Digital systems are a good example. Another factor is user innovation. Knowing about customers creates option value. This is the notion of the “killer app.” The third factor is architecture. Being able to take existing modules and rearrange them creates option value. Japanese copier manufacturers engages in this kind of architectural redesign and moved in on Xerox.

The potential value of a given system is a factor of the number of modules and the number of experiments. This is the idea behind the notion of “best of breed.”

Strategy in this kind of modularity is a lot like chess. There are lots of contingencies. There are many wining strategies. There are strategic patterns (gambits, to continue the chess analogy).

There are four strategies:

1. Blind competition. Many times players have no sense of what will happen and how it will play out, but companies get in and compete hoping to get bought if they’re good enough. Compaq, Kaypro, and others followed this strategy.
2. High return on invested capital (ROIC) on a small footprint. Examples: Dell vs. HP/Compaq. Sun vs. Apollo.
3. Lead firm competition. Microsoft is an example. Being a monopoly is a key strategy. Other smaller players also do this in niches. Mergers and acquisition (Cisco) is another example here
4. Open source development. Apache, Linux, etc. IBM is using this strategy.

He elaborates on the High ROIC strategy, going into detail on Apollo, “the darling of Wall Street.” Apollo kept control of many key aspects of the design. Then comes along Sun and the do even less. Their strategy was to use as many off the shelf parts as they could. Sun knew that you could focus on the core parts of the system and outsource everything else. Sun’s secret sauce was a piece of hardware that did memory management. Sun’s other key choice was to adopt industry standards wherever possible. Sun had half the working capital per dollar of sales compared to Sun. Their ROIC was 20% at Sun while Apollo’s was 2%. Sun needed less capital to compete. Dell has done even better. They have negative working capital. Their suppliers are funding the company.

He moves to “lead firm.” As the lead firm, you’re always under attack. Everyone is after you. The strategy is to deter potential competitors, even be threatening. Creating FUD is a key tactic. This is an unstable situation, as Microsoft has found out. A more stable “lead firm” strategy is Cisco’s approach. By buying small firms with big potential, they absorb the attackers.

So, how do you compete in a modular industry with modular clusters?

• Expect turmoil.
• Use M&A to become the lead firm in some slice of the stack.
• Use design architecture to reduce your footprint and increase ROIC.
• Use open source software to clone your complimentor’s products. That maintains discipline and innovation.

Rich Nelson of UTC and his staff are to be commended for a stellar event. Judd Bagley captured the audio. I’m hoping we can get it up on IT Conversations soon.

02:01 PM | Comments (0) | Recommend This | Print This

April 13, 2006

Larry Weber and Customer Experience

I really enjoyed listening to Larry Weber speak about his view of how the Web will change in the face of “user-generated media,” his catch all for blogs, wikis, podcasts, and everything else you can imagine. Larry is a well known high-tech PR person who’s thought a lot about how new media influences the behavior of companies. It was especially interesting to me because of some other ideas and work I’ve been doing on enhancing customer experience in eCommerce and online service contexts.

One of the key ideas I walked away from in the talk was that commercially oriented Web sites are all about transactions at this point: “click and buy” but that will change and the customer experience will come to dominate. Offline retailers have long known that if you keep the customer in the store another 20 minutes, they’ll buy more. Online merchants have had a tough time being that engaging.

Here are a few other interesting points (I’ve linked to related clips from the audio):

• The primary job of the CEO is to be an aggregator of community. Larry talks about creating constituency maps. If you do, you’ll probably be surprised at how many different groups you’re trying to communicate with.
• Why do companies still publish paper reports to shareholders? Why not have an interactive video with the CEO, the CFO, and some customers? Put it online in rich media.
• In the same vein, enterprise generated media is critical to the relationship that you have with your customers. Who needs press releases when you can have a blog? “They’re always dumb anyway,” he says. Why do you need marketing collateral? Podcasts replace interviews and so on.
• Proctor and Gamble is taking money from the TV budget in order to create blogs and wikis with the goal of getting feedback from customers on what products to develop, how they should function, and what they should look like. He says: “We don’t need to know everything about you, we need to know what you want from us.”
• The new success measure is length of engagement If you don’t have a social interface that’s thoughtful and educative, you’re losing money. We have to measure engagement rather than clicks. Get people on your site and have a party. Measure how long are at the party.
• Larry is sick of CEOs saying “I need measurement.” What they need is the ability to adjust. We’re living in a kinetic world. You can’s just throw something out and measure it without being able to change it (and I’d add “in real time”). This is a hard job.

09:04 PM | Recommend This | Print This

March 20, 2006

Document Engineering

At the InfoWorld SOA Executive Forum last week I met Bob Glushko who’s on the faculty at Berkeley’s School of Information, what they’re calling the “i-school” (with no royalties to Apple, apparently). Bob’s the director of the Center for Document Engineering. The mission of the CDE is to “invent, evaluate, and promote model-based technologies and methods that enable the automation of document-centric business processes and the implementation of business relationships as a network of document exchanges.” As XML technologies have made documents machine-readable and automatically processed, the notion of engineering these documents has become more important.

Bob’s also the author, along with Tim McGrath of Document Engineering : Analyzing and Designing Documents for Business Informatics and Web Services, a book I’ve had recommended to me by more than one person. I’ve ordered it and I’m anxious to read it.

When I spoke to Bob he mentioned that he’d just started blogging at Doc or Die. His latest entry references the SOA Forum and makes this statement about course-grained, doc-style vs. fine-grained, RPC-style Web services:

[T]he best argument for coarse document exchanges is that if you go that way you’ll be making a conscious design choice and almost certainly have invested some effort into designing the document models or evaluating standard document ones. The documents you exchange will more likely be ones that are easy to process because they’ll have unambiguous semantics and use robust code sets and identifiers. They’ll be easier to reuse across a range of related partners and services.

From Doc Or Die
Referenced Mon Mar 20 2006 15:15:45 GMT-0700 (MST)

RPC-style interfaces are almost invariably angle brackets around an interface designed for some other purpose.

03:06 PM | Comments (2) | Recommend This | Print This

March 14, 2006

Firefox Upgrades Still Painful

I’ve been putting off upgrading to version 1.5 of Firefox on OSX for a while now because it’s always a bigger pain than it ought to be. Last week I was forced to for reasons that I won’t go into. Like past upgrades, l had to play games to get SpellBound (the spell checker plugin) to work and enable Emacs keybindings to work. At version 0.9, I could understand and put up with this, but I’m growing tired of it at version 1.5.

08:41 AM | Comments (1) | Recommend This | Print This

February 16, 2006

Ron Kohavi on Data Mining and eCommerce

Today’s colloquium was Ron Kohavi from Microsoft research. His talk was titled: Focus the Mining Beacon: Lessons and Challenges from the World of E-Commerce (PPT). Ron was at Blue Martini Software where he was responsible for data mining. They developed an end-to-end eCommerce platform with integrated business intelligence from collections, ETL, data warehousing, reporting, mining, and visualization.

Later Ron was at Amazon doing the same thing. Again, simple things work (people who bought X bought Y). Human insight is the key—most good features come from human ideas, not extensive analysis. Amazon measures everything. Any change was introduced with a controlled experiment so that they could quantify the value of any change.

Really simple things help customers a lot. Customers want simple stuff. He references an experience at SGI where the Naive Bayes algorithm was what pleased customers the most even though it’s one of the simpler machine learning algorithms.

For data mining to work you need:

• Large amounts of data (lots of records)
• Rich data with many attributed (wide records)
• Clean data from reliable collections (no GIGO)
• Actionable domain (have a real-world impact, experiment)
• Measurable ROI.

eCommerce is a great domain for using data mining techniques.

Auto-creation of the data warehouse works well if you own the operational and analysis systems. At Blue Martini, they had a DSSGen process that auto-generated a star-schema data warehouse,

Collect business level data from the operational site. Collect search information, shopping cart stats, registration form stats. Don’t forget external events (marketing, etc.). Put those in the warehouse as well to correlate them.

You have to avoid “priors.” Businesses are amazingly biased and believe they know what they know is right. Data can help.

Do you collect form errors on the site? They did this for BlueFly. When they ran the report after the homepage went live, they noticed thousands of form errors. People were putting search terms in an email sign up box because it looked like a search box and there was no noticeable search box on the page.

Crawl, walk, run. Do basic reporting first. Generate simple reports and simple graphs. Then use OLAP for hypothesis testing and then ask the characterization questions and use data mining algorithms.

Agree on terminology. For example, how is “Top Seller” defined? Amazon and Barnes and Noble have a different definition. Sales rank can be hard to calculate when you’re doing it continuously.

Any statistic that appears interesting is almost certainly a mistake. He gives this example “5% of customers were born on the same day, including year.” This is because, lots of people enter 11/11/11 for their birthday when it mandatory. Daylight savings time creates a small sales spike in October and sales dip in April.

Simpson’s paradox: if you don’t understand this, you can reach mistaken conclusions. He shows the Bob and Ann reviewing papers example. Kidney stone example. Simpson’s paradox happens when summed data leads to one conclusion, but when you segment the data you get the opposite conclusion. This happened in a study of UC Berkeley graduate admissions where the aggregate data showed a greater percentage of men than women were accepted, but when you segmented the data by department, each department admitted more women than men. The key is understanding that the segmenting variable interacts with “success” and with the counts. This is non-intuitive. Here’s a formulation:

if a/b < A/B and c/d < C/D, 
then its possible that (a+c)/(b+d) > (A + C)/(B + D) 

Simpson’s paradox happens in real life. During knowledge discovery, you an state correlations and associate them with causality, but you have to look for confounding variables. This can be complicated because the confounding variable may not be the ones you’re collecting. Look for statements about confounding variables. Also, controlled experiments that split the population randomly, you don’t get the paradox.

On the Web, you can’t run experiments on sequential days. You can’t use IP to split population (load-balancer randomization) because of proxy servers. Every customer must have an equal change to fall into either population.

• Duration: only measure short term impact
• Primacy effect: changing navigation in a web site may degrade customer experience, even if the new navigation is better.
• Multiple experiments: on a large site, you might have multiple experiments running in parallel. Scheduling and QA are complex.
• Contamination: assignment is usually cookie based, but people may use multiple computers.
• Normal distributions are rare (97% of customers don’t purchase, leading to a skew toward zero.

Auditing data is important to make sure its clean and you get good results:

• Make sure time series data exists for the whole period. It’s easy to conclude that this week was bad relative to last week because some data is missing.
• Synchronize the clocks from all collection points. Make sure all servers set to GMT.
• Remove test data. The QA organization isn’t using the system in ways consistent with customers.
• Remove bot traffic. 5-40% of site traffic can come from search bots in some periods. These can significantly skew results.
• Utilize hierarchies. Generalizations are hard to find when there are many attribute values. When you have 20 million SKUs, you may not see many trends. Generalize product categories.
• Remember data time attributes. Look for time of day correlations. Computer deltas between such attributes (e.g. ship date minus order date).
• Mine at the right granularity level. Aggregate clickstreams, purchases, and other information to the customer level.
• Phrase the problem to avoid leaks. A lean is an attribute that “gives away” the label. E.g. heavy spender pay more sales tax. Phrasing the problem to avoid leaks is a key insight. instead of asking who is a heavy spender, ask which customers migrate from spending a small amount in period one to a large amount in period two.

Picking the right visualization is key to seeing patterns. A heatmap cross referencing date by day of week will show anomalies in purchases more readily than the classic “purchase by day” kind of graph.

UI Tweaks. Small changes to a UI make a large different. He gives an example from Microsoft help. Changing from a “yes/no” answer on “was this helpful” to “five starts” dropped response rate by 3.5 times. Another example is checkout page. There’s a factor of 10 difference in conversion rate on a checkout page when you add a “enter a coupon code” box. People think they should go see if they can get a coupon somewhere and abandon the cart.

One challenge is finding ways to map business questions to data transformations. SQL designers thought they were making it easy for business people to interact with databases. Explaining models to users is difficult. How can you make models more comprehensible? Slowly changing dimensions are hard. Customer attributes drift over time. Think about making recommendations for maternity dresses. Also, products change. Detecting robots and spiders is difficult. There are heuristics, but they’re far from perfect.

Ron finished with a few quotes: “One accurate measurement is worth a thousand expert opinions” (ADM Grace Hopper) and “Not everything that can be counted counts and not everything that counts can be counted.” (Albert Einstein)

01:49 PM | Recommend This | Print This

February 03, 2006

Newer Is Not Always Better

Today I ran across OldVersion.com who’s tag line is “newer is not always better.” OldVersion.com is a collection of old versions of programs. When I saw it, I thought of a couple of benefits: first old version often run better on old computers because newer versions require more resources. Second, some new versions disable features that you want or add features that interfere with how you use the program. One benefit I hadn’t thought of that’s listed prominently on the site is the ability to avoid spyware. Older versions of programs that are now bundled with spyware are often less tainted than new programs.

The most popular downloads? DeadAIM 3.2.8, LimeWire 4.0.7, Yahoo Messenger 5.0, Winamp 2.95, and WinMX 3.31. Older versions of iTunes are also available for those of you who don’t like the additional CRAP restrictions that are part of newer versions.

06:27 AM | Recommend This | Print This

February 02, 2006

Calendaring Tools

I put a piece up at Between the Lines on calendaring tools and in particular, SpongeCell a nifty online calendaring tool that accepts English language commands for creating appointments.

03:48 PM | Comments (1) | Recommend This | Print This

January 31, 2006

Internet Explorer 7 Beta

Microsoft has released a public beta of Internet Explorer 7. Supposedly more secure, less prone to phising attacks, blah, blah blah.

11:48 AM | Comments (2) | Recommend This | Print This

January 05, 2006

CIO Reporting Relationships

Found these interesting paragraphs in a story in CIO Magazine on their annual CIO survey:

There has been a corresponding change in your place on the org chart. Just over three-quarters of you now sit on the company’s management committee. Your most prevalent reporting relationship is to the CEO. That’s been true in all of our “State of the CIO” reports, but since 2002, in response to the cost-cutting fixation that gripped many companies and the fearful reaction to Sarbanes-Oxley, the percentage of CIOs reporting to the CEO had been going down while the percentage reporting to CFOs had been going up. This year, however, the percentage of CIOs reporting to the top boss rose from 40 percent to 42 percent, while those reporting to their CFOs dipped sharply from 30 percent to 23 percent.

The significance of this shift is both personal and professional and can be seen in the diverging circumstances of these two groups of CIOs. Of those CIOs who report to their CEOs, 91 percent sit on the company management committee, whereas only 61 percent of CIOs who report to their CFOs do so. The CFO reports say they struggle more with alignment and spend more time putting out fires than do the CEO reports. The CEO reports have much more money to spend (their average annual IT budget is $27.5 million versus $12.5 million for the CFO reports), and they take home more money as well ($196,800 in average annual compensation versus $180,700).

From Your Agenda 2006 Page 2 - Editorial - CIO
Referenced Thu Jan 05 2006 11:37:16 GMT-0700 (MST)

When budgets were tight, moving the CIO to a CFO reporting relationship must have seemed like a good idea because it made sure that reducing cost was the number one priority. It’s no wonder, however, that this reduced business alignment. CFOs, as a rule, aren’t particularly strategic—that’s not their job.

I think the problem’s even worse in those anachronistic situations where the CIO reports to some business line manager. How can you serve the business when only part of the business determines your budget and priorities? You can’t.

11:37 AM | Recommend This | Print This

January 04, 2006

Modularity Rules

A number of my colleagues don’t believe you can teach design, or at least that teaching design is hard to do. I not only disagree, but feel that if we’re to help students prepare to be influential, we have to teach design. Good programmers are also good designers, many are good architects. But for the most part, they’ve picked that up as an implicit part of their education. Explicitly people taught them the nuts and bolts of programming.

Consequently, I’m always on the hunt for books that I think future CTOs and CIOs ought to read. I found a spectacular example over Christmas break: Design Rules, Vol. 1: The Power of Modularity by Carliss Y. Baldwin and Kim B. Clark. This book is a must read for anyone who is or aspires to be an architect, CTO, or CIO.

Baldwin and Clark were at Harvard Business School when this book was written (Clark is now President of BYU-Idaho). The book is a great mixture of design, business, and technology that, in my mind, strikes right at the center of what a CTO ought to be concerned with: how architecture, specifically modularity, affects the value of products. Some finance and business background is helpful, but not an absolute must—I’d use this book in an upper division CS class with no business prereqs, for example.

The book is about the power and value of modularity in general, but Baldwin and Clark use the computer industry as an example. Most of us are so used to modularity in the computer industry that we take it as a fore-ordained imperative, but Baldwin and Clark show how modularity was imperfectly understood and executed in early computer systems and how IBM, with the creation of the System/360 completely changed the computer industry forever.

In the early 60’s IBM invested $20B in 1999 dollars to create System/360. That’s right—they invested $20B before they ever sold anything in a scheme that was quite risky. They had to issue more stock to maintain a positive cash position during the development period. The investment paid off handsomely, earning IBM approximately $170B in 1999 dollars as a result.

My first reaction was “what company today would have the resources and guts to invest $20B in a new, speculative technology product line?” But as I read, I realized that’s precisely the point: they don’t have to. IBM’s investment changed the nature of the industry so completely that modularization is the name of the game. Thousands of individual companies invest similar amounts in new ventures in aggregate, but no one company has to because of modularization. Not only is the investment spread out because of the architecture of computing systems, so is the risk.

Web 1.0 is a great example. Because of the architecture of the Internet and specifically HTTP, URLs, and HTML, thousands of companies tried their hands building modules to fit in that architecture. These experiments represented billions of dollars in investment. Some paid off and some didn’t. Rather than one or two firms trying to guess what people want and then investing everything in an all or nothing project, the modular architecture more or less assured that a decentralized market could run thousands of experiments. The result is the Web we use today. It’s modular architecture allows it to continue to evolve in a piecemeal fashion.

Design Rules does an excellent job of making this all explicit in ways and at levels that CS students seldom see. This book isn’t a book on software architecture. This is a book that tells you the power of architecture when it’s done right and quantitatively shows the value of modularity.

10:56 AM | Comments (1) | Recommend This | Print This

December 22, 2005

International Association of Software Architects

I didn’t know there was an International Association of Software Architects. Did you? Membership appears to be free.

12:25 PM | Comments (3) | Recommend This | Print This

December 13, 2005

Cut the Vision in Half and Ship It

How many of us can relate to this?

Moral: If you find yourself talking more than walking, shut up, cut the vision in half, and launch it. You can always fill in the gaps later. In fact, you’ll know more about what gaps need to be filled after you’ve launched “half a feature” than if you tried to fill them in before launching anything.

From Simple means launching something - Signal vs. Noise (by 37signals)
Referenced Tue Dec 13 2005 09:52:40 GMT-0700 (MST)

09:52 AM | Comments (2) | Recommend This | Print This

December 07, 2005

Google's Golden Rules for Effective Technical Teams

Hey! It’s Google Day at Technometria. Not really, but this was still interesting. Google’s Eric Schmidt and UC Berkeley’s Hal Varian list ten “golden rules” that Google tries to follow:

1. Hire by committee.
2. Cater to their every need.
3. Pack them in.
4. Make coordination easy.
5. Eat your own dog food.
6. Encourage creativity.
7. Strive to reach consensus.
8. Don’t be evil.
9. Data drive decisions.
10. Communicate effectively.

The goal is to be a good place for knowledge workers. They start by talking about Drucker:

At google, we think business guru Peter Drucker well understood how to manage the new breed of “knowledge workers.” After all, Drucker invented the term in 1959. He says knowledge workers believe they are paid to be effective, not to work 9 to 5, and that smart businesses will “strip away everything that gets in their knowledge workers’ way.” Those that succeed will attract the best performers, securing “the single biggest factor for competitive advantage in the next 25 years.”

From Google: Ten Golden Rules - Issues 2006 - MSNBC.com
Referenced Wed Dec 07 2005 21:07:13 GMT-0700 (MST)

There’s more detail in the article, of course, but I thought what they said afterwards about problems they face was more interesting. In the paragraphs that followed the golden rules, they talked about these:

• “Techno arrogance” that kills team work
• The not-invented-here syndrome
• Maturation of the company
• Ensuring communication methods keep pace with increasing scale

All in all, some pretty good points about keeping a technical team effective.

09:12 PM | Comments (1) | Recommend This | Print This

November 30, 2005

How Newspapers Can Use the Internet

Robin Miller writes an interesting essay at Slashdot on “why [newspapers have] failed to adapt, and what they must do if they want to survive in a world where the Internet dominates the news business.” The lessons are helful for anyone trying to build content-based Web sites.

09:55 AM | Recommend This | Print This

November 08, 2005

Business Continuity Planning for Academics

Writing about business continuity planning in light of avian flu scares for Between the Lines made me think about the same subject in the context of what I’m doing now: teaching classes, doing research, and interacting with students. I came to the conclusion that we could actually manage fairly well.

• My students are already using email and instant messaging to contact me. Naturally, we still meet face to face a good deal as well, using IM mainly for quick discussions, setting up appointments and so on, but in an emergency we could move more to IM and email.
• My classes already have most of the material online and my students use wikis for collaborating on everything from research projects to course notes.
• I’ve got a good podcasting set-up and could easily record lectures and post them online along with slides and other material.
• I give quizzes and other assignments online and much of the grading happens with online grading tools.
• I’ve not done online discussion sections using IRC for a decade, but that wouldn’t be hard to get going.
• I’ve got high speed Internet in my home and most of my students have it at home as well.
• I have a nice, private office at home (in fact it’s really much better than my office at work) where I could work.

Would it be as good as traditional course delivery? Probably not, but in an emergency it would be good enough.

I suspect other CS profs would do about as well. Even if they haven’t done much podcasting, turning on the mic and editing down sound is something they could easily figure out. Other, less technically inclined, faculty, might do with some training on these tools and non-technical students are probably less likely to be familiar with them.

03:33 PM | Recommend This | Print This

November 03, 2005

Twelve Reasons Not to Use Microsoft

Robert Scoble lists twelve reasons people tell him they don’t use Microsoft. The thread has over 100 comments. Interesting reading.

02:38 PM | Recommend This | Print This

September 26, 2005

Scale-up and Scale-out

As I listen to server manufacturers these days the choice seems to come down to “scale-up” or “scale-out.” The former meaning that you can get more processing power by adding more processors in the same server (symmetric multi-processing, or SMP). The latter technique increases processing power by coding the application to run across lots of 1U dual-processor “pizza-box” servers. Blades are a variation on that same theme.

Each of these has it’s place. SMP is particularly effective when the application has a monolithic architecture and requests for service aren’t always independent. Databases are a good example of the kind of application that people run on big SMP boxes because of cache coherency and other issues. Multiple, independent servers makes sense when the application can be split multiple independent tasks. Web servers are a good example of applications that people run “scaled-out.”

Some recent developments in the world of processors could portend changes to the conventional wisdom surrounding these two ways of scaling.

Intel and AMD support up to 4-way SMP and no more. You can buy 8-way, 16-way, and 32-way SMP machines, but this is accomplished at considerable expense and engineering expertise. I think we’re close to seeing the last of the 8-socket servers. Only IBM and Unisys sill make Intel-based 8-way systems. Currently, 8-way and higher SMP servers represent less than 1% of the Intel-based server market and that’s likely to go down. Here’s why:

From » Scale-up and scale-out | Between the Lines | ZDNet.com
Referenced Mon Sep 26 2005 08:19:27 GMT-0600 (MDT)

I was in Austin visiting Dell last week. This article is a reflection of thoughts I had while I was there and at IBM a few weeks before that. There used to be a time when I cared deeply about processors because I was always searching for a little more power. Now, I’m basically to the point where I don’t care. The switch by Apple from PowerPC to Intel didn’t even register. Still, as this article shows, there are some long term trends that are going to create some significant changes in how we use servers and how we program them.

08:15 AM | Recommend This | Print This

September 21, 2005

KVM Over IP

I’m in the process of buying a KVM over IP solution for my rack at BYU and it occurred to me, that I’d like this technology to be standard on every computer. I’d love for my keyboard, mouse, and monitor to just plug into the network instead of routing bulky cables. More than that, however, I’d love to get rid of a few of the connector types that plug into my laptop. The network is my docking station!

07:31 AM | Comments (11) | Recommend This | Print This

September 15, 2005

Jon Udell's Interview with Bill Gates

After engaging in a hand-slapping contest with Napoleon Dynamite for control of Microsoft, Bill Gates sat down with Jon Udell for an interview. Jon has the podcast and transcript versions available on his blog. It’s well worth reading—Jon geeks out with Bill and asks some great questions. Bill gives some good answers. Dan Farber, at ZDNet calls it “one of the better interviews I have read/heard in covering Gates for more than two decades.” Go Jon!

03:38 PM | Recommend This | Print This

September 12, 2005

Skyping a Good Deal on eBay

This morning Steve Fulling, CIO of Sento (where I’m on the board), asked me via IM: “why would eBay pay $2.6B for Skype when Oracle “only” paid $5.8B for Siebel?” Since he and I have had lots of conversations about customer interaction hubs and CRM, the context of the conversation naturally flowed in that direction. I realized that in some ways, what Oracle and eBay are doing is similar, although they’re operating at opposite ends of the longtail: they’re both selling tools for people who sell things to interact with the people who want to buy. Oracle is trying to sell expensive, feature-rich CRM software packages to big companies so that they can manage their customers. eBay enables small merchants to interact with with small numbers of customers for a small monthly fee.

But, why would eBay buy Skype? Unlike Yahoo! or Google, eBay has always had a fairly narrow strategy. Their Web site isn’t anything fancy and looks about the same as it did in 1998. So, why buy a VoIP company? I can think of several reasons which are squarely within eBay’s area of interest: exploiting longtail opportunities in eCommerce.

From » Skyping a good deal on eBay | Between the Lines | ZDNet.com
Referenced Mon Sep 12 2005 14:09:41 GMT-0600 (MDT)

This whole thing will be interesting to watch from an identity standpoint as well. eBay and Skype were both huge repositories of identity data. Now, the combined entity is gigantic. There will be plenty of opportunity for misstep. TO really exploit the combined entity, eBay will have to normalize the identities in some way. If they do it right, they could be a key player in Identity 2.0.

02:17 PM | Recommend This | Print This