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.

Friday, February 25, 2011

The obvious, but yet ill applied, relation of Open Source and Auditability

In this post I comment two blog entries related to the use of open source software for auditing purposes in the banking area.


In the first one, Open Source Banking for Financial Stability, Jean Paul Smets  affirms that some serious problems presented by financial products not compliant to the regulations are caused by software systems which "are not subject to any kind of regulatory control and, therefore, may be used to circumvent regulations either through functional inconsistencies or through temporal inconsistencies." Therefore, he defends the idea of using a reference open source software, without getting rid of the software in which banks invested for decades. This reference, besides offering an auditable software representation of the regulations rules, would be used "to provide to regulation authorities a very accurate picture of [banks] activity, much more precise than what accounting can provide." - by importing the data handled by existing bank's software.


In the second post, Python Could Become the Language of Finance, Jonathan Allen informs that SEC is proposing that Asset Backed Securities should include a “program that gives effect to the flow of funds, or “waterfall,” provisions of the transaction.” Waterfall in this case "refers to how some bonds are broken into levels, where those who bought into the higher level must be paid off before the lower level sees any money." The interesting part is that SEC is planning to mandate Python as the language for building this reporting tool, because it is open source, uses a standalone interpreter, and is supported by many platforms, including proprietary software such as .NET.

Although the first post is an opinion, the second isn't, and both present good arguments to motivate regulatory organs to use more open source for auditing tasks in the financial area, and, why not say, in other areas. The use of open source reference softwares would (i) help people compare their implementations of regulatory rules with a standard implementation, (ii) provide cheaper software that could be customized for specific adopters, while following the regulation, (iii) provide automated tools for regulatory agencies to audit data. In that way, maybe the number of financial scandals could be reduced, as well as regulatory work in other areas, such as environment, could be simplified and streamlined.

Sunday, February 13, 2011

Enterprise Information Systems Patterns - Part III

After my last post, the code in Github changed many times, since I was experimenting with both the basic concepts and the testing stack we are using. We decided not to write features (BDD's Given-When-Then constructs) for the configuration of Resources, Nodes, and Movements, since it would be overkill (as you can see in the sketch branch, from December 12, 2010): by reading the specs anyone can understand and check the functioning of configuration.

The comments below are based on the last implementation (January 09, 2011), which doesn't implement Path nor the parsers for the configurators. We are considering writing features for Path configurations, because Paths represent business processes, and therefore, it make sense to have high level descriptions of requirements.

Currently, the proposal is based on two base classes, from which all others derive. The first one, Configurable (previously known as Maskable), is the base for building the abstract concepts, and the second one, Configurator, is used for providing a "friend" class for each concept which is responsible for managing the configuration of the concepts' instances.

Besides the basic attributes, Configurable abstract class holds a "To Do" method, which is simply a placeholder to remember that a method for doing "basic things" with instances should be implemented by subclasses. Configurators on the other hand must be able to parse, persist, and retrieve configurations to be applied to concept's instances. They are multitons, in other words, for a given key, composed by configuration's mask and version attributes, only one configurator object may exist. Therefore, every concept class, such as Movement, has a configurator class, such as Movement_Configurator.

Configurations supply the following attributes for instances (spec files provide complete configuration examples):
-Mask:  defines a specific type for the instance. Example: payment (a payment movement).
-Version: holds the version of the mask, multiple versions can be in use at the same moment. Example: monthly (monthly payment).
-Category: associates a category to a specific concept. Example: financial (monthly payment is a movement of category financial).
-Description: provides a description for the key mask+version. Example: ' a monthly payment from a organization to a person'. Note that, in this example, organization and person can also be categories.

Right now the implementation is in a very simple state, the next step is to implement Path, which is expected to reveal more requirements for making this framework more usable. For testing, we are going to use some real-world workflow implemented in ERP5, applying the mappings presented in the technical report "Mapping Business Process Modeling constructs to Behavior Driven Development Ubiquitous Language" to describe the workflow using Given-When-Then.