Defining and Handling Functional Processes

My last blog entry gave a broad overview on what I am currently after in my sparetime. One core question that plagues me for quite a while now, is on how to define functional processes within the application: incorporate the process definition into the messages or describe it explicitly within the application architecture?

Application Architecture

Describing functional processes and the depending data flow explicitly within the application architecture has two major benefits

• Known structure and data flow eases the pain of extending the application according to customer needs
• Predictable behavior due to known structure and data flow eases the pain of monitoring and managing the application in operation mode

Messages

Incorporating the functional process description into the messages being passed around has one major benefit

• Flexibility of application reconfiguration enables the application management to quickly react to changing requirements

Hence, the main question - as always in computer science - is to answer wether to have a known structure which is easy to monitor and maintain but difficult to extend or to have a highly flexible application which allows the product owner to quickly respond to customer requirements.

In a generic approach, achieving both targets is difficult (or near to impossible), but as I know about the context the application will be deployed within, there is a chance to nail down some basic structural aspects which ease the pains of the operations and support team while maintaining maximum flexibility within that borders.

Therefore the application is structured into so-called domains which handle specific topics, like orders, customers, payments or recommendations. These domains are pre-defined and receive messages dedicated to their specific topic. Within a domain, eg. order, the messages tell the processing components on how to handle them. This allows the product manager to offer max. flexibility to the customer when it comes to the specification of a certain behavior within a domain. This approach is outlined in the iServices wiki.

Finally has to be said, that the messages floating around in the system as well as the provided domain interfaces follow a functional approach instead of a technical one. This particularly refers to the way how these artifacts are designed: they try to map the functional context instead of its technical implementation.

The next blog entry will discuss a concrete application context as I have been too vague on that topic so far :-)