Enterprise Architecture at the Crossroads
Enterprise Architecture is facing several challenges as a discipline and a practice. In this blog post, John Gøtze outlines four central challenges, and discusses what should be done. He suggests that enterprise architecture management must focus on enterprise collaboration.
The discipline Enterprise Architecture (EA) is at a crossroads, facing four challenges:
- The first challenge is to overcome the narrowness of scope of present practice in EA, and re-gain the coverage of the entire business on all levels of management, and a holistic and systemic coverage of the enterprise as an economic entity in its social and ecological environment.
- The second challenge is how to face the problems caused by complexity that limit the controllability and manageability of the enterprise as a system.
- The third challenge is connected with the complexity problem, and describes fundamental issues of sustainability and viability.
- Following from the third, the fourth challenge is to identify modes of survival for systems, and dynamic system architectures that evolve and are resilient to changes of the environment in which they live.
A recent (in-press) peer-reviewed article, Enterprise Engineering and Management at the Crossroads – the result of a collaborative effort between eleven authors from four continents – discusses these four challenges and the state of the art of the discipline of Enterprise Architecture, with emphasis on the challenges and future development opportunities of the underlying information system, and its IT implementation, the Enterprise Information System (EIS).
The article provides pointers to possible radical changes to models, methodologies, theories and tools in EIS design and implementation, with the potential to solve these grand challenges:
The article argues that EA needs to embrace full or broad views of the enterprise as per the original vision of the discipline’s mission that originated in manufacturing (e.g. computer integrated manufacturing systems), and the parallel developments in information systems and software development. This division between information systems, system science, and manufacturing & industrial engineering needs to be resolved as it is still felt today and hampers the discipline of EA as a whole. Any credible development of the discipline must equally cover and explain deliberate change and evolutionary change in a system of socio-technical systems, the production & service to the customer, and the management & control of the enterprise, the technical resources (logistics, manufacturing machinery, communication systems, computer systems), human resources, financial resources, and assets of all other kind (knowledge & information assets, buildings and grounds, and various intangibles).
As EA is moving up the hierarchy from technical to management levels, the language and skill set of its practitioners has to change to better reflect the specific needs and language of the management community. This needs to be reflective in terms of not only language, but also culture. The focus must be on views of the organisation that management science is interested in (People, Capability, Place, Role, Relationships and Trust, Risk, Finance, Brand Strategy, Knowledge Management) rather than detailed, possibly local technical views of the organisation.
A central concern in EA is the development of the information system that implements a coherent, aware behaviour of the enterprise on any scale. It is acceptable (even desirable) that the implementation of these properties should not have a single locus, so that the system should display these properties without a single subsystem or system component being responsible for them. If awareness and coherency are emergent properties of the enterprise, it is likely that the enterprise (and its information system) would be more resilient in terms of being able to maintain these systemic properties.
A New Paradigm for EA
The article suggests a new paradigm for EA:
It is clear that the future is not in EA reinventing the complete gamut of management models, but it is in providing a unifying platform through which the multiple models used in the various life cycle phases and in the various stages of the enterprise’s life history can be combined. The combination needs a new paradigm though, as current EA methodologies struggle with the reality of complex relationships among models present at different abstraction levels. In essence, guided evolution of the enterprise requires that enterprise modelling not be seen as a top-down or bottom up process, but as a powerful problem finding and problem solving tool that supports transformational activities both on the strategic and operational levels.
In my article from 2013, The Changing Role of the Enterprise Architect, I argue that in facing ‘wicked problems’, enterprise architects must focus more on problem-finding than problem-solving; true craftsmen look at situations in a problem-finding manner, rather than blindly applying the same method and tool every time to what may be a new and interesting challenge.
Enterprise architecture practice must be collaborative, and enterprise architects should be cooperative in character, able to engage in many kinds of communication and collaboration. I argue that enterprise architects must have both:
- dialectic skills and competencies in resolving conflicts, creating consensus, synthesis and common understanding, detecting what might establish that common ground, and the skill of seeking the intent rather than just reading the face value of the words, and
- dialogic skills including listening well, behaving tactfully, finding points of agreement, managing disagreement, and avoiding frustration in a difficult discussion.
Jason Uppal picks up on this in his lecture at a recent EA conference.
The dialectic/dialogic distinction is of course a classic discourse in educational research (see for example Rupert Wegerif, Richard Paul, and Andrew Ravenscroft) and generally throughout the critical social sciences (“Bakhtinian dialogic and Vygotsky’s dialectic”) ever since Hegel.
In Together: The Rituals, Pleasures, and Politics of Cooperation sociologist Richard Sennett states that the distinction between dialogic and dialectic is fundamental to understanding human communication. Sennett says that dialectic deals with the explicit meaning of statements, and tends to lead to closure and resolution. Whereas dialogic processes, especially those involved with regular spoken conversation, involve a type of listening that attends to the implicit intentions behind the speaker’s actual words. Unlike a dialectic process, dialogics often do not lead to closure and remain unresolved. Compared to dialectics, a dialogic exchange can be less competitive, and more suitable for facilitating cooperation. Sennett explains further in a lecture at Harvard: The Architecture of Cooperation.
The Importance of Enterprise Collaboration
Cooperation and collaboration are closely related concepts, and often thought of as synonymous. In fact, they are quite different.
Oscar Berg‘s Collaboration Pyramid may explain the difference:
Berg distinguishes between the three layers in this way:
- The community is the enterprise seen as a group of individuals that share the same purpose, vision and values. It is about shared attitudes and behaviors within the enterprise, or the culture if you like. It is also about the individual’s ability to be seen, participate and be recognized, all of which are fundamental for developing a sense of belonging, identity, and self-confidence.
- Cooperation is about people enabling each other to do something, for example by providing a person with information or other resources that make the person more able to perform a task. Cooperation can be seen as the opposite of selfishness and competition. People help each other out for some mutual benefit.
- Collaboration is about a team of people that work closely together to achieve a certain goal. It can be a permanent team, like a production unit at an assembly line, or temporary team, like a project team. The team would most likely have a formally appointed leader, someone who is responsible for the planning, coordination, follow-up, and communication within the team as well as the world outside the team.
Enterprise collaboration is a term that covers all these three all-important concepts of the “social” enterprise. The term is often mistakenly used to cover social networking tools and intranet, but should be seen as a wider concept and a more comprehensive platform for the enterprise, wherefrom strategic alignment and viable process and information flows are tangible outcomes.
In our Collaboration whitepaper, we explain further how QualiWare is enabling our customers to work with collaboration in their enterprise architecture work.
European Government Enterprise Architecture: Interoperability Architecture
European Government Enterprise Architecture: Interoperability Architecture
European public-sector EA must deliver actionable recommendations and effective solution designs to support government demands for interoperability and digitalization.
Gartner: Interview With Dr. John Gøtze: Outcome-Driven
Public-Sector EA in Europe. 30 April 2015
Government Enterprise Architecture (GEA) in the European context has two major levels:
- Each country’s own National GEA practice
- European GEA practice
Strictly speaking, the European practice has not been called Enterprise Architecture per se, but was and is in all but name a Government Enterprise Architecture practice (“EA by stealth”).
It became the theme interoperability that caught the attention of the European Commission, who defines interoperability as the facilitation of cross-border and cross-sector information exchange, taking into account legal, organisational, semantic and technical aspects (source).
From IDA to ISA2
The Inter-Change of Data Between Administrations programme (IDA) was launched in 1995 and later became the Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens programme (IDABC), which offered funding of some €25 million per year from 2004-2009 for various pan-European interoperability projects. One of these projects formulated the European Interoperability Framework v1, published in 2004, which provides recommendations and defines generic standards with regard to organizational, semantic and technical aspects of interoperability, offering a comprehensive set of principles for European cooperation in eGovernment. The framework was accompanied by the IDA Architecture Guidelines. Updated in 2010, the framework (now European Interoperability Framework v2) became part of the European Interoperability Strategy.
For continued work on European interoperability, a new programme was established in 2010: The ISA Programme, Interoperability Solutions for European Public Administrations:
Public administrations are expected to provide efficient public services to businesses and citizens across Europe. ISA, the programme on Interoperability Solutions for European Public Administrations, addresses this need. ISA supports and facilitates efficient and effective cross-border electronic collaboration between European public administrations. The programme enables the delivery of electronic public services and ensures the availability, interoperability, re-use and sharing of common solutions (source).
With a budget of €164 million for the period from 2010-2015, the ISA programme has established a number of action areas.
The ISA action on Interoperability architecture studies the possibility of structuring European public information systems and services around a joint architectural blueprint. This action develops together with the Member States and the relevant European Commission departments a joint vision for an Interoperability Architecture for European public services. This involves outlining its scope, deciding how the architectural building blocks will fit together, and determining the need for interface standards between such building blocks, tools and services that can be reused across borders and sectors, such as the following:
- a multilingual service, CIRCABC provides private workspaces for collaborative groups to share information and documentation;
- a Machine translation service can be used by European public administrations to facilitate efficient and effective electronic cross-border interaction;
- the sTesta project provides a secure private European network for data exchange between all the EU Institutions and national networks.
ISA has further supported the development of interoperability-related recommendations for the assessment of standards and specifications used by Member States when acquiring electronic tools and services. The aim to create not only more interoperable information systems but also more efficient use of public funds via sharing and reuse of completed assessments among eGovernment projects. The National Interoperability Framework Observatory tries to help in the sharing, and collects/creates informative Member State Factsheets.
On 26 June 2014, the European Commission adopted a proposal for a Decision of the European Parliament and of the Council establishing a programme on interoperability solutions for European public administrations, businesses and citizens (ISA2). The proposal will now be transmitted to the Council and the European Parliament. Once adopted by these, it will be implemented by the European Commission based on proposals submitted by the Member States and the Commission services. ISA2 will cover the period 2016-2020 with a financial envelope of €131 million.
- Conceptual Reference Architecture. This involves defining conceptual reference building blocks that are needed in order to build systems supporting public services. A conceptual reference architecture captures the fundamental patterns and concepts that should be applicable for all domains and more specific architectures.
- Cartography. This involves mapping existing reusable solutions towards the conceptual reference building blocks. The cartography is meant to include solutions that are readily reusable.
European Interoperability Reference Architecture
The European Interoperability Reference Architecture (EIRA) is
an architecture content metamodel defining the most salient architectural building blocks (ABBs) needed to build interoperable e-Government systems.
On 8 June 2015, release 0.9.0 beta of the EIRA entered an eight-week public review period. Stakeholders working for public administrations in the field of architecture and interoperability were invited to provide feedback.
What is EIRA?
The EIRA provides a common terminology that “can be used by people working for public administrations in various architecture and system development tasks“. The EIRA initiative is part of Action 2.1 of the ISA Programme.
The EIRA is a four-view reference architecture for delivering interoperable digital public services across borders and sectors. It defines the required capabilities for promoting interoperability as a set of architecture building blocks (ABBs). The EIRA has four main characteristics:
- Common terminology to achieve a minimum level of coordination: It provides a set of well-defined ABBs that provide a minimal common understanding of the most important building blocks needed to build interoperable public services.
- Reference architecture for delivering digital public services: It offers a framework to categorise (re)usable solution building blocks (SBBs) of an e-Government solution. It allows portfolio managers to rationalise, manage and document their portfolio of solutions.
- Technology- and product-neutral and a service-oriented architecture (SOA) style: The EIRA adopts a service-oriented architecture style and promotes ArchiMate as a modelling notation. In fact, the EIRA ABBs can be seen as an extension of the model concepts in ArchiMate.
- Alignment with EIF and TOGAF: The EIRA is aligned with the European Interoperability Framework (EIF) and complies with the context given in the European Interoperability Strategy (EIS) . The views of the EIRA correspond to the interoperability levels in the EIF: legal, organisational, semantic and technical interoperability. Within TOGAF and the Enterprise Architecture Continuum, EIRA focuses on the architecture continuum. It re-uses terminology and paradigms from TOGAF such as architecture patterns, building blocks and views.
EIRA in one picture
The figure below provides a high-level overview of the four views in EIRA. Each of the four views consists of a set of Architecture Building Blocks (ABBs) and relations pertaining to the legal, organisational, semantic and technical domain of an Interoperable European Architecture. Each view has entry and exit points from one view to another.
The legal, organisational, semantic and technical domains are the classic European interoperability concerns. The EIRA defines building blocks for each view.
In addition, a new Interoperability specification underpinning view has been added as an additional view, depicting architecture building blocks of the different views as a taxonomy of interoperability specifications:
EIRAs raison d’etre?
The key concepts of the EIRA and their relationships are described here:
The following list explains the different relationships:
A. The EIRA is derived from the European Interoperability Framework (EIF);
B. The EIRA has one view for each EIF interoperability level;
C. Each EIRA view contains several EIRA ABBs;
D. EIRA ABBs can be used to create reference architectures;
E. A SAT addresses a certain interoperability need. It consists of a sub-set of the most important EIRA ABBs and is derived from a reference architecture;
F. An EIRA SBB realizes one or more EIRA ABB;
G. A (interoperable) solution consists of one or more SBBs;
H. A (interoperable) solution realizes a solution architecture;
I. A solution architecture can be derived from a SAT or directly from a reference architecture;
J. As the EIRA focuses only on the most important ABBs needed for interoperability, other ABBs (= non-EIRA ABBs) can exist;
K. Similar to ABBs, non-EIRA SBBs can exist next to EIRA SBBs.
Release 0.9 of the EIRA does not provide as much detail about the SBBs as it does on the ABBs. This will be done in another project. Also see the SBB template document.
Further information about the EIRA can be obtained in the document ‘An introduction to the European Interoperability Reference Architecture v0.9.0’ (EIRA_v0.9.0_beta_overview.pdf). The release consists of the following release components:
- EIRA_v0.9.0_beta.archimate: Archi file containing the EIRA ArchiMate model.
- EIRA_v0.9.0_beta.html: HTML version of the EIRA ArchiMate model.
- EIRA_v0.9.0_beta_overview.pdf: PDF document containing an introduction to the EIRA, including its key concepts, used ArchiMate notation, tool support, and views.
- EIRA_v0.9.0_beta_ABBs: An HTML file containing the definitions of the architecture building blocks.
- EIRA_v0.9.0_beta_release_notes.pdf: PDF document containing the release notes.
- EIRA_v0.9.0_beta_release_document_set.zip: Zip file containing each of the above mentioned files.
Quick analysis of EIRA
EIRA lists 161 architecture building blocks. Of these, more than half are technical:
- 82 Technical View (27 Application and 55 Infrastructure)
- 26 Organisational View
- 19 Semantic View
- 18 Legal View
- 6 Interoperability View
- 10 Deprecated (11 if ABB59 Logging Service included – not marked in View:Deprecated but in Status).
The building blocks are described via selected archimate model concepts, of which four are used a lot:
- 40 archimate:ApplicationService
- 34 archimate:BusinessObject
- 26 archimate:ApplicationComponent
- 18 archimate:DataObject
Other model concepts are also used:
- 6 archimate:BusinessProcess
- 5 archimate:Contract
- 4 archimate:BusinessActor
- 3 archimate:BusinessRole
- 3 archimate:InfrastructureService
- 3 archimate:Network
- 3 archimate:Node
- 2 archimate:ApplicationInterface
- 1 archimate:BusinessFunction
- 1 archimate:BusinessInteraction
- 1 archimate:BusinessInterface
- 1 archimate:BusinessService
So, looking at the big picture, EIRA is perhaps a bit “heavy” on the technology side of interoperability, but does cover the four layers. In particular, EIRA establishes a set of views across the four layers. In doing so, it has to “embrace and extend” ArchiMate.
EIRA and ArchiMate
EIRAs commitment to ArchiMate is somewhat courageous. And somewhat creative, for example:
- EIRAs Business Capability is covered by archimate:BusinessFunction
- EIRAs Business Information Exchange is covered by archimate:BusinessInteraction
A Business Capability is the expression or the articulation of the capacity, materials and expertise an organization needs in order to perform core functions. Enterprise architects use business capabilities to illustrate the over-arching needs of the business in order to better strategize IT solutions that meet those business needs.
A Business Information Exchange is a piece of business data or a group of pieces of business data with a unique business semantics definition in a specific business context [ISO15000-5, UN/CEFACT CCTS].
These are work-arounds to two well-known ArchiMate limitations.
The archimate:BusinessObject is also quite busy, and for example covers these ABBs:
- Business Rule
- Business Information
- Organisational Procedure
- Organisational Structure
Again, work-arounds to current ArchiMate limitations.
EIRAs ABBs have changed with each release. Deprecated ABBs in the 0.9 beta include:
- Business Process
- Business Process Model
- Business Transaction
- Licensing and Charging Policy
- Metadata Management Policy
- Data Routing Service
- Data Routing Component
- Information Security Policy
- Data Quality Policy
- Logging Service?
So, Business Process and Business Process Model are deprecated, but the archimate:BusinessProcess model concept is used several times, namely for these ABBs:
- Public Policy Cycle
- Definition of Public Policy Objectives
- Formulation of Public Policy Scenarios
- Impact Assessment
- Public Policy Implementation
- Public Policy Evaluation
ArchiMate of course allows for a certain amount of flexibility (ArchiMate 2.1, Chapter 9 Language Extension Mechanisms), but the creativity can be dangerous, expecially in an interoperability context.
EIRA is an many ways ahead of ArchiMate. The challenge is that ArchiMate is under continuous development, and is likely to change on exactly these areas in future versions (see chapter 12.1 in the ArchiMate 2.1 spec). So EIRAs current notation standard should be seen as a temporary “fix”.
A note of caution
EIRA has obviously selected a winner of the longstanding Process vs Capability Debate. Eradicating processes is rather bold, and contrary to advice from experts like Roger Burlton, Paul Harmon, Alan Ramias and Andrew Spanyi, and Keith Swenson. While it is laudable to focus on capabilities, the use of capabilities should not be seen as an alternative to using processes and business process models. Both are needed.
EIRA and Open Data
The EIRA model is available as an Archi file. The data is also available in Archi-produced HTML and images.
From a maturity standpoint, this is only just acceptable. Even an Excel sheet version would be better, but better would be “raw data” available in a range of formats, possible as an api.
Of course, The Open Group is working on an ArchiMate Model Exchange File Format, and has sponsored the development of an Archi plugin for exporting to that format.
Apart from listing a few generic and rather useless Dublin Core metatags (in the HTML table), the current EIRA model is weak on metadata provision. EIRA could, for example, have used Data Catalog Vocabulary (DCAT) and Asset Description Metadata Schema (ADMS), and the team may want to check out this guide.
EIRA does not have any mapping to any other framework.
The Legal and the Organisational views are less conventional as architecture views go. The Semantic, Application (Technical) amd Infrastructure (Technical) views are classic architecture views in many EA frameworks. A comparison with established frameworks seems to be a good idea.
A key part of the US Federal Enterprise Architecture Framework Version 2 (FEAF-II) is the Consolidated Reference Model, which equips the US Federal Government and its Federal agencies with a common language and framework to describe and analyze investments. It consists of a set of interrelated reference models that describe the six sub-architecture domains in the framework:
EIRAs Legal view is roughly equivalent to FEAF-IIs Strategy (Performance Reference Model), and EIRAs Organisational view roughly equivalent to FEAF-IIs Business Reference Model.
Contentwise, EIRA and FEAF-II use these two layers in different ways:
EIRAs model scope is wider than FEAF-IIs, but FEAF-II is more comprehensive as a classification scheme.
EIRA should consider taking inspiration from FEAF-II, and at least add a security view. If anything, such view should become mandatory for all European governments.
Towards EIRA 1.0
The 0.9 release of EIRA is a big step forward for reference architecture work in European governments.
QualiWare proposes a rapid consolidation and documentation process, and then releasing Version 1.0. EIRA should not await the next version of ArchiMate, but rather run with well-documented revision control.
QualiWare is committed to supporting international governments in their interoperability work. QualiWare fully supports using ArchiMate 2.1. If customer demand requires it, the “EIRA ArchiMate” approach can easily be supported.
QualiWare Conference Coming Up
On 5-6 May, at Axelborg in Copenhagen, we hold the QualiWare user community’s annual gathering. The two days are packed with keynotes, thematic sessions, and customer cases. And a game.
We have four keynotes:
- The future of managed business transformation by Kuno Brodersen
- The Fourth Industrial Revolution: How “Industry 4.0” becomes Smart Production by Professor Charles Møller
- Expanding Enterprise Architecture to Enable Business Transformation by Louise Harris
- Integrated EA as a steering instrument by Dr. Achim Kamelger, OMV
We also have a wide range of sessions and workshops, and several customer cases including Maersk Oil, SOS, OMV, SDC, ATP, and Apply Sørco. See the full program here.
Seats are still available, and you can register here.