Archive

Posts Tagged ‘telecom assets’

Separating the 3G/LTE bit-pipe and voice from data to survive

Large operators are focusing on building the fastest and most reliable networks; increasing call and SMS traffic; offering the best data plans for surfing; offering excellent business communication services; building a machine to machine business; offering impressive IPTV; etc. Management effort has to be divided between all these and other businesses. The quest to get departmental budget is long and hard.

So if you are a telecom CxO and you get three business cases, which one do you choose?
1) LTE business case – heavy investment but strategically key and very good ROI
2) IP PBX vs on-site equipment business case – low initial investment and clear business model
3) Telco PaaS business case – low initial investment but unclear business model

Any business leader would say 1 is best, then 2 and do not invest in 3. However there is something called “The Innovator Dilemma“.  LTE will make it easier for dotcoms to offer IP PBX as well as cannibalize voice and SMS revenues because over-the-top players will be able to offer mobile VoIP and IM. Even if a CxO would invest outside of LTE in disruptive technologies then it is still very likely that the best people will want to work in the LTE project and not in a disruptive technologies project.

Note: An operator that does not invest in LTE will be dead in 2 years so investment in new network technologies is crucial for operators to survive in the short-term. So the solution is not to invest only in disruptive technologies.

So what should operators do?

Create a holding company and three independent sub-companies:

  1. The bit-pipe
  2. The cash-cow manager
  3. The future

The bit-pipe company is focusing on the network and its operations. Cost reductions, stability, network quality and new network technologies, e.g. LTE, are key for this company. This company should be able to work on low margins and even work together with competitors if it makes financial sense, e.g. share network resources or resell capacity to competitors.

The cash-cow manager should also be a company focused on maximizing profits and minimizing costs. The cash-cow manager gets to manage the circuits and deliver voice, SMS and traditional telco services. They have the liberty to provide these services on top of other networks if it makes financial sense.

The future is a company that will have the bulk of the people and some seed capital that will pay salaries for the next 18-24 months. The mission should be clear: “Focus on new revenues coming from data”. There will be no cross-charging between the other two companies. Either you get new revenues or your future is looking very bad. Why would you be so extreme? Look at McKinsey, Telco2Research, etc. they all say the same. Key telco assets will loose their value in the coming 2-3 years as has happened with location. Or operators start to work on new data revenues NOW or they will have to fire tens or hundreds of thousands of employees in 2-3 years. Telefonica already started a process to fire 20% of the workforce. Separating employees into a new company and giving them one mission will make everybody focus on success. Innovative revenue-generating data services is what the telecom industry needs. Without it everybody will start feeling the pain very soon…

How to avoid becoming a bad Amazon-clone when doing IaaS?

February 17, 2011 Leave a comment

In previous posts I already expressed my doubt about telecom operators getting any real benefits from offering virtual servers and other IaaS aspects to their customers. It looks like “a 2000 déjà vu” in which operators started to offer hosted email after Yahoo and other showed them the way…

So if you don’t want to be a bad clone of Amazon AWS what can you do?

Alternative 1: The Mobile IaaS

Operators are all about mobile communication. However creating mobile applications is hard. Testing them is even harder. Let alone testing them on different hand-sets in a continuous automated testing approach.

This is exactly the type of services that a mobile operator can offer:

  1. Mobile hardware virtualization – instead of virtualizing an x86, why not virtualize the phone hardware, e.g. Nvidia Tigra2. A mobile operating system (MOS) developer could choose which hardware to virtualize: the amount of ram, which sensors, which CPU, which graphics card, etc. Afterwards different flavors of operating systems can be ran on this hardware: iOS, Android, Blackberry OS, Symbian, Windows Phone 7, etc.
  2. Mobile operating system virtualization – For less experienced developers they can already pick a pre-configured phone, e.g. iPhone 4. Afterwards a developer can launch applications on the phone.
  3. Automated mobile phone testing – After installing the application on the phone or using the build in browser to access a remote application, a developer should be able to run automated tests. This would allow for a continuous testing approach whereby a new version of a mobile app or an HTML5 application can be automatically tested by a whole set of mobile devices.

The business model would be the same as virtual servers: you pay by the hour.

Alternative 2: Telecom Infrastructure as a Service

