Oracle, after its purchase of Sun Microsystems, has found that it owns a number of things including MySQL and Java. MySQL presents obvious problems, as it competes with Oracle's big, expensive database. But Java also presents problems.
Oracle has two challenges with Java. The first (and obvious) challenge is money. Specifically, how does Oracle "monetize" Java? Extracting money from programming languages is possible; Microsoft succeeded with BASIC, Visual Basic, and C#. (Although the last was really profitable through Visual Studio, not the language itself.)
Extracting money from Java remains elusive. Oracle's latest attempt to sue Google has failed. It was a "whale" strategy, designed to obtain a large amount from a single entity. With the loss in court, will Oracle look for a different strategy, perhaps one that looks for fees from more (and smaller) entities?
Revenue is one headache for Oracle. A second headache exists, one that is less obvious, and may show up in the expense, not revenue column.
Oracle's history has been with SQL, a language designed in the 1970s for accessing data. As a programming language, it has been remarkably stable, with only a few changes since its inception. In contrast, programming languages like Visual Basic, C, C++, and C# have seen frequent and sometimes significant changes. Java, too, has seen changes, and it has the "JCP", the Java Community Process, which allows just about anyone to recommend changes to the Java language.
This second challenge is more subtle, and possibly larger, for Oracle. After decades of a stable, unchanging language, is it capable of managing a fast-moving programming language? After decades of maintaining the Oracle database (which I'm sure had lots of internal changes and lots of changes requested by Oracle's relatively few high-paying customers) is Oracle ready to maintain a product used by "the rest of us"?
This is the bigger issue for Oracle. Maintaining the Java code base, adapting it to new platforms, adding features to the language, and putting up with all of the pesky requests from pipsqueaks (highly opinionated pipsqueaks, some of us are) is going to be expensive.
So Oracle is in a squeeze. On one side, Java has no significant revenue. On the other, it has expenses (possibly higher than the expenses for the Oracle database). How will Oracle navigate these straights?
I see a few possible ways forward:
Find a funding mechanism Perhaps licenses, perhaps advertising. Perhaps a version of Java for the Internet of Things.
Tie Java to the Oracle database Make Oracle the easiest database to use in Java.
Keep Java but stop development A fast was to reduce costs, but also a fast way to anger users. (On the other hand, Oracle seems to care little about user opinion.)
Spin off Java If Java doesn't fit into Oracle's strategy, why bother to keep it?
The last is an interesting idea. IBM might be interested in Java. Google almost certainly would. Microsoft probably not so much -- except perhaps to prevent Google from acquiring it.
Showing posts with label strategy. Show all posts
Showing posts with label strategy. Show all posts
Sunday, July 10, 2016
Sunday, December 21, 2014
Technology fragmentation means smaller, simpler systems
In the past, IT shops standardized their technologies, often around the vendor deemed the industry leader. In the 1960s and 1970s, that leader was IBM. They offered products for all of your computing needs, from computers to terminals to printers and even punch cards.
In the 1980s and 1990s, it was Microsoft. They offered products for all of your computing needs, from operating systems to compilers to office suites to user management. (Microsoft offered little in hardware, but then hardware was considered a commodity and available from multiple sources.)
Today, things are not so simple. No one vendor that provides products and services for "all of your computing needs". The major vendors are Microsoft, Apple, Amazon.com, Google, and a few others.
Microsoft has a line of offerings, but it is weak in the mobile area. Sales of Microsoft tablets, Microsoft phones, and Windows Mobile are anemic. Anyone who wants to offer services in the mobile market must deal with either Apple or Google (and preferably both, as neither has a clear lead).
Apple has a line of offerings, but is weak in the enterprise area. They offer tools for development of apps to run on their devices but little support for server-side development. Anyone who wants to offer services that use server-side applications must look to Microsoft or Google.
Amazon.com offers cloud services and consumer devices (the Kindle) but is weak on development tools and transaction databases. Google offers cloud services and consumer devices as well, but lacks the enterprise-level administration tools.
Complicating matters is the plethora of open-source tools, many of which are not tied to a specific vendor. The Apache web server, the Perl and Python languages, several NoSQL databases, and development tools are available but not with the blessings (and support) from vendors.
Development teams must now cope with the following:
Browsers: Internet Explorer, Chrome, Firefox, Safari, and possibly Opera
Desktop operating systems: Windows (versions 7, 8, and 10), MacOS X, Linux (Ubuntu, SuSE, and Red Hat)
Platforms: desktop, tablet, phone
Mobile operating systems: iOS, Android, and possibly Blackberry and Windows
Database technologies: SQL and NoSQL
HTTP servers: Apache, NGINX, and IIS
Programming languages: C#, Java, Swift, Python, Ruby, and maybe C++ or C
Cloud platforms: Amazon.com AWS, Microsoft Azure, Google cloud
Cloud paradigms: public cloud, private cloud, or hybrid
I find this an impressive list. You may have some factors of your own to add. (Then the list is even more impressive.)
This fragmentation of technology affects your business. I can think of several areas of concern.
The technology for your systems You have to decide which technologies to use. I suppose you could pick all of them, using one set of technology for one project and another set of technology for another project. That may be useful in the very short term, but may lead to an inconsistent product line. For example, one product may run on Android phones and tablets (only), and another may run on Apple phones and tablets (only).
Talent for that technology Staffing teams is an on-going effort. If your project uses HTML 5, CSS, JavaScript, and Python with a NoSQL database, you will need developers with that set of skills. But developers don't know everything (even though some may claim that they do) and you may find few with that exact set of technology. Are you willing to hire someone without on of your desired skills and let that person learn them?
Mergers and acquisitions Combining systems may be tricky. If you acquire a small firm that uses native Android apps and a C#/.NET server-side system, how do you consolidate that system into your HTML, CSS, JavaScript, Python shop? Or do you maintain two systems with distinct technologies? (Refer to "inconsistent offerings", above.)
There are no simple answers to these questions. Some shops will standardize on a set of technologies, combining offerings from multiple vendors. Some will standardize on a vendor, with the hope of a future industry leader that sets the standard for the market. Many will probably have heated arguments about their selections, and some individuals may leave, staying more loyal to the technology than the employer.
My advice is to keep informed, set standards when necessary, and keep systems small and simple. Position your technology to shift with changes in the industry. (For example, native apps on Apple devices will shift from Objective-C to Swift.) If your systems are large and complicated, redesign them to be smaller and simpler.
Build and maintain systems with the idea that they will change.
They probably will. Sooner than you think.
In the 1980s and 1990s, it was Microsoft. They offered products for all of your computing needs, from operating systems to compilers to office suites to user management. (Microsoft offered little in hardware, but then hardware was considered a commodity and available from multiple sources.)
Today, things are not so simple. No one vendor that provides products and services for "all of your computing needs". The major vendors are Microsoft, Apple, Amazon.com, Google, and a few others.
Microsoft has a line of offerings, but it is weak in the mobile area. Sales of Microsoft tablets, Microsoft phones, and Windows Mobile are anemic. Anyone who wants to offer services in the mobile market must deal with either Apple or Google (and preferably both, as neither has a clear lead).
Apple has a line of offerings, but is weak in the enterprise area. They offer tools for development of apps to run on their devices but little support for server-side development. Anyone who wants to offer services that use server-side applications must look to Microsoft or Google.
Amazon.com offers cloud services and consumer devices (the Kindle) but is weak on development tools and transaction databases. Google offers cloud services and consumer devices as well, but lacks the enterprise-level administration tools.
Complicating matters is the plethora of open-source tools, many of which are not tied to a specific vendor. The Apache web server, the Perl and Python languages, several NoSQL databases, and development tools are available but not with the blessings (and support) from vendors.
Development teams must now cope with the following:
Browsers: Internet Explorer, Chrome, Firefox, Safari, and possibly Opera
Desktop operating systems: Windows (versions 7, 8, and 10), MacOS X, Linux (Ubuntu, SuSE, and Red Hat)
Platforms: desktop, tablet, phone
Mobile operating systems: iOS, Android, and possibly Blackberry and Windows
Database technologies: SQL and NoSQL
HTTP servers: Apache, NGINX, and IIS
Programming languages: C#, Java, Swift, Python, Ruby, and maybe C++ or C
Cloud platforms: Amazon.com AWS, Microsoft Azure, Google cloud
Cloud paradigms: public cloud, private cloud, or hybrid
I find this an impressive list. You may have some factors of your own to add. (Then the list is even more impressive.)
This fragmentation of technology affects your business. I can think of several areas of concern.
The technology for your systems You have to decide which technologies to use. I suppose you could pick all of them, using one set of technology for one project and another set of technology for another project. That may be useful in the very short term, but may lead to an inconsistent product line. For example, one product may run on Android phones and tablets (only), and another may run on Apple phones and tablets (only).
Talent for that technology Staffing teams is an on-going effort. If your project uses HTML 5, CSS, JavaScript, and Python with a NoSQL database, you will need developers with that set of skills. But developers don't know everything (even though some may claim that they do) and you may find few with that exact set of technology. Are you willing to hire someone without on of your desired skills and let that person learn them?
Mergers and acquisitions Combining systems may be tricky. If you acquire a small firm that uses native Android apps and a C#/.NET server-side system, how do you consolidate that system into your HTML, CSS, JavaScript, Python shop? Or do you maintain two systems with distinct technologies? (Refer to "inconsistent offerings", above.)
There are no simple answers to these questions. Some shops will standardize on a set of technologies, combining offerings from multiple vendors. Some will standardize on a vendor, with the hope of a future industry leader that sets the standard for the market. Many will probably have heated arguments about their selections, and some individuals may leave, staying more loyal to the technology than the employer.
My advice is to keep informed, set standards when necessary, and keep systems small and simple. Position your technology to shift with changes in the industry. (For example, native apps on Apple devices will shift from Objective-C to Swift.) If your systems are large and complicated, redesign them to be smaller and simpler.
Build and maintain systems with the idea that they will change.
They probably will. Sooner than you think.
Tuesday, May 14, 2013
IT must be strategic as well as tactical
Anyone running an IT shop (or running a company) must divide their efforts for IT into two categories: strategic and tactical.
Strategic efforts help the company in, well, strategic ways. They introduce new products to counter (or surpass) the competition. They create new markets. They do big, bold things -- sometimes risky -- for big returns.
Tactical efforts also help the company, but it smaller and less flashier ways. They improve internal processes. They reduce waste. They increase operating efficiencies. They do not do big, bold things, but instead do small, meek things for small returns.
But to do big, bold things you need a team that has got it's act together. You need the infrastructure in place, and you need a team that can build, operate, and maintain that infrastructure -- while implementing the big strategic stuff.
If your networks are reliable, if your storage is planned, allocated, monitored, and available, if your people have access to the information they need (and only that information), if your systems are updated on time, if your sysadmins have the right tools and your developers have the right tools and your analysts have the right tools and your sales people have the right tools (and they all know how to use them), then you probably have the tactical side working. (I say 'probably' because there are other things that can cause problems. A complete list would be larger than you would want to read in a blog post.)
If you're having problems with the strategic items, look to see how well the tacticals are doing. If *they* are having problems, start fixing those. And by fixing, I mean get the right people on the team, give them the authority to do their jobs, and fund them to get tools and technologies in place. Make sure that your people can get their "real work" done before you start doing grand things.
If the tacticals are working and the strategic items are not, then you don't have a technology problem. (Well, you might, if your strategy is to build something that is not feasible. But even then you would know. When your tacticals are working you have competent people who will tell you your strategy is not possible.)
Bottom line: get the little things working and you will have a reliable platform for larger efforts.
Strategic efforts help the company in, well, strategic ways. They introduce new products to counter (or surpass) the competition. They create new markets. They do big, bold things -- sometimes risky -- for big returns.
Tactical efforts also help the company, but it smaller and less flashier ways. They improve internal processes. They reduce waste. They increase operating efficiencies. They do not do big, bold things, but instead do small, meek things for small returns.
But to do big, bold things you need a team that has got it's act together. You need the infrastructure in place, and you need a team that can build, operate, and maintain that infrastructure -- while implementing the big strategic stuff.
If your networks are reliable, if your storage is planned, allocated, monitored, and available, if your people have access to the information they need (and only that information), if your systems are updated on time, if your sysadmins have the right tools and your developers have the right tools and your analysts have the right tools and your sales people have the right tools (and they all know how to use them), then you probably have the tactical side working. (I say 'probably' because there are other things that can cause problems. A complete list would be larger than you would want to read in a blog post.)
If you're having problems with the strategic items, look to see how well the tacticals are doing. If *they* are having problems, start fixing those. And by fixing, I mean get the right people on the team, give them the authority to do their jobs, and fund them to get tools and technologies in place. Make sure that your people can get their "real work" done before you start doing grand things.
If the tacticals are working and the strategic items are not, then you don't have a technology problem. (Well, you might, if your strategy is to build something that is not feasible. But even then you would know. When your tacticals are working you have competent people who will tell you your strategy is not possible.)
Bottom line: get the little things working and you will have a reliable platform for larger efforts.
Wednesday, August 22, 2012
Microsoft changes its direction
Microsoft recently announced a new version of its Office suite (version 13), and included support for the ODF format. This is big news.
The decision to support ODF does not mean that the open source fanboys have "won".
As I see it, the decision to support ODF means that Microsoft has changed its strategy.
Microsoft became dominant in Windows applications, in part due to the proprietary formats of Microsoft Office and the network effect: everyone wanted Microsoft Office (and nothing else) because everyone that they knew (and with whom they exchanged documents) used Microsoft Office. The proprietary format ensured that one used the true Microsoft Office and not a clone or compatible suite.
Microsoft used that network effect to drive people to Windows (providing a Mac version of Office that was close but not quite the same as the Windows version). Their strategy was to sell licenses for Microsoft Windows, Microsoft Office, Microsoft Active Directory, Microsoft Exchange, Microsoft SQL Server, and other Microsoft products, all interlocking and using proprietary formats for storage.
And that strategy worked for two decades, from 1990 to 2010.
Several lawsuits and injunctions forced Microsoft to open their formats to external players. Once they did, other office suites gained the ability to read and write files for Office.
With Microsoft including the ODF formats in Office, they are no longer relying on proprietary file formats. Which means that they have some other strategy in mind.
That new strategy remains to be seen. I suspect that it will include their Surface tablets and Windows smartphones. I also expect cloud computing (in the form of Windows Azure) to be part of the strategy too.
The model of selling software on shiny plastic discs has come to an end. With that change comes the end of the desktop model of computing, and the dawn of the tablet model of computing.
The decision to support ODF does not mean that the open source fanboys have "won".
As I see it, the decision to support ODF means that Microsoft has changed its strategy.
Microsoft became dominant in Windows applications, in part due to the proprietary formats of Microsoft Office and the network effect: everyone wanted Microsoft Office (and nothing else) because everyone that they knew (and with whom they exchanged documents) used Microsoft Office. The proprietary format ensured that one used the true Microsoft Office and not a clone or compatible suite.
Microsoft used that network effect to drive people to Windows (providing a Mac version of Office that was close but not quite the same as the Windows version). Their strategy was to sell licenses for Microsoft Windows, Microsoft Office, Microsoft Active Directory, Microsoft Exchange, Microsoft SQL Server, and other Microsoft products, all interlocking and using proprietary formats for storage.
And that strategy worked for two decades, from 1990 to 2010.
Several lawsuits and injunctions forced Microsoft to open their formats to external players. Once they did, other office suites gained the ability to read and write files for Office.
With Microsoft including the ODF formats in Office, they are no longer relying on proprietary file formats. Which means that they have some other strategy in mind.
That new strategy remains to be seen. I suspect that it will include their Surface tablets and Windows smartphones. I also expect cloud computing (in the form of Windows Azure) to be part of the strategy too.
The model of selling software on shiny plastic discs has come to an end. With that change comes the end of the desktop model of computing, and the dawn of the tablet model of computing.
Subscribe to:
Posts (Atom)