Avoid disruption as platforms evolve

Platform evolution is outside the control of project managers. Users migrate to new platforms on their own. Tools and languages become obsolete, unsupported, or just too inefficient compared to new choices.

Platform changes are at once disruptive and highly demanding. First, they insert delays and take resources away from delivering new value. There is pressure to hazard guesses about quickly evolving markets in order to have enough time to move. Finally, everyone expects that existing business value will be present on the new platform, but that is hard to meet: Although most business requirements are independent of platform, most specification documents (if there are any, and they are up-to-date) may be for a specific language and platform.

With Soft-X-Form™, the churn and evolution in platforms and devices does not have to erode the value of your applications:

Software Activity	Traditional	Soft-X-Form™
1. Request (e.g. requirements)	Migrating business value requires complete specifications which must be reviewed, updated, and/or rewritten for each new platform.	The existing, working implementation source code is analyzed and converted directly. For added benefits, use this step to separate the business logic from the low-level implementation. (Also, this analysis can be performed prior to the need to convert.)
2. Development	Programmers implement features using a specific programming language, on a specific platform. Re-use is hard, and the result runs in just one place.	Cross-platform business logic with lasting value should be implemented in a single language, and then translated to a variety of platforms. You decide to stay in the original language or convert and work in a new one. Since the translation process is automated, there is no long delay, avoiding pressure to make long term commitments to moving markets.
3. Test	Retesting preserves value, but it does not add any. When features are implemented by hand, at a low-level, defects still must be located by exhaustive testing in order to be removed.	Testing is limited to the parts touched by developers and to ensure the automatic code conversion/generation for the language and platform are correct. The correctness of the translation processor can be validated by sampling, not exhaustive testing.
4. Deployment (e.g. publishing) and user adoption (e.g. training.)	Differences in implementation are a barrier to user migration. Users dislike applications that provide different ways to do the same thing on different platforms.	A common layer, including business logic and UI, helps users migrate and interoperate across platforms.