Coherency Management

Dr. John Gøtze is a founding partner in the Danish think-tank EA Fellows. He also serves as the International President of the Association of Enterprise Architects (a|EA). He certifies enterprise architects via Carnegie Mellon University’s Certified Enterprise Architect program, and also teaches EA at Copenhagen Business School and the IT University of Copenhagen. For almost 10 years, he was a civil servant. As chief consultant in the National IT and Telecom Agency he initiated the first government-wide EA program in Denmark. Previously he worked for the Swedish Agency for Public Management, and co-created the national e-government strategy. He holds a M.Sc. in Engineering and a Ph.D. in participatory urban design, both from the Technical University of Denmark.

JEA: Describe how you became involved with Enterprise Architecture?
Gøtze: If we understand EA as engineering and designing enterprises, and enterprises in its widest sense, I got into EA very early in my career. After high-school, I became a shop-floor worker in a chromium-plating plant, where I got motivated to study engineering with the idealistic purpose of designing better working environments, healthier to humans as well as the environment than what I had experienced. So, while studying and researching (for 12 years), I kept the idea of engineering the enterprise, but wandered a bit around what kind of enterprise: I started with ‘the factory’ – mechanical engineering, operational analysis, production planning – but got angry with Tayloristic tendencies and became, for a while, somewhat of a luddite. I got into sustainable living/energy/ecology – where we see the world as an enterprise, but also the all-important community as an enterprise. Fast forward to me then seeing the city as a (very extended) enterprise, which can actually be architected, though not easily. I had started finding enlightenment in Christopher Alexander (architecture), Stafford Beer (management cybernetics), Gregory Bateson (anthropology), Richard Sennett (sociology), Hannah Arendt (political philosophy), and many others. My Ph.D. focused on participatory decision making and stakeholder engagement in urban architecture, spiced up with a bit of HyperCard, AI, and the at that time brand new Internet (web). Well, I ended up in the civil service, working with all aspects of eGov. It was here, in the late 1990s, that I got introduced to ‘actual’ EA. In 2001, I started taking the Danish government along on the EA journey.

JEA: How are Enterprise Architecture practices different in Denmark than the rest of the world?
Gøtze: To illustrate some similarities and differences, let me first comment on the Danish Government’s EA practice, which I helped give birth to. It started out as a whole-of-government approach, cutting across all levels of government (state, regional and municipal), and today there are significant joint efforts across the levels of government, with more shared solutions than we see in most other countries. Adaptation of EA is based on recommendations and incentives rather than laws and regulations, but we see more and more EA-components becoming mandatory, for example the use of business cases and certain technology standards, and in general a focus on ‘all of government as one enterprise’, though in some areas restricted to ‘the State as one enterprise’, but even here with ambitious cross-departmental shared service initiatives we rarely see in other countries. So it is not ‘enterprisey’ initiatives we lack. The problem is, in my view, that there is too little focus on architecture as a discipline. In 2005, the OECD did a peer review of e-government in Denmark, and pointed out that to achieve benefits, enterprise architecture must be understood and applied as widespread as possible. The formal government EA framework and methodology, called OIO EA, is actually currently only adopted by 4% of agencies, official statistics show. And it is not because the remaining 96% uses TOGAF, EA3 Cube or something else; the vast majority simply don’t ‘do’ enterprise architecture, but rush into concrete investments and projects. The architecture work we see is hence more segment-oriented, sometimes silo-oriented, and more often than not connected to procurements and solutions. Hence, we see quite a few EA-related initiatives from vendors and consultants, and generally have a growing EA-community. This community is also growing because the private sector has more and more EA savvy companies, or at least, groups or individuals within these who are practicing EA in some way or another. By and large, Foundation mode of EA is dominant, but there are also a few companies where EA is not just an IT-thing.

