Update: End of Thesis, New Book

This blog has been dead for a while, partially due to a major, positive change of circumstances in my private and professional life. First of all, I married my wife on September 25 in Sydney. Hence, my surname has changed to Jensen-Waud. I will use this on all blog entries, e-mails, and social networks---including LinkedIn---from now on.

Secondly, I finished my master's thesis with the final (catchy) title: Government Enterprise Architecture Adoption: A Systemic-Discursive Critique and Reconceptualisation (click here to download a PDF format from Google Docs). I was awarded full marks (ECTS cale: A, Danish scale: 12, Australian scale: HD) for the final product with the a remark of excellence from my supervisor, Dr. Gotze: apparently it has excellent potential to evolve in to a full-scale PhD thesis. I will examine my options and possibilities in the near future for turning this in to a full-scale PhD or doctorate in business administration. 

My next project is to work on a book with the Sourcing Initiative with the headline: Enabling Collaboration. The time frame of the book is 12 months with  updates released publicly on an incremental basis. The book is a not-for-profit project with the final product being released under the Creative Commons license, very similar to the loosely knit network of authors contributing to Dr. Gotze's popular and important book on e-government and government 2.0.

So what will the agenda of my contributions be? The theoretical foundation of the book is that Enterprise Architecture is an important instrument for managing organisational sourcing processes. Given the recent interest of describing and architecting business and operating models for building and shaping the modern enterprise---particularly when shed in the theoretical light of the virtual organisation (Raffaini 2001)---I have formed my own research area of interest. When sourcing business operations and enabling collaboration in the extended enterprise, it is crucial to understand how each enterprise relates to others, especially in terms of regulations, knowledge production, profit generation, collaboration, and communication. In the classic, Zachman-inspired view of the enterprise (Zachman 1987), an enterprise architecture provides a static, consistent snapshot of an (extended) enterprise at a certain point in time. Building several architectural representations of all the enterprises sourcing and collaborating in the extended enterprise is thus key to managing efficient and effective sourcing processes. However, as I stated in my master's thesis, the enterprise is too complex to build a uniquely transparent and consistent picture at any point in time. Instead, I argue, it is the core role of Enterprise Architecture to highlight the communicational and discursive processes taking place within and in between the virtual enterprises. 

A second, important research factor is that the analysis and management of sourcing processes should depart from and emphasise systems thinking as a means for understanding how social and communicative entities in the extended enterprise cooperate, constrain, and collaborate with each other. 

Sourcing enabled by Enterprise Architecture thus carries two important dimensions: 

1. A systemic dimension describing how the virtual network of enterprises emerges and is managed in a coherent fashion through architectural thinking
2. A communicative (discursive) dimension describing how the flow of information and knowledge in the sourcing value chain should be captured and understood in a holistic manner.

The final theoretical foundation is built on K. E. Weick's theory of sensemaking (Weick 2001) and Luhmann's general theory of social systems (Luhmann 1995, Luhmann 2000).

For now, have a very Merry Christmas and a Happy New Year wherever in the world you may be.

References

Luhmann, N. (1995), Social Systems, Writing Science, Stanford University Press, Stanford, California.

Luhmann, N. (2000), The Reality of the Mass Media, Stanford University Press, Stanford, California.

Raffaini, M. (2001). The Virtual Organisation, in Proceedings of the 7th International Conference on Concurrent Enterprising, Bremen.

Weick, K. E. (2001), Making Sense of the Organization, Blackwell Publishing.

