Archive for November, 2010

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.

Architecture rules

Add a comment

An attempt to articulate basic rules that apply to any kind of architecture.

The objective is to increase awareness and quality, as far as architecture is concerned.

Rules are expressed below, at level 3 of title. Text includes comments (normal paragraphs).

1.1. Quality of representation

1.1.1 An architecture diagram describes a single aspect

Avoid mixing elements form different nature.

According to the “separation of concerns” principle.

Only views can mix several types of things, for a specified need for communication.

1.1.2 Every element of an architecture diagram is unambiguous

Given the aspect the diagram deals with, the nature of all elements of the diagram must comply with the metamodel of this aspect.

The list of elements includes the nodes and the connections.

1.1.3 The existing or necessary connections between the elements are clear

A diagram which just identifies the nodes of the architecture without considering their connections is not sufficient.

Architecture is precisely about the way things are linked together.

1.2. Quality of an architecture

1.2.1 Architecture aims at expelling redundancy

The best architecture is one that designs a system without redundancy.

This statement applies also to the business aspects.

Sometimes, decisions are made to consciously add redundancy in the system. In such cases, the rationale has to be expressed. It can be for performance or security reasons.

1.2.2 Architecture aims at reducing coupling

The optimal architecture is the one that minimizes coupling, while delivering the proper services.

The analysis of coupling encompasses:

  • A quality perspective: numbers and places of dependencies, building up a network that defines the architecture qualitatively.
  • A quantity perspective: frequency and volume of the interactions that occur at the interfaces (mathematically speaking, architecture is a valued graph).

NB: there is a balance to be found between redundancy and coupling, whatever the aspect analyzed.

1.3. Continuity

1.3.1 Any architecture representation is continued through more detailed representations or models

1.3.2 For a given aspect, architecture (the overall view) and design (the detailed view) adopt the same notation

That implies that they rely on the same metamodel (which is more important).

1.3.3 The detailed design obeys the high-level decisions and principles that have been stated through the architecture

Relation between enterprise architecture and solution architecture

This statement implies a certain discipline to be imposed to the projects. Related to EAM (Enterprise Architecture Management)

1.4. Justification

1.4.1 All decisions of architecture have to be documented and justified

1.5. Traceability

1.5.1 All decisions and elements imposed by architecture of a given aspect have to refer back to elements situated in antecedent aspects

1.6. Quantification

1.6.1 Whatever its aspect, level or scope, the documentation of a system includes quantitative information

Without this information, the decision-making comes to be difficult or hazardous.

Some examples:

  • Semantic aspect: number of instances for a given concept or business objects, frequency of change…
  • Logical aspect: volumes of flows through the system as it is designed by the logical architecture graph.
  • Physical aspect: consequences for the data storage, for the networks and the machines.

1.7. Capitalization

More about EAM than architecture description.

1.7.1 The architecture description needs to be progressively consolidated

1.7.2 Every significant project delivers models compliant with the target architecture

1.7.3 These models are poured into a central repository in order to enrich the architectural vision and to get available for he community