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.