Zachman, J. (1987), `A Framework for Information Systems Architecture', IBM Systems Journal 26(3), 276-292.

Case Study Mode

Hello Fellow Followers, 

I am sorry for the radio silence, but I have been extremely busy writing up my case studies for the last month. It is the biggest and most important part of my thesis. Luckily, I have been provided to really interesting case studies from two Australian state government agencies: Ipswich City Council in QLD and Land and Property Management Authority in NSW. 

Both case studies focus on the adoption of EA and meta-modelling practice within a government context. The results have been very interesting, and I honestly can't wait to publish my findings. 

Meanwhile, hang on. I am still here, and there are some interesting writings to be released!

Cheers

Anders

On Government Adoption of Enterprise Architecture as an Institutional Process

 During the past few days, I have been reviewing Kristian Hjort-Madsen's PhD 'Architecting Government: Understanding Enterprise Architecture Adoption in the Public Sector' in relation to enterprise ontology and enterprise modeling methodologies. A vast amount of his referenced research publications is framed around institutional theory, in which organisations are seen as acting in various institutional fields (e.g. professionalism, legislations, polices, technological trends) that stimulate and constrain organisational decisions (Dimaggio & Powell, 1983). Hjort-Madsen believes that this is one of the key influences behind EA adoption [1], but it also comes at the cost of theoretical lopsidedness with a paradoxical backlash: institutional forces might explain certain reasons for EA adoptions in government, but institutional analysis tends to ignore the importance of free will of agency and rather draw its explanations from abstract, nearly autonomic forces in the organisational environment. Ultimately, the importance of free will—both on the individual level and within organisations—is trapped inside an institutional iron cage manifested in socially contrived institutions that—paraxodically enough—were created, maintained, and bureaucratized by human free will in the first place. Several researchers have criticised the institutional approach:

1. Hasselbladh and Kallinikos frame the popularity of institutional analysis in organisation theory whilst acknowledging its analytical tendency to reify social, emergent structural forces: “[...] the social and cultural processes that make up the project of rationalization and shape the structure functioning of work organisations have either been bypassed or given an exogenous status, reified to ’reality’, ’society’ or ’environment’ and treated as independent variables in cross-sectional or longitudinal empirical research.” (Hasselbladh & Kallinikos, 2000, p. 698) Neo-institutionalism, the authors say, grew out of a organisation studies as a response to classic positivist thinking: “[Neo-institutionalism emphasises that] Organizations are not responses that eolve as detached rational calculations. [...] The realist-materialist conception of organizations as adapting systems in natural environments of resources, threats and opportunities has, thus, again been brought to the fore and criticized as inadequate, on several grounds.” (Hasselbladh & Kallinikos, 2000, p. 698) This shift might get rid of some problematic assumptions, but the result is merely another reduc- tionistic approach: organisational rationality now happens “by reference to legitimacy, as the major prerequisite for organizational survival and success.” (Hasselbladh & Kallinikos, 2000, p. 699)—but praising legitimacy as the key variable in organisational logic is merely shifting the influencing parameter in the same first order systemic view of organisations [2].
2. Another key problem with institutionalism is tendency towards generalisability and the perceived birds-eye view of the organisational field, which tends to neglect local actions: “Neo-institutionalism offers no account of the means through which a domain of action is conceived, rules of conduct, performance principles and devices of controls are developed and forms of actorhood constituted.” (Hasselbladh & Kallinikos, 2000, p. 701) The global, generalising institutional perspective thus takes precedence over local meaning production, whilst failing to account for how and why a specific process of institutionalisation emerges and exerts influence (Hasselbladh & Kallinikos, 2000, p. 702).
3. Mintzberg extends the above problems into management and strategy (Mintzberg et al., 2002, ch. 10), where he clearly explains the problems of institutional theory: organisations are turned into fruit flies swerving wildly in a thick, hazy porridge of policies, regulations, and cultural norms. Individual, strategic decisions (e.g. government adoption of ITIL) is turned into a programmatic stroke of the environment, invisibly but collectively manuscripting the behaviour of every CIO. After all, as Mintzberg writes, “what is an ’industry environment’ but all the organizations functioning in it?” (Mintzberg et al., 2002, p. 297)—or is the environment merely a social construction that actorhood applies locally in order to cover up for mistakes or irrational behaviour? Mintzberg rightfully labels this view “looking at the world through the wrong end of a telescope” (Mintzberg et al., 2002, p. 293), and this is exactly what Hjort-Madsen tends to practice when he backtraces government practice to an illusorily forceful environment.

In summary, selecting an institutional foundation for analysing EA programs might provide a more qualitative framing of EA, but it is still: 

1. reductionistic in the sense that organisational behaviour and rationality are mainly shaped by external institutional processes reified into a certain corporate reality. Rather, these processes are created and sustained by social, contrived entities (e.g. bureaucracies)—and not prescribed through scientific laws of society.
2. ontologically paradoxical, since an institutional understand pays more attention to the so- called environment than the organisations inhibiting the environment, but fact is that the environment is constituted by nothing but the inhibiting organisations in the first place.
3. ontologically imbalanced since it removes the analytical focus from local, immediate and particular to a birds-eye view in search of generalisability.

It follows from these conclusions that institutional theory is -- on its own -- insufficient for describing and explaining the complex social mechanics of government adoptions of EA -- or any other transdisciplinary methodology with a high degree of organisational volatility and complexity.

I will work on how to developing and extending these views. Feel free to comment as I am looking for counterpoints and additional material and research material for inclusion in my thesis.

Footnotes
[1] For instance, see (Hjort-Madsen, 2007) (Publication II in (Hjort-Madsen, 2009)), (Hjort-Madsen & Marjin, 2007) (Publication III in (Hjort-Madsen, 2009)), (Hjort-Madsen, 2007) (Publication IV in (Hjort-Madsen, 2009)), and (Hjort-Madsen, 2009, p. 18, 20, 36, 61).
[2] As Hasselbladh and Kallinikos assert, Parsons’ structural functionalist framework for sociology already high- lighted the importance of inter-subjective meaning and interpretation in 1951 (Trevino, 2001). Thus, some aspects of institutional theory are very close to Parsons’ systems theory of society—and therefore not an inherently new theory of paradigm for understanding social organisation.

Sources

Dimaggio, P. J., & Powell, W. W. (1983). The iron cage revisited: Institutional isomorphism and collective rationality in organizartional fields. American Sociological Review, 48, 147-160.
Hasselbladh, H., & Kallinikos, J. (2000). The project of rationalization: A critique and reap- praisal of neo-institutionalism in organization studies. Organization Studies, 21(4), 697- 720.
Hjort-Madsen, K. (2007). Institutional patterns of enterprise architecture adoption in govern- ment. Transforming Government: People, Process, and Policy, 1(4), 333-349.
Hjort-Madsen, K. (2009). Architecting government: Understanding enterprise architecture adop- tion in the public sector. Phd doctorate.
Hjort-Madsen, K., & Marjin, J. (2007). Analyzing enterprise architecture in natinal governments: the cases of denmark and the netherlands. In Proceedings of the 40th hawaii international conference on systems sciences. Big Island, Hawaii.
Mintzberg, H., Ahlstrand, B., & Lampel, J. (2002). Strategy safari (2nd ed.). LT Prentice Hall. Trevino, A. J. (2001). Talcott parsons today: His theory and legacy in contemporary sociology.
New York: Rowan and Littlefield.

Enterprise Ontology Practice

I have great news! Firstly, I have today (tentatively) put the last dot into my chapter on Enterprise Ontology Practice. Secondly, I have converted all of my Word/docx and Omnigraffle sources into LaTeX and vector graphics. I simply wasn't happy with the quality of Omnigraffle's diagrams (despite the tool's great modeling features), so I decided to go with Tikz/PGF instead. Granted, it took a great effort to convert my graphics, and for non-technical people it might be a hassle to manually sketch out your graphics inside a text editor, but the result is absolutely stunning. Below is an example of a relatively simple Tikz/PGF diagram, which frames the adaptive enterprise within first order systems theory: 

The above is a compressed PNG version, so it does not look as nice as on my high-quality PDF publication from LaTeX. It took me half a day to really get into Tikz/PGF, but once you get the basics it is really easy to build high quality graphics and diagrams. 

As far as the Enterprise Ontology practice chapter concerns, I have until now completed my examination of three EA modeling tools and their relation to organisational concepts from second order cybernetics. And example of this would be: how well does the tool handle fuzzy, semi-structured processes or human workflows? Another example is: how well does the tool model and capture the different dimensions of knowledge (as an example cf. Ikujiro Nonaka's SECI model for knowledge creation). Not surprisingly, this support is very limited; qualitative and interpretative concepts are merely limited to full-text meta data attributes hidden well behind the formal BPMN diagrams.

I am very excited about posting my results, but I yet have to wait a bit. It still requires a sharp pen and a peer review from my supervisor.

Journal Recommendations

Often getting access to a specific scientific journal can be very cumbersome or expensive, unless you have bulk access through an academic or research institution. In the past few weeks I have been looking for journal articles at the intersection of Enterprise Architecture, radical constructionism, and systems science, and I came across this free, public journal: Constructivist Foundations. It is a free, peer-reviewed journal with several famous researchers and academics onboard, including S. A. Umpleby and Terry Winograd. The content is definitely promising and interesting.

On a personal note, I am currently working on the next chapter of my thesis, which concerns the enterprise ontology in practice and the application of engineering and modeling tools. I already have an extensive experience with taxonomy modeling in ARIS (Software AG), but the test bench will also include tools from IBM, SAP, MEGA and Sparx Systems.

Paradoxes in EA and Systems Research

In my ongoing research, I have identified a close link between enterprise architecture/engineering and systems science. P. Harmon, the prominent business process thinker and author of the book Business Process Change (K. Harmon 2007), Hoogervorst (2009), and Dietz et al. (2008) all discuss the influence of systems science and systems thinking on the process management and enterprise engineering disciplines as such, whilst K. Harmon (2005) even stresses the contention that systems thinking is a basic premise for the successful IT/management strategy implementations in today's organisations. Interestingly, these authors share the same foundations of research: cybernetics and systems thinking as put forward by Norbert Wiener (1948) and Ludwig von Bertalanffy (1969) -- and for Dietz and K. Harmon, R. L. Ackoff (1981, 1993).

Obviously, systems science and cybernetics has offered very important contributions to IS research -- especially within process management where organisations are better conceived as self-regulating, self-controlling systems rather than Laplacian machines that reason and act only by their internal causal structures. Systems researchers such as Beer, Bertalanffy, Ackoff, and Checkland have all contributed towards making this a mainstream research branch within a multitude of sciences, and it has also found its way to the enterprise engineering. But K. Harmon's integration of enterprise architecture research and systems thinking is a good example of cybernetics as a research eulogy: we have finally found the magic gemstone that bridges the gap between our IT systems and business operations. 

Unsurprisingly, that wide statement come at the cost of certain ontological premises. In my thesis research, I have made an attempt at systematizing these premises and their ontological influences on enterprise architecture. The criticism might not be unique or new, but at least it is an attempt to put very important research in the broad frames of enterprise architecture. We keep stating that EA is the future meta discipline for the modern enterprise; thus we also need a broad meta framework that is capable of 1) questioning its own foundation and 2) supporting the diverse types of knowledge, processes, and methodologies within an organisation in order to create and sustain innovation. In my next blog entries, I will present these critique points, and hopefully receive some valuable feedback as well. I haven't been very good at replying to your valuable comments; that is only due to me being busy, and not because of arrogance or ignorance. I will post a follow up very soon. 


Defining Cybernetics
Before I present the initial critique, it is valuable to define what cybernetics really is, and how it relates to systems thinking. Both disciplines are often used interchangeably, but there are, depending on the author, certain differences. 
Systems theory and Norbert Wiener’s theory of cybernetics are closely related (Heylighen 1999). But where systems theory focuses mainly on the structure of systems, cybernetics concerns the function of a system (e.g. what the system does) in relation to other systems. But, as Heylighen puts forward in Principia Cybernetica, both concepts are facets of the same subject and have permeated into a vast amount of sciences from information systems and biology to social sciences (ibid.). To provide a comprehensive analysis of EA and systems thinking, it is thus also necessary to draw in cybernetics.
The word cybernetics stems from the Greek word kybernetes meaning pilot or steersman and was by one its pioneers, Norbert Wiener, defined as the science encompassing “the entire field of control an communication theory, wether in the machine or in the animal.” (Principia Cybernetica: Defining ‘Cybernetics’ - http://www.asc-cybernetics.org/foundations/definitions.htm -- accessed on Apr 11 2010). However, that is only one branch of a definitional wilderness, spanning from Bateson’s very rigid explanation of cybernetics as “a branch of mathematics dealing with problems of control, recursiveness, and information” (ibid.) through Humberto Maturana’s very broad definition of cybernetics as “The Art and Science of Human Understanding. (…) Why? The Person that guides the ship, the skipper, acts both on practical know-how and intuition. Thus, the skipper acts both as a scientist and as an artist,” (ibid.) – and finally to Heinz von Foerster’s very cryptic conceptualisation: “Should one name one central concept, a first principle, of cybernetics, it would be circularity.” (Ibid.)
Concluding on the previous analysis of systems thinking within EA, it is tempting to assume that a systems theoretical foundation for EA is less mechanistic and more nuanced in its conceptualisation of knowledge and organisations. But, in my opinion, that assumption is flawed.

Paradox no. 1: The Enterprise is a System v. The Enterprise as a System
Systems science, as put forward by the authors previously mentioned, operates on the basic assumption that an enterprise is a system, and therefore one must frame it as a system in order to manage it efficiently[1]. But this “systemification” of organisation theory is just as reductionistic and mechanistic as orthodox Cartesian thinking: if we invert the implication, we are logically forced to accept the inference that if the subject matter of interest is not a system, it is not an enterprise. Operating from that premise automatically constrains our framing of organisations in another way and thus entails a new systemic reductionism in the EA discipline. There is a fundamental difference between postulating that enterprises carry systemic properties, behave like systems, or should be interpreted or framed as systems, since the conceptualisation here occurs at the epistemological level (how the knowledge about the subject matter is produced), rather than stating that the subject matter inherently is a system in its own right (which thus occurs on the ontological level -- this entails that the fundamental nature of reality or reality is essentially constituted by systems). The words ‘is’ or ‘behaves like’ make a very distinct -- and crucially important! -- difference.
Accordingly, the philosophical underpinnings of the notion that an enterprise is a system – and, as articulated by Bertalanffy, is best framed as a biological system or organism -- are questioned by Kast and Rosenzweig (1972): 

“One of the basic contributions of general systems theory was the rejection of the traditional closed-system or mechanistic view of social organizations. But, did general systems theory free us from this constraint only to impose another, less obvious one?” (Kast et al. 1972) 

Here the authors draw in Daniel Katz and Robert Kahn, who criticise the organismic perception of organisations (1966):

“The biological metaphor, with its crude comparisons of the physical parts of the body to the parts of the social system, has been replaced by more subtle, but equally misleading analogies between biological and social functioning. This figurative type of thinking ignores the essential difference between the socially contrived nature of social systems and the physical structure of the machine or the human organism. So as long as writers are committed to a theoretical framework based upon the physical model, they will miss the essential social-psychological facts of the highly variable, loosely articulated character of the social system” (Katz and Kahn, 1966, p. 31, my emphasis)

Both sources clearly underline the problems of the systems (or first order cybernetic) approach to organisations and EA: the baseline assumption that an enterprise is a system and that this system behaves like an organism (rather than like a predictable machine) is fallible and just as reductionistic and mechanistic as the Machine Age thinking introduced by Ackoff (1981).


Footnotes

[1] An example thereof: Dietz writes, “As said before, the basic premise of enterprise engineering is that an enterprise is a designed system” (Dietz et al. 2008, p. 573), and supports that contention by stating: “The most important premise in the notion of Enterprise Engineering is that an enterprise is a designed system instead of an organically growing entity.” (ibid. p. 578) Similarly, K. Harmon equals enterprises and systems by stating that “frameworks and methodologies used in the development of enterprise architecture should, and in time will, more clearly demonstrate that an enterprise is an intelligent complex adaptive system of systems” (K. Harmon 2005 p. 3).

References
Ackoff 1981: Creating the Corporate Future: Plan or be Planned For -- Ackoff, R. L., Wiley, 1981.
Ackoff 1993: Beyond Total Quality Management. High profile lecture. University of Hull, 18 September 1993.
Bertalanffy 1969: Bertalanffy, L. von, General Systems Theory, New York, George Braziller 1969.
Dietz et al. 2008: Enterprise Ontology in Enterprise Engineering -- Dietz, J. L. G and Hoogervorst, J. A. P. - Proceedings of the 2008 ACM symposium on Applied computing -- ACM.
K. Harmon 2005; , "The "systems" nature of enterprise architecture," Systems, Man and Cybernetics, 2005 IEEE International Conference on , vol.1, no., pp. 78- 85 Vol. 1, 10-12 Oct. 2005.
P. Harmon 2007: Business Process Change, 2nd edition, Morgan Kaufmann Publishers, 2007. 
Heylighen et al 1999: Principia Cybernetica: What is Cybernetics and Systems Science? – F. Heylighen, C. Joslyn, V. Turchin 1999 – http://pespmc1.vub.ac.be/CYBSWHAT.HTML (Accessed on Apr 3 2010).
Hoogervorst 2009: Enterprise Governance and Enterprise Engineering, J. A. P. Hoogervorst, Springer 2009. 
Kast et al. 1972: General Systems Theory: Applications for Organization and Management – The Aaademy of Management Journal, Vol. 15. , No. 4, General Systems Theory (Dec. 1972) pp. 447-465, Fremont E. Kast and James E. Rosenzweig, publ. by the Academy of Management.
Katz and Kahn 1962: The Social Psychology of Organizations – Katz, Daniel and Robert L. Kahn, New York: John Wiley and Sons, Inc. 1966).
Wiener 1948: 

Cybernetics: Or Control and Communication in the Animal and the Machine. Wiener, N. Paris, France: Librairie Hermann & Cie, and Cambridge, MA: MIT Press.Cambridge, MA: MIT Press.

On Enterprise Taxonomy Completeness

Yet again it is time for an update on my thesis progress. After revising my initial introductory chapter with my supervisor (John Gotze), I decided to revamp the chapter completely and go forward with a more tangible problem: the failure of strategic IT and process redesign programs in government. Enterprise Architecture claims to hold the cure for these failures, but is it really that simple? 


In order to get deeper into that discussion, I started out by reviewing Roger Sessions' Enterprise Architecture framework comparison on MSDN (A Comparison of Top Four Enterprise-Architecture Methodologies), in which he compares some of the most contemporary approaches to architecture: Zachman, TOGAF, FEAF, and Gartner. Sessions, albeit very practical in approach to evaluation, poses a few very interesting problems in his analysis: 

• Basic lack of analytical coherence and empirical evidence: his measurements or rankings of each framework stem entirely from personal use, and no no empirical foundation is included: "Keep in mind that these ratings are subjective. I'm sure most people would disagree with at least one of my ratings." Still, a finite scale of methodology ranking emerges out of the blue, with no coherent explanation of how the measures were chosen, nor discussing why other measures were left out. In my opinion, it is interesting how much time is spent on talking about frameworks rather than doing an empirically well-founded research effort to find out how efficient they actually are. Honestly, such a research effort might actually provide better informed decisions than an arbitrary soup-de-jour selection of framework criteria.
• Secondly, Sessions introduces an interesting parameter: taxonomy completeness, which "refers to how well you can use the methodology to classify the various architectural artefacts. This is almost the entire focus of Zachman. None of the other methodologies focuses as much on this area." It certainly is an ambitious contention to provide a finite taxonomy for the enterprise, but how is such completeness achieved? Complete in terms of what? Complete compared to what? Is it because the methodology, framework, or modeling language is capable of expressing any possible state or snapshot of an enterprise at any point in time? Organisations are ambiguous, interpretative systems, not engineered machines that we can model in its entirety with a rigorous charting tool. Imagine expressing the many facets of corporate life, the politics of process standardisation, and the controversy of introducing cross-departmental cost centers in UML 2.0 or ArchiMate: if an ontology or taxonomy is to be complete, it would have to comprehend exactly that snapshot of the enterprise, but the difficulty (or ridicule?) of fulfilling that task hopefully requires no further elaboration.

By no means do I want to commit the fallacy of ontological or radical constructivism, but there seems to be some serious problems with how informed our choices of and trust in frameworks and tools really are. Granted, there are lots of benefits from choosing a structured approach to enterprise architecture and engineering, but all too often the we ignite a heated discussion of the specific framework in itself rather than examining the realistic benefits from applying a structured approach and systems thinking in an organisation. Applicability and practical benefits should be our point of departure, and not how well a framework (documented in a very thick manual) maps to another framework, when it is obvious that both methods provide an excellent structured body of knowledge and best practices for applying enterprise engineering. Again, I want to refer to the GERAM methodology developed by the IFIP-IFAC Task Force on Architectures for Enterprise Integration -- it provides a unified platform for capturing the essentials of a reference architecture and presents it in a pragmatic way, without claiming an ontological monopoly such as taxonomy completeness. 

Of course, having a reference architecture, a corporate dictionary, and a common taxonomy is very useful -- especially as a communication tool. But having a dictionary of important models is still very far from having a complete depiction of the enterprise -- what Sessions claims to be an important measure for methodology selection. Similarly, GERAM discusses the importance of having a common taxonomy -- Generic Enterprise Modeling Concepts (GEMCs) -- but the IFIP-IFAC Task Force never claims the ability to capture everything in one model, but instead discusses the applicability of ontologies at different levels of ambitiousness and rigor. 

Stay tuned in the following weeks, as I will be exploring and discussing the relationship between enterprise engineering, systems science, and 1st order cybernetics. 

Zachman: Not a Point of Departure for an Enterprise Methodology

I have spent the last few days reviewing the most contemporary Enterprise Architecture (EA) frameworks. As I am trying to establish a common description of the methodology behind EA, my goal is to sketch the intersection of methodological assumptions these framework impose on organisations. However, the analysis is still on a very high level of abstraction as my goal is a cross-framework conceptualisation. Of course, every framework has its own domain of application, knowledge, and assumptions, and the analysis is fully aware of that.

People usually refer to the Zachman Framework when addressing EA's point of departure. John Zachman published his famous first words on enterprise integration in the IBM Systems Journal publication A Framework for Information Systems Architecture in 1987, and he is still regarded by many academics and practitioners as the father of the discipline itself. In 2009 I even had the pleasure of following John Zachman presenting an updated version of his framework, and it was definitely inspiring and valuable. Besides being the first to propose an important quantum leap in the integration of business and technology, Zachman is also an excellent speaker and entertainer.

However, my analysis does not depart from Zachman's original writings, and that is with a specific reason. Zachman has continuously emphasised that his framework concerns structure and taxonomy, and in general not process or methodology. The Zachman Framework is specifically focused on representing a static state, taxonomy, or blueprint of an enterprise, but not how the enterprise has grown the architecture over time -- no development methodology is prescribed. It is merely a snapshot or slice of the enterprise at a certain point in time. As Zachman puts it: "The Zachman Framework is a schema. [...] More specifically the Zachman Framework is an ontology [...] The Zachman Framework is not a methodology." Zachman's classification structure is very useful for systematically classifying and describing the current state (or future state) or an architecture, but in my opinion he poses some fundamental erroneous assumptions about methodology and ontology -- and manages to represent it in a misleading way:

- The definition of an ontology is (according to Wikipedia): "the philosophical study of the nature of being, existence or reality in general, as well as the basic categories of being and their relations." Let us for a moment assume that it is the second sentence that Zachman focused on when using the word ontology in his writings. Ontology is in the first place quite a big word (or efficient discourse) to use when describing one out of many frameworks, and I agree with Dave Snowden when he postulates that the word taxonomy is a much better concept in the context of enterprises.

- Given that ontology concerns the "basic categories of being and their relations", Zachman must assume that a being is already in place, and that this being is involved in the creation of the relations. Being assumes a process, the creation of something -- taking part in the world -- or maybe less dramatic: the organisational field -- over time. But if Zachman's schema only concerns the organisation at a single point in time, how can it truly represent the inherent causality between the objects it claims to classify in an efficient way? A complete description of the objects and their interdependencies within an enterprise must assume a certain level of context within time and space. A snapshot for putting the enterprise in a context is simply not enough. And as ontology assumes both causality and being, Zachman's framework simply is not an ontology. Similarly, Mendeljev's periodic table (which Zachman often uses as an powerful analogy to his own concepts) not only describes the static composition of atoms (implies structure), but also how atoms evolve over time (implies process) as they wobble between a stable and unstable state. Again, Zachman's use of the term ontology is insufficient.

In short: the word ontology is simply too strong a discourse for a classification system, and a snapshot classification is again not sufficient for efficiently describing an organisation without loosing important information. How and why the organisation is in its current state are in my opinion two major prerequisites that need to be determined before we can describe an optimal future state, and the Zachman Framework is in a conscious manner sawing off the branch that its own reality check with methodology sits on.

In my search of enterprise methodologies, I have decided to take GERAM - The Generalised Enterprise Reference Architecture and Methodology -- as my point of departure. Peter Bernus, one of the authors behind the framework -- presents it as a meta methodology for describing reference architectures: “Potentially, all proposed reference architectures and methodologies could be characterized in GERAM”-- whilst emphasising the framework's ultimate purpose of methodological unification:

“GERAM is intended to facilitate the unification of methods of several disciplines used in the change process, such as methods of industrial engineering, management science, control engineering, communication and information technology, i.e. to allow their combined use, as opposed to segregated application.”

The IFIP-IFAC task force certainly created the first real stepping stones towards a true ontology and methodology for formally characterising and representing an enterprise in context. After all, that requires an inclusion of both structure and process, and these cannot be separated without leaving out important knowledge about the enterprise itself.

Creating a Thesis Infrastructure

I am currently in the process of starting my thesis work. With my background in software engineering and software process improvement (SPI), I am aware of how crucially important configuration management is. When working one or more people on a source code project, it is more than just best practice to use a source code control system (SCCS) -- it is inherently important. Now, let us transfer this idea to a master's thesis context.

When working on a document more than 20 pages long, neither Microsoft Word nor OpenOffice.org are -- in my opinion -- sufficient for maintaining references, bibliographies, table of content, and just general layout performance. People start complaining about product performance, and once your XML hell of a .docx document has reached the size of 100 pages, Word just plainly sucks. Instead, I prefer LaTeX (with the byname a document preparation system) for authoring my documents and collaborating with others. Okay, Google Docs might be a useful tool for collaborating around simple documents, but it simply is not as powerful as LaTeX with regards to referencing, formatting, and splitting files into separate documents. LaTeX's achilles heel is its steep learning curve and geeky image: as an author you do not write your document, you compile it into a PDF document from your LaTeX source code. But when you have mastered the basic commands and set up a useful infrastructure, LaTeX is your extremely powerful friend. A friend that you will never let go. The major benefits of using LaTeX with an SCCS are: 

1. Version control. You have a complete history of all changes within your document. 
2. LaTeX documents are clear text -- not binary or fancy, funky . Similarly to any source code, you can use standard Unix tools such as diff and merge for controlling your source. Also, you can use any editor of your choice (I use Vim and Aquamacs/Emacs 22.0) for authoring your thesis, rather than staring into a Word screen with pastel colors and that awfully ugly ribbon panel.
3. Documents can be split into sub-documents. This allows you split up your work into reasonable chunks, and each person can work can work undisturbed on one part. In the end, LaTeX maintains the merging with ease. 
4. ToC's, bibliographies, and referencing is managed on the fly. You can even switch from Chicago referencing to APA style referencing with just one change in your master document. 
5. LaTeX has a huge community, and its user base spans from students in astrophysics over computer scientists to professional publishers. And oh, did I mention that many publishers in academia are also using it?

But on the other hand: 

1. LaTeX features a steep learning curve. If you have done basic computer programming before, it should be pretty easy for you to catch up with LaTeX. If not, it might require some time to adjust.
2. LaTeX arrogantly ignores the WYSIWYG principle. Rather, the program adheres the paradigm What You See Is What You Mean. If you are doing complex layouts, this requires you to compile and watch your layout often. Also, forget all about using your mouse for drawing tables.
3. Compiling in images is not very easy, and it may require some file conversion. However, once you know the drill it is quite easy.

After setting up my own LaTeX environment, I have created a checklist for other people to follow. It assumes prior knowledge of SCCS and LaTeX, but at least it provides an offset for curious, aspiring thesis students.

1. Set up a source code repository. I prefer Subversion whereas Ruby'ist prefer Git. Both systems are pretty easy to set up, but each has its own advantages and specialties. Subversion is centralized, whereas Git is a distributed SCCS. 
2. Read Nicola L. C. Talbot's guide to using LaTeX for writing a PhD thesis. It is really good. Next, use LaTeX on Wikibooks for quick questions. Especially pay attention to how to use LaTeX for referencing and bibliography management.
3. Download and install LaTeX and BibTeX. They are usually provided in a distribution, depending on your OS. If you are on a Mac, I recommend using the MacTeX distribution. On Windows, MiKTeX does the job.
4. Create a main LaTeX document with a separate class (.cls) file for controlling your layout, templates, and preferences. The main LaTeX document should control all package imports. 
5. Split your thesis into different files according to your current thesis structure (hint: \include).
6. Use BibTeX for bibliography management -- you won't regret it! Create an easily memorable list of books or articles that you use the most. I usually use in lowercase -- for instance: weick2001. Thus, I can now use \cite{weick2001} inside my LaTeX document. 
7. Use Bibsonomy for looking up and reusing existing BibTeX definitions. 
8. Remember to commit often and provide a meaningful description to your commit message. This makes it easier to follow the version history after three months.
9. I keep all of my .tex documents in a separate folder. Also, I created folders for the PDF articles that I am using. Give the articles the same name as the reference name in your BibTeX bibliography.
10. Keep all of your images in TIFF or PostScript format. It is easier for LaTeX to process and scale. 
11. Use a good text editor with syntax highlighting and automatic indentation. Aquamacs and Vim are great on Mac OS X. On Windows, Notepad++ is a great solution.
12. Create automation scripts and shell aliases for building your PDF master document on the fly. This makes it easier for you to quickly generate a new master document. 
13. When adding files to your repository, remember only to add the source files and not the binary output files that LaTeX or BibTeX generate -- it is not necessary, as these are simply derived from your source files!

These are my initial recommendations. I hope somebody might find them useful. Please leave any comments or feedback. And now, I am better off really getting started with my thesis work.

EDIT: Søren Vrist also recommends using this German web site for reusing citations for BibTeX. Thanks a lot for your recommendation, Søren.