Open Business Concepts (posted by Fabien Villard)
One Task in Technical Architect’s Task List
Amongst tasks devoted to the technical architect lies the choice of external solutions. This is a long process that involves the choice of suppliers, the creation of an evaluation grid, RFPs, work with suppliers relation teams, POCs and other evaluation prototypes, synthesis of all information and then presentation of all results to the team responsible for the final choice. During this process the architect and experts meet the suppliers to have demos and question sessions to dig into the internals of the proposed products.
Persistence Models
One of the points of such an information gathering process is to ensure that the physical model for persistence is compliant with the context and constraints of the IS the product will be included in. This is important in physical layer but also in logical layer: are the concepts correct in regards of the IS needs? To answer this question the simplest way is to get the logical and physical models from the supplier. But they are never given. Instead questions about concepts are answered by showing how the GUI manages them. And so I find myself trying to rebuilt in my mind the logical model of the product the supplier presents to me. And all other architects and experts in the meeting are doing the same job. Don’t hope to end with the same model that way. Each time the debriefing session shows that we have understood things differently and that we don’t have assurances the concepts are really those we need.
Not to say that if they are not really what we’d hope there is nothing to do: the product forces its own concepts inside the IS.
This is “Concept Capture”
Concepts are not what we need but what suppliers have decided we need. This is precisely the same behavior as proprietary formats for files: once we have stored our information in a provider solution built with closed formats, we’re tied. Because we don’t have rights to “reverse engineer” the formats (our mileage may vary from country to country, but still) we have to consider we’re no more owner of our data. This is the same for concepts: once we have bought the solution and the proposed concepts, we are tied to them. No matter what good analysis we may do, it will be very difficult if possible at all to include the results in the product.
It is also done by internal development teams when they are implicitly left with the semantic and logical models to do themselves. They capture concepts in what they have understood from the business and subsequent evolutions are difficult or even impossible.
What is the solution to Concept Capture issue?
Praxeme. Surprise, surprise :-)…
By analyzing sooner the semantic and logical needs, Praxeme ensures that concepts implemented are those needed by the business. Obviously this works great for internal projects and this is the core usage of Praxeme. But it may also help software suppliers: they may either (or both :-) use Praxeme to create there products and they may create products that can be included in a composite IS while respecting Praxeme. This would be great.
…and Open Business Concepts
Pre-built models (Currently a Praxeme initiative from Pierre Bonnet and Dominique Vauquier) are part of the answer: by using and participating in pre-built models internal teams and software suppliers are able to ensure that the concepts they include in there software are the good ones and offer the richness needed to build business centric IS.