JEA: You have said in the past that Enterprise Architecture principles are important, how so?
Gøtze: I sometimes call principles ‘the Mother of all best practices’ in EA, because it is my experience that it is a very useful exercise for enterprises to formulate, debate and discuss the fundamental enterprise and architecture principles, and to use these in their governance practice, portfolio management, etc. I define a principle as a commitment, whether chosen or assigned, that has impact on one’s actions. This definition is inspired by Hannah Arendt, who talked about how principles incite people to act and nourish their actions; simply put, the principles in political philosophy are honor in monarchies, virtue in republics, fear in tyrannies, and freedom in Athens. In the context of enterprises, principles form the basic rules by which decisions regarding architecture management can be made; specifically, the principles express the fundamental rights of everyone in the enterprise with respect to architecture management; provide guidance when faced with multiple choices for strategy, business and technology decisions; apply when the consequences of a decision in one part of the enterprise may affect another; are the basis for enacting enterprise-level governance for managing strategy, business and technology coherently. The principles operate as a cohesive whole. That is, no principle stands on its own, but is considered in the context of all other things being equal. The principles are used in combination as criteria for judging a decision. When analyzing options, the capability of each option to meet the requirements of each principle is evaluated. Then, each option is considered in the context of its capability to meet the requirements of the principles as a whole. Different principles should be weighted differently for different kinds of decisions. When a decision is made, the applicable principles and their relative weight for the facts considered will be recorded. Thereafter, given the same situation, the same decision is made. Consistent application of principles is vital for the long-term effectiveness of architecture management across the Enterprise. Additional information and the supporting rationale for each of these EA principles should be created, and made available throughout the enterprise. TOGAF has a good ‘formula’ for how to describe principles (name, statement, rationale, implications).

JEA: What was your most favorite Enterprise Architecture project and what made this one so good?
Gøtze: I don’t want to select any single engagement as my favorite, but of course some engagements have been more interesting than others. I generally like engagements where architecture is done with enterprisingness in a ‘true’ community of practice (CoP). I’m very inspired by the way Etienne Wenger talks about CoPs, that is, as ‘places’ where the participants develop a shared repertoire of resources, be it through experiences, stories, tools, ways of addressing recurring problems, in short a shared practice, and where they are doing so with a sense of joint enterprise and identity. So it’s when all the dictionary’s meanings of ‘enterprise’ is in play, I really like doing EA: when it’s a purposeful or industrious undertaking in an organizational context created for business ventures, with a readiness to embark on bold new ventures.

JEA: What was your least favorite Enterprise Architecture project and what made this one not very good?
Gøtze: As someone who is proud of our discipline, I really hate it when I see projects that call themselves EA-projects, but in fact is something else, and when they fail, they blame EA for the failure. Last year, for example, a big Danish company had a huge CRM-consolidation effort that failed utterly, but being part of a bigger EA-program, it dragged the whole EA-program down, and EA got all the blame for the failure. I realize there are situations where it is perfectly in order to criticize a given EA-program and its priorities, but find it disturbing when criticism becomes bigotry.
JEA: Do you feel that Enterprise Architecture is a viable career path for program managers, analysts, and/or technologists?
Gøtze: I certainly do think EA is a viable career path for all of the above, as well as for many others. Otherwise I wouldn’t spend a great part of my time certifying enterprise architects. In my view, there is more than ever need for enterprise architects in today’s enterprises, and here I fully agree with Philip Allega from Gartner who recently said, “Regardless of industry or size, now is the time for enterprise architects to act”. Traditionally, the vast majority of enterprise architects have an IT background, but that’s starting to change, and we see more and more strategy and business people coming into EA. This is a very good thing, because the biggest challenge is to find the right balance between strategy, business and technology.

JEA: What advice would you give to someone just starting a career in Enterprise Architecture?
Gøtze: It really depends on that someone’s profile and experience. Whether it’s my university students, or those professionals I certify or coach, I often end up telling them to read this and that book, and suppose a general advise would be: read books. Since EA is a meta-discipline, there will always be another, relevant book to read. But as important as learning through reading books is, it is learning through practice that gives you experience, and the most important advice I can give is for them to join, build and nurture their communities of practice. And of course, they should join the Association of Enterprise Architects and become active in their local chapter.