Four Approaches to Enterprise Architecture
December 10, 2010
Enterprise architecture (EA) has been developed by four different disciplines, as shown in the table below.
| Discipline | Focus | Architecture | Frameworks and Techniques |
| Management Consulting | Money | Enterprise Modeling | FEAF, BPM |
| Information Systems (IS) | People | Enterprise Architecture | Zachman, TOGAF, ARIS |
| Software Engineering | Software | Model Driven Architecture | UML, MOF, SOAML |
| Systems Engineering | Hardware | (System of) Systems Architecture | SysML, MODAF, NAF, UPDM |
Enterprise modelling was first applied to analyse industrial operations, extending IDEF and other process modeling notations. Later, information systems people applied similar techniques for aligning the IT with the business it supports, and for IT management in general. After software engineering established object oriented modelling of the internals of software systems, systems engineering adapted these techniques to hardware and software co-design. Systems-of-systems thinking led them to extend their reach beyond technology and into the enterprise realm.
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.
Organizations that are taking up enterprise architecture should be aware of this fragmentation, and make sure that the frameworks and techniques they select fit their needs. An IS or management consulting approach will need to be linked with other techniques that adequately cover the technical details of software and systems design. On the other hand, the more technical frameworks may not offer the high level views that communicate with business people and system users. For instance, the MODAF and NAF metamodels require you to put in a lot of details that you may not care about on the business architecture level. Here are some examples:
- Rather that directly stating that a project contributes to a goal, MODAF forces you to add intermediate objects stating when the contribution is delivered (milestone) and what the contribution consists of (capability configuration).
- Rather than directly stating that a software application implements a service, you have to state which physical capability configuration provides the service, which hardware artefacts it contains, and finally the software is only included as hosted on the hardware artefacts.
- With a flow-oriented approach to information modeling, you cannot model the information needs of organizations, applications, activities etc. without also stating how this need is met, who provides the information, as the source of the flow.
- Rather than modeling relationships as associations, properties and tagged values are applied. This supports the composite structure visualizations that systems engineers seem to prefer, but makes it more difficult to produce node and link graphs, and to perform what-if-analysis along the relationships.
- The difference between types and individuals is important in software engineering because the types define the software design, while the individuals just will be represented as data in the running system. Most enterprise architecture frameworks need not worry about this difference, because the models are intended for interpretation by humans, not machines. They often describe the features of individuals and the common features of groups of individuals (classes, types) in the same manner, greatly simplifying their languages.
Issues like these makes it more difficult to use the models to communicate with business stakeholders, and to trace dependencies for analysis of consequences. The added complexity also increases the cost of modeling, perhaps resulting in the project having to choose a narrower scope for the architecture.
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?
Frank Lillehagen
Håvard Jørgensen
Active Knowledge Modeling 
March 22, 2011 at 20:36
I’m not sure you’ve really understood MODAF. You’ve put it in the Systems Engineering category when it has little to do with SE. MODAF covers strategic enterprise planning and capability (a level above the categories you mention), business processes, services (business and technical) and eventually in the Systems Views it covers a bit of systems engineering.
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…
March 22, 2011 at 22:03
I’m not sure you’ve really understood what the post is about. It tries to describe four different perspectives on or approaches to EA. All the approaches cover some of the same areas, so it is not about a difference in scope. MODAF is for EA, not for systems engineering, I agree. My position is just that MODAF is an EA approach that follows a systems engineering perspective, and puts more emphasis on systems engineering problems and world views than approaches that come from other discplines. It is “EA for systems engineers”. It defines “Enterprise Architecture” as a systems architecture where the system happens to be an enterprise.
As an example, look at service provisioning. From an information systems perspective services are provided by application software, e.g. in TOGAF. From a systems engineering perspective services are provided by physical systems, e.g. in MODAF.
There are sound reasons for these differences. In the industries where the IS approaches originate, hardware systems are standard off-the-shelf, often even virtual clouds, that are not of critical concern for the EA. In the military field however, hardware and communication devices are custom made and critical components to a much larger extent, often demanding a substantial share of the IT budgets.
April 24, 2011 at 00:23
Hi Håvard,
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
April 26, 2011 at 08:58
Thank you for insightful comments. I agree with almost everything you say, even if you don’t accept my diagnosis. As you say “the problem wouldn’t exist except if the people don’t talk to one another or collaborate with one another”. This lack of communication and collaboration is exactly what I have experienced, and the main motivation for writing the post. I’ve met people who completely dismiss frameworks and methodologies from other disciplines because it does not fit with their own preconceptions.
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.