Business: the right description
We generally consider the business through its activities. This spontaneous approach of business reality ranks among the functionalist approaches. It entails a difficulty: we are considering the enterprise in its organizational aspect.
Yet, what we see in this aspect are actors, activities, processes, use-cases… All this stuff conveys organizational choices.
Therefore, representations of this aspect can hardly be shared and generalized.
When the purpose is convergence, simplification, agility… we need a more generic representation. We need to isolate the core business knowledge, using abstraction and expelling variability.
The right description of business must include a semantic model
We must recognize above this “pragmatic” (organizational) aspect a more abstract one, made of business objects, regardless of organizational habits and, of course, independent of technical choices. This aspect, we name it semantic. The semantic model is not only a sort of conceptual data model; it intends to express the business knowledge. We can use here an object oriented approach, which provides us with all the tools we need:
•class diagram to structure the concepts,
•state machines to catch the transformations and objects life cycles, etc.
Object oriented approach is connoted software but it lies upon philosophical works. That explains its ability to efficiently structure representations. It can really empower the formal expression of business knowledge.
Software: the optimal structure
When equipped with the two business representations – semantic and pragmatic – we can search for a better structure for the software solution.
If we conceive this structure directly in terms of technology and technical choices, we will get a representation which will be subjected to technical change. Also, there will be a risk of entering in excruciating details. Such a representation will make it impossible to drive the IS transformation on the long term.
For all these reasons, our frame introduces an intermediate aspect, between business and IT: the logical aspect. It is the ground where will be made the structural decisions regarding the software system.
For instance, SOA is a style for a logical architecture.
The logical aspect is linked with the previous aspects. The methodology states the derivation rules which help discovering the logical services.
The arrows from the logical package express dependencies and summarize dozens of derivation rules.
For more information, see the “Guide of logical aspect” (ref. PxM-40).
This approach complies with the Model Driven Architecture standard (MDA).
How to determine the proper structure of the IT system
Logical Architecture: the change
By applying this approach, we deeply change the structure of the system.
Indeed, the logical architect receives from the semantic model a list of object domains. Object domains are an alternative way for structuring a model, opposed to functional domains.
The “General Architecture Dossier” goes further into this discussion.
How the comprehensive approach radically changes the structure of IT systems
As a result of this philosophy, the modeling database set up by the initiative is structured this way:
1.A UML package named “Semantic aspect” is broken down into object domains and subdomains.
2.Another package is named “Pragmatic aspect” and shows the some of the functional domains needed for covering the business activity. At this stage, it mainly contains the identified use-cases.
3.The last package is about the “Logical aspect” and adopts the terminology for SOA.
In addition, the “scope” module compiles dictionaries, requirements and objectives from various sources. All together these materials make up the “thesaurus”.
NB: The General Architecture Dossier and the Thesaurus are additional deliverables of the initiative.
