Cart
[Home] [By Thread] [By Date] [Recent Entries]
Well, yeah, it can be harder. Is the thinking one-off? The suite operates around a common data model. XML thinking asks the question, what if the common data model of the suite requires a common data model so we can *afford* to build non-common variants. When an application passes some level of functionality, it becomes too expensive to build for a sale of one. The common data model creates a market. How common is it? Perry says, local nodes rule. Ok. True enough. Yet, does that remove the necessity of a common model, or in some cases, does it mean that the common model is shallow but affective, ie, shapes the dataspace effectively? In the police business, there is a standard for police data. It doesn't have a bit of XML, OOP, or even C in it. It just names the names, associates a description, and a type to the data. We build everything else based on a not-so-common model of business rules that determine relationships (a before b, a and b, a Not B) and so forth. The common model is simply the definition of the data for the last guy in the food chain: the FBI. The local guys could care less about it, yet as stated, accomodating the last receiver enables us to get enough definition that we can create structure, and once we have structures, the local rules are just customization with a few new thingies here and there. Now we have a product and a market because there is a fair amount of custom work and a fair amount of shared definitions. There is reuse but it may not be very deep. There is commonality, but only in that there is a consumer at the end of the food chain waiting to be fed. Last guy rules. What about standard processes? Two scenarios: Evolution: Over time, a few leaders in a market emerge, mostly the top dog and the second dog. The decisions they enforce locally about their product colonize the market. The Nos and Yeses for commitments to modifications and enhancements add features and variant, and you sold the second version to recoup the cost of the prototype and now you have customers on maintenance so some bugs became features but... It begins to converge because o the customer tends to imitate his peers and o with only two dominant attractors, the shape of the process emerges, and people understand it, think it is the right way instead of simply a product of feedback (processes evolve and devolve). In other words, you accept minima because they get what they pay for. Promise control is everything. After some time of doing that, it becomes ripe for sharing process definitions. Process controls emerge from neighbors that exchange anything. The longer the chain, the more important it is to satisfy the last guy first. The bottom of the stack rules. The XML is the easy bit. The trick is getting Big Dogs to share. Interoperation is about willingly sacrificing market share to cohesion with the anticipated reward being expansion or replacing old with new. I hear Malthus rattling.... Fiat: Some committee grinds for years and says, "ok, here is what you are doing and here is what is common and here is a standard definition. We described the things we named and typed and now you can implement structures for these." Back to square one. Who sez? Well, who cares? Len http://www.mp3.com/LenBullard Ekam sat.h, Vipraah bahudhaa vadanti. Daamyata. Datta. Dayadhvam.h -----Original Message----- From: Jeff Lowery [mailto:jlowery@s...] Any suite of application built around a common database is reusing the same data model. The ugly problem is that it's a relational model most of the time, and winds up having to be mapped into a set of hierarchical objects *by hand*. I'm not going to hazard a guess as to whether the process could be automated if the data in the object hierarchy, with many of the attendant constraints, was represented as a schema. It couldn't be any harder, however.
|
