Astro Software Business Plan
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.
posted by douglas dooley @ 2:25 PM
0 comments