Why not offer telecom infrastructure as a service instead of pure virtual servers? Admitted, the boundry between IaaS, PaaS and SaaS might be thin but ideas can be the following:

  • Billing as a Service: this can go from offering a complete billing system as a service to MVNOs or other industries that need real-time billing capabilities. To the other extreme whereby you would only offer APIs for partners and developers to charge.
  • Numbering Plan as a Service: more then just offering DIDs, you should be able to create services and associate them to a number formed by shortcode+mobile phone+app id => 12367012345601 => calling this number would forward the call to the application 01 belonging to the mobile subscriber 670123456 and 123 means the owner pays the call. 234 could mean caller pays. 345 could mean caller pays premium call and gives revenue share to owner. This could allow every subscriber to have multiple applications without having to pay €1-€5 for a virtual phone number.

Alternative 3: Mobile Development IaaS

Different from the mobile IaaS in the sense that we focus on facilitating the development and hosting of applications for mobiles. Developers would find tools to develop mobile application interfaces very easily. You write it once and run it on a large set of different mobile devices. Services like mobile push notification, device detection, charging, etc. should also be available. Also the hosting is optimized for mobile applications in which you have very strict low-latency and unreliable connectivity requirements.

Alternative 4: Beat Amazon AWS at Bootstrapping, Configuration Management, and other cloud operation automatization

If you are going to offer virtual servers, focus enormously on the bootstrapping and configuration management. Amazon and others have virtual images that allow a quick deployment of an existing configuration. However that is good if your application is stable and your software stack needs few modifications. Real-life applications and business solutions need a lot more flexibility. Setting up a database cluster, a webserver/proxy/memcache farm, a high-availability loadbalancer, an application server cluster, etc. are very manual tasks on most public clouds. True you can get an image with an apache, tomcat and mysql pre-configured, but you do not get a multi-node cluster image. To solve this you could use software like Chef or Puppet for provisioning and ControlTier or Capistrano for command & control. See my other blog post

Alternative 5: Be the Salesforce for Telecom & Mobile Applications

This is more PaaS then SaaS but being a Telco PaaS in which in a Salesforce.com style you can use Web 2.0 and drag-and-drop to create mobile and telecom applications. Instead of having to code, people can create application via visual designers.

Alternative 6: No.de/Heroku/etc. alternative for quick web & mobile front-ends combined with custom protocols and on-site systems

No.de is PaaS for applications written in Node.js a javascript language that allows for massively scalable applications to be quickly developed.

Heroku is a PaaS for Ruby applications.

These are language specific PaaS that are similar to Google App Engine (GAE).  Where GAE allows Java and Python, No.de has Javascript and Heroku has Ruby. Developers can very easily create applications. However GAE falls short writing front-end applications: Web GUI/Mobile HTML5 quickly. Also integration with non-HTTP protocols is not offered. Although the Internet lets you believe HTTP and FTP are the only protocols out there, there are literally thousands of binary, alternative standards and proprietary systems that large enterprises can not do without. Examples in the telecom industry are RTSP, SS7, etc.  If you can combine the speed of developing modern front-end together with the integration with legacy systems, binary protocols, on-site systems, etc. then you can have a large advantage when corporations want to move their back-office to the cloud.

Alternative 7: The Zoho/37 Signals for Telecom Applications

Zoho and 37 Signals are companies specialized in creating one-purpose mini applications for small and medium enterprises. Instead of a Siebel, Zoho will give you a basic CRM that works out of the box and has virtually no learning curve.

Zoho allows others to build applications on their infrastructure as well and resell them.

The same concept could be applied to telecom. Mini telecom applications like a PBX in the Cloud, SMS marketing, etc. are build on a common infrastructure. Externals can extend the application portfolio and resell them.

Alternative 8: Hosted PaaS

Instead of offering PaaS you offer a hosted PaaS infrastructure for enterprises. Each enterprise gets their own PaaS. Companies like Longjump and WSO2 are in this market. Be sure to add in some telecom assets…

My telecom assets are under attack. What should I do?

November 22, 2010 2 comments

The last player to join the attack on the telecom operator’s business is Apple: How to bypass carriers, Apple-style? (Special thanks to Dinesh Vadhia).

Apple never played according to the telecom rules in the first place. They have been the only mobile hardware vendor that could set the rules instead of negotiate them.

Who is attacking my assets?

