Over the past 20 years, we have been using various “Frameworks” to capture information about architectures and systems. Beginning perhaps with the Zachman Framework, which is still one of the most successful. The Zachman Framework is timeless for this reason: it forced us to think about the standard interrogatives (Who, What, When, Why, Where, and How) and different perspectives (Executive, Business Management, Architect, Engineer, and Technician) as applied to the enterprise. The idea was to build models in each area, starting with simple lists and working into detailed models of the systems at a component level.
Other frameworks followed, included the DoD Architecture Framework (DoDAF – which came from the C4ISR Architecture Framework), the Ministry of Defence Architecture Framework (MODAF), the NATO Architecture Framework, and many others. All these Frameworks were built on the idea that the information could be easily “binned” into these boxes, but as we know many of the models in these Frameworks included maps between different data elements, such as the CV-6 from DoDAF that maps Capabilities to Operational Activities. Recently, the Object Management Group (OMG) and others have been trying to push out a Unified Architecture Framework (UAF) that combines the models from many of these other frameworks into a single, very large framework. OMG is also responsible for developing the Unified Modeling Language (UML), Systems Modeling Language (SysML), and the Unified Profile for DoDAF and MODAF (UPDM).
All of these framework and languages are ways to capture information about a system or enterprise and show them as a set of data, often as a picture or model with two or more pieces of information in the model. An example is the DoDAF OV-5a, which is a functional hierarchy of Operational Activities, which only contains a single entity class and the decomposition relationship between those entities. Another example is the OV-5b, which shows the Operational Activities and the “Resource Flows” (which many of us recognize as inputs and outputs to/from the Operational Activities) between them. Thus, we have now two entity classes and the associated relationships between them. Obviously, the information in the CV-6, OV-5a, and OV-5b overlap in that the same Operational Activities need to show up in each of these models. But how many of these different models would we need to complete describe a system or enterprise?
An alternative way to capture information is to use an ontology (and the DoDAF 2.02 is based on a rather large ontology – the DoDAF MetaModel 2.0 or DM2) that captures the information in a finite number of classes (or bins) and a set of relationships between these classes. The classes and relationships can have attributes associated with them, which are also pieces of information. At the ontology level, all we see is a mass of data, so most of us want to see the pictures, and most architects and system engineers seem to prefer this approach.
An alternative to the DM2 is the Lifecycle Modeling Language (LML), which contains both an ontology and a set of diagrams to capture the necessary technical and program information associated with a project. This language uses an ontology that appears simpler than the DM2, but actually hides the complexity through the large number of relationships between entities and the fact that the relationships can have attributes associated with them. LML purports to be the 80% solution to the ontology, meaning that you may decide to extend it to meet your specific needs. But let’s just stick with it. LML has 20 classes of entities, and each entity class has a number of relationships associated with it (over 40 in total). So, if we ignore the attributes, we have over 20(20-1)/2=190 combinations of information possible. Does that mean I need 190 or more diagrams to visualize all this information, perhaps – it could be less, but it could be more. Can we really have that many different diagrams to represent this information, which is what a Framework would require? And of course, if we add in all the attributes to both the classes and relationships, then we are trying to display a lot more information than this.
So, Frameworks are a useful starting point, which is how John Zachman uses his framework, and it may be enough for enterprise architecture, but it’s not a panacea for all of systems engineering problems. Sooner or later as we want to decompose the system to a level we can determine what to buy or build, as well as manage these kinds of projects, you likely will need to use a more robust approach. LML and this kind of ontology makes it much easier to capture, manage, and visualize the information. See for yourself. Go to www.innoslate.com and try out the tool that uses LML for free. Explore the Schema Editor to see the entire ontology. Play with the “Getting Started” panel examples. I think once you do you will find this approach works much better than the Frameworks. In addition, Innoslate has a “DoDAF Dashboard” that enables you to create DoDAF models directly from the dashboard, so if that’s what you are more familiar with, you will find it the easiest to get started. Notice that may of the other projects are automatically populated with the information from the other models. That’s because Innoslate reuses that information to automatically create the other views!