OPE AG Mission
The Mission Statement of OPE AG - as it still stands today - was first written in Winter 2008 as I was spending my sabbatical leave in Davos, Switzerland. I had finally time to stop and reflect my 10 years in the IT field. This possibility of thinking out-of-the-box resulted in a list of almost dozen different business ideas for the next Big Thing that I could work with.
One of these ideas - and the one that eventually became the Idea that I started developing further - formulated the problem statement as follows:
There is something Fundamentally Wrong in how Business Software Applications are developed Today.
Our Mission is to Fix This.
The idea starts from my observations of about ten years in the field of Enterprise Application Development: creating custom software applications for larger companies.
The fact that everyone recognizes is that the quality of software development is not good enough. In my opinion, the problem starts from the process, which typically goes something like this:
- Business logic is defined in a Word document (Requirement Specification, ”Specs”) by a consultant or internal project managers.
- People understanding the Business check* that the "Specs" corresponds to real-life business needs
- Programmer Reads* the "Specs" and creates code to Implement* the logic
- Bugs are found in testing or when the application is taken to production
- Bugs are fixed and the corresponding changes* are made to the specs
- Later the business process changes and these changes are reflected* to the application: Specs is updated*
- Years later the application needs to be changed - e.g. ported to a new platform - and the business logic is* available in the specs
Everyone who has been involved in this process knows how easy and common it is to bypass any of the points marked with asterisk (*). And any bypassing will result to either Business Process, Specification or the Resulting Software being out-of-sync. This results to problems at least with the last point, but usually even in the earlier stages of the software lifecycle.
What I am suggesting is that we need a new kind of process and a set of tools that allow separating the real Business Logic from infrastructure code that is created by the programmers. Preferably, this business logic should be described in a way that...
- Code could be generated directly from the specification: The first time as well as when changes are made later.
- Domain experts - the business users, who understand the business logic - could read and potentially even write some of this machine-readable specification.
- Business Logic should be the real business logic and not the infrastructure code such as parsing XML files, checking for nulls, authenticating etc.
As for what is happening in the industry around, there is some very interesting work going on in the field of Domain-Driven Design (DDD), Domain Specific Languages (DSL) including the "Oslo" project from Microsoft and Aspect Oriented Programming (AOP). The most convincing critics are saying that all this was already tried with the case tools and there is a fundamental mismatch between the business logic and the code describing the business logic much the same way as the "Object-relational impedance mismatch" between object code and databases. Well... I don't believe them: I think we should go back to the idea of case-tools with a little bit different angle and using the improved technologies that we have today.
Finally, the planned contribution of OPE AG to all this is:
The target is to introduce in 2010-2011 timeframe tooling and process descriptions solving some aspects of this problem or solving this problem in certain business domains. In the meantime, OPE AG is also doing project work - see the Services section - partly to finance the product development and partly to use real projects as a platform to reflect the direction of the product development: After all, Good software can be produced with the current processes; it is just not as common as it should be!
Last updated by Olli Perttilä on 29.5.2009