Perhaps I should clarify that in our approach we do not have just business services and non-business services...
We classify services into many different types - based for example on those business model subjects. So for example - Process Services are designed to provide operations that support one specific business process or sub-process. - Core Business Services provide operations that are responsible for maintaining records about the instances of particular set of business types. Several other types are explained in the meta model. Core Business Services is perhaps not an ideal name, and we are aware of that - but we have used it for so long... its the intention that counts, not the naming. Core Business Services can still make use of "data" services that may be provided by the underlying data sources if required. But we would impose rules for example, that the sales process can only use the Customer Core Business Service (CBS) for information about customers, and not the web service that just happens to be exposed by the current database used to store the customer records - as that is more implementation-dependent and may change - whereas the Customer CBS is architected to be more stable. For example we typically find that the Customer CBS in a large organization has to aggregate or broker information about customers across several data stores. Over time, behind that Customer CBS, those data stores will evolve, merge, depricate, new ones will appear... but the Customer CBS should remain the one source of the thruth about customers. (we find high demand for this in large organizations) Those data stores may themselves expose data services that are consumed by the Customer CBS, but they are designated as underlying or implementation-dependent services in our model, and should not be consumed by anything else - only via the Customer CBS. So for example, the sales process cannot consume the data service directly, it must go via the Customer CBS. Again, you will find these rules expressed in the documentation of the meta model. However, we expect, and find, that most customers wish to modify the meta model and the rules to some extent to meld with their current best practices. That's one of the prime things we help them with, establishing *their* reference architecture. We don't try to force our model and approach on them as the only way to do it. It's a starting point. Of course, if they don't have any existing approach and want to use our approach "as is", they are more than welcome. :-) lawrence --- In [email protected], Michael Poulin <m3pou...@...> wrote: > > It looks, Lawrence, we have conceptually different definition of the business > service and this scares me. > > To me a service becomes a business service not through an association but > through core of the service realising a Business service, Business function, > Business feature, or Business process. You may have a Business feature which > is not associated with any particular Business function at the moment but > tomorrow it may work for several different Business functions. I do not > accept (even for completeness or elegance purposes) a definition of, e.g., a > shovel as a financial tool only because a banker use it in his garden. > > I am also afraid that definition of a service via association may be very > confusing: the same service may be associated with different in their nature > things - what such service is? > > Please, please, rethink "We didn't think the meta model should be overly > draconian about what's mandatory, in order to accommodate different opinions > or development processes. " Naming things by what they are is not 'draconian' > but realistic, otherwise we would be doing politic, not technology. About > different opinions, why we so "politically correct" about this? What do you > think, really think about an opinion that considers a submarine as an > airplane (both of them can swim and fly)? We will not be able to move forward > if we cannot agree and common opinion on the fundamental things. > > If you want an example, here you are. Assume we have a business service than > calculates credit risk exposure. We also need some stored data to be > delivered for this calculation. This data is interpreted in business > semantics, i.e. it is the business data. If we use a Web Service to deliver > this data to our calculation engine, may we call this Web Service a business > service? Remember, business service is a product which has to be treated as a > product with its own business functionality and expected business Real World > Effect. Isn't mentioned Web Service is just an extension of database driver > (in 98%)? What business functionality it provides? - None. Data store is not > a business entity. Such Web Service may be considered and technical > infrastructural service and only in the case if database driver is considered > as a service. > > > > I've got the point of 'a canonical Business Type Model'. However, I stack at > the "model is then used to identify core business services that manage the > data for these business types. " To me, business services do not manage any > data, they manage functions that use data represented in accordance to the > business meta-data definition. Look, if a name of a database table filed is > 'price', it does not mean PRICE in all cases: some > applications/services/business logic can use the value in the 'price' field > as a COST, which is not exactly the same thing, or as a FEE... The meaning of > the field is assigned to it not in the database but in the meta-data of each > service. I would understand following model: a business service needs a > business data; the business service involves data service and represents its > business meta-data model; the data service knows how the meta-data of > particular business service is mapped on the physical data store schema and > which values > have to be returned. This allows me having a notion of, e.g., Client in > different services, where the Client is defined by different meta-models, for > example, one meta-model contains 3 fields and another meta-model contains 5 > field. The data service knows how 3- and 5-field models are mapped onto the > 'canonical Business Type Model', defined in the data store, and extracts > corresponding fields for both services using the same data source. >
