AOM Application

Hello! Since this is my first post, let me introduce myself. My name is Reza Razavi. I’m currently heading the research and innovation efforts of AAS that I co-founded in 2007. I’ve been involved in developing industrial AOMs since 1993. In particular, I implemented a software system for calibrating bore gauges that allows domain experts defining new gage types, their attributes and calibration procedure themselves, and make them readily (without compilation) available for use by calibration operators. Calibration procedures are defined as a composition of atomic measurement and calculation services. This allowed our customer to reduce the cost of their maintenance by at least a factor of ten, while being able to easily adapt their gauge calibration procedures to specific customer needs. Then, I switched to academic research and have been collaborating with Ralph Johnson and Joe Yoder since the early days they initiated research on AOMs.

Now, as an early adopter of AOMs for both industrial and academic software projects, I would like to react to the Rebecca’s tweet/retort to Michael Feathers (@mfeathers) where she stresses “Meta-architectures aren’t “old” technology…they’re “proven” technology…”.

For example, here at AAS we have developed a novel software platform that allows developing web-enabled AOMs by reuse and extension. We are currently working on large scale development of such AOMs to address the need for individualized and adaptive web-based solutions to populations like the elderly. The elderly need customized care. Imagine that each person had a computer in the cloud that watched over him or her. We propose adaptive web servers to empower end-users and their communities, like caregivers, to give themselves an active part in the design and customization of their web-based services. So, once more, meta-architectures and AOMs have proven powerful in supporting business applications with highly-demanding dynamic adaptivity requirements.

It should also be emphasized that with AAS-Platform, AOMs figure today at the very heart of a unique solution to the latest approaches to service delivery and business development as explained in The Power of Pull , where end-users and their communities are perceived themselves as valuable actors of service innovation and personalization, and empowered to assume their responsibilities.

Furthermore, as it is emphasized by David Siegel in his Open Letters to Apple Board Members, and Sergey Brin, Larry Page, and Eric Schmidt (Google), “the future of media, entertainment, productivity, and business tools is in the cloud”. However, “the power shift of the 21st century is not to use the cloud to re-create our desktop tools but to build data-driven ecosystems that take us far beyond what we could have done without the power of the cloud.”. David Siegel, urges that to build “data-driven ecosystems”, and to “empower people to collect and use their own data for themselves” (in alignment with the “pull” model), web technologies shall start by “getting the data out of the apps”.

AAS-Platform has been designed and implemented with these requirements and service delivery model as primary considerations. It enables the large-scale development of websites like Yahoo! Pipes by regular application developers, where the active and collaborative participation of end-users (even non-technical people) as partners in the service innovation and delivery processes is supported by design.

Specifically, AAS-Platform allows Web-based AOMs that maintain an “open user activity flow model”, and allow end-users to interact with and modify that model (which is otherwise “hard-coded” by programmers). Every piece of meta-data and data that end-users care about may be accessed via dedicated atomic services and reused when assembling new services, thereby contributing to the concept of “data-driven ecosystems”. Read more …


AOM – A Practitioner Report

by atzmon on December 28, 2010 · 0 comments

My name is Atzmon Hen-tov and I am the Chief Software Architect at Pontis (  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!