Monday, July 30, 2007

The Evolution of Apple

A great Harvard case about Apple Inc is available on http://hbswk.hbs.edu/item/5729.html for $6.95

The Apple case originally appeared in 1992 and has been rewritten 5 times since. "The company always looks a little different, yet many of the core issues that pose challenges for it remain constant," says Yoffie
From the executive summary

Executive Summary:
Apple's continuing development from computer maker to consumer electronics pioneer is rich material in a number of Harvard Business School classrooms. Professor David Yoffie discusses his latest case study of Apple, the 5th update in 14 years, which challenges students to think strategically about Apple's successes and failures in the past, and opportunities and challenges in the future. Key concepts include:

  • Apple has an undeniable hit with the iPod, yet faces the question of whether the growth of that business and Apple overall can be sustained.

  • Looking at Apple through the lens of the company's previous chief executives gives students insights into why Apple lost its way after Steve Jobs left the company.

  • Student opinion of Apple tends to be excessively positive or excessively negative, depending on the company's current fortunes.
--

I suggest taking a look at it

Monday, July 23, 2007

A New Strategy for the Enterprise Software Industry (Post 2 of 4)

A SheeleyTech working paper

This is post two of a four post series.
1 A background of the enterprise software industry.

2. An examination of this industry using the analysis techniques in Clayton Christensen’s book Seeing What’s Next. I analyze the customers of this industry by categorizing them into undershot customers, overshot customers, and non-customers. This analysis determines which market segment offers the largest opportunity. I then look to see if the industry is signaling a change to target this market segment.

3. A competitive comparison determining which players are best to implement the strategy based on their resources, processes, and values.

4. My strategic road map for the company that is best fit to become the next leader in the enterprise software industry.


Customer Analysis
Undershot Customers are most likely very large corporations who will pay exorbitant amounts of money for slight improvements to their current enterprise systems. These customers can take advantage of economies of scale. The sizes of these businesses allow them to profit off of any improvement to the enterprise system.

Overshot Customers are small to medium size businesses that cannot adsorb big costs for every upgrade to the enterprise system. These companies tend not to pay for new improvements or the latest release. These companies have to anticipate big returns for any purchase or upgrade to the enterprise software.

Non-customers are small companies that tend to find cheaper alternatives that might not be the best solution but help get the job done. In these businesses you will find collections of excel applications that have been transformed into advanced accounting and management programs.

According to the US census bureau, in 2004, 99.7% of companies in the United States are small to medium size businesses[i]. If my overshot analysis is correct, then most businesses in the US are overshot customers. Anyone who works in an IT department that manages SAP or Peoplesoft enterprise systems, or knows someone who does, is aware that these systems are highly complex and upgrades are very costly. Integrating new features into these systems require IT departments to work weekends, cause downtime to the systems, and require an upfront purchase of a license and hardware for the new components.

According to Christensen’s model, if there are overshot customers in the industry then low-end disruptive innovations, displacing innovations, and downward migration of required skills will be occurring.

Looking at the software industry, there should be signals that these trends are emerging. We will look at the OnDemand business model as a low-end disruptive innovation, niche CRM and customer contact solutions as displacing innovations, and the emergence of Web Services and webapps as a downward migration of required skills.

The OnDemand Business Model is one that allows customers to use the software under a variety of payment plans. Companies with the business model offer solutions that do not require upfront costs for new hardware or software installations. The software is priced at different levels that allow their customers to pick the plan based on the level of usage required. These solutions give small and midsized businesses cheaper solutions than purchasing more expensive licenses and new hardware.

Niche CRM and Customer Contact Solutions are just a few displacing innovations that have emerged. Displacing innovations take aim at a specific feature of an existing product line. Solutions that target customer relationship management and customer contact campaigns are just a few of the areas where new players are sharpening their expertise. Their customers do not want to pay for an entire enterprise system or have already purchased one but are willing to pay for specialized features particularly needed for their industry.

Web Services and Webapps are examples of downward migration of required skills.
Web services are a means to define and expose application interfaces. Web services allow for easy upgrades and integrations of existing system. Web services are interfaces that define and verify integrated systems. Also, Web services allow enterprise systems to be loosely coupled, so that each component of the system is less dependent on the other components. This reduces the experience needed by IT departments to maintain and integrate new components into the systems and reduces the downtime required for most integration efforts. This also allows niche solutions to be created without complete knowledge of the other enterprise systems in their customers’ existing systems.

Webapps are applications that are accessed over the internet. These applications require now hardware, downloads, or installations. They are practically a webpage that looks and feels like an application. New enterprise solutions are emerging that are exclusively webapps. These solutions do not require an IT department or even a highly technical employee to do the setup.