So which telecom assets are currently under threat:

  1. SMS – instant messaging has been attacking SMS for years but now with the next generation of smart phones the number of SMS killer apps has exploded.
  2. Voice – Skype and VoIP providers have been attacking voice calls for years. However also here smart phones are accelerating decline.
  3. Roaming – Apple’s independent SIMs could easily attack the roaming segment. Also VoIP on Smart Phones will.
  4. Billing – Micropayment solutions from Paypal and Google Checkout are trying to enter this domain. Squared from a former Twitter-employee is attacking the mobile payment terminals in shops.
  5. Spectrum – Google’s CEO is the chairman of the New American Foundation that is trying to convince the American government to open medium-distance spectrum for free. Sort of WiFi but with kilometers reach.
  6. High-speed interconnect networks – Google is paying part of some of the under-sea links that connect multiple Asian countries.
  7. Fiber to the home – Google is rolling out fiber to the home.
  8. VAS – mobile apps are taking over from the value-added services.
  9. PBX like Business solutions – on-site premise equipment is being substituted by virtualized Cloud-based solutions.
  10. The telecom network – telecom operators are becoming bit pipes. New bit-pipe-only companies however are trying to specialize in this domain, making it hard for communication service-oriented operators to keep on making the same profits.

What should operators do?

If there was one simple answer, I would not be writing this post but living on my own private island 😉

However if history can be a teacher, let us look at an industry that has been facing similar threats: Hollywood. Prices of distributing digital content have fallen close to zero. However the industry has been trying to keep on charging €12-€30 for CDs and DVDs. They have hardly embraced digital distribution and are now in a negative spiral of demise.

Telecom operators can easily get stuck in this same vicious circle. History has been cruel in the past: extremely lucrative postal monopolies were destroyed by email. There is no rule that states that economic wealth from one business model is substituted by a similar lucrative business model afterwards. Often analogue dollars are traded for digital pennies.

Accept digital pennies but collect them all

The first survival strategy is to embrace change and to go for digital pennies. This is often hard to do within existing companies. As such the proposed strategy is to set-up a parallel organization whose objective is to focus on these new business models and how to make money with them. Let the main company focus on the telecom hits (Voice, SMS, etc.) and the other company on the long-tail telco services.

Long-tail telco services are all about enabling communities of developers and companies to create new and innovative telecom solutions that they can sell to others. The focus should be on enabling others. Not on building them yourself. Being an App Store for telecom network-assets-based applications and not a builder of telecom services.

This parallel organization should be in close collaboration with partners and even dotcoms. If you can´t beat them, join them. Find ways of enabling startups to become successful with your network and other assets, not on building a parallel solution around your assets.

The music industry never understood this message but hopefully the telecom industry does.

Go IP and forget Circuit

Accelerate IP solutions and forget about circuit networks. The speeds at which services are rolled out in a circuit-based network are too slow to fight off competition. Isolate the circuit-based network elements and put an IP-based front-end.

Use the Cloud to quickly launch beta services.

Avoid building infrastructure and use the Cloud to innovate. In the telecom world services are often not launched until they are perfect. But perfect for who? It is better to launch beta services quickly and get real customer feedback instead of marketing-surrogate feedback. Launch multiple services. Check which are the successful ones. Kill the others and heavily invest in the successful ones. Cloud computing and open source can dramatically reduce innovation costs.

Build long-tail services and a common innovation-ready architecture

If you are going to work with hundreds of partners to quickly innovate then the way to interact with them is via self-provisioning. Build billing, telco network app stores, customer care, monitoring, etc. solutions that allow a third-party to automatically provision and test their solutions. Be open with interfaces and light on approval. Let them approve a web-based contract instead of sign a physical paper.

Also enable innovation via the right infrastructure. Let teams focus on the business and services. Not on storing data, managing users, billing, monitoring, etc. Common service APIs to interact with assets and common ways of building new services should accelerate time to market and avoid reinventing the wheel.

This is a time for innovation together with smart partners. Not a time to focus only on CAPEX reduction. Too many effort is spend on operating as cheap as possible and not on generating new revenues. At the end the best CAPEX reduction is to shutdown a telecom company that does not innovate at market speed and became obsolete 😦

 

Marketing’s and IT’s loss of power

November 4, 2010 Leave a comment

In Telco 1.0, “marketing” decides what customers want and “IT/Network operations” will take 12 months to roll out the new service.

