Any new application, no matter how well designed, will be subject to change over time. Specifically

1. Technology change: How the application must connect to and use supporting technology (communications, database, user interface, runtime control etc) will change in response to new technologies, and new versions of existing technologies, becoming available.
2. Requirements change: How the application should behave, and what features it supports will change in response to evolving business needs.

Failure to account for technology change results in a legacy application that is frozen in time and needs specialized maintenance. Failure to account for requirements change results in a brittle application that doesn't do what is needed by the business. In both cases costs start to go up and value starts to go down with the effects being felt in as little as 6 months. Structs and nodes Development (SAND) was designed to address both kinds of change, and as a side-effect it also decreases the effort associated with initial development.

See the SAND Services Inc. website for an overview of SAND. In technical terms, SAND enables us to deliver:

1. Complete, flexible messaging data definitions from struct declarations.
   
   

   utilities: equivalence matching, copying, conversion, field defaulting, field and message level validation. supporting framework: revision checked transactional persistence, paged ad hoc query processing, XML serialization, messaging, remote error handling, authorization filtering, caching, testing, encryption, display and editing forms.

   
   
2. Business module definitions from node declarations.
   
   

   supporting framework: deployment configuration, runtime management, logging, messaging, statistics, error signaling. Message processing modules: For an outbound synchronous message (such as a query message returning a collection message), use the corresponding generated "call" method. For an outbound asynchronous message (such as a stats message), use the corresponding generated "send" method. To handle an inbound synchronous message, override the corresponding generated "onReceive" method. To handle an inbound asynchronous message, override the corresponding generated "onDelivery" method.

   
   
3. Logical groupings of struct and node declarations into one or more apps, and a target deployment.
   
   

   supporting framework: fully automated build and deployment processing, navigable docs. [more information on directory structures]

   
   
4. Full Configuration definitions for each deployment.
   
   

   supporting framework: The configuration defines what nodes will be running on which servers, and what data must be initially available at startup. Initialization is fully automated. [example TaskHeap demo deployment description]

   
   
5. User interface screenflow SandUI definitions for each deployment.
   
   

   supporting framework: The screenflow defines the application components of the user interface. graphics: We provide design services through our partners, and can provide you with alternatives for site graphics and overall design. If you already have a site design, we can build from your existing base.

   
   

6. A development platform deployment on SandBoss, and a production platform deployment according to application requirements.

7. An automated regression test suite confirming system requirements.

Most of these aspects can be seen from the Requirements Definition & Architecture that is generated as the first step in any new project. See the process page on the main website for more details.

© 2002-2005 SAND Services Inc.
All Rights Reserved.