Sundial Services
Professional Software Engineering Consultants Since 1992

The Challenges of "Existing Software":

Although "computer software does not wear out," the software and hardware environment in which it operates – does. The programming languages in which they were written sometimes change too, and they sometimes change in ways that cause existing software to (rather abruptly) stop working. Sometimes the vendors in question "deprecate" or abandon their systems, or simply go out of business.

Your options at this point can be quite complicated – such that we cannot hope to anticipate what circumstances might apply to your case.

Therefore, we'd like to break it down into several different relevant categories, then tell you what we think about each one. Finally, we'd like to briefly discuss how you might engage us, in what capacity(ies), and what to expect.

Please note also that your situation is quite likely to fall into more than one of these categories.


Scenario: Vendor/Product Abandonment; Obsolete Hardware/Software Environments

Early software solutions were built to operate within the constraints of hardware that today seems unimaginably small: 16-bit (or even 8-bit!) machines that were starved for both memory and disk storage. "One megabyte" was a generous amount of RAM (requiring special tricks since the architectural limit was 640K); a "ten megabyte" hard-drive was enormous. "33 mHz" was fast. Programs had to be divided into "overlays." Today's sophisticated resource-management strategies that allow multiple programs to operate independently on the same machine (and to easily access all of the resources available to them) simply did not yet exist, because semiconductor manufacturers couldn't do such things – yet.

As computer technology continued to advance at astonishing speeds, various vendors of early software products began to realize that the business case for their original software products was coming to an end. Some products, like WordPerfect or WordStar or Lotus 1-2-3, wound up their business (willingly or unwillingly), maybe sold-off their assets at fire sale prices, and disappeared. Others, such as Borland's Paradox, briefly re-invented themselves by deploying entirely re-conceived products that merely retained compatibility with their predecessor's data. Still others, such as FoxPro, gambled (unsuccessfully) on the notion of transplanting their character-based methodologies into a new and very-graphic world. But as the technical tsunami continued, company after company continued to be swallowed-up. Either they disappeared or they morphed into brand-new companies that had nothing at all to do with what they once had been doing.

Either way, the technology that is the basis of the software that you now continue to rely on "effectively no longer exists." (And we say this even though for several decades we sold a product that "owned" a slice of that market, and even though we continue to sell copies of it to this day.) If you continue to operate a system of this nature, you are unfortunately now presented with an extremely large "phase-change." In our opinion you must retire this system at once, and you must develop a fundamentally new replacement business process ... more or less from scratch.

