Archive for March, 2010

Guidance for the responsible enterprise

Add a comment

The Praxeme Institute has published a document which summarizes its philosophy:

Enterprise Transformation Manifesto

This document is aimed at all the different functions of the enterprise (in the broadest meaning that we give to this term), in particular:

  • executive management, who will find within, a unified discourse and list of principles to guide their transformation programs;
  • communication or marketing directors, for whom signing the manifesto will be seen as a way of affirming certain values of their enterprise;
  • IT directors and more specifically within the IT department, the transversal functions who will appreciate the repositioning of enterprise architecture.

The manifesto will also be of interest to the academic world, calling for of a multidisciplinary approach, around which teaching content can be organized (please refer, in particular, to chapter 7).

Two documents are available to date:

  • the manifesto itself, a list of principles which guide enterprise transformation;
  • the comment on the document made by the Praxeme Institute.

For the enterprises that relate to and see themselves in this text, it offers an opportunity to communicate and affirm their values.

Details regarding the terms and conditions of the endeavor can be found at the end of the manifesto.

See: http://www.enterprisetransformationmanifesto.org

CEISAR & Praxeme Common Glossary

Add a comment

CEISAR (Center of Excellence in Enterprise Architecture) and the Praxeme Institute joined forces and published a common glossary with a selection of terms in the field of enterprise transformation.

By converging our vocabularies, we intend to ease the communication with business and to facilitate training for enterprise architects and other transformation agents.

http://wiki.praxeme.info/uploads/Thesaurus/THS02-CeisarPraxemeGlossary.pdf

What’s new in Enterprise Architecture

Add a comment

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

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

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

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.