Ideas on Enterprise Information Systems Development

This blog is devoted to ideas on Enterprise Information Systems (EIS) development. It focuses on Lean Thinking, Agile Methods, and Free/Open Source Software, as means of improving EIS development and evolution, under a more practical than academical view. You may find here a lot of "thinking aloud" material, sometimes without scientific treatment... don't worry, this is a blog!
Every post is marked with at least one of Product or Process labels, meaning that they are related to execution techniques (programming and testing) or management techniques (planning and monitoring), respectively.

Wednesday, December 15, 2010

Enterprise Information Systems Patterns - Part II

The project in Github reached an initial implementation, which I separated in a branch named sketch, given that it is mixing configuration and instantiation. The master branch now is in accordance with the proposal, which I continue to discuss below.

Remember that the core idea is to use the concepts as Lego parts. This mean avoiding using subclasses in general, but masking the abstract concepts through configuration. After configuration, I need to implement specific functionalities for the concepts.  These functionalities will be implemented in two places:
a) At instances of concrete concepts, by defining specific behavior for
different contexts (paths).
b) At path objects, in the form of coordination code, which will make the path''s
movements collaborate to realize a business process.

In that way, we are going to have a two-phased development/customization process:
a) Configuration: defines descriptors, which represent concrete uses of the
abstract concepts. Descriptors list the types used to transform the abstract
concepts into concrete ones. Configuration is done through a Domain Specific
Language (DSL), having each concept a template text to be used for its
configuration. In the future, we expect to define a proper grammar for this DSL.
b) Implementation: uses descriptors to make the concrete concepts instantiable
and implement the specific code related to their concrete use. Each concept has
a callable object with a proper name, which is defined during the implementation
of user stories.

Thus, in a first moment, a domain specialist will configure concrete concepts
using the DSL. Configurations are reused during the implementation, when
user stories instantiate and define the specific behavior of the concrete

Right now, we have implemented Resource and Node, as well as the Maskable superclass, which will serve all concepts. I can say that the project is in the configuration phase yet, meaning that we haven't implemented any code for "using" the concepts in some business process.

Regarding the DSL used for configuration, we have to investigate its relation with our BLDD proposal. Remember that this proposal is used for implementing business processes, while the current DSL is used for configuring objects, which occurs before implementation of the processes. Maybe an execution DSL which uses the same terms used for configuration will grow from this investigation.


  1. Connection in ERP5 is named as Base Category, foe example, Causality, Predessessor, Sucessor ... are instances of Base Category.

    Base Category objects is a quite generic implementation which is used to describe (or give a name and generate accessors) relations between any object. Anyway, this is not a core concept, because it does not represent anything in real world.

    Core concepts (now days implemented as Core Interfaces) are used to represent Documents, which are used by end user and not to define internal classes (like a relation, or a property or an acessor).

    From code point of view, I recommend you use interfaces and possible zope.interface API, it clarifies the code documentation and design (Personal Opinion).


  2. Yes, I am aware of Base Categories.
    However, given this framework is didactic, I decided to: (1) use a more verbose name (2) use it to connect only movements and (3) make it a core concept.
    Also, as I said on the first post, if someone wants a really working framework in Python should use ERP5.

  3. What I really mean was the Connection was not a Business Class because a Connection has no equivalent document into the real world.

    It should be a but a auxiliar or implementation class and not a core concept.

  4. You're right... next commit I will change it!

  5. After agreeing with Rafael Monnerat's remarks, I took way the following part of the post (second paragraph):
    As I said before, the proposal is built on top of concepts borrowed from ERP5 Framework, sometimes interpreted in a different way. For instance, we introduce the concept of Connection, which is used to connect two movements, and can be used in one or more paths. There is a possibility of this concept become the Causality concept used in ERP5, but currently it is more generic than "just" cause and effect relationships. Therefore, we have:
    Concept 5: Connection
    It describes the relationship between two Movements, in the context of one or more paths.
    I decided to that to avoid confusion with the README at Github.