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?