During initial application development, managing persistent data is frequently viewed as a minor aspect of the software. Later in the development cycle, it becomes clear that data management is a discipline to itself that often influences the complete application architecture.

The data ex machina team can help you to understand, and meet, the needs of your software that originate from persistent data management. We can contribute to any of your development activities (We call them activities, and not "phases of development", because every software developer knows that the development process cannot be strictly separated into phases which follow each other in a strict sequence or circle).

Don't hesitate to contact us if, after looking at the situations below, you suspect that we should work together.

Activity	Our contribution
Analysis	Essential for every successful application is a suitable model of the application domain. We have built models for a great variety of complex domains, including biochemistry, mechanical engineering, mail distribution and others. Such models (often expressed in a modeling language like UML) can also provide a base vocabulary when talking to your users. Use cases are stories that describe interactions of users with your software systems. They are a very powerful means of communicaton between potential users and the software developers. As a side product of our domain modeling work, we are experienced in dealing with use cases, can help you to write better use cases and make sure they contan the information the developers and customers find helpful. Having those prerequisites, we can analyze with you what your application requires with respect to persistent data management. Usually, not all of the data needs to be persistent, and not all persistent data is used in the same way. It is very important to classify your data and to determine in which way it is going to be accessed, if you want to evaluate queries, how much data of each kind the application will have to deal with etc.
Design	Based on the requirements of your application, you have to design an architecture. Which data model and which database management system (DBMS) to choose and how to integrate them into your application are decisions that can make a tremendous difference in effort and cost when you start implementation. Very often, application programmers then just fire away and create the data structures (tables, class definitions, DTDs,...) inside the database system without much thinking, because they "already know what the data looks like". But usually, there are several alternative ways of designing the database schema, and if you do not compare at least some of them, you will very likely end up with a schema that makes implementation, maintenance, and evolution ineffective and costly. We are experienced schema designers for any data model, and can produce clean and effective schemas for your application. To get the most performance out of your data management architecture, careful physical database design is necessary. Our assistance in selecting index structures and partitioning schemes of your data, or maybe even creating special indexes four your data access profile, can be a crucial factor in speeding up your application.
Implementation	While most of our implementation resources are bound by Natix development, we always try to find room in our schedule for particularly challenging contract work, e.g. implementation of novel index structures and specialized storage formats. But maybe you should contact us anyway, because some of your specialized needs can be satisfied by Natix, which contains configurable, optimized modules for a variety of data management tasks.
Deployment	After software construction, sometimes the performance of the system does not meet your expectations. This may result from changed requirements, or unusual customer environments, or maybe you don't know at all why things don't work out as planned. By careful interpretation of the system's runtime behaviour and fine tuning the DBMS, we can maybe fix the problem without large changes and development work.
Evolution	After the users understand your software and feel comfortable using it, there soon will be new, and changed requirements, or even completely new ways of using the application. You certainly don't want to redesign everything from scratch, but just welding on extensions without thorough planning is leading to complicated, difficult to maintain systems, and before long you will have to redesign everything. Working with us can show you the appropriate points to evolve your software are. Maybe the model is more flexible than you thought, or there are lesser known features of the DBMS, and you don't have to change that much after all!