Software Quality Series: Portability
Portability for cars may not mean much, but for software applications it does. An application or system is said to be truly portable when all of its components can run on various platforms, containers, operating systems or even devices with no need for platform-specific compilation. The ideal portable application is also maintained on a single code stream and a platform-independent executable supported by platform-specific configuration files is the only build artifact that end-up in the customer’s hands. Given this definition, a Microsoft .NET application is not portable because it runs only on Windows and potentially only on PCs. A Java application on the other hand, while more portable than .NET is still not the ideal, since it requires a recompile for a handheld device using the J2ME.
So, how does portability affect the overall quality of a software product?
Let’s look at the following scenario.
Initech, is a leading provider of enterprise-grade TPS report cover sheet solutions developed in Java and J2EE. Having Java as the primary build platform has gained Initech a competitive advantage over its competitors due to the fact that the product runs on multiple platforms with no need to recompile.
Noticing that its customers deploy on a variety of J2EE severs, Initech has also invested in an application server-independent solution. By doing so Initech has tapped into a larger market and made its investment worthwhile.
One day Initech’s development group receives a question from an existing customer on whether they can use DB2 as the underlying database for TPS. The customer is in the process of consolidating all of the enterprise databases into a single platform and needs help to transition from Oracle to DB2. This is not an entirely unexpected question and despite that it has been raised several times; the company has kept its products specific to Oracle. And it makes sense to do so. 80% of the application’s business logic resides in Oracle as stored procedures, sequences or objects.
In this example Initech has reached a semi-portable state by creating an application-server agnostic product, but failed to address portability of the database. This failure is ultimately perceived as a product quality issue and as a result Initech is not well positioned to gain or keep non-Oracle customers.
Portability in the age of SOA
With latest advances in Service-Oriented Architectures (SOA), portability has become less of an issue. If proper architectural designs are in place, platform-specific applications can be transformed into less technology-dependent and more accommodating to inter-operable business needs. A good example is two components of a large enterprise application. One of the components is a mortgage processor in .NET and second one is a downstream accounting system in J2EE. Both components access various data stores throughout the enterprise and communicate through asynchronous messages and SOAP-based web services. In this case both components are platform-dependent and still achieve a larger business objective. It may be said that this large enterprise application exhibits high quality regarding portability, because it has achieved internal platform-independence through SOA.
Portability in the age of Open Source
According to a view, building a brand-new enterprise system today has to do more with picking the right open-source frameworks than coding business logic. Knowing that most challenges in software development can be traced to configuration and deployment problems, it is even more difficult to disagree with this view. Today open-source frameworks have come a long way to constitute the backbone of many enterprise applications. When thinking of portability of the enterprise application it is imperative to think of the portability of its parts. Do they work on all platforms? Do they support multiple application servers and/or databases? Will they play well with other open source frameworks?
Monitoring Portability
High quality software is easily recognized with its portability. To ensure high portability, projects should plan properly and monitor builds constantly. Should a problem arise, it should be addresses as soon as possible.
Many leading projects today take advantage of Continuous Integration (CI) and nightly builds to ensure the source code still compiles after the day’s changes. Most projects include some regression testing in the build process, and some projects also generate daily binary builds for public download. Some open source projects such as the Mozilla and Perl use tools such as the Tinderbox tool to help assure portability by building the code on multiple platforms after any code change; if the build breaks on any platform, then all subsequent code changes are limited to fixes [1]. Some projects additionally incorporate platform-specific code style checkers and grid-supported build capability, usually to support testing for portability [2].
Conclusion
To ensure maximum portability across databases, application servers, platforms, operating systems, and devices high-quality software should address portability early and monitor constantly. Leading enterprises make portability part of their Continuos Integration (CI) process and treat portability issues as seriously as broked build issues. Tools such as Ant, Maven and Tinderbox can simplify the continuos portability monitoring.
References:
1. High Quality and Open Source Software Practices, T. J. Halloran (thallora@cs.cmu.edu), William L. Scherlis (wls@cs.cmu.edu), Carnegie Mellon University
2. Open Source Evaluation and Assurance, Professors Bill Scherlis, Jim Herbsleb, Jonathan Aldrich, Aaron Greenhouse, Carnegie Mellon CyLab
October 9th, 2006 at 6:04 am
Portability software cost a lot more to write and takes longer to write/test. Also if your software is portability to lot of different system, then your support and testing people must understand all those system.
It is nice to get a bigger market by writing portability software, however often in real life you have to choose between being the leader in a small market, or being 10th place in a big market, and therefore not getting any sales in the big market.
On the project I am working on, we decided that we could not afford to be portable to different database systems. However we know that this may change at some point, so we have written very few stored procs etc, every time we write a some database code, we ask our self how hard would it be to port, and iff there is a different way to write it that does not cost a lot more, but will be easier to port, then we go for the easy to port method.
I rather have a product shipping and being in money on the 80% of the market that will pop up with our choose of database, then have a none finished product that does not make us any money that will work with all the big database vendors. When customers ask for a different database, we ask them how match more are they willing to pay EVERY year to cover our costs of supporting it, at that point it is common for the end-users (that pay for our software) to force their IT people to go with our choose of database.
October 9th, 2006 at 8:12 pm
Hi Ian,
First of all thank you for reading and commenting. I agree with most of your points.
While your statement “Portability software cost a lot more to write and takes longer to write/test” is generally on the money, it’s important to carefully calculate the trade-off between time spent on portability vs. potential market share gain. I think one can argue that portable software may not necessarily prolong the development cycle, because there is little time gained between writing a DB-independent DAO method vs. writing a stored procedure. This is assuming the software uses a DB-independent ORM layer such as Hibernate, EJB3 or iBatis.
Come to testing, if the application is already being covered with a number of unit tests, portability will not add any significant platform-specific unit testing. Similarly, if the application is furnished with a suite of automated functional, integration and performance tests, those should still be able to run OK. Where the problem could arise is if/when some of these tests fail for a specific platform. That may require additional debugging and fixing. While this can be seen as a potential issue with costs of portable software, I’ve seen this actually working in favor of my former clients. They did use to deploy an enterprise application to Jboss, WebLogic, WebSphere and OAS. Sometimes one of the app servers would fail the tests, however occasionally that would turn out to be a defect or non- J2EE -compliant code.
Companies sometimes fall into the trap of placing way too much business logic into the database layer. Business logic in the DB layer is a non-ideal practice for at least several reasons:
1. Stored procedures are not portable. They will not support a switch to another data storage (OODB, Different DB vendor, XMLDB)
2. Stored procedures are not easily testable
3. Stored procedures are not easily debuggable
4. Since they are not OO, there is no easy way to take advantage of OOD concepts such as reusability, encapsulation and polymorphism. There is code duplication.
5. Finally, stored procedures means split architectural design spanning multiple layers. This makes the design more difficult to communicate via standard design languages such as UML.
Having said that, I know that businesses have to make money and if the market dictates a profitable single DB solution, then that’s probably what they should do. In those cases focusing on a single database may not be a terrible thing if the business understands the potential implications of such a decision.