Project Approach
DataJini's vision is that technology is not an objective but a means to an end. Our project approach and technology architecture is all geared towards enabling the end-customer to achieve their objectives. We have placed these Business Objectives (BO) at the center of our project approach. When executing a custom build project, we follow Project Objectives (PO) and Project Principles (PP) that enable us to meet the end-customer's Business Objectives (BO).

Project Objectives (PO)

PO 1	Project objectives must align with strategic objectives end-customer.
PO 2	Solutions must be fit for purpose (meet requirements).
PO 3	Ensure (increase) continued stability for end-customer.
PO 4	Compliance (SOX).
PO 5	Enhance (increase) the simplicity of the IT landscape.
PO 6	Standardization of the architecture process (CMMI), resulting in: • Predictability • Improve the maturity level and effectiveness • Re-use of best practices • Robust tracking & tracing (SOX) • Setting boundaries • Guarantees consistency (SOX)
PO 7	Reduced Total Cost of Ownership (TCO), in both initial costs (CAPEX) and maintenance costs (OPEX).
PO 8	Improve/decrease time-to-market.
PO 9	End-customer satisfaction.
PO 10	Delivery responsibility.

Project Principles (PP)

PP 1	Do a project properly or don’t do it at all. Justification: sloppiness will always bite you in the end.
PP 2	Simplicity I: Maximizing the Amount of Work Not Done (MAWND). Applies to the following areas: - Maximize the automation of your development - Maximize the automation of your maintenance - Maximize the automation of your deployment
PP 4	Simplicity II: Keep solution as simple as possible (as simple as possible and only as complex as necessary) Justification: PP2 (MAWND)
PP 3	Don't repeat yourself. Justification: PP2 (MAWND)
PP 5	Maximize self documentation. Applies to data model & software. Use unambiguous semantics in data model & software. Use Uniform naming conventions in all tiers of your application. Table names/column names are 1:1 with view names/column Table names/column names are 1:1 with software-parameters Table names/column names are 1:1 with API-calls. Table names/column names are 1:1 with web services Table names/column names are 1:1 with GUI-prompts. Only allowed differences for GUI-prompts are: Replacing underscores with spaces Init-cap individual words Trim of application prefixes. There is no valid reason to differentiate in naming conventions. Justification: PP2 (MAWND)
PP 6	Database centric approach. "What the periodic table is to chemistry is the relational model to database technology" (Quote C.J. Date) Data integrity is a vastly underrated but very valuable asset: in our minds it is essential; enforce all your business rules in at least your database tier. Database driven application relies on the relational model. The database-tier is always better in performing data intensive tasks then any other tier. Justification: PP2 (MAWND)
PP 7	Keep derived elements as close as possible to the origin elements: - keep documentation close to data model - keep documentation close to software - keep code close to data model (virtual columns) Justification: PO 5
PP 8	Avoid all manual redundancy. Applies to software & data. Redundancy is only allowed when there is no other option (with a solid justification like performance) and when redundancy is 100% automated. Allow automated propagation of your implemented business rules to other tiers in your software stack. Example: Generic software that automatically renders a drop down in GUI, based on database check constraints. Justification: PP2 (MAWND)
PP 9	'Off the shelf' and 'proven technology' preferred above custom development. Justification: PP2 (MAWND)
PP 10	Enforce strict consequent conventions for patterns. Most custom development, maintenance and deployment (80% ) is a general reusable solution to a commonly occurring problem which can be captured in generic patterns. The error-prone manual tasks for those patterns should be automated. Justification: PP2 (MAWND)
PP 11	Configure 'what' (functional requirements) in a structured repository and automate the 'how' (software development, software maintenance & software deployment) This Model Driven Development (MDD) approach results in a clear distinction between the functional requirements and the technical abstraction that implements them. Justification: PP2 (MAWND) and PP10.
PP 12	Make sure there is a clear distinction between functional requirements and solutions. Often a solution (maybe not the best solution) is chosen without justification by a functional requirement.