How quickly can a
team of developers, with an understanding of OSS data models and system design,
produce a reasonably useful OSS application?
The answer is inversely
proportional (not a phrase I've used much since A-level mathematics class) to
the amount of *choice* built in to the application. Note that I said 'choice'
not 'complexity'. Smart people can build highly complex functionality very
quickly, but as soon as they have to build something data-driven, flexible,
customisable, which will run on a large number of hardware/OS/database
platforms and browsers, their development time grows exponentially.
Though
counter-intuitive, the removal of 'choice' is becoming more popular. The
emergence of Software as a Service (SaaS), cloud-computing, and application
platforms suggests that software purchasers, system managers, and end users are
happy to have less choice when it comes to IT and platform options, as well as
less choice when it comes to the ability to highly customise the application.
Generally, architectures that offer less choice are differentiating themselves
as offering rapid installation (or zero installation), rapid development and rapid
roll-out to users.
Let's consider a
scale of choice, from a platform architecture perspective. Starting with maximum choice for developers and integrators, through to architectures with virtually only one choice:
Java and an
Oracle/IBM/MySQL database. This is the architecture the established OSS vendors
use most. Being 'Java based' or 'web enabled' became a key selling point around
2002-2004 driving the adoption of this architecture. It became popular because
it offered *a lot* of choice compared with the more proprietary, less portable architectures
used in the late 90s. The theory of Java's 'write once run anyway' offered the
possibility of supporting a range of hardware/OS combinations. The web-based
clients built on this architecture offered more choice for client access.
There's also a choice of vendors for Java platforms (although since BEA's
acquisition by Oracle, the number has reduced), offering big customers (as most
telcos are) an open market to negotiate over license costs.
Linux, Apache,
MySQL, PHP/Perl. The traditional ‘open
source’ architecture, also known by its acronym LAMP, also offers a range of
hardware platforms and OS choices, although their primary economic benefits are
low (or zero) license costs and support for 'commodity' hardware based on Intel
hardware. LAMP can offer more choice than a commercial Java and database combo,
as customers can pick and mix open source or Linux implementations of
commercial products. In its purest form though, LAMP does narrows the platform
choice: there's not many enterprise
class open source databases or Java application servers, MySQl and jBoss being
the only two generally considered suitable. LAMP can bring financial benefits with
more vendor choice at the server hardware level: there are lots of vendors able
to sell Intel servers, with little migration cost for the customer, resulting
in healthy competition.
Microsoft .Net and
SQLServer. Microsoft offers a single-vendor platform for OS and web/application
server software. This approach is quite distinct from the Java philosophy, and
one that is not always universally appreciated. It has its benefits though. Like LAMP,
it runs on commodity Intel hardware offering a greater choice of hardware
vendors with less risk of lock-in. Microsoft also promote the productivity
benefits. There's less need to support pick and mix technologies or platforms,
allowing .Net to instead focus on improved out-of-the-box integration. .Net may
only offer one way of doing some things, but at least that one way has been
designed, tested and implemented in a user friendly way. While Java has a
multitude of architectures and deployment options, managed by uber-flexible XML
configuration files, .Net offers a limited choice configured by an
industry-leading integrated development
GUI.
Cloud Computing. To
choose a cloud computing architecture is to remove all choice of hardware, OS
and application server. It's basically picking a single vendor web, application
server and database vendor. The 'cloud' exists in the vendor's data centre and
is accessed via the internet. The end customer will typically only have access
to configure a few basic features of the application platform upon which their
code and data resides. The proposition is that the cost of resources in the
cloud is less than the customer buying their own hardware, OS and application
servers. Also, cloud resources are easily ‘turn-on-and-off-able’ when the
computing power requirements change. The pay-off of this massive cut in choice
is much lower running costs and maximum resource flexibility.
Software as a
Service. If a customer just wants to buy a commercial product, rather than
develop their own, then SaaS offers many of the benefits of cloud computing
with an application read- to-go. Compared with buying their own licenses and
receiving a CDROM to install, SaaS greatly reduces deployment time and
management costs. It also removes any choice of hardware, OS, and application
server. Some SaaS products provide for a level of customisation through
development, usually limited to a single (often proprietary) language.
Whether an OSS developer appreciates flexibility, rapid development, a nice IDE, or the latest technology, it's often economic factors that dictate the architectures used by telcos.
Strategic IT
architecture choices have typically been made to drive cost savings inside the
telco. While a purchaser will consider license and support costs, the main
objective is the greater benefit of avoiding vendor lock-in. If the telco can
select a consistent platform technology while still ensuring every major
project has the chance to go to competitive tender for hardware and software,
then the telco is on to a good thing. This approach by the telcos was one of the
factors driving Java and LAMP support over the last decade.
This approach does
run the risk of making short-short term savings at the expense of increased
project cost and 'total cost of ownership' (TCO). To have a pre-selected
architecture may lock out emerging cloud and SaaS solutions which offer the
necessary functionality at a reduced overall cost to the project. Many telcos
have experienced slow and costly IT system deployments. As a result TCO is
becoming more of a consideration and the economics of ‘reduced choice’ become
more appealing.
SaaS and
cloud-computing also often offer their customers more favourable license terms.
Services are paid for on a subscription basis, rather than as a one-off license
purchase. A Typical pricing model for SaaS would see revenues equivalent to a
one-off license being spread over 4-5 years.
Let me be very clear:
The greatest limiting factor to telco adoption of cloud and SaaS is the lack of
commercial OSS products that support these architectures. Will we see adoption
of new architectures by software vendors in the near future? I think so.
Start-ups need to ‘play catch-up’ in terms of developing functionality, and
Microsoft .Net, SaaS and the cloud offer the opportunity for faster
development. In the crash-economy start-ups can do business with smaller
overheads by offering their products as SaaS or cloud services, and their
customers can benefit from the economics of these architectures and pricing models. Provided the
vendors and the telcos are willing to trust business critical applications to these
relatively immature technologies, it could be a win-win for both parties.