In Telco 2.0, the marketing department no longer decides what customers want and IT/Network operations have 3 months to roll out hundreds of new services.

Impossible?  What is Telco 2.0?

Telco 2.0 is the age where Internet technologies and business ideas meet the telecom world. What are these new ideas?

1. The customer is always right

No group of marketing experts is better able to predict what customers want then the customers themselves. In the dotcom world, customers are in control. They get an avelanche of services and options and via other people’s rating, comments and collective intelligence are able to decide what best suits them. Instead of launching one new release every 6 months, dotcoms launch new incremental features on an hourly, daily or weekly basis. Often several alternatives for the customer to pick from. It is the customer that decides what is right for them and what can be killed quickly due to lack of interest.

2. Give the customer control

If the customer knows what they want then they should be able to get it and if it is not available build it themselves. The explosion of Appstore apps shows that different customers like different things. In the next 12 months we will see VAS stores and build your own VAS designers allowing users to build or configure their own value-added services.

3. Allow the customer to make money

Whoever builds a great VAS should also see an abundant reward for it. High revenue shares for innovative thinkers are becoming the trend. Consumers selling solutions to consumers is no longer an exception.

4. Be the enabler instead of the break

Trying to stop innovation is useless. The Skype’s, Google Voice’s, Twilio´s, Tropo´s, Ribbit’s, etc. are unstoppable. Join the enemy and enable people to use your assets. Otherwise they will find ways around your assets, sooner than later. Think about what happened to location-based services…

5. Think Global and Volume

Local solutions are likely to be copied by others. This is a winner takes it all market. Think global. If you are not global, find a global partner and non-competing other operators and join hands. The money is in the volume. With 1M VAS people are likely to communicate more than before.

6. Analog dollars for digital pennies

The “Free economy” is changing more than one existing business model. Don’t think that because in the circuit world you can charge 15 cents/message that in the IP world you can charge the same. The music labels have found out that if you keep on charging a high price, piracy will rule. Does it mean that everything has to be free or losses are guaranteed? No, also not. However history has shown that technology (r)evolutions can destruct a business model without replacing it with an equal lucrative one:  think stamps and emails. The new economic rules dictate that scale and long tail attrack money. Google changed the ad industry from high priced TV ads to low priced adwords. However since they fully automated the process, the scale is enormous and so are the gains. So to be successful in the new telco 2.0 world, you need to offer thousands of services and make money with volume not with individual services. Who better can dominate a world for nano payment then the world leader of micro payments a.k.a. billing and charging.

The new role of marketing

Marketing will no longer be about evaluating which services customers might like and at what price.

Instead the focus will be on finding the right enablers for customers to build and configure the services they want. Afterwards these services can be offered on an open marketplace for others to buy and sell them.

Listen to what customers say on social networks.

Use number crunching on large volumes of data to understand hidden trends.

The new role of IT and operations

A telecom architecture is one of the most complex architectures to explain to non-telecom experts. A new generation of dotcoms are coming up with alternative architectures that separate execution from data and application logic. If you don´t know Google App Engine, take a look how applications are deployed onto a “virtual” application server and data is stored in a “virtual” database. Exactly this concept is what is needed for the next generation of telco services. You deploy telco apps on to a “virtual” service delivery framework, with access to telco assets via APIs and to unified subscriber data in a “virtual” datastore. IT should be the enabler of launching services and not the one that focus on building the services.

Try often, kill quickly

September 8, 2010 1 comment

When the words “technology and innovation” come to mind, most people think about Google, Apple, Amazon, Facebook, Salesforce, etc.  Just a few think about telecom operators. The biggest telecom innovation has been mobile voice. SMS was never a technological innovation but an unplanned surprise success. MMS never got close to SMS. The iPhone and Android did not come from any telecom operator or provider.

Why is it that five people with a limited budget in months are able to stun the world whereas massive multinationals with deep pockets are not?

The reason is simple: “To innovate you have to try often and kill quickly”.

Google launched Wave in the beginning of this year. Google “killed” Wave about 6 months later. Every day Google makes a change to their search algorithm.

The current process