These signals and trends are clear signs that the enterprise software industry is changing and is refocusing on the overshot customers who make up most of the business market. Next, I will analyze the competitive battles and determine which players are preparing to emerge as the next enterprise software leader.

[i] Small business is usually defined as under 100 employees and medium size businesses are usually defined as companies with 100 to 500 employees

Sunday, July 22, 2007

A New Strategy for the Enterprise Software Industry (Post 1 of 4)

A SheeleyTech working paper

This is post one of a four post series.
1 A background of the enterprise software industry.

2. An examination of this industry using the analysis techniques in Clayton Christensen’s book Seeing What’s Next. I analyze the customers of this industry by categorizing them into undershot customers, overshot customers, and non-customers. This analysis determines which market segment offers the largest opportunity. I then look to see if the industry is signaling a change to target this market segment.

3. A competitive comparison determining which players are best to implement the strategy based on their resources, processes, and values.

4. My strategic road map for the company that is best fit to become the next leader in the enterprise software industry.


Background
In the 1970s, IBM and other software companies created the first widely used enterprise software applications. This disruptive technology allowed companies to digitally manage the business’ payroll and financial accounting. These systems were host-based. Host-based architectures perform all functions of the system on one machine. The storage of data (financials, and employee information), the processing of the data, and the presentation to the user are run on one mainframe.

Since this time, a series of sustaining innovations has occurred. Functions that address, human resource departments, customer relationship management, supply chain management, inventory management were added to enterprise software systems in order to meet the demands of the current market. The enterprise systems also changed into client-server architectures to increase the accessibility of the systems and to take advantage of processor power of multiple machines. These systems are a collection of dedicated database machines and dedicated processing machines. Users access these systems through client applications on their local PCs, many times through a web browser. These systems became widely popular and large enterprise companies such as SAP and Oracle capitalized on their demand.

In the past few years, new types of enterprise systems are emerging. Buzzwords such as OnDemand, Saas (Software as a Service), SOA (Service-Oriented Architectures), and webapp (web application) are used to describe these new types of systems. Companies like Salesforce.com, SoundBite Communications, WebEx, and RightNow Technologies Inc. are the new players in this field. These systems do not require the customer to host software on their networks. There is no IT department required to maintain the systems and many of these applications use an onDemand billing model. These models bill the customer each time the system is used or allow for multiple pricing plans rather than purchasing a license or other expensive one-time charges.

Thursday, July 19, 2007

A TRUE benefit of using web services document style messaging over remote procedure call (RPC) style

Before reading this post, if you are not familiar with web services check out
http://www.ibm.com/developerworks/webservices/library/ws-docstyle.html
or
http://www.java-tips.org/java-ee-tips/enterprise-java-beans/document-handling-in-web-services-applica.html
or even
http://en.wikipedia.org/wiki/Web_service


The top three benefits of document over RPC are validation, asynchronous processing, and a less rigid contract between the client and the server. The first two benefits are more of a coding convenience than an added benefit and don’t really impress me. To me the third benefit is really the power of document style. But until my current project, I have yet to have a situation where I was able to utilize this powerful benefit. I want to explain my case for why a less rigid contract is the only powerful benefit and then I want to share with you a situation where documents style messaging is really the only option. (Note: there is this idea of using document style to save state, but my disagreement with this idea will soon become a completely separate post on SheeleyTech. For right now, just trust me. For most systems, don’t try to save state through web services.)

Validation in XML This benefit uses the power of XML. Document style uses the power of XML to validate the message where as with RPC the code behind the operation does the validating. So either the code does the validating of the XML. No big deal. (except that it allows you to have a less rigid contract, but that’s more than just validation)

Asynchronous Processing Ok another feature of document style, but I can name many other ways to get my RPC style call to be asynchronous for the client. Again, no big deal.

A Less Rigid Contract Now this benefit is cool. The idea here is when a client uses an RPC style web service; the client application relies on that specific method signature. Any change by the client of the parameters will break the client application. In other words, the interface cannot ever change unless it changes on the client as well. With documents style, this isn’t the case. Changes to the server interface that in RPC would change the interface, in document style only change the schema and therefore will not break the calling application.


So if you are like me, the last benefit sounds really cool, but where would you need it. I mean, I have used documents style in the past, but only to help future efforts that might need to make changes to the interface. …well, actually I used it only for the sake of using a documents style, RPC would have done the trick just as well. Besides, I’m really not quite sure how I could later change the schema without hurting any client applications. If they are relying on some data being in the Document message and I remove that data from the schema, won’t this cause them to have errors? This whole idea of using document for “great” benefits over RPC has really escaped me. ...until now.

