Vintera Systems

Early post mentioned that expensive commercial product can be over-killed. Imagine MS Word, world most popular word processing tool. How many of you actually are using advance feature of MS Words? The same thing applies for enterprise commercial product. Typical commercial product has the following characteristics:

• try to accommodate many of requirements in one product
• more complex to setup and implement due to many variables in accommodating diverse requierments
• locked in to vendor architecture an must rely on them to fix bug
• cost you money for licenses

In some cases Open Source product is more appropriate due to simplicity and its focus on 20% of the most important requirements.

In some projects this is what happen:

… and if this is the case, you bet you should go with Open Source solution.

In the previous posts we discussed about the challenges in Enterprise Development. One of the solution we presented was leverage on Specialized Products. Specialized product is product which exist for just one single reason: solve specific problem.

Without Specialist product, this would be our architecture:

Inside the Application Box, we are likely find extremely crowded components, because there is no separation of concerns, it does everything under the sun: process logic, integration, database update, provide data to front end, etc.

In very simple application, this might work, but in Enterprise level application where you have huge requirements, and need for adaptability, this solution will be hard to manage.

The better approach will be to delegate some responsibilities to external modules or product called specialist, as shown bellow:

In above pictures, Enterprise Service Bus (ESB) will take on Integration role, so you do not have to write custom code for that. Business Process Management (BPM) will be at the core of your process, which there no custom coding whatsover.

At the end of the day, we will see productivity will improve, and quality of life gets better .

Unlike traditional development methodology, where Business Analyst must define the specification, and programmer design and code into workable final product from the specification, Process Driven Development lets Business Analyst or User itself working on the process model, and at single click, all the runtime artifacts are generated from the model and deployed into the system. Design and coding activities have been skipped ! Due to this simplified process, customers will get the following benefits:

• User will be able to participate because process is designed using graphical modeling tool –> removing communication gap and message loss between parties
• It is zero code approach, the model is directly deployed to runtime!
• Zero code means no programming error
• More declarative and explicit, easier to debug
• Agile methodology: shorter ‘code’–deploy–test cycle

Many have been said about issues in developing enterprise application, which I think best described in The Project Cartoon.

If we can summarize the problems, probably it would be:

• Requirements not properly explained & understood
• Communication gap across stages and group
• Time constraint & complexity force programmers to deliver sub quality product
• Actual requirements only discovered during UAT
• Over-killed product have cost customers more time, resources and money

The remedy could be found by reading between the above lines:

• Let user participate in business modeling and requirements
• Reduce complexity of application by leveraging on specialized product
• Use Open Source if possible, because Open Source is easier to implement and focus on 20% most important requirements

In the next post, I will share, how BPM can fit into solving these problems.