The cost for a telecom operator to innovate is massive. A simplified process would be the following:

  1. The marketing department receives calls and visits from every possible telecom provider on a daily basis.  New ideas are thrown on the table to see if they stick.
  2. The marketing department selects the best ideas.
  3. These ideas are scanned by the different other departments, e.g. operations, finance, legal, IT, etc.
  4. A multi-disciplinary team is assembled to write the requirements for the new service, a.k.a. RFI.
  5. Several possible telecom providers receive the RFI and provide a response.
  6. A budget is allocated based on the responses and an RFQ, request for quotation, is organized.
  7. Several telecom providers respond to the RFQ.
  8. A bidding war is started and one or two winners are selected. If there are no clear winners then a proof of concept is requested.
  9. The winner develops the solution. Operations, IT, marketing, legal, accounting, etc. all work together to launch the new service.
  10. The service is launched.

The whole process easily can take a year or more and costs multiple millions. If this would be your money, you would be very careful how you would spend it as well. The end result is that only a handful of new services are launched. Only those that are expected to be immediate successes.

This process is a very “useful” process for driving down large integration and network equipment costs. However it is not an innovation stimulating process.

How can you bring innovation back to telecom?

The first step is to avoid a small set of marketing people to take decisions on what is a good service or not. The only person that can legitimately decide if a service is good is the end-user.

The dotcoms therefore launch very often incremental and new services. They monitor in detail which ones, users like. It is even possible that different alternatives are launched in parallel to see which of them the users prefer. Direct feedback is critical. If a service is not picking up or users complain about it, it gets killed quickly. Services that get good feedback are continuously improved, based on user´s feedback.

How to apply “try often, kill quickly” to the telecom world?

The major show-stopper is the telecom architectural complexity. Although a marketing person has a good idea, it often takes months to update all the systems. The reason is that network operations, business logic and user data are scattered over multiple systems and departments.

To solve this problem, services and data should be separated from the network. Google´s technological differentiator is their generic data store a.k.a. Bigtable. Bigtable is an in-house developed generic high-volume, always-available data store. More than 60 services are reported to be using this common data store. Services as different as docs, maps, app engine, etc.

Google has over a million servers. Maintenance and operations are fully automated. Software is written in such a way that failure of hardware is assumed. Hardware are not top-end but instead commodity  rather low-end servers. Software can easily extend over hundreds of servers.

Applications are isolated and use the servers and data through standard interfaces.

I can´t throw away my legacy

Of course an established operator can not throw away their legacy systems. So until we have a common data store and isolation between software and hardware what can we do?

The trick is to start small, move quickly and use asset exposure. Isolate the legacy systems and expose simple APIs to the telecom assets. Via asset exposure a lot of the “hard-coded” SS7 services can be substituted with network intelligence in the cloud. Mini applications can be written by anybody from a large multinational to an individual developer. As long as users can pick their preferred services and applications from the “net app store”.

Data should also be transitioned to a common data store. In the beginning this might mean nightly synchronization of different silos. However little by little the common data store should become the master of the data. Dotcoms are no longer using sql database as a one-size fits all solution. Google, Yahoo, Facebook, Twitter, etc. all developed their in-house solutions and some even open sourced them.

Applications should be running on public or private clouds hence scaling up demand for the top applications during the day and well as scaling down during the night. This should control CAPEX of the hardware. Too much logic is packed into proprietary hardware. Software should be separated from hardware and written in such a way that it can scale to hundreds of servers.

Development teams should not have a contract of 12 months with a waterfall of requirements. Teams should be small (5-6) and have short iterations to deliver small incremental innovations. The dotcoms have a tendency to release new features multiple times a week. Even some multiple times a day. Get immediate feedback and kill if not successful. For telecom innovation teams to do the same, they should be multi-disciplinary. Ideally a mix of people from the operator and strategic partners. It pays off to have a common architecture to deploy the individual services quickly. It pays off even better to have an open API so the innovation team works on the infrastructure for others to innovate.

The small teams should have at least one person that is business and marketing focused and that has the commercial responsibility to make the service a success. Different small teams that have high pressure of time, innovate quickly. Pressure of time is also important. If there is no external pressure of time, then it has to be build internal. A simple technique is to allow people from all over the organization to take a break of their day job and to take part in an innovation team. They should have clear milestones. One month to come up with an idea. Two months for a prototype. Three months to launch the first beta. Two months to get user traction. Any milestone missed means the project is stopped or at least potentially stopped. Failure is not a shame. Quite the opposite. People will go back to their day to their day to day job with new ideas and new energy. After a while they might try again and have success. Innovation and failure go hand in hand. If you can not afford failure, you can not get innovation…

