The fastest easiest way to get it right.

The Business of Andromeda


Andromeda is first and last a business tool, meant to enrich developer and user alike.

This is accomplished in three ways. First, a dramatic reduction in the labor required to create business software. Second, far more predictable timelines. Third, an extension of the useful life of software assets.

These are remarkably easy things to accomplish if we are in possession of a handful of very clear ideas, but paradoxically they are almost impossible to attain if those ideas are lost. This section aims to lay out the main ideas that make Andromeda -- and its gains -- possible.

The Main Ideas

All Business Rules Resolve to Database Specifications

This idea is self-evident. Anybody with any experience in software knows that when we discuss the requirements of a business program, we are talking always about the database, what it must record, what the constraints are, and what derivations will be made from it.

What is not always so obvious is what you can gain if you take this simple reality as the cornerstone of your software development strategy. Taken to its logical conclusion, if the database specification contains all business rules, then all of the tasks of database creation and maintenance can be automated, as well as the rotuine tasks of UI programming.

Therefore Andromeda provides a way to specify all business rules in the database specification and it automates the creation of the database and program code from that specification.

Automated Values Must Be Fully Supported

A database specification cannot be complete unless it contains automated, derived data. These are values that come from other values. Every business application derives data out of user-supplied values, and if all business rules are going to be put into the database specification, then it must allow any valid automation.

Andromeda provides complete support for automated values, far and away more than any product we have ever seen. Any kind of derivation that can be expressed in terms of normalized tables can be built into an Andromeda database, from the simplest extension of price * qty to complex multi-table aggregations, cascades, and cross-references.

A Programmer's Best Asset is Data

Code is a terrible thing to invest in. It begins to lose value almost as it is written, and becomes only more expensive to own as the system around it grows.

The Andromeda programmer invests in data, not code. The primary asset in any project is the database specification, which completely specifies all business rules, and which is used to automatically build a database that completely implements them.

This radically alters the cost dynamic for the Andromeda developer. Instead of pouring precious programming dollars in expiring code, the Andromeda developer creates a growing body of data that generates software automatically. When new platforms arrive, we have only to recreate a small amount of builder code to see the entire investment come to life on alternative platforms.

Predictable Costs

One of the biggest timeline killers is mid-course decision making.

The software industry has long known that if a project's requirements could only be fully known at the outset, the program could be correctly written. Yet this proves impossible to achieve in practice for any non-trivial project, the project's full requirement can never be known until the project is well underway. And of course once it is under way sometimes fundamental flaws are found and fresh decisions must be made which may undermine earlier work, or may drastically extend the timeline.

By contrast, Andromeda projects will usually take an amount of time roughly equal to their table count, and table count is something that can be guessed at with some ease early on.

This is possible because Andromeda focuses all human judgement into only one phase of development: the database design. Every action after the database design is fully determined by the database design, and therefore every action after the design can be done by a program, no human intervention is required.

The bottom line is simple, the amount of human judgement required will be roughly equal to the table count, and the amount of discussions amongst project stakeholders will also follow roughly the table count. This is how Andromeda renders projects predictable.

Local Talent

The combination of the above ideas leads to a drastic reduction in labor required to develop complex programs. Very complex systems can be built with one or two Andromeda developers, the creative design group, and if needs be, one or more programmers grinding out such things as reports, labels, forms and export/import routines.

With the team size drastically reduced, it becomes possible to obtain the benefits of local talent without the cost pressures that come when local talent must be purchased in large amounts.

Unpredictable Costs

There are certain activities whose costs, by their nature, cannot be very well predicted. Creative activities are often unpredictable, and communication between different groups can be difficult and cause confusion and delays.

Secure Data Software has found that our time spent on creative efforts and third party communication dwarfs the time spent on actual system development, often by 10:1.

Creative Efforts

There is nothing in the Andromeda strategy to eliminate creativity or make it predictable, that is the job of those uniquely talented to do so, it is a human skill, not a technology. What Andromeda does do is completely separate the creative from the technical. Once a database design is finalized, management is free to spend as much or as little as they choose, as priorities dictate, to beautify the project.

In practice you can generate your web layout and cosmetics in parallel with the programming. We have done this to good effect. Once they are both mature in their own spheres, you can "skin" the system with the layout and implement the CSS styles.

Andromeda makes it possible for a 4 hour brainstorming session to create a 30+ table system that takes only 16-24 hours to program completely, but there can still be 40 hours of design work on the layout, and 1-2 hours "gluing" the UI design to the database.

Touchpoints To Third Parties

In any situation where a third party is involved, there is the risk of unpredictable schedules. This comes entirely from the need to coordinate. Meetings must be sceduled between customer, developer and third party. Protocols between systems must be worked out. Difficulties and bugs must be carefully analyzed and delicately discussed to keep lines of responsibility clear and to avoid the finger-pointing that people fall so easily into.

In terms of clock hours, we have seen that systems involving third parties must estimate that 90% of the time spent on the 'touchpoint' will be in communication and documentation. If it appears that the technical side of the job will take 10 hours, for designing the tables and putting in special import/export, expect 100 hours total after all testing and interaction is complete.

Customer Experience

An amazing fact about databases is that nearly anybody can participate meaningfully in a database design session. Domain experts, non-technical VP's, programmers of any stripe, customer staff, all can readily grasp the concept of organizing like information into tables. The concept of the foreign key is largely self-explanatory when shown to most people for the first time.

We express this as Ken's Law: People Understand Tables Just Fine.

But while it is true that people can understand tables, it is not necessarily true that they think in those terms. The most common thought patterns among screen-facing users is to think in terms of screens, while management may think in terms of processes. All of them of course resolve to data in tables.

A customer base that is unused to thinking in precise detail will need some education along these lines and this will take time. A system of 40 tables may come together in 4 hours of brainstorming, but there may be 3 other sessions which appear far less productive while the customer is led to the table-oriented approach.


The time taken to develop Andromeda projects is highly predictable, based on its concentration of decisions and its high degree of automation. The actual rates of progress will depend on your own staff, but will break down as follows:

  • Programming, tends to go as the count of tables

  • Overall design template, a one-time cost. A "skin" or template can be combined into an Andromeda project in 1-2 hours, depending on the skill of the programmer.

  • Special UI screens, depends entirely on number of special pages and the detail on the pages.

  • Customer experience. The design is first and last expressed in terms of tables. While users can be easily brought to an understanding of table-oriented thinking, some time may need to be spent to bring them there.

  • Third Parties. Any imports/exports or external feeds or interaction will be disproportionately high compared to the simpler tasks of database design and normal development.

comments powered by Disqus
Home |  Documentation |  Download |  Credits |  Contact |  Login
Andromeda © Copyright 2004-2013, Licensed under the GPL Version 2