(In many cases we don't have to say that, but in this scenario, we think we do. Sorry ...)

A parallel problem occurs when the software environment upon which your software depends no longer exists. For example, Microsoft is now permanently abandoning support for 16-bit software in their modern (now, 64-bit) systems. And this isn't simply a "CPU architecture" consideration: many of the foundational assumptions made by early software (such as: "we can have free access to the C:\ drive") are simply no longer sustainable.

Therefore, "like it or not, change has now been thrust upon you," such that you can no longer remain where you are. However, this is not simply "a lateral move" which would seek to replace the existing system with a re-implementation of the same thing. This must be regarded as an opportunity to re-evaluate the business process of which this system has been a part, and to move that process to a fundamentally-better one ... considering, at all times, "build versus buy." (And kindly remember that this is not a prelude to a vendor sales-pitch: we're not "a vendor," and so "we have no product to sell.")


Scenario: "You're Dead, Jim ..." (So, How Do We Now Recover Data In A Useful-to-Us Form?)

This bit of business (from an early on-line 'Star Trek' game, where Dr. "Bones" McCoy gives unfortunate bad news to Captain "Jim" Kirk) is sometimes unpleasantly true: "the software is dead, the original developer is [figuratively or sometimes literally] dead," and you need help simply extracting data from the present system in order to enable your situation to move beyond it.

The database and file structures that ran beneath early software systems were a direct consequence of their user interfaces: to present a data-input "form," you had to define a corresponding "table" and so-forth. (The notion that "these computers could actually support SQL" seemed unthinkable until Microsoft Access® 1.0 actually did it.) Business logic could not be directly codified in database structures as we more-commonly do today. The fundamental design of applications was constrained by "overlays" and other programming strictures that – while very real then – are no longer relevant today.

The process of recovering business process knowledge, and data, from these systems is therefore sometimes a process of forensic examination, especially when the source-code to the system is no longer available.


Scenario: Hardware

"Ka-chuck ... brrrzzt ... ka-chuck."

Yeah, you've heard it, and it quite-properly scared the Dickens out of you each time that you actually went to the broom-closet where that hard-working piece of hardware still sits. You mash the button that will re-boot that server just one more time, but you know that you are living on borrowed time.

But how do you get out of this mess, and take your business forward?

As previously discussed, if this server is supporting a now-obsolete hardware/software environment, such as "16-bit Windows 3.1" or hybrids such as "Windows-95" and so-forth ... your actual situation falls under the auspices of the previous section. (Sorry.)

If your server is supporting a more-recent environment – Windows versions later than "XP," Linux, or Apple OS/X – you probably should be at-least entertaining the option of "time-sharing" or "hosting," a.k.a. "the Cloud." In other words, quit trying to support the physical hardware yourself, and instead allow a third-party company, who might have hundreds of subscribers in a situation very similar to yours, to "leverage the economy of scale" in your favor, using hardware firepower you can't match.

Read More about the various very-different things that "the Cloud" might refer to.

We are not a hardware-services company, and we do not represent any hosting company or cloud provider. If your particular situation calls for "real iron," we'll be the first ones to tell you. But many companies today find "the flexible combination of maneuverability and horsepower" that a well-designed "cloud" deployment offers to be – with very good reason – quite irresistible. If we feel that this strategy is appropriate for you, we'll describe specific ways in which you can advantageously use "the cloud." (But if other, "non-cloud," options might apply, we'll present those also. We're not biased. We have no skin in this game. We're on your side.)


Scenario: "Breaking Changes"

You said that computer software "doesn't wear out"... so my [web site] won't "suddenly quit working,'" right?

Unfortunately ... no.

Web-site software is most-often built using on-the-fly interpreted languages (Java® being today's notable truly-compiled exception) which are, first of all, subject to the possibility of "breaking changes" in the language itself. (The widely-used PHP language is especially susceptible to this.) Language providers sometimes "deprecate" features that they don't like anymore, and remove them from the language! Suddenly, and after what you supposed would be an innocent upgrade, your software does not run.

But a further exposure is presented by the contributed software libraries – all of them consisting of software written in the same interpreted languages – upon which whatever software was originally prepared for you implicitly depends.

When properly managed, these libraries are a critical benefit to the language in question and actually represent a very strong reason for using them, since they are "vast amounts of reliable source-code that your implementors didn't have to write."

"Woo-hoo!™" ... however ... Sometimes these libraries cease to be maintained, and thus become flawed or inoperable. Sometimes their providers decide to "deprecate" features upon which your software utterly depends. Or, they might fail to keep up with the changes in technology. Or, they might implement (say ...) database access in a way fundamentally different from the way that the rest of your application did.


Scenario: Regulatory and Business Changes

Sometimes the situation that surrounds an existing software system are entirely "through no fault of its own." The implementors (and subsequent maintainers) of the system were as foresighted and future-proofing as good professional business practices (of that time) might have called upon them to be. "Yes, indeed, your money was well-spent!" But – now, things have changed, and your software hasn't.

"Regulatory changes" might span the entire gamut from sweeping government regulations such as HIPAA to comparatively-simple(!) vendor requirements such as PCI. In either case, it is quite impossible for us to further speculate as to exactly what changes might now be called for, because they might be "superficial" to the application in its present form, or they might impose profound changes.

"Hardening" issues, when not imposed by regulation, might simply be matters of operational necessity: you see that your systems are being hammered by thousands(!) of unauthorized/pure-garbage(!!) requests per day, and you very-simply need for them to stop. In some cases we can accomplish this by imposing upon these interfaces additional strictures that are much stronger than "mere passwords." (In some cases, we can make the vulnerable interfaces vanish, for everyone but you. An intruder who's "port-scanning" your system, looking for vulnerabilities, cannot detect the secret door by which you effortlessly enter.)

"Business-Need / Evolutionary" changes are those which are the most likely to be incompatible(!) with the system as it stands today, necessitating the building-out of new "outrigger" software to complement the present system while remaining compatible to it. (Easier said than done.)

As by now you have very-well anticipated, there are no "categorical" solutions to these myriad issues. But we can meaningfully assist you in sorting them out, so that you can better devise – and perhaps, with our assistance, implement – a way forward.



So, Where Would We Begin Working With You? "Present-State Analysis."

Any sort of "canned solution" to your problem would be meaningless. Therefore, our first task is to conduct a methodical present-state analysis. The objective is to determine what can be done with your software, and what we think should be, and to present this to you in the form of a very detailed report.

  • If applicable, this report will also describe what we consider to be an appropriate set of subsequent steps, with non-binding objective projections of cost and time, whether we do the work or not.

This detailed report is intended to be a (paid-for) stand-alone deliverable, not a pre-sales or a sales-qualification document.

Furthermore, it must be clearly understood that the process of arriving that this report might turn out to be iterative: it may well be necessary for us to bill for it using progress payments. Nevertheless, we will at each iteration present you with explicit details of our progress so far, and engage you explicitly as to how we should next proceed. (This decision, as always, "is up to you.")

The delivered report is meant to be a working document. It is detailed enough to allow it to be presented to other companies or to be used as the basis of an RFP, which we can also help you to prepare and/or to evaluate. If it so happens that we can be of service in the subsequent project, we will so indicate. But we do not perform the present-state analysis on any such assumption.

We always begin with present-state analysis, and we insist upon it because we believe in it. Decades of experience have taught us its profound importance. "Comprehensive advance analysis, before any work begins," is – we believe – the most-important stage of any software-related project. Yet it is often overlooked or skimmed-over in the zeal to get started, and, frankly, to win the contract. This is an extremely costly error that can sometimes doom the project to failure before it begins. We have seen it happen many, many times. So, we won't let it happen to you.

"The analysis is our first deliverable. Whether there is a subsequent contract to perform work ... remains to be seen."

How may we help you?

Contact Us!