The perfect API

September 8, 2010 1 comment

Asset exposure is a hot topic in the telecom industry. Everybody is talking about opening up telecom assets for others to create new services. However I haven´t seen any successful asset exposure by the established operators yet. Why is this? Let´s look at the four major European players.

Vodafone calls network asset APIs,” enablers” and is offering mobile payment and location services. More is announced. Then again there is also betavine, oneapi and vodafone network apis. And we are not talking yet about widgets and mashups.

Telefonica has the movilforum, O2 litmus and the movistar developers platform.  A list of separate APIs is available with exotic names like “Manage Post Pay Bolt On’s API”.

“Orange developer” gets you in Google to all you need to develop. Unlike Vodafone and Telefonica.  A long list of APIs is available, including the personal profile api and the personal richprofile api.

“T-Mobile developer” also worked. Unfortunately there was no information for network assets API only mobile apps development.

There is one red line in this short test: “being a telecom developer is a hard job”.

Finding the sites with development information is hard. You would think that “operatorname +developer” should be enough to Google you there.

Understanding which API to take is even harder.  I don´t want to imagine writing an application with the APIs.

It is clear that European telecom operators would like to have an active developers community but they would need to understand some basic principles:

  • out of sight, out of mind
  • 80-20
  • simplificationality
  • eat your own dog food
  • make one millionaire
  • collective
  • compete against the dots

Out of sight, out of mind

If I can´t find your API in the first 5 Google items when I look for developer and your company name, then I will probably never write an application for you. SEO, search engine optimization, is the first mandatory step when a developer portal is launched. Your portal can be the best in the world but if I can´t find it then I can´t use it.

80-20

80% and even 95% of all applications only need 10% to 20% of the functionality. The telecom industry has made a habit of “over-standardizing” APIs. A simple example: sending an SMS. What does an application developer wants to do in 95% of the cases? Send “text A” to “number B”. Only 5% of the applications need a receipt that you actually read the SMS. Even below 0,01% would like the operator logo, the internal port for message delivery in the device, etc. to be available. So the trick is to have a very basic high-level API and if required a more detailed low-level API.

Simplificationality

Why use “simplificationality” if you can use “simple”? Developers want to keep things simple. Programming is already hard enough. Standards bodies in the IT industry have designed the XML and SOAP standard to share unstructured data between as many systems as possible. Developers are neglecting both and are migrating to JSON and REST. A JSON document is a lot shorter and holds the same info. A REST API you can call from the command line. There is an interesting startup that has taken this simple principal and applied it correctly:

Eat your own dog food

A lot of startups are using the slogan: “eat your own dog food”. If you create something for others to use, then the first user should be you. Amazon created their web services stack for internal use and afterwards opened it up to the world. Until your services are not written with your API, then you should not open it up for others. After writing some services with your own API, you can be sure that it is fully functional, well documented and no longer has awkward glitches.

Make one millionaire

The economy is moved by the invisible hand which in human language means: “people are selfish”. I am prepared to suffer and write an application with your API as long as I have a change to become an overnight millionaire. Apple´s App Store has made for sure somebody a millionaire. As soon as there is one, there will be a million others trying. Make sure you share your revenue is based on the value contribution (Apple sells => 30%, developers invents and writes => 70%). If people feel they have an honest chance of becoming rich, then they will go the extra mile.

Collective

99.99% of all the apps that developers will write with your APIs will be rubbish.  However as long as users are able to easily find the other 0.01%, the operator will make money will all 100%. For users to be able to find a needle in a haystack, you need collective intelligence. People need to be able to benefit from viral marketing, recommendation engines, top 25, etc. in order for them not to have to waste their time. Early adopters will try out the bulk of the apps but they are only a minority. The rest of the mortals need to be helped. If I am looking for the coolest game, then it should be first in the list of games.  Apps needs to be automatically clustered, categorized, recommended, etc.

Compete against the dots

An operator´s competition for asset exposure is not your-next-door-operator but a dotcom that offers a way around your assets. For years operators sat on their location assets without exploiting them. Google came and wiped most of the value out with its Latitude, Maps and Goggles. Copy the dotcom technology and ways of doing things.

%d bloggers like this: