Inchoate Curmudgeon

The OMG Model Driven Architecture (MDA) explores the formal concept of transforming and instantiating models. “In the MDA, models are first-class artifacts, integrated into the development process through the chain of transformations from Platform Independent Model (PIM) through Platform Specific Model (PSM) to coded application.”

The “coded application” terminology is bit unfortunate, since the MDA concepts, due to the meta-model approach, could translate to infrastructure implementations: “realization artifacts” might be a better phrase. However, from the viewpoint that the implementation is realized entirely by configuration in emerging infrastructure implementations, such as VMware and Sun Dynamic Infrastructure (DI), the “coded application” wording may still apply.

This whole topic of modeling infrastructure architecture is somewhat messy, probably due in large part to the overwhelming preponderance of Java coders and architects in the architecture modeling domain. The concepts of architecture usually start and stop with software architectures, for Java what I call “inside the container thinking.”

I do know that I personally think the way that we enterprise and infrastructure architects “draw architectures” is completely unconstrained and rife with opportunities to misunderstand what we are “saying”. There has been more than you might think written about this, mostly concluding that the UML is the “best we have.”

However, very few people bother with specifying infrastructure architectures in UML, since using the best available diagram for viewing and manipulating the model, the Implementation Diagram, results in a very cluttered artifact for all but the most trivial cases. The other thing is that the none of the tooling I’ve used does a good job of constraining the implementation model to conform with the Class Diagram, which represents the meta-model for the implementation. As far as I know, this is the same for all modeling tools.

As a plain English example, I might model in a Class Diagram that specifies a server has a connection to two or more load balancers. This is fine for general constraints and specification, but when I draw an implementation model, there are no checks that my implementation actually specifies at least two load balancers. Not good.

The difference for us versus Java developers and architects is that they generally leap from Class Diagram to code. The Implementation Diagram is a representation of the state of a running application, modeling instances of the classes and their relationships. It’s not where they spend their cycles since they can just write the freaking code.

For infrastructure architects and infrastructure implementers, there is no such thing as an “infrastructure compiler”, that is a formal, unified, centralized human readable code that is transformed and realized as a gob of functioning infrastructure. Although some modern mechanisms go a long way, we remain mostly at the infrastructure corollary of wire-wrapping to implement code. We currently need implementation diagrams and other more concrete artifacts than Class Diagrams to tell various disciplines how to wrap their wires.

Going forward, we need a Platform Independent Model, a Platform Specific Model, and the “codes” that instantiate the model, all tied together. Modern provisioning systems centralize the control mechanisms.

The typical interest in CMDB with respect to provisioning is good, since at least has the capability to model the desired end-state. However, CMDB probably isn’t the right place to model the PIM, any more than it is the right place store Java Class Diagrams, unless we expand the notion of CMDB as it is currently used.

The current limitations with respect to implementing architectures with highly distributed configurations shift quite a bit with a combination of the “virtualization of everything” and the capabilties of modern provisioning systems, but we still lack the tools, and frankly the aggregate wherewithal I’m afraid, to make that final leap to “compile infrastructure specifications” into implementations. We have to stop looking at our feet. I imagine all the emerging provisioning and orchestration tools are intended to address this, but I can’t quite see it all tied together yet.

Some of the available MDA tooling might be worth a survey to see how they could be adapted to help realize infrastructure implementations. In particular, one tool I’m aware of, AndroMDA, is capable of accepting user-coded cartridges that can generate code fairly flexibly for different implementations. It’s used for Java, but I think may be agnostic enough for the task.

The vision is that we could generate XML and other text based configurations and specifications for an infrastructure implementation from UML models and diagrams.

Another possible approach is just modeling infrastructure meta-concepts and implementation concepts in a database and figuring out ways to transform them back and forth from PIM to PSM and XML. Some of the things that I and a colleague of mine are considering, that involves using RoR for in a provisioning scenario with DI and Solaris Provisioning System (SPS), would be a subset of this effort. The shortfall of course is visualization, or “diagramming”. We’d have models and transformations but still would lack a pretty “view”, and ways to manipulate the model visually, other than reports or web pages with text. Kinda boring. Perhaps this is just GUI sugar?

Trackback URI | Comments RSS