Will Apple Survive until 2021? - Revisted

Two years ago I published a post titled: Will Apple Survive until 2021?
Apple is not unique. I published other Vendors Long Term Survival posts e.g. Google, Microsoft, HP, Software AG, SUN, EMC.

My conclusion was: "My answer is that the probability that it will not survive is higher than the probability that the other vendors (not including Software AG and obviously not including SUN) I discussed will not survive". 

My habit is to Revisit, when a significant event occurs.
Waze acquisition by Google is a significant event, which should need Anti-Trust clearance. Perhaps this event, is more significant for Apple than for Google. Apple's costly and unsuccessful Maps application is lagging behind Google Maps. 

Many Web pages pointed out on two losers, who tried to acquire Waze and failed:Apple and Facebook.
Perhaps, there is more than one loser, but The Loser is not Facebook. Your guess is correct: it is Apple.

Maps Business Value Proposition
Smart Phones and Tablets based technology may enable fulfillment of a an ancient dream of Location Based services and advertisement. Appropriate Maps application is a necessary condition. 

Waze uniqueness is its Social Mapping. Social Mapping could be a key for success in providing services beyond roads and traffic services.         

Revisit Conclusions
No need to change my 2011 conclusions: "My answer is that the probability that it will not survive is higher than the probability that the other vendors (not including Software AG and obviously not including SUN) I discussed will not survive".  

Customers Typology: The Good The Bad and the Ugly Part 1: The Good

Source: Wikipedia

One of my favorite movies is Sergio Leone's The Good The Bad and The Ugly. 
No Moral considerations are included in The Good's , and the other two's considerations. 

Many use this film name as titles to articles.
They classify products or people to three categories: The Good, The Bad and the Ugly.

For example, about 15 years ago, when Object Oriented was not yet a mainstream methodology, I read an article about Object Oriented programming languages.

It was written by PARC, a SmallTalk vendor. According to the Article The Good is Smalltalk, The Bad is COBOL and the Ugly is C++. 

In reality not always the Good survives. Java replaced SmallTalk due to its enhanced Scalability and better marketing. C++ and COBOL survived. 

The Good
The Good Customer, unlike the Customer who Knows Everything, knows that he does not know everything. He is able to estimate his knowledge boundaries: he knows what he knows and knows what he does not know. He knows what the Consultant knows better and what he knows better than the Consultant.

Unlike the Self-deprecating Customer, he does not agree automatically to all the Consultant's recommendations.
Unlike The Captive he does not always follow a vendor or an expert's recommendations.

Not accepting automatically, a vendor's view or a consultant's recommendation, does not mean ignoring this information. The Good Customer, considers all view without prejudice.

The Good Customer's ability to understand his knowledge boundaries, help him in finding an optimal definition of the Consultant's role and tasks: The Consultant should provide the knowledge and experience the customer lacks. 

This role definition enables the Consultant and the Customer to build a well formed working team. The team is goal directed and each team member complements the other.  

In order to define a customer who is an organization,  as a Good customer, most of its employees should cooperate with the consultant. 

For example, one of my Customer's CIO was  cooperating well. However, his deputy told me that he will not cooperate with me. 
"The reason for not cooperating with you is not related to you. It is because I am not cooperating with the CIO" he told me frankly.
Other employees of the same customer, who refrain from cooperating, were not as honest as he was: they told me nothing. 

The Good Customer expects a well defined products. Unlike the Paralyzed Analyzer, he use these products for planning and execution of the plan.  

Last but not least, the administrative aspects are  executed well, e.g. providing basic technical conditions like a working sit, an Internet connection etc. and paying to the Consultant as defined in the contract.

A Case Study: Israel Tax Authority
I selected an old Case Study in a very old topic: Y2K.
I selected it because I am not able to imagine another Consultancy assignment in which it is so obvious to notice that I (or even the most wonderful consultant) would fail, unless I would have a Good Customer. 

Y2K is a problem caused by usage of 2 digits year fields in Databases, Files and Program code. It is not possible to distinguish between the year 1900 and the year 2000, if you use two digits and not four digits.  

For example, a 105 years old woman was invited to join a kinder garden due to this bug. 105 years old woman in a kinder garden is funny and harmless, but collapsing national Tax Systems is a lot less funny.

The Israel Ministry of Finance used my consultancy services starting October 1999. According to two independent auditing authorities reports, there was high probability that the Israeli TaX Computerized Systems will collapse in January 1st 2000 due to Y2K bug.  

I had to provide a Second Opinion (a Third Opinion in this case). 

Issues and Methodology
Timing is a relevant factor. I had less than two months. The average Y2K project begun 2, 3 or 4 years before January, 2000 and not a month and a half prior this date. 

The Customer had approximately 50 different Application Systems, as well as additional Infrastructure Systems.

I had to create a special methodology due to the shot time until January 2000.

The following bullets summarizes my approach:

• My duty was more than evaluating failure probability, e.g 70%, 20% etc. I had to identify specific systems and specific issues. Solution: Scheduling meetings with all System Managers in order to map the systems and the problems ASAP. 

• The prevailing Y2K methodologies were irrelevant. They were suitable for longer projects. Solution: a new methodology adapting other methodologies to shorter time cycle. The new methodology was based on quick problem identification and assigning Severity level to each problem. High severity problems where immediately reported to the CIO and discussed in order to enable them to find a solution and execute it.

• adapt for scenarios in which not all problems will be resolved before January 2000. Solution: Assign Business Impact Value (BIV) to each system. Solve first all problems (including minor problems) in Systems with high Business Impact Value. For example, Income Tax System got the highest BIV. Fixing its problem first, could result collapse of another system with more sever technical problems. The other system could have a very low BIV because the tax it collects is very rare tax. 

The implication is that the customer should provide a rough estimate of the Business Importance of each system. This approach is applicable to Modern systems and concepts like SOA, BPM and Cloud Computing: Start with handling Business Pain Points.   

• If a problem unrelated to Y2K will occur in the beginning of Year 2000, it will be attributed to Y2K bug. According to Murphy's Law, if such a problem would occur, it would occur in January, 2000.  The Solution: In spite of the short time, critical no-Y2K problems should also be identified and solved prior to the transition to the 21 Century. 

The Results 

The Customer was satisfied. 
I met all System Managers and mapped the applications and the Infrastructure, identified systems BIV and specific Y2K related (and few sever unrelated) problems and the required solutions.  

The Customer fixed problems identified during the Consultancy Project, including few high-priority problems, popped up to the CIO immediately, as specified in the methodology. 

The conclusions were based on Risk Analysis.  The main conclusion was that no system is subject to collapse in January 1st 2000. A significant damage could be resulted only after the middle of year 2000. 

The systems behaviour after January 2000, supported my conclusions: No system collapsed at January, 2000 or later.  

The Most Important Success Factor
The Key for success was Full Cooperation. Every employee cooperated: CEO,CIO, CTO, Operational Managers, Systems Managers and every other employee.

It was impossible to schedule and perform about 50 meetings with all system managers in one month without full cooperation.

without full cooperation, It was impossible to get all the information about the Systems and surely it was impossible to fix them.