1. By defining “derived types” in the data management architecture, and allowing these derived types to be used wherever a metamodel defined static type can be used. A derived type is defined by a query over the elements’ attributes and relationships (recursively if needed), and the scope of the query is generally defined by the type(s) that the derived type specialises.
2. By decoupling the visual representation of the element from the data, and introduce visualization rules or macros that flexibly map data items to visual characteristics, preferably in a user-defined way.

In the example of message flows and sequence flows, the linestyle and arrowstyle of the symbols should be decided by whether or not the link crosses a pool boundary. If flexible visualization is combined with derived types, you would of course link the visual characteristics to the derived type. This solution should be dynamic, so that if you e.g. move a task from one pool to another, the associated flows change visualization (and membership in derived types) automatically.

I still think that editors however should optionally show some visual difference between some types even though they may be treated the same behind the scenes as this has an advantage for readability for users (a point which I think may be related to your idea of templates).

Eg: Message flows and sequence flows have efficient perceptual processing difference which enables the user to easily distinguish between the 2 without having to use the cognitive part of their brain. In fact I allow sequence flows to be dragged across pools and after the user has finished I’ll automatically convert it into a message flow.

Around the time when this post was written we were told by systems engineers in one meeting that TOGAF was too high level and did not offer the technical precision needed. The next week I was in a management consulting meeting where TOGAF was dismissed as too technical and low level. Both of these groups regarded themselves as enterprise architects, but they had very little in common. What I’ve found surprising and disturbing is the lack of respect shown towards other disciplines, and how difficult it can be to establish common ground for communication. The overly simplistic overview presented above was an attempt to bring these issues to the surface, and to indicate that all these approaches have a practical motivation and a sound foundation.

First of all I think it is an interesting blog post you have written. Though I disagree with you on the on the four different perspectives on Enterprise Architecture, that you have developed.

Essentially everything you do in an enterprise is about money and as such it makes little meaning to define four different disciplines to deal with the concept of enterprise architecture, especially since the table somehow suggests that the four approaches you’ve defined are opposed to one another.

In my opinion it is rather obvious that a framework that has been applied to information systems development (like UML) isn’t the notation form or framework that most business process specialists like to work with since the two sets of stakeholders have different backgrounds and different means to understand what a diagram or other form of document is representing.

I’m a bit puzzled over your statement, that is quoted below:

“This wide range of perspectives has lead to confusion about purpose, target audience, terminology, and suitable techniques. For instance, while the technical disciplines see UML as a suitable modeling framework, few IS and management consultants agree. When IS is concerned with requirements and portfolio management, some systems engineers see these domains as separate from EA. In most business sectors, hardware is a standard commodity that IS need not focus too much attention on, while in military systems the hardware is cutting edge, subject to demanding requirements, and a core concern for systems engineering.”

How have the four different perspectives led to confusion about the purpose, target, audience and terminology? Who of the IS and management consultants disagree with the usage of UML as a framework? When speaking of hardware I assume you mean components of the infrastructure including servers, dump terminals, mainframes and personal computers?

I agree with you that one of the focuses of Enterprise Architecture has to be on facilitating communities of practice where the members (people of all levels in the enterprise) can share knowledge on how the enterprise is working. From that the problems that the enterprise might be facing can be dealt with from a systemic point of view, and the solutions would have to be organized and implemented according to that view. Sure it is a challenge to “overcome” the problem of ontology and semantics but in reality these two components are different for each company and therefore would a generic framework fail to overcome the “fragmentation” you talk about.

“Enterprise Architecture is first and foremost a meeting place, a common ground for communication across engineering disciplines and business units. The fragmentation that is taking place puts this function at risk. If we are not even able to interoperate among enterprise architects, how can we promote enterprise architecture as a methodology for solving users’ interoperability problems?”

In other words I agree that there are a degree of fragmentation over what the concept of Enterprise Architecture is about and how the architecture is represented in the best way possible; however I don’t see it as a problem due to the people who works with each of the “disciplines” you’ve defined have different backgrounds and means of understanding the representations. As such the problem wouldn’t exist except if the people don’t talk to one another or collaborate with one another.
The focus has to be turned to how people collaborate and how “communities of practice” can be facilitated in order to make the various forms of employees understand how the enterprise works and how to solve the problems the enterprise might be facing.

Best regards,
Peter Flemming Teunissen Sjoelin
CoherencyArchitect.com

I guess this means that when you link identity to the spatiotemporal extent of a thing, you are also talking about the spatiotemporal extent across possible worlds, maybe even across all imagineable worlds?

PS – there are some serious misunderstandings in your post on IDEAS too. IDEAS has nothing to do with UML or OO. We happened to use a UML notation, but as is clearly stated on the first page, this was for convenience only. I think I explained all this to you when we met in London…