My name is Atzmon Hen-tov and I am the Chief Software Architect at Pontis (www.pontis.com). I would like to share with you my experience with AOM and the business benefits Pontis gains from using AOM. Pontis was lately nominated as the fastest growing company in the Telecommunication sector in Europe (see Deloitte Technology Fast 500 EMEA).
First, some background about Pontis. Pontis provides Targeted Marketing in the Telecommunications and Cable-TV domains. Targeted Marketing means that end-users get only offers and promotions that are relevant to them and they get them at the right time. For example, just before you load money to your pre-paid phone, we’ll offer you to extend the amount and get a special bonus (e.g., 100 free short messages). We deploy our systems at the customer premises and typically integrate with 10-15 customer systems. Each customer has a distinct set of systems we need to integrate with and a lot of other differences from other customers.
In Pontis, we follow the rule – “if it changes a lot, move it to the GUI”. The motivation behind this rule is to reduce changes in Java/Scripting/Technical code and allow our system users to define, configure, tune and operate the system without needing to get help from technical people. Getting help from technical people often means a new, full blown software delivery. Although many companies practice Continuous-Delivery these days (See this book for a great reading on the subject), it is better to avoid code changes and the consequent risks and project overheads.
We discovered that “what changes a lot” is the customer domain model. That is, each customer has different attributes for the subscriber (“Subscriber” is “customer” in Telco slang), different types of price-plans, and different structure of events (e.g., for voice-call, money charge, short-message send). At first, we developed the generic part of the system (the part that is used by all customers) in Java and then defined the customer specific parts in DSLs (Domain Specific Languages) from which we generated Java code. When the model grew to more than 1000 classes, this proved to be a poor choice. After every change in a DSL you had to wait 20+ minutes for code-generation, compilation, packaging, deployment, etc. In other words, the Edit-Execute Cycle became really bad.
Enter AOM.
AOM is an interpretive approach; the model (meta-data) is interpreted and executed at runtime. No code generation, no more “let’s make a coffee or two and come back to see if the build is done”. This doesn’t come out easily. You need to write sophisticated code that accounts for all the variability you give the end-users in defining the domain model. Luckily the Adaptive Object Model site provides you with handful of patterns to do just that.
We started with a few variability points, that is, model classes that can be extended in the AOM GUI and added more as needs were identified. Today we have a rich AOM application with 50+ variability points that allow non developers to fully customize the application model for each new customer.
AOM is so critical to our business model that we have an official AOM Engineer role in Pontis whose responsibilities are to customize the generic product and to maintain the customer’s AOM metadata in configuration management. By having non-developer AOM engineers we gain better communication between the stakeholders; AOM engineers are not occupied with technical stuff (Java, Patterns, Performance, third-party libraries, etc.) and talk the language of the business. But since they are the actual implementer they close things up with the developers to the very last detail (e.g. when a new generic feature is required to implement a business use-case).
Looking back at the last year or so, I can confidently say that AOM made a big difference in Pontis. A difference in the way we work, in the way we deliver software, and in the way we think; most notably in the frequency and quality of our deliveries. Whenever a new requirement arises, the first thing we do is try to figure out how it can be satisfied by AOM-only changes. If it’s indeed possible (and an impressive amount of times it is; I actually have some numbers on this, but it’s a story for another day), the AOM engineer can implement the change via the GUI and spare the cycle of Java delivery.
We’re still learning as we go. There are many challenges, not all of them technical – in particular, we haven’t worked out the kinks of merging changes between different environments. I invite you to learn together with us – come back here for more!
