Common Platform Basis: Difference between revisions

From Cibernética Americana
Jump to navigationJump to search
No edit summary
No edit summary
Line 10: Line 10:
</ul>
</ul>
<br>
<br>
Our core platform services are made available in bindings for any of the above and our initial buildout will create a generic vertical for each distinct enterprise case using all of the above.
Our core platform services are made available in bindings for any of the above and our initial buildout will create a generic vertical for each distinct enterprise domain set or 'dominion' using all of the above.
<br><br>
<br><br>Some people focus on one or another of these packages as the basis of their enterprise impelementation. This focus is not without consequences but it cannot be helped because shopping for what you think you need instead of what you actually need is a buyer's prerogative.
Note that only there are only 4 actual development packages above, and only 2 really full featured ones at that, but this is the way people currently shop for the basis for thier development needs, so we have to accomodate it. This focus is not without consequences but it cannot be helped because shopping for what you think you need instead of what you actually need is a buyer's prerogative.
<br><br>
<br><br>
What you actually want, and may not know it, is a system that achieves your functional goals (assuming these are reasonable and feasible) and has the properties highlighted in the Value Prop(osition). In general what you may have think is the 'platform' choice or package du Jour generally has little to do with the attainment (except possibly to hinder it) of there properties. Nonetheless, unless such a choice presents a full blown conflict with the attainment of our
What you actually want, and may not know it, is a system that achieves your functional goals (assuming these are reasonable and feasible) and has the properties highlighted in the Value Prop(osition). In general what you may have think is the 'platform' choice or package du Jour generally has little to do with the attainment (except possibly to hinder it) of there properties. Nonetheless, unless such a choice presents a full blown conflict with the attainment of our
<html><a href=/everything/index.pl?node=total+quality+management>Total Quality Management</a></html> goals, we can accomodate it.
<html><a href=/everything/index.pl?node=total+quality+management>Total Quality Management</a></html> goals, we can accomodate it.

Revision as of 02:32, 5 June 2007

Domain Content Mgt. System (DCMS) integrated the following packages for the indicated standard purposes and can be for key milestones in the to initialization of your dominion (enterprise domain(s)):

  • dojo (js,AJAX)
  • JBoss (JMX, etc)
  • Joomla (default CMS)
  • Drupal (Organic Groups)
  • LAMP (DCMS core)
  • TYPO3 (site template)


Our core platform services are made available in bindings for any of the above and our initial buildout will create a generic vertical for each distinct enterprise domain set or 'dominion' using all of the above.

Some people focus on one or another of these packages as the basis of their enterprise impelementation. This focus is not without consequences but it cannot be helped because shopping for what you think you need instead of what you actually need is a buyer's prerogative.

What you actually want, and may not know it, is a system that achieves your functional goals (assuming these are reasonable and feasible) and has the properties highlighted in the Value Prop(osition). In general what you may have think is the 'platform' choice or package du Jour generally has little to do with the attainment (except possibly to hinder it) of there properties. Nonetheless, unless such a choice presents a full blown conflict with the attainment of our Total Quality Management goals, we can accomodate it.