Last week Joe Yoder and I presented, “When Should You Consider Meta-Architectures?” at QCon San Francisco. We were speaking in the Design at Scale track organized by Michael Feathers. Michael didn’t give us a compelling introduction (in daily overview he said we’d be talking about some older but still useful technologies). So I was pleasantly surprised when the room was nearly full. I’m guessing that Martin Fowler’s earlier keynote where 1/3 was on DSLs, might’ve been the reason some curious folks attended our talk. Or maybe it was my tweet/retort to Michael: @mfeathers Meta-architectures aren’t “old” technology…they’re “proven” technology…that is showing up in many new places….
Or maybe it is because QCon is a conference where people expect to soak up new technologies, design and architectural ideas, and programming languages. QCon is techno-geek mecca.
In our one hour talk we didn’t have a time to describe details of the different meta-architecture styles. We started out by contrasting two ways that people typical evolve working systems, the traditional programmer-centric way with conventional software architectures, and the end-user/domain-expert enabled way that was possible with meta-data based architectures. The primary difference between these two architecture approaches is that the goal of meta-data driven systems is often to support domain experts who are non-programmers making changes to a domain model using tools that support them in making domain model and rule changes (instead of by programmers who are writing/revising their programs).
We then gave a whirlwind overview meta-data representation techniques and presented the core elements of the adaptive object-model style—the particular meta-architecture approach that builds on good object design skills and well-known patterns.
The last half of our talk presented case studies of production systems built meta-data techniques and primarily using the adaptive object-model architecture style in the telephony, insurance, medical, manufacturing, and archeological artifact tracking.
What shouldn’t be surprising (but often is to those who don’t know the leverage you can get \avoiding writing bulky, dumb code) is that these systems are usually built by a small team of very good developers/designers (on the order of 101 people). But these designers are capable of building frameworks, infrastructure and tools, and have a good design skills, design pattern knowledge, and the ability to fathom domain models. For example, Pontis reduced the deployment of a new custom installation of their telephony marketing system from 1 year per installation to 1 month. They also wrote an impressive tool that domain engineers (not programmers) to modify business rules and domain objects without developer intervention.
Not every systems needs to give domain experts the ability to directly make changes to their domain models and business rules, but meta-data based architectures (and in particular, adaptive object model systems) can provide some amazing leverage.
