Views on the Industry
Friday, July 20, 2012
Corporate Information Technology (IT) represents an approximately $100 Billion annual spend on hardware, software and services across the vast array of offerings. Beyond Apple, Microsoft, IBM, SAP & Oracle, there are a wide variety of solutions. But one technology has been a mainstay across the Global 2000 corporations since its inception in the 1990’s, and that is Java. Enterprise Java, in particular, has achieved deep penetration in the normally mundane IT environments of the Global 2000, mainly through said companies investment in Java Application Servers which often-times run web properties, is utilized as the platform for all types of on-line transactions, and integrates legacy applications. The Enterprise Java specification has been and continues to be a deep and broad offering for most kinds of IT development standards. At the heart of the continued success of Enterprise Java platform lies the Enterprise JavaBeans (EJB) development paradigm. EJBs are components or discreet amounts of code to achieve a certain inter-action among software running with an application server.
This plan will detail the market opportunity for creating pre-built EJB components in order to sell web functionality in to the Global 2000 who have invested in application servers. This is not a new concept as several small vendors sold EJB applications in the late 1990’s and early 2000’s that provided functionality for on-line business. Some of these vendors were acquired by application server vendors, others died out in the wake of the IT recession following 9/11/01. But the concept has never been abandoned, as application server customers continue to utilize the EJB standard as a way to re-use code to achieve functionality around a wide-variety of projects. If one IT development project can be shared without re-writing everything for new projects, efficiencies are created as a write-once-run-anywhere concept for the reason that Java is utilized, allows the code re-use.
The best way to think of this is an on-line trading experience that requires a shopping cart. If the shopping cart is either written or acquired by an application server customer, it can be used across multiple trading environments by writing to the EJB specification. A customer such as P&G might have thousands of trading relationships across its enormous IT environment, and with the right attention and maintenance of the EJB standard, one shopping cart piece of code could be used for all of the trading relationships. What Astro Software is proposing is that pre-built EJB components would be sold in to application server customer environments to offer a large head-start on a development project. Components could be created for nearly any type of functionality, offering an enormous opportunity to create EJBs for nearly any type of discreet on-line inter-action, from B2B, to CRM, to supply chain management, to on-line transactions of any sort. This document will lay out the market opportunity, the proposed component model and what it would look like, and the reason why this is a great opportunity for investors to tap-in to the Global IT spend.
a. The application server market represents the base of customers who utilize Java to develop software programs and conduct data integration that will be deployed on the app server platform. In 2000, this market consisted of a majority of the Global 2000 businesses, as Enterprise Java was viewed by the customers to have less likelihood of being locked-in to a specific vendor’s offerings, as the vendors adhered to the Java specification for cross-platform functionality. Today, it is difficult to estimate how many of those same app server customers continue to rely on Java as the basis of their enterprise development, but judging from the vendors’ continued investment in upgrading their app server offerings, there is a sizeable base remaining. This is not to say it is a legacy market, as continued enhancements in the Java platform have resulted in ease of development and a straight-forward architecture for maintaining the environment.
The main app server vendors are Oracle, IBM, JBoss and VMWare, all offering a complete suite of tools to make running Java better than ever. The app server suite market represents a multi-billion dollar opportunity for the vendors which is a major reason why continued innovation surrounds the market. When used appropriately, app servers provide a common-runtime for Java applications to be deployed and integrated across a customer’s IT environment. This allows developers to learn the Java specification rather than the vendor’s specific proprietary technology architecture. As stated this allows far less vendor lock-in, through the write-once-run-anywhere promise of Enterprise Java. With the plan to write EJB components that strictly adhere to the specification, Astro looks to take the value proposition of Java one-step further than previously sold in the marketplace by developing components that can be used regardless of the vendor offering, as long as it continues to adhere to the Enterprise Java specification.
The value of this model is self-evident in that it provides pre-built functionality for the app server customer to utilize without having to start from scratch every time a new development project is under-taken. Componentized software also allows a more comprehensible maintenance strategy, as pieces of software code can be swapped in-and-out as long as it can run on the application server, which allows developers to focus on their key competency and in-a-way mash together code that previously would have to be built from the ground up. Enterprise Java components gives customers flexibility that is simply not available through other models, as it provides the flexibility to integrate development projects according to need rather than what can be accomplished under other coding models. EJBs are the so-called “Holy Grail” of software architectures as it allows developers to bring-in pre-built components to get the project up-and-running more quickly and in an understandable way of maintaining the architecture.
b. The three models available to Independent Software Vendors (ISVs) are basically found in three distinct strategies:
1) Open Source (OSS) - - this model allows the free transfer and privileges of the under-lying source code to be viewed by anyone within the open source community for the software application. OSS has been very popular for fledgling ideas to get up-and-running with little resources, as developers from across the world are invited to share the responsibilities of writing the software architecture. Red Hat is the most successful OSS company, and has achieved a viable revenue stream from its support and maintenance business, as its software is free to acquire. Services are typically where OSS revenue streams, where the OSS ISV will provide bug fixes and other support services that allow a customer to have a contact point when things go off-plan, that is so important in the software industry. A weakness of the OSS model is not having intellectual property concentrated within the OSS company, but instead is shared by the developers on the project, regardless of their affiliation with the OSS company. A strength is the large-base of expertise that can be drawn upon for improvements and ideas for future iterations of the software application. This could be a route taken by Astro Software if a base of developers can be identified who would help write the EJB components proposed in this document, and would be a key determination of how far and how fast the development of components could be reached.
2) Licenses - - this is by far the most common way that ISVs release their product, by selling licenses, the company keeps intellectual property and sells the functionality as well as services, potentially creating an additional revenue stream than what can be achieved through the OSS model. Software is traditionally not cheap to acquire so the market penetration is often lower for a license model than an OSS model where the software is freely distributed. In addition to the supplemental revenue stream, license model ISVs have greater control of the distribution of the software and for this reason there is a larger revenue opportunity than OSS, but it comes with risks, as well. The main risk is the degree to which a license model can get up-and-running, for development staffs cost money and without a customer base identified, many license model ISVs can go bust before they even regain their initial investment, but the pay-off can concomitantly be much more lucrative. Due to the degree of complexity of the EJB model, some manner of in-house development staff is required, if for nothing else to have expertise within the company to do support and gather requirements for next generation products. This is not to pre-clude the possible advantages of the OSS model, but it is a general assumption that more revenue is possible with the license model.
3) Hosted - - it is a relatively new option, as ISVs instead of delivering software applications to its customers instead make their functionality available via a browser, so that all of the processing is handled by the hosted ISV company. Salesforce.com has made a nice business out of this model by marketing itself as a hassle-free solution for those customers that wish to get up-and-running more quickly and achieve business results in a more direct way thatn what it typically takes to acquire or download software and work on integration and deployment that is required when the customer hosts its own copy of the software. The Hosted model doesn’t have as much IT-ness to it, as a casual user of the web can readily learn how to use the hosted software and make changes that are processed by the Hosted ISV. Changes can be more quickly rolled-out to customers as its just the front-end that are typically the concerns of a user of hosted software. The downside is the lack of a license revenue model, so Hosted can be less lucrative, like OSS. Hosted also does not have the same capability for deep integration in to a customer’s IT environment, as Hosted is often used for “clean-room” deployments with minimal data integration. Even this is changing, but the most demanding of organizations need to access legacy applications and data to achieve business metrics for successful implementation of a project. Hosted is easier and more cost conscious, but has a less lucrative up-side that the traditional license model.
c. EJB components are slices of pre-built software code that provides a certain, discreet amount of functionality to accomplish a certain set of requirements. EJBs can be written for such tasks as accessing a database or running an entire on-line shopping experience. They can be as small and short-lived or large-scale and lengthy in duration of usefulness as needed. EJBs can be written to satisfy a credit check, a shipping transaction, a supply chain inter-action, a customer-facing service application or any of countless on-line experiences. There is literally no limit to the amount of components that could be part of the Astro sales strategy, for any type of market requirement. What you get from an EJB is reliability and stability to match the standardized code so there is little vendor lock-in. In time, it is easily conceivable to think of hundreds of components being accessed by any type of customer at one-time, meaning that a sales strategy for EJBs could become quite lucrative with some execution toward delivering solutions out of component software.
With so much common sense logic that many components would offer a real market opportunity to an ISV selling them, it begs the question of why are there not already pre-built EJB components in the marketplace? The EJB standard has gained a reputation for reliability but in its earliest inception it was difficult to do, as the Enterprise Java standard was only formally released in 1999, a short-time ago in software architecture parlance. Over time improvements have been made with each passing iteration of the specification and the corresponding solutions that came out of the standard set. There have been companies that have re-used components across projects, for this is a common software practice, but very little has been done to make them as re-sold components. This is what we intend to do with this company, make pre-built components that can be sold in to the application server customer base, as the app server vendors have made no move toward creating their own component-based applications for sale to their customers. It is an un-tapped market, and considering the enormous changes that the “cloud” architecture holds for IT, EJBs have a real chance at becoming the standard for deployment in conducting mini-transactions on-line.
The coming wave of cloud solutions are essentially componentized software concepts as it is discreet and limited in scope the transactions that are conducted on-line, even so EJBs can scale to accomplish the most important business tasks. The cloud economy will value speed and reliability, as well as time-to-market considerations, and this is custom made for component software, as EJBs have a foot-hold in corporate IT today, and could extend its reach in to the cloud environments that so many of the Global 2000 are investing in today. There is no clear picture for what might emerge from the cloud architectures being built today, but adhering to a standard is certainly one of the key requirements, so that a customer does not get locked-in to a specific vendor’s solutions. EJBs are built for these requirements, and it is not difficult to imagine that it could have a real, viable market opportunity with cloud customers looking to get up-and-running more quickly than building in-house. With the right execution, an EJB component vendor, such as the one proposed in this plan, could become a leader in cloud solutions, a multi-billion dollar opportunity already. Growth of the cloud architectures is expected to explode this decade, it would be a real opportunity to have a set of components available for when the Global 2000 begin to think of their architectures for the coming twenty years of IT environments.
Thursday, June 07, 2012
proposal for EJB component start-upEnterprise JavaBeans (EJB) components are discreet units of functionality in enterprise software terms, so that you can think of it as encapsulating a certain amount of lines of code to achieve a specific outcome. Components have long been something of a 'holy grail' in software coding, as it could be re-usable as well as sold as stand-alone function. EJBs came out in the late 1990s with that same promise and were mildly successful in its first generation. A few small companies even attempted to do business models off of component functionality, often-times aligning with Java application server vendors, such as BEA, Sun, ATG, and Bluestone, which all offered their own forms of EJB applications along with their app server platforms. BEA went so far as to acquire one of the component vendors, called Theory Center, and re-sold Theory Center's EJB components as the BEA WebLogic Commerce Server, which was a very popular way for BEA to demonstrate the application server's core capabilities.
The EJB specification remains the primary standard for Java application server vendors to follow in maintaining the promise of Enterprise Java for portability of applications written to the platforms that support the standard. EJB components also remain a common development paradigm for enterprise development, in terms of how to achieve application and integration development outcomes that can be re-used across a number of projects. The easiest way to think of this is the shopping cart functionality found on e-commerce web-sites. Think if a company has a goal of setting up a B2B commerce site to conduct trading with its many partners. Rather than writing a new shopping cart experience for each trading relationship, the core functionality is written once and re-used across a number of use case scenarios. This is a re-usable component example, as the shopping cart components or set of EJBs would be used for many trading relationships without the need to continuously re-write the same core functionality.
What I propose is a new set of components that could be sold to these enterprise customers that have invested in the EJB standard via their acquisition of application server platforms to serve as e-commerce conduits within IT environments. It is a tested model while also including the promise of continued support by Oracle and its many Java partners. The components would be discreet in terms of functionality, but could be sold as solutions for anything from B2B to B2C to CRM to Supply Chain Management. The target customer is your typical application server acquirer, when they are looking to see what the cloud offers their existing infrastructure, the components would serve as helping hands to get up-and-running more quickly. Components flying around, all centrally managed, but business use cases could also dictate how the components inter-act. A marketing manager could ask the supply chain team to do a query on which components are used most prominently in transactions, and the developer team could build new components or acquire new components to satisfy requirements.
It would take an enormous under-taking to compete with a company that had a head-start on delivering EJBs to the application server customer-base. With some agility, clouds could be the domain of components, and the Java standard would have a foot-hold in to the build-out of this next evolution of information technology strategies. Components, by their very nature, offer a relief from the management complexity of current solutions, while also complimenting installed base platforms, such as ERP. The market is set, the opportunity is there, developers working with focus is what is needed. I can only offer support, it is up to you to seize the chance to put a mark on enterprise software, an established and lucrative market. It may not be your calling at-the-moment, but I would like to put the thought in your brain of remembering back to the very inception of Enterprise Java. Now is the time to fulfill that early promise, EJBs are not dead they have just become boring. With some skill and execution, we could make them cool and useful again. Get a foot-hold on the cloud environments via application servers and components, and there is no telling what other opportunities will come around.
Monday, January 30, 2012
pre-built EJB componentsThe case is simple, and it has a history: build functional applications that are cross-platform, and revive the model of Java to be write-once-run across multiple platforms. This was done, in some form, by Theory Center before they were acquired by BEA in 1999, and it allowed WebLogic to take the early lead, that ultimately led to their sizable cash-out, in the form of the Oracle acquisition. Nothing made IT managers happier than to see something actually working on top of these Internet operating systems, that were to be known as application servers. They could see what they were investing in, if Theory Center worked, then their own development efforts could also work. I was working on iPlanet's competitor to WL, and never once did I see a deployment of Theory Center, yet many of the largest financial services firms and teleco's, deployed WebLogic in their environments. Some will say that application servers never lived up to their promise of integrating all of Java, in to one common platform, that could rival Microsoft's datacenter offerings. But that is what is available today: a belief that cloud computing will re-orient the data-center like no other offering brought forth by enterprise vendors in the last twenty years. It is the Internet taken to its natural destination, and it is custom-made for application server vendors to take their offerings in to the cloud. The vendors, themselves, are coming at from different angles. JBoss is the lead environment for Red Hat Linux, and OS that desires to see the market go cloud, it is Oracle that will lead with applications for intra-environment deployment, and IBM will offer up some customization to argue for their own tools to be deployed as cloud infrastructure. Even Spring Source is in the cloud game with VMWare having invented the enterprise cloud architecture. What do all of these have in common?
They all are lacking the Theory Center moment, when you can walk in to a customer and visibly demonstrate what is being explained in technical terms. The promise of pre-built functionality has always been on the minds of the vendors, and customers have their own in-house set of components that run certain functionality, and that can be re-used across multiple projects. What is needed is a firm, a coalition of firms, or a series of start-up moves to re-kindle the fire originally set by the promise of the EJB component model. Pre-built EJBs are what would give the cloud that discernible advantage over the Azure promise of integration across the platform. Windows Server is acquiring the enterprise, slowly but surely, with 50% of deployments worldwide having gone to WS, and 20% with Linux, and 30% other. In order for the remaining non-Windows 50% to compete, it needs these pre-built components to show the power of Java's development model, and work across the vendors to prove the deployment model. Whether that be IBM Global Services, or Oracle's Support Network, or JBoss consultants, worldwide, the component model needs a new life. This can be done in basic steps toward a full-fledged platform, that would deliver shopping cart, credit card transactions, other shopping features for consumers, B2B transactions like supply chain management, integration with all sorts of data sources are ready for pre-built functionality, and beyond.
The best way to deliver this is on top of Glassfish, as the Reference Implementation for JEE 6 and 7, it can showcase the advanced cloud features of Enterprise Java. Pre-built components would give customers something to work with as they investigate the business model of going with Java over Azure in the cloud build-out. Microsoft will be forced to retaliate, but they do not have an industry that has committed to delivering specification after another, with partners, that compete for the same accounts. The Microsoft components will be more centered at Google, anyway, their Great Plains product-set has been focused on ERP and other large functionality efforts, not micro-enough to be componentized in time for Java components to build a user base that will set them off on the cloud projects, that are certain to spring up, as IT managers look to new models to improve delivery of their respective employers' web offerings. Get EJBs back in the discussion, and integrate with other non-EJB models through JAX, and see the application server vendors regain the argument that has been eroded by years of over-hype, now is the time to deliver on the hype of Java on the server-side. Right now, it is all a process of upgrades and maintenance decisions, make it about the cloud and see new models and new opportunities rise to the surface.
This cause has been called for before, it has been dis-credited, and to be honest, is like kryptonite to IT everywhere. The promise of pre-buuilt components, a long-time Holy Grail in development, is a real possibility in deployment, today, with the clouds becoming the leading selling point of vendors, and the leading interest area of customers. How to make these clouds work? Microsoft has it figured out with their complete package of development and integration among a wide-swath of products. All Java needs is a development environment, pre-built components, and application servers to compliment the data sources and integration efforts already in place across the enterprise. There is no need to sell new platforms, or new models, the app servers are the cloud OS, always have been, they were just disguised as dot-com enablers, in their earlies incarnation, but they power the Internet. Where would IT be without enterprise Java, it would be stuck in non-standard, non-compatible environments, without any hope of achieving acquisition or other-wise integration, it would be much costlier to run an IT environment, without application servers. Re-charge the debate around Java with pre-built EJBs, that work across cloud environments, make it a competitive marketplace for selecting components, that can work together, and turn the power back to developers within enterprises. The cloud will shake out from there. Without it, there is no functionality to sell on, and allows Microsoft and Azure all the advantages of integration without standards. All of the Java vendors would benefit, and Glassfish would have a standing chance of becoming one of those deployment environments ready for the cloud. This is Oracle's best opportunity for the cloud, beyond whatever WebLogic does to become Fusion for the Oracle Cloud, a pre-built set of Java specific functionality would be a major starting point for how Java vendors are to approach the cloud. It would translate to benefits across the Java ecosystem.
Wednesday, January 11, 2012
Sun software spin-offIf its not going to be used to sell hardware, then it should be given its own life, outside of Oracle, its wasted value, just to be specification Reference Implementations, that is comical, its industry-grade, and can stand on its own, it should be set free. MySQL, SSO, ESB, JEE, even NetBeans could sustain a whole new company, and these are redundant assets within the parent company's offering, they are not investment worthy, so why not let someone else do something with it. Cannibalization is possible, but considering the pay-back on green environments it could get to and turn-back in to maintenance revenue with a simple agreement from parent and spin-off, there is very little logic that just letting them wither on the vine in the argument that Sun was bought for hardware alone, and it is in keeping with the long-term principles of holding off Great Plains in medium-sized accounts. I have said this all before with some degree of implementation plan, like my earlier logic on a fork on Google Code, i dont need to see that exactly happen, but it needs room to breathe, and right now the oxygen on Glassfish, in particular, is being cut-off from ExaLogic sales push. This is not the only value of Sun, more can be done, and the only way I can see anything getting near its true value is for a spin-off.
This reminds me a lot of iPlanet. Back then, when the Sun-Netscape Alliance was in its first year, there was a lot of hype for the Sun investment in Netscape products. I was a kid, on my first job out of grad school, and actually advocated for an IPO, i was naive, but eventually fell in to line that it would work better as a vertical solution. And it did, it served Sun well, even though it caused us to work over-time to clean up the iAS 6.0 mess, it served Sun well. That didn't show up in the acquisition price, but Sun would have been virtually a worthless chip designer had it not been for the middleware assets. Oracle is doing its best to revive Sparc, and i applaud them for that, I think they should continue doing it, its great for the Valley, great to overcome Google's black-hole of data center design support, other companies need non-Google cloud data centers, and Oracle with Sun hardware fits the bill. Good job whoever worked on that, even Solaris seems to be safe for existing accounts. But the other side of Sun is breath-takingly innovative. All the middleware assets are better than JBoss and Spring Source, and by not addressing their value, Oracle is giving legit competitors a little more breathing room. Just keep 51%, split up 49% with investors who are savvy on enterprise software, and let some employees have a period of time where they could be employees of Oracle, still, while working on the start-up of acquired Sun software assets. Its really straight-forward, and is custom-made for an aggressive company like Oracle. It would appease the Sun employees who are not fortunate enough to work on Fusion, and give a little energy to the growing international monstrosity that is Oracle. It would simplify things for everyone.
Customers would know that they have the support of Oracle, if they invest in this new iPlanet-like company. Call it the Oracle-Sun Alliance, or whatever, just get some value out of it. Its like Oracle executives would rather keep WebLogic as the only option to punish customers, they are eventually going to get something better in IIS, .Net, and Great PLains, when it is all rolled-in to one environment on VS, only Glassfish stands in the way of this happening. Dont let it die out of fear of the unknown, like WebLogic will be dead if there is some innovation, WebLogic is not going anywhere, it is the development environment for BPM on the ERP apps, that is huge, like really huge, but it cant be expected to also fend off more nimble cloud purveyors as well, that is not logical. Oracle needs both, but that is not what is happening now, customers see the messaging about departmental apps, so no matter what Glassfish people tell Oracle sales reps, there is no way to get in the customer conversations, it is as an after-thought in Oracle strategic direction. There is no reason this should be the status quo, there is room to move forward, but it takes fresh thinking, and see the challengers as real, dont get caught flat-footed on your flank-side.
Friday, July 08, 2011
a primer on GlassfishIts predecessors in Netscape Application Server and iPlanet Application Server did not work, and so it took the re-write of the Reference Implementation of the Sun ONE Application Server to provide the roadmap that would lead to a stable app server platform, that could be open sourced and turned in to Glassfish. Now, it is being systemically dismantled in the hands of Oracle as all the real money is in the big-ticket product lines of WebLogic, Oracle DB, and PeopleSoft ERP, and no one seems to notice. This leaves a market where only JBoss is sticking to the Enterprise Java specification, and competing platforms such as Spring Source turn their nose at Oracle, and build cloud environments. This is a shame, after all the effort to get a viable app server platform from Sun, it is being killed from within, with no real sales strategy, and little in the way of marketing support. Something should be done, but the Oracle employees charged with the success of Glassfish, as they were at Sun have not come out with anything more than technical analysis, and do not understand the marketplace's changing tide toward the cloud, waiting instead for Java EE 7, while everyone else shuns Oracle's customer-hosted-only model.
What can be done? Forking with unlimited resources would be fun, the ESB is top-notch, the EJB container is fast, and MySQL is well regarded to give customers a complete deployment platform for the cloud, and it would be taking on a long-time nuisance in the throes of developer interests. Does anyone anywhere have positive experiences with Oracle developer support, they simply dont do it, their site is fractured and useless with case examples of successful deployments, or easy-to-use documentation, like how the Glassfish team initially set its sights on, and still we get no word from anyone at Oracle that they plan to sell Glassfish to their enterprise base. Put simply Glassfish is more potentially disruptive than anything that WebLogic will do with Fusion. And still no action, Oracle is well positioned to dominate enterprise computing, both hardware and software after getting Sun for a negligible amount, so maybe it is time to take them on, and put Glassfish back in the running for leading enterprise cloud environment.
All of this is well documented but what could be hugely different than anything that a previous fork has done, is actually put a company behind it, and pay the developers that work on it, not allow all of the benefits go to a single entity, though i would propose a company to organize all of the efforts, whats to stop getting paid on commission and equity. I have proposed this before, but i wanted to signal the charge again, as Oracle pays little attention to anything other than Fusion, the DB, and the Google lawsuit. What if Fusion never delivers, and Glassfish is forked, could not Oracle's huge customer base be primed for a move off old WebLogic and convert them to cloud purveyors on Glassfish? I dont know what you guys are working on currently, absent an Android app, the most lucrative field in IT is in the enterprise, and Glassfish is ripe for the taking, so consider your options well when investing your coding talents in to community efforts, and do not waste your time on Oracle's Glassfish, go for a forked version, just like they did with Linux off of Red Hat. It is doable, and the time is right to take Oracle to task for its opposition to the developer community. Join us, and begin the cloud revolution via Glassfish.
Saturday, April 23, 2011
will Glassfish survive?i am just trying to reconcile how the better product receives 1/10th the resources, i mean WebLogic was dying before the acquisition, JBoss had it beat, and then Oracle picks it up for a song, somewhat cheaper than they got Sun, in relative terms, and turns it in to the base of Fusion, and ERP, and invests all this money in to it to become the enterprise platform, all while Glassfish was getting good, and ready to take-down JBoss, or at least take on Spring Source, and then the acquisition, and all funding dried up, all OSS community participation went away, and now its just a small division in an over-grown company, that has not innovated in a decade, but instead relies on its monopoly of the core piece of enterprise computing, and few hostile actions against erstwhile allies in the struggle with Microsoft, and it comes undone, Glassfish must be set free in order for Enterprise Java to survive, it will be irrelevant if it just goes the way of the Reference Implementation, it is too valuable for that, and so this is what i propose:
- Glassfish and MySQL spun off, with SSO, in to a separate company with 49% control by Oracle, and 51% control by all of us who will sign-up to the project, evenly divided among new and tiered for subsequent employees, but the company will always retain a bigger share of the control than Oracle, so as to not withhold innovations for the sake of the larger mother company.
- This will give Oracle a competitive wedge to go in to Red Hat, IBM, VMWare, and Microsoft accounts leading with Glassfish, to be ported to WebLogic when the time is right, for enterprise features, but build out Glassfish to be a cloud purveyor, so as to lead the market with Oracle benefiting without losing out on the focus of the internal sales force.
- Glassfish will in turn focus on becoming an intranet cloud provider, complete with hardware reference implementations, and core software builds on top of Linux, as ordered and copied and forked and implemented and enhanced by Oracle, so all Glassfish deployments will run on Oracle Enterprise Linux and Sun hardware, every last one of them.
- Oracle will provide the funding and make the determination when a VC should be brought in for help, if desired, the employees of the Glassfish/MySQL/SSO company will focus on delivering product and let the expert financial team at Oracle chart the future for its investment, with a solid understanding of the long-term picture, and the standing of Java if the company were to succeed.
- McNealy, Schwartz, Polese, Dooley, and Safa Catz on the Board with broad oversight of the direction of the company and an eye toward further integration with Oracle, further development of the Enterprise Java specification, and further build-out of clouds for Oracle's customer base that would like to look in to the opportunity available with the economics of hosted infrastructure.
- headquarters in GRand Rapids, Michigan with costs of office building, relocation of employees, and subsidization of international employees to work on the OSS projects, need to pay developers well, as this is a long-term view with no initial exit strategy available through stocks, as this company will not go public for an extended period of time.
all of this is accomplished with the introduction of a little risk-reward analysis by Oracle, that needs a jump-start and prove why it has been the biggest financial supporter of Java, and why it has earned the repsect of those who thought it could not innovate out of the dot-com bomb, and the resulting recession, they have proven to be the best bet in enterprise computing, and they have earned their chance at going for the biggest de-thronement in the take-down of Microsoft across the enterprise cloud infrastructure, with Linux, Java, Glassfish, and MySQL, it is all within reach, just $10M to start, open communication channels, and a little trust in the process, and it will be all there for the taking, its time to kick-start Java again, and nothing would do that better than GLassfish...,
Thursday, March 17, 2011
glassfish as cloud platformThe really impressive thing about the Glassfish 3.1 release is the position it puts the product-line in to deliver on a whole new open platform for Oracle to pursue over-time non-established customer bases, in all target verticals, customers or in many cases, enterprises, that have not committed their entire infrastructure to Oracle or SAP, or IBM for that matter. What it does, in a short-term sense, is provide the Oracle sales force with something that can be sold in to 'green' environments, where there is no established leader among the mis-matched product acquisitions that said businesses have made, on a plethora of software companies' product-lines. It reinforces Oracle as a provider of leading-edge Enterprise Java features, that seem to only be getting better for both developers and administrators, alike, as Glassfish 3.1 offers the scalability offerings that will get customers interested beyond departmental applications, that are just looking for something cheap and easy. What Oracle can now say to the thousands of customers that are looking at JBoss for standardization or even SpringSource, is that there is now something better with Oracle's support plan. It will continue to be a process of differentiating the comparative features of WebLogic with Glassfish, but by turning to the cloud for full featured deployable component-ized apps, Glassfish 3.1 will carve out a sizeable and growing niche for developers to understand and for administrators to test, while maintaining a share of budget for advanced, next-stage deployments.
The cloud has been a moving target, transforming from on-line storage to app customization in order to take the features of scalable deployment to the next generation of mixing and matching applications, and parcels of applications to run different features of a web platform. Glassfish 3.1 delivers all of the functionality to look at what could come next, in the development of the cloud, as usability is delivered in clusters, and integration with development environments, that are standard to JEE, for cost-effective testing in environments that are beginning to move to the cloud for deployments. It would not be initially beneficial to Oracle to run a cloud based on Glassfish, though it is conceivable that customers of Oracle could do just that, and by maintaining increased cross-platform support, but only with the core, Glassfish remains a stellar alternative to the other open source offerings in Enterprise Java, including some of Oracle's biggest competitors to emerging markets. Oracle is well positioned to offer a feature-complete cloud offering, that would rather than cannibalize sales of WebLogic could actually open doors, in to new business environments, particularly those that are not somewhat invested in Enterprise Java, as of yet.
The next stage is taking the product-line to the positioning stage, and really offer an alternative off of JBoss and Spring Source, which continue to dominate the standard and non-standard environments, respectively. Oracle would be well-served to open up about Glassfish's potential as a deployment platform for next-stage applications in the cloud, and as Enterprise Java continues to lead the standardization process, as Java continues to maintain its role in the enterprise, there is a need to spell-out how customers should view the two-tiered application server offering, but not to detail, that is still being worked out. Instead, Glassfish 3.1 marks a point where Oracle can actually support two deployment platforms, alongside WebLogic, though it needs to be aggressive with both platforms, the Glassfish opportunity is to gather enough momentum with developers, that has continued to build since v. 1, and move to marketing the feature-set as being ideal for the cloud, and get some named customers on-board that will use Glassfish for reasons that can be duplicated in the cloud. Things that enterprises don't typically do, but considering the economics of an OSS-model, would actually benefit certain customers with knowledge on deployment architectures.
This will take reference architectures on Sun hardware, it will take more-detailed deployment guides on various types of applications, also more competitive analysis on how it stacks up with other OSS offerings, and sales guides for when a customer states something about looking at next-generation development and/or cloud deployment. Oracle's customers are, for the majority, savvy enough to understand when one product-line is tailored for their needs, and Glassfish 3.1 meets the requirements of those forward looking businesses and organizations that need something fast and now, while giving them a deployment guide for when certain aspects of their development match a broader roll-out with scalability requirements. It is not too soon to spell out the differentiating value of Glassfish 3.1 as soon as possible to gather more coverage from the customers and media on why the product-line yields what has been missing from Enterprise Java in the last few years: a distinct leader on new features and advanced deployment capabilities. The cloud is but a term to use in conversation, the real work is only accomplished when detailed documentation provides additional language and materials to realistically put the features of Glassfish 3.1 in perspective. This is the call for Oracle to do, and the time is right to transcend the standard marketing, to take the product-line of Glassfish to new levels, appearing to carve out a respectable niche among paying customers.