Andrzej Sobczak interviews John Gøtze
Andrzej Sobczak runs www.EnterpriseArchitecture.pl (ArchitekturaKorporacyjna.pl), and is an assistant professor of the Department of Business Informatics at Warsaw School of Economy. Andrzej is currently working on a book in Polish, which would be titled “Enterprise Architecture Management. Experts’ Views” if it were published in English. Alas there are no plans of an English version.
1. The issues concerning enterprise architecture are quite a new area of research. Definition of this term itself is still being discussed. Tell us how you understand this term or give definition that you commonly refer to. Do you agree that each organization possesses enterprise architecture even if it has not been optimized or documented?
The definition I use is: ‘Enterprise Architecture is the inherent design and management approach essential for organizational coherence leading to alignment, agility and assurance’. This is taken from the Coherency Management book. This implies that I fully agree that there is always architecture in place in an enterprise; EA is really about the mastery of the architecture of the enterprise. A well-architected, well-functioning and well-documented enterprise is a coherent enterprise.
The most common and classical form of EA is what we call Foundation Architecture. The EA is most often done to align IT to the business. The Foundation Architecture can be seen in the most widely accepted definition of EA provided by Ross, Weill and Robertson where â€œEA is defined as the organizing logic for an organizationâ€™s core business processes and IT capabilities captured in a set of policies and technical choices, to achieve business standardization and integration requirements of the firmâ€™s operating modelâ€. Another idea about EA, we call it Extended Architecture, came about in the late 1990â€™s and focused on engineering an entire enterprise from integrated strategy, business, and technology perspectives. To support this expanded view of EA, a number of approaches and tools were developed to provide standardized, repeatable methods for describing an enterprise in all dimensions – beyond just the IT perspective. Whereas Foundation Architecture used architecture methods and tools to capture business requirements in order to design better IT systems, in the Extended approach, architecture methods and tools capture strategic goals and related business requirements in order to design the enterprise.
In the Foundation and Extended modes of EA, artifacts (various types of documentation) are created as the result of an EA process or method, somewhat extraneous to the functioning enterprise. But what if architecture tools, methods, and models became embedded in the normal (usually existing) processes of the day? We call this Embedded EA, where the architecture, rather than relying on processes and people extraneous to the business programs (and their processes), is produced by the processes themselves. In this way the architecture is organic and ever greened naturally.
Balanced Architecture is a term that we use to describe when an enterprise utilizes the best and the most appropriate characteristics of each of the three modes of EA. It is unlikely that any organization has yet reached a level of maturity in their EA program, so as to have a truly balanced architecture state.
2. Tell us more about the book “Coherency Management” and the concepts included in it. What is coherency management and how it is related to enterprise architecture?
The book’s full title is ‘Coherency Management: Architecting the Enterprise For Alignment, Agility and Assurance’ (editors Doucet, Gøtze, Saha & Bernard), and it discusses a new way to look at Enterprise Architecture. Coherency Management represents a significant point of evolution in the design and management of all enterprises. This includes, and is especially beneficial for, highly dynamic organizations, that sometimes have chaotic operating environments. The concept of Coherency Management is about using EA to advance alignment, agility, and assurance in large, complex organizations. The essence of this concept is that the architecture (words and pictures) of enterprises should become consistently structured, formalized, used to attain coherency. The best way to do this is to adopt EA as the ongoing, overarching method for describing, abstracting, analyzing, designing, and re-engineering new and existing enterprises-regardless of the market, industry, or government sector. Most importantly, it is about EA becoming pervasive.
With submissions from over 30 authors and co-authors, the book reinforces the idea that EA is being practiced in an ever-increasing variety of circumstances – from the tactical to the strategic, from the technical to the political, and with governance that ranges from sell to tell. The characteristics, usages, value statements, frameworks, rules, tools and countless other attributes of EA seem to be anything but orderly, definable, classifiable, and understandable as might be hoped given heritage of EA and the famous framework and seminal article on the subject by John Zachman over two decades ago. Notably, EA is viewed as an Enterprise Design and Management approach, adopted to build better enterprises, rather than a IT Design and Management approach limited to build better systems.
3. Could you tell us what you think about main benefits resulting from possession of enterprise architecture within organizations and major barriers connected with implementation.
Current literature in EA list several benefits like business-IT alignment, standardized business processes, business and process flexibility, business transformation, IT cost reduction, operating cost reduction, application maintenance cost reduction, business risk management, senior management satisfaction, quality of service improvements among many others. But these are all intermediate benefits contributing towards the three primary benefits and outcomes: Alignment, agility and assurance; alignment refers to the ability of the organization to operate as one by working towards a common shared vision supported by a well orchestrated set of strategies and actions. Agility refers to the ability of the organization to respond to and manage change. Assurance refers to the ability of the organization to establish and institutionalize (internalize) practices that ensure fulfillment of organizational goals and achievement of outcomes.
I think the main barriers are related to the organizational practice, including communication and competence management. EA is difficult to communicate about, especially if one insists on using EAs own language.
4. Enterprise architecture is most often introduced in medium and large organizations. Do you think that there are some organizations for which such enterprise architecture is exceptionally beneficial? What sort of criteria should be used while choosing such organizations?
In my view, all kinds of organizations can benefit from EA. The degree of relevancy of EA in a given enterprise depends on a number of factors. Many find it useful to work with the concept of operating model as introduced by Ross, Weill and Robertson: The four fundamental business models determined by the combination of high or low business process standardization and integration (i.e. Coordination, Diversification, Unification, Replication). Each operating model captures a particular set of process design principles. Identifying an operating model is a necessary first step in building a foundation for execution, and is a feature of successful companies. Unification is in many ways for the most EA savvy, and will require a high level of architecture maturity.
In the real world, many enterprises have many different operating models in their various lines of business or segments, and then sometimes also just because they’re an incoherent mess. Both ends of this ‘scale’ can benefit from EA, but probably in different ways.
One criterion I sometimes use is enterprisingness, the degree of ‘enterprise’, in the meaning readiness to embark on bold new ventures.
5. At the very beginning enterprise architecture was perceived through the “as-is” and “to-be” models. However, it turned out to be insufficient to apply this concept in practice. Thus a dynamic element has been introduced – I mean Enterprise Architecture Governance. Nearly in the same time the enterprise architecture was expanded of issues connected with SOA, safety and risk management.Â We can see that the concept is constantly developing. How do you think, in what direction the enterprise architecture is likely to change?
The EA profession is mired in a technology paradigm that grossly undersells its capability to bring coherence to the entire business. Infosys recently published a Survey in which the major finding is that “Alignment of business and IT organization is the #1 objective of enterprise architecture â€¦” That is certainly goodness, but how about assuring the all parts of the business are aligned with each other? How about ensuring all the oars are pulling together? According to the same survey some business-oriented indicators are starting to gain traction.
As mentioned above the Coherency Management book introduces a way to look at three distinct modes of EA – Foundation, Extended and Embedded â€“ that really shows how EA is, or can be, practiced. Foundation is where there is an enterprise-wide view and plan for technology and in more advanced enterprises there is use of Enterprise Business Architecture to ensure the technology and business are well aligned. This is the predominant form of EA practiced today. Extended is where the science, tools and techniques of EA are extended into (and used by) all parts of the enterprise to design/describe much more than technology. For example, it could be used to help design better policy or build better organization charts or improve service descriptions. Embedded is where EA science, tools, and techniques are ingrained in everyday processes and people contribute to the overall EA without being Enterprise Architects or necessarily knowing that they are contributing to the EA work. For example, the budget line items are conformant to EA standards which allows parts of the Enterpriseâ€™s Architecture to be updated on a regular basis but by people doing budgets not EA. The classic Enterprise Architect then (in addition to former duties) also ensures the artifacts created by the various process owners adhere to and contribute to an overall EA effort.
I am quite convinced that we in the coming years will see more and more enterprises moving beyond the Foundation mode, and embrace the Extended and Embedded modes. In many ways we can say that the ‘EA-nirvana’ is a balanced architecture, where the right combination of Foundation, Extended and Embedded ensures that you have a coherent enterprise.
6. Is the enterprise architecture appropriate tool to be used in time of recession?Â Or shall we wait for “better times” to implement it?
EA is indeed appropriate in recession times, I think. We know that EA is especially helpful in highly complex and dynamic environments, and have seen its benefits in, for example, M&A situations. EA is a good approach to counteract short-termism and yet to deliver immediate results, such as crucial prioritizations and essential impact analyses. So in fact, I see particularly many reasons for enterprises to adapt EA in these times. But do it right, well, and smart.
Some analysts out there are coming with drastic predictions about EA program closures, but this is not really what I see. Of course, some EA programs are shut down, but more often, they are reshuffled and reorganized, and quite often, this is perhaps not such a bad idea after all.
7. You have a lot of experience with enterprise architecture in government. Do you think that enterprise architecture is a good tool of transforming the way government organizations work?
Yes, I think that EA is crucial to transforming government, because it is essential for government to have an integrated and coherent approach to its strategies, business and technologies, and that is exactly what EA is all about. EA is often considered a transformational effort dealing with change, but as laudable that might be, this in fact falls well short of EA’s full potential. If we only ever do EA as part of a transformation project, how can EA ever tell us what transformation to make? Therefore, EA must become pervasive and regularized, and continuously be tied to ongoing strategic planning and corporate governance.
For the public administration, this means that EA is a way to enable that created policies are implementable and in fact implemented; that policy programs can meet their targets and create the outcomes they aim at; and of course also, that the ongoing e-transformations (e-gov, e-health, â€¦,e-*) are more successful.
8. You have a rich experience in implementation of enterprise architecture – both in companies and public administration units. Are the way of implementation and problems similar or are there some major differences between these two types of organization?
Although there are differences between public and private sector EA practices, organizations in both sectors are facing the same sorts of problems: Messy organizational politics, struggles between the lines of business, weak enterprise governance, etc. Actually, I think the two sectors can learn a lot from each other. The specific frameworks and such may be different, but they share a lot of challenges.
9. Does the concept of enterprise architecture come true in public administrations of different countries? Are there any differences between public administrations of different countries in approach to implementation of enterprise architecture?
As with other aspects of administrative policy and public management, there are both similarities and differences in play when comparing various countries and how they work with EA in the public administration. Some countries mandate EA by law to make sure that agencies ‘do’ EA, while others ‘just’ have national EA-programs for awareness, support and maybe some governance, and others have no EA-program at national level, but some have regional or municipal, or agency-based, programs.
10. How do you think we could measure benefits of enterprise architecture implementation in public administration?
You should look at measures that show EAs impact. This can be related to cost avoidance, risk mitigation, and much more, so a traditional business case is often difficult to establish. But you really only need one or two early ‘successes’ that demonstrates EAs value to the enterprise to get initial buy-in. However, the more successful EA becomes in adding value to the enterprise, the more invisible it becomes; we can call it EA by stealth, and that’s the situation where EA is done ‘everywhere’ in the enterprise.
11. What do you think is the role of enterprise architecture in ensuring interoperability of informatics systems? Can enterprise architecture facilitate paneuropean public e-services?
As the European IDABC activity about interoperability has shown (and NATO and others showed earlier on), standards are essential to create interoperability, and in my view, EA is a perfect ‘placeholder’ for an interoperability framework and standards policy. I was personally involved in the creation of the first European Interoperability Framework in 2003-2004, and even though that one didn’t promote EA, we did so when we implemented the Danish Government’s Interoperability Framework. Unfortunately, the interoperability work got swamped with politicised debates about open standards, most importantly the document format war between ODF and OOXML. Please note that I am 100% for open standards and 100% against vendor lock-in, and generally think that it is important for govenment to participate actively in international standardisation, but hated seeing how big vendors used the situation to take govenments as ‘hostages’ in the development of interoperable document standards.
EA could be a useful facilitator of paneuropean public e-services, and actually already helps doing so in the sense that it is already used at local/national level to identify services for digitalisation, etc. But at the European level, it is quite challenging. IDABC, or whatever it will be called in the future, is probably not the right place to put a European EA program becuase they’re ‘by nature’ IT-centric, as they demonstrate with the IDABC architectural guidelines.
12. What are the quick-wins of enterprise architecture implementation in public administration?
The quick-wins can be plenty, but will depend on how EA is approached and what is done in the initial phases. However, if EA is done blindly ‘by the book’, e.g., as prescribed in TOGAF’s ADM or in Carnegie Mellon University’s EA Implementation Methodology, chances are that there will be few quick-wins; rather, you should start out by understanding the context of the enterprise you implement EA in, and then identify some strategic and tactical initiatives where EA could help, and where there will be a clear business case for the initiative.
So, look at the enterprise’s major burning platforms, the in-your-face-as-you-walk-in-the-door as-is situation, and how the enterprise’s self-awareness about the as-is is. Sometimes, actually oftentimes, a simple maturity assessment and some good communication about this can have a huge impact in terms of getting acceptance and buy-in to initiatives. In many cases, getting buy-in for an initiative can itself be regarded as a quick-win of the EA, because before the EA, the sponsor couldn’t get buy-in.
13.Could you share your experiences connected with the work Danish national policy for a government-wide enterprise architecture and interoperability framework?
The Danish Government’s EA practice, which I helped give birth to (2003-2005), 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.
14. What are your experiences in teaching enterprise architecture at the university? What are the main challenges that arise from transmission of such knowledge?
I love teaching at the university, and EA is my absolute favorite teaching subject. My actual experience is that I have been running a master-level (M.Sc.) course in EA at the IT University of Copenhagen for 5 years, and also been supervising many master’s thesis projects about EA. One the overall challenges is that there is just as much ‘unlearning’ as actual ‘learning’ in play when getting into EA as a discipline; especially with IT-students who often need to ‘unlearn’ technocentricity etc. Since EA is what we call a pracademic discipline â€“ practitioner-based and academic â€“ EA may be seen as a special challenge to the classical university student (i.e., one who is yet to meet the ‘reality out there’/practice), and as such does pose some fundamental didactic challenges. The way I deal with this is, first, that I invite many practitioners in both as students (via Open University) and as guest lecturers, and second, that student projects very often are case-oriented. This is, as is happens, very useful from both the practitioners and the ‘pure’ academics.
I think EA is worth of being the subject of a full degree program, rather than, as in my case, a single module within an e-business program. My graduates clearly could have a more ‘pure’ EA-profile, if I could have build their whole Master’s program up around EA.
15. Do you think that we should make an effort to elaborate National Enterprise Architecture?
Yes! To be frank, I know very little about the EA-situation in Poland, but my point here is that any nation should take good care of their national enterprise architecture. There are many advantages of running a national EA program, which deals with cross-agency (joined-up) initiatives, such as shared services, and takes on a responsibility for creating guidance and leadership in various segments.
A couple of years ago, in an organization called ICA (The International Council for Information Technology in Government Administration), I chaired a study group about national EA programs. One of the main lessons I learned was that with concerted and bold national efforts, EA in government is much more likely to work. If EA is purely seen as an agency-level concern, it will have limited success, because many of the advantages of doing EA in government is in cross-agency areas.