My current project is enhancing a really cool application for the Air Force Research Lab. The need is for the system to be able to act as a standalone application (i.e. the client and the server are all on the same machine acting as a single application) and also act as a service and a client. (i.e. the client will be located on one machine and the server be on another machine handling service requests from whom ever is calling it).

The reason document style is needed for this design is because of the services that the server is exposing to the client. There is a ton of them (for this post we have N of them). Each service has its own set of parameters. In order to handle direct and web service mode, at first we thought we needed N times 2 handlers for each service (one to handle calls to the service directly and one to handle the call through web services). (See Diagram 1 below) Instead, if we use document style messaging for the web services, we can define the parameters for each service in the schema. We can have 1 handler for all calls thought web services and one handler for all calls to the services directly (See Diagram 2 below).

Diagram 1 A quickly made diagram of the system using RPC style messages

Diagram 2 A quickly made diagram of the system using document style messages

Before, the reason we needed N web service handlers was different parameters for each service. With document style, the parameters are defined in the schemas that define the structure of the XML document. The service proxies are needed to gather the required data for each service. Once the proxies have gathered the data, they can pass on the single parameter to the web service handler. The web service handler now only needs to make a single generic call that passes in the single parameter.

This design is simpler and contains fewer dependencies. It should also cut down on the time needed to build the system. I hope this now gives you a concrete real world use of web service document style messaging.

Wednesday, July 18, 2007

Radio can still do what google and itunes can't

Last night I listened to the both the director and general manger of sales for WFNX Radio in Boston (http://fnxradio.com/1/home.asp). They were talking to my ebusiness strategy class at Bentley College. They talked about the radio industry and challenges they face in this new internet world we live in. I found it interesting to hear that they didn’t see the iPod or online advertising (Google, Yahoo!, etc.) as a threat to their business. They are sales guys so my first reaction was, oh yeah right. But the more I think of the points they made, the more I think the terrestrial radio industry does have a chance of survival.

Their argument was that people listen to terrestrial radio because of the connection to community, and the local customization that they offer. The example they gave was the following. When you only listened to downloaded music, you lose touch with what is going on in the local news, music, and sports scene. You become disconnected with the constant real-time stream of up-to-date information. They noted that people put radio station bumper stickers on their cars of because people identify with local radio stations. You don’t often see people with a New York Time or Google bumper sticker.

I think they might have a point but I feel the radio industry is going to have to move much faster and adapt new technologies that will keep them ahead or equal with their competitors. If community and local customization are their key advantages, then they need to capitalize on these points.

Right now when I listen to a radio program I picture a group of DJs or talk hosts sitting in a room with microphone talking. I think they need to step out of their stations and into more locations. They need to integrate more with the local community and host their shows in traffic during rush hour, or at the local mall. They do this now, but they need make it less of a special event and make it an every day thing. Google can’t pull up in traffic next to its audience or visit the local Dunkin Donuts, but local radio can.

Take the local Fox news station here in Boston http://www.myfoxboston.com/myfox/pages/InsideFox/GoodDay?pageId=5.2
Their morning program does these promotions called Zip Trips. Every Friday they do their morning show from a new town. They promote the town all week and give new facts about it. When that Friday morning comes along, people from all over the town are at the broadcast crowding the backgrounds of the cameras.

Listeners want to feel connected, and they want to feel that they belong to something. If terrestrial radio can capitalize on the personal local community aspect of their business, then they do have a chance. Online advertisers are constantly looking for ways of focusing ads to specific customers. But if radio can keep their devoted communities of followers, then advertisers will continue to tap into these valuable markets.

Tuesday, July 17, 2007

Web2.0 and Mortar

We all know the story of the dot-com boom and bubble. Ecommerce sites were popping up with hopes of becoming successful businesses. The hype grew so big that people were predicting the end of malls and regular retail stores. Now that the hype has come and gone and regular retail still remains. Now most businesses have an online and a store presence or also known as “click and mortar”. Turns out, having both a store and an eCommerce site is the best strategy in retail.

Now we have web2.0 (http://en.wikipedia.org/wiki/Web2.0). I guess web1.0 was the checkout feature and now web2.0 is the wiki, social networking, customization, blogs, and more. Websites are now appearing that are web2.0 businesses. Myspace, wikipedia, igoogle and other sites are set to be the next thing. These technologies are not necessarily profitable but companies are paying big money to buy them up for fear of missing the web2.0 boat (the purchases of friendster and youtube come to mind). But what if the conclusion of web1.0 turns out to be the proper conclusion of web2.0? What if the profitable outcome of these web2.0 business models is not just to create a website but to incorporate the features of web2.0 into a physical store. We can call it “web2.0 and mortar” or “wiki and mortar”.

Could web2.0 move to the real world? Could the experience I have when I walk into Wal-Mart be different for me that for you? Could the isle next to the milk be coffee for me but cereal for my wife? Probably not. But I can see large communities of people change the how a store operates or what it sells? a wikistore? Stores are constantly doing market research to find out what their customers want. Why not just let them define it for the store. Customers logon to the stores website and edit the wiki-inventory and add and remove new items.

Or what if you can network with other customers in the store? Would the social networks that myspace creates be created for a brick and mortar store? If a community forms around your store are they more likely to buy? Will they feel like it is their store? (i.e. a more loyal customer base.) Just like communities and social groups helped make Ebay what it is today, could the same happen for the local grocery store or for the local pizza shop? Are we as consumers on the verge of having more control or say in what we buy and what services are offered to us? Will web2.0 become a profitable business model for Brick stores? I think the answer to this will be if the large collective knowledge of customers make companies more profitable than the a few very smart executives. I think we are not far away from finding out.

Monday, July 16, 2007

Engineers know best

In my current position, I switch from a project management role to a software engineering role depending on the project. Each project I get a different perspective of what is needed to make a project a success. This volley of perspectives, in my opinion, is making me a better manager than if I was no longer an engineer.

For example, a few months back I was acting as a software engineer. My job was to develop a utility component for a large planning system. The component was an HTN planner (http://en.wikipedia.org/wiki/Hierarchical_task_network) cool stuff! Anyways, with two months left before the project was due, I still had a lot of code left to write. The project lead at the time kept pushing me to delegate some of the work to another engineer as to assure that the development would finish on time. The problem was that all of the tasks that were left depended on the piece I was still working on. I couldn’t have someone else work on them because the code wasn’t ready yet. I was unable to explain this to the project lead and he assigned someone to those tasks anyways. The engineer now working on those tasks quickly realized he could not properly work on his assignment and decided to do the best he could. In the end, it actually took longer redoing his tasks. A few weekends and nights at the end of the project helped finish everything on time anyways.

Now I am acting on another project as the project lead. Last week we got word that the project’s due date has cut short by two weeks. It is up to me to figure out how to remove two weeks from the schedule and still complete all of the tasks. The two options for cutting back on a schedule are cutting the scope of the project or increasing the man power. Unfortunately, we cannot cut back on the scope. Given the nature of this effort, all pieces are absolutely required. The only thing left was to add more people. Using the cash reserve planned into the project, I am able to assign another engineer to the project.

I ended up asking one of the engineers to look over his tasks and look for something to carve out for someone else to work on. The reply, “sorry, there is no room on my tasks for someone else.” I looked as the description of the tasks he had again. It was the largest set of tasks on the project and it was on the critical path. It had to be broken up. I brought it up to another manager who had worked closely with this engineer a lot. He said he would talk to the engineer. Again the engineer would not change his mind.

Then it struck me. Here I am, doubting an engineer on his recommendations for the tasks that he knows more about than anyone else. He is a great engineer. Who am I to doubt him? He says he can get the work done quicker if needed but only if he is the only one working on that part of the code.

I have decided to trust the engineer and not assign anyone else to the project. I hope he is right.

UPDATE: See Engineers know best - follow up

Saturday, July 14, 2007

lifeaholic - First Post!

I find myself wondering if I am what everyone calls a workaholic. I get up in the morning, work all day. When it’s the end of the day I either head to class until 10 PM, I come home and study or I head to a professional organization meeting. On weekends, I am either reading my textbooks, writing a report, or reading a book directly related to my career. I watch TV but it is usually CNBC.

Everything I look at and do somehow comes back to my career and my work. But is this because I am obsessed with my work? Or is it that the world I live in is obsessed with the type of work I do? Take the iPhone, for example. It’s a small computer, it runs software on it. Everywhere I turn someone is talking about this device. Or take Google, the term “Google” is now a household verb that everyone uses. “Google it!”. but when someone says it, I hear “use a technology that did not exist ten years ago and was developed recently by two guys who developed a new search technology and slapped a very simple interface on it, and use it to help you”. If I go to the checkout counter at the local Shaws and I am using the self checkout, I can’t help but find myself thinking of all the challenges the developers went through while creating this piece of technology. But they did it and now I am checking myself out of the supermarket faster than I could have without it.

I guess for the non-techie who works in another industry these are not part of their work, but for me this is what I do. I look to solve problems with computers. No matter where I go there are examples of technologies solving problems and making people’s life easier. So how can I escape my work? Do I want to?

I can write software, I can manage software projects, I understand how businesses run, and the strategies their executives are taking. This is my career and at the same time this is the world we live in. Am I a workaholic or am I just loving life? I see it as the latter. I love the world I am living in. I see it as a better place than ever before. I love it so much I too want to make it better. I want to learn about life more and more. I am a lifeaholic.