BA372 - Portability
- Porting: transferring a
software product to another platform.
- Platform / Interoperability:
- Hardware.
- OS.
- Server.
- Client.
- (Human) language (should The OSU Catalog & Schedule of Classes have
an English/Spanish switch?).
- 'Usership' ==> open source vs. proprietary.
- Organizational and regulatory environments (e.g., MA-MS ODF controversy).
- Hohmann (p. 115): "Marketects and tarchitects
alike often pursue portability with a fiery passion."
- 'Claimed' motivations to port:
- Support of multiple platforms provides access to additional markets.
- Support of multiple platforms shows that we can meet customer needs.
- Portability paradox:
"Customers choose a platform because
of its unique features and perceived benefits, but most portable applications
are explicitly designed to avoid platform-specific features."
- Problem: inherent tradeoff for platform-independence?
- 'Real' motivations to port:
- Writing portable software is interesting and neat (compare with resumé-driven
design).
- One or two, early key customers want the tool on different platforms
(pressure to have income causes early porting).
- Portability is ALWAYS about money
(p. 118):
- Train developers on multiple platforms.
- Purchase and system maintenance of multiple platforms.
- Development, testing and QA on multiple platforms.
- Management of multiple release cycles.
- Portability does not compensate for a poor product.
- Good products do not necessarily HAVE to be portable (see Pfizer/Sun example
on p. 118).
- Carefully compare revenue/platform with cost/platform.
- Technologies (generic tools) have a higher need/opportunity for portability
than applications (p. 117).
- Technologies are mostly built with portability in mind: modular, stubs
for drivers, configuration files, etc.
- How to port:
- A priori instead of
ex post;
i.e., build it portable in the
first place.
- Use interpreted languages:
- Need an interpreter for each platform.
- Single code base.
- Compiled languages:
- Compiler for each platform.
- Only write 'portable,' 'cross-platform' (standard-compatible)
code.
- Nonetheless; often minor code variations across platforms.
- Some products provide platform-independent code libraries;
e.g.,
Galaxy by Visix
(no longer in business).
- Write standards-based codes; e.g.,
ANSI (Standard) SQL rather than Transact-SQL (Microsoft) or PL-SQL (Oracle).
- Use XML for data communications.
- Matrix of pain (p. 121-126):
- Multiply the various platforms into a theoretical number of combinations
to support.
- Delete all impossible and unlikely combinations.
- Rank order.
- Decide:
-
Pareto chart of customer configuration distribution.
- (shows you what % of customers uses/wants each of the combinations).
