Content framework

Add a comment

“Content framework” is the expression used in TOGAF 9. It is simpler than “methodological framework” and I will adopt it, even though one can always argue what content it is about. For us, it is clearly the content we have to deal with through architecture, that is the content of the Enterprise System, so the enterprise itself.

A content framework identifies the big classes of objects we have to deal with. It comprises the selected categories of representation. Of course, a framework is not limited to its graphical expression. It is not enough to display a slide with a few boxes and in-the-hype labels. We have to thoroughly articulate the notions and link all types of elements together. One would deride this endeavor as a theoretical exercise and a waste of time. Certainly, it is theory, the sort of theory that prepares and guides action – the only way of preventing confusion and waste of resources on the scale of the enterprise. In the absence of such an endeavor, not only these resources are wasted, but also innovation or improvement opportunities are missed and the transformation disciplines are loosing their legitimacy and their power of imagination.

NB: Transformation disciplines include strategy, organization, architecture, design… on every aspect of the enterprise.

Rules that a content framework obeys

The rules below help to make clear the meaning of the framework and its implications. They also prepare the deployment of the framework in terms of methods and tools.

1. The framework embraces every aspect of the enterprise. To put it in other terms, it includes every type of information to be collected and decision to be made in order to transform the enterprise and its systems.
2. Every type of element has a single place inside the framework.
3. The framework puts these elements into order, so as to ease the transformation chain and to clarify roles and responsibilities.
4. The framework is not limited to a static view: it specifies the dependencies between its elements and explains how the elements relate to each other.
5. The framework is based upon a metamodel that contains the definitions and relations of the types of elements.


The content framework is about the system itself, as opposed to its development and management.

“System” designates the enterprise through all its aspects. Enterprise Architecture is about this Enterprise System. It encompasses every aspect, from strategy to deployment. Its added value plays precisely on the ability to link together the choices and decisions related to all aspects of this complex reality.

The comprehensive approach to the Enterprise System

Enterprise Architecture is the discipline that analyzes the strategy and determines the main decisions for transforming the Enterprise System. As such, it has to base its approach on a framework that is broad enough to encompass every aspect of the enterprise.


The starting point of the approach to the Enterprise System is the corporate strategy. Broadly speaking, the methodology must prepare us for collecting any considerations that answer the question “Why?”, including statements that cannot necessarily be formalized as models. This includes values, objectives and orientations of all sorts, business requirements, vocabulary… This material will be referred to each time a choice has to be justified.

Thus, Enterprise Architecture endeavour starts with a “political aspect”. The term “political” is understood in its original meaning of something related to the City or community.

Why do  we have to separate the core business knowledge from the business activity?

When it comes to describing the business of an enterprise, we first fall and spontaneously perceive activities. Processes, use cases (elementary working situations), business capabilities… are ways of identifying and documenting the business activities. We need these descriptions and they pertain to Business Architecture.

Nevertheless, as these descriptions result from the same “functionalist” culture, they entail limitations that may hinder our efforts toward convergence and agility:

  • Most of the time, a process description or a use case embed organizational assumption and work habits, making them difficult to be shared. Indeed, these organizational contents are likely to be local and unstable.
  • The breakdown structure of the business activity cannot avoid redundancy.

This is the reason why we need another representation of the business, not to replace the former ones but to complement them. This more abstract representation focuses on the core business knowledge, the semantics – regardless of the multifarious ways of enacting this knowledge.

This imposes a significant constraint on the methodological framework: it ought to distinguish a semantic aspect (the core business knowledge) and the pragmatic aspect (the business activity). This difference takes place inside the Business Architecture.

To complement the business representation

The semantic aspect is about the “What?” of the enterprise (what objects does it create or manipulate?). The pragmatic aspect is about “Who?” and “Who does what?” (the players, their actions…). We can also see the organization as an answer to the question “How does the enterprise deals with the objects?”. Another question that may have significant implications is “Where?”. In order to provide a holistic and exhaustive view of the enterprise, the methodology introduces a “geographic aspect”. This is the proper place to discuss location of resources and activities, mobility, outsourcing, round-the-clock distribution…).

How to build a shared and stable view of the information systems?

As far as the IT system is concerned, the challenges include:

  • designing an optimal structure that can be implemented on the long term;
  • making the description stable enough, so as to accompany the long-term transformation;
  • providing the companies or subsidiaries of the group with a description that makes sense for them, despite the diversity of technical environments.

The response of software engineering has been coined with the phrase “logical aspect”. A logical model describes an IT system, regardless of technical choices. At least, it is relatively independent from the technical target. The advantages of this approach are:

  • the logical architecture is a permanent description, which is in use through the transformation;
  • technically speaking, it is generic enough so that the companies can share a common view of the system, even at a detailed level.

Moreover, the logical aspect is the appropriate level of abstraction for the architects to cope with all concerns and high level requirements imposed on the system. First, they have to choose the style of the system they want to build. Here, SOA is an obvious candidate. Then, they adopt a metaphor that will help them to isolate and arrange the building blocks.

Can we contribute to improve productivity?

Once a logical specification is delivered, to develop software means to translate this specification into technical terms. In an MDA (model driven architecture) spirit, this translation can be partly automated.
In the case of a package solution, integration takes advantage of the logical model. Indeed, the pivot language ensuring the smooth communication throughout the system is derived from the logical model. With the logical architecture in mind, the architects are able to alleviate the impact of package integration.

How to clarify responsibilities between development and production?

The transformation chain ends up with the physical aspect. It can be defined as the projection of the software on the hardware. In order to better clarify the responsibilities, the framework distinguishes:

  • hardware – the infrastructure, strictly speaking;
  • the physical aspect – the infrastructure with its software content.

Conclusion: benefits from a comprehensive approach

As a conclusion, the content framework proposes:

  • an external and simple view with the three categories of architectures, corresponding to three communities or cognitive universes: business architecture, information architecture, infrastructure (see the framework-table);
  • a more detailed and holistic approach to the system, through the notion of aspect.

Praxeme proposes the Enterprise System Topology as a framework which complies with the above requirements. Its metamodel reflects this structure and approach. It clarifies the terminology and is a useful starting point for guidelines as well as for tooling.
As far as method frameworks are concerned, a critical point is how the identified aspects relate one to the other. The Topology of the System Enterprise answers this question.

This entry is filed under foundation. And tagged with , , , , , , , . You can follow any responses to this entry through RSS 2.0. You can leave a response, or trackback from your own site.

  1. No Comments

Please leave these two fields as-is: