QualiWare + EA Professional Development Days 2017

presents the 2017 QualiWare + EA Professional Development Days 2017

Ottawa, February 6-10, 2017

Presentations – 2017 QualiWare+EA Professional Development Days Presentations (Ottawa, Canada)

CloseReach and QualiWare invite you to join us for the 3rd annual QualiWare + EA Professional Development Days. An event to promote networking, learning and collaboration for Architects and QualiWare enthusiasts, novices and experts alike.

Meet other QualiWare users, Business and Enterprise Architects, Project Managers, Analysts, BPM Specialists and Quality Managers. Share architecture and QualiWare experiences. Learn from customer case studies. Take part in interactive ideas exchanges. Influence product development.

Building on the success of 2016, we will be expanding your opportunities for learning and knowledge sharing. Join us for this excellent professional development opportunity:

Speakers Day (Monday) – the best place to hear about the latest developments in enterprise architecture and business transformation in Canada and globally. Speakers Day early bird pricing is in effect: $250 per person, 5-pack: $1,125.00, 10-pack: $2,125.00. HST extra. Includes a great day of speakers as well as breakfast and lunch.

Featured Speakers:

  • Kuno Brodersen – EA and Digital Transformation Strategies
    • A leader in the business modeling and enterprise architecture field for more than 30 years.
    • CEO and Co- Founder of QualiWare ApS. QualiWare provides comprehensive modeling tools and consulting services that focus on enhancing business efficiency, effectiveness, productivity, competitive positioning, and organizational profitability. QualiWare’s products and services help the customer succeed with Quality Management, Process Management and Optimization initiatives, Business Excellence programs, Enterprise Architecture initiatives, and/or IT solution development needs.
  • Roger Burlton – A Journey from Business Architecture to a Digital Process? A Case Study in Government Transformation
    • Respected pioneer in the introduction of innovative approaches for Business Architecture and Process Management
    • A leader in the field of Business Process Management, having authored one of the most
      read and followed books on the topic early in BPM’s growth.
    • Chair of the BPTrends.com Advisory Board
  • Stephen Challinor – Enterprise Architecture as a Business Enabler
    • Director Enterprise Architecture, Department of National Defence
    • Co-Chair Government of Canada EA Working Group
    • 27-year career as a public servant with a broad background in complex project and procurement management, weapon systems and equipment management, business and financial management, IM/IT systems and Alternate Service Delivery (ASD) initiatives.
  • Skip Lumley – Developing and Implementing a Pan-Canadian Standard for Public Sector Business Architecture
    • Co-founded and managed the consulting firm Chartwell IRM Inc. from 1984 until its acquisition in 2010 by KPMG Canada.
    • Leader in the development and support of government reference models: the Municipal Reference Model (MRM), the Public Service Reference Model (Province of Ontario) and the Governments of Canada Strategic Reference Model (GSRM).
    • Currently serving as an independent advisor to public and civic sector organizations on the use of reference models for program review, policy development, strategic planning and change management.
  • Stephen White – Digitalizing Your Business Processes
    • Business Process Management Institute (BPMI) Board of Directors
    • Former Chair of BPMI Notation Working Group and author/editor of Business Process Modeling Notation (BPMN) 1.0 & 2.0 Technical Specification
    • Chair of OMG Revision Task Force and Co-Chair of OMG FTF for BPMN 2.0
    • Contributor to OMG CMMN 1.0 specification
    • Co-Authored Book “BPMN modeling and reference guide”

Tool-Day (Tuesday) – How-To Seminars/Workshops: Business Modelling (BPMN, Capability Modelling, Requirements & Traceability); Collaboration using QualiWare Web Publishing; Change & Problem Management using QualiWare Governance Workflow Engine; Modelling Revision Management, Back-up and Recovery Strategies.

Tuesday seminars/workshops are offered at the nominal (full day) cost of $20.00 + HST per person with 100% of proceeds being donated to the Royal Ottawa PTSD Clinic.

Business Architecture Training (Tuesday-Friday) – “Made in Canada” Business Architecture training & certification with Roger Burlton.

QualiWare Training (Wednesday-Friday) – take full advantage of QualiWare’s EA software

  • QualiWare Data Visualization
  • QualiWare Command Language (QCL) Basic.

For more information or advance seating reservations for Speakers Day and all of the week’s events, contact Susan Wolfenden; susan@closereach.ca, 613-825-1769. Space is limited – call now!

Please feel free to share this invitation with colleagues.
Help us make this event the place to be in Canada for all things architecture related!

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:

  1. Each country’s own National GEA practice
  2. 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;
  • 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.

Current efforts:

  1. 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.
  2. 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.

The views

Legal interoperability View
Organisational interoperability view

Semantic interoperability view
Technology interoperability view – applications

Technology interoperability view – infrastructure

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:

The “metaview” detailing and specifying interoperability.

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:

  1. EIRA_v0.9.0_beta.archimate: Archi file containing the EIRA ArchiMate model.
  2. EIRA_v0.9.0_beta.html: HTML version of the EIRA ArchiMate model.
  3. 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.
  4. EIRA_v0.9.0_beta_ABBs: An HTML file containing the definitions of the architecture building blocks.
  5. EIRA_v0.9.0_beta_release_notes.pdf: PDF document containing the release notes.
  6. 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
  • Privacy 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 BurltonPaul HarmonAlan 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.

Interoperable frameworks?

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:crm

  • Strategy
  • Business
  • Data
  • Applications
  • Infrastructure
  • Security

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:

US FEAF-II Performance Reference Model
EU EIRA Legal Interoperability view

EIRAs organisational view
US FEAF-II Business Reference Model

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:

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.


QualiWare Academy

Digital Academy

Learn to work with the QualiWare LifeCycle Manager (QLM) platform. 

Our free digital Starter course gives a comprehensive introduction to our platform. Take the course at your desktop, on your tablet, whenever you want. It’s free.

Instructorled Class Training

QualiWare Academy offers a range of in-class educational services that can be delivered both on premises or online.

Contact Sales@QualiWare.com for more information.

QualiWare EA³ Living Enterprise

QualiWare fully supports the EA3 approach.

The EA3 Approach suggests using the Living Enterprise EA repository design pattern with hierarchical rows and functional columns

The design of the Living Enterprise EA repository may look similar to Zachman’s classic framework, in that it uses hierarchical rows and functional columns. However, it is different in that:

Living Enterprise
  1. it is based on a separate meta-framework (the EA3 Cube Framework);
  2. it uses three hierarchical levels;
  3. the functional columns are not based on basic interrogative questions, but on the 5 layered cube with one or more cross-cutting layers (EA3 default includes security). Other columns can be added;
  4. the cells of the matrix are changeable and are often populated with EA documentation that represents composite views of several types of primitive models;
  5. it has areas for additional information on the EA program; and
  6. it is designed to be implemented as a website and therefore has navigation and version control features.

These six points are the basic Living Enterprise EA repository design rules, and can be seen as a way to measure conformance and compliancy of EA3 implementations.

QualiWare EA and EA3

qwframeworkQualiWare’s EA ArchitectureFramework is fully compliant with the Living Enterprise requirements. It uses hierarchical rows and functional columns; it uses a meta-framework; its columns are architectural layers; it has changeable cells; it is supported by additional information and EA management functions; and the QualiWare EA toolset includes a very powerful web-platform with support for collaborative decision making, social collaboration, social analytics and governance workflow management such as delegation of responsibilities for information sharing and consultation.

QualiWare’s framework orders the columns slightly different from the Living Architecture default, and has an Organization column instead of a Security column. A cell-by-cell comparison of the QualiWare framework and the default Living Enterprise is provided below. Implementers of an EA Framework and repository design are advised to review each cell (and column) in both these frameworks, and use whatever makes sense.


EA3 Living Enterprise


Strategic Goals and Initiatives Column

Strategy Mission and Vision Cell:
Here is where the enterprise’s mission and vision statements are located. These are the highest level policy statements that the enterprise has, reflecting why the enterprise exists and in general what it strives to be.
Policies Goals and Initiatives Cell:
Here is where a list of the enterprise’s strategic goals and initiatives is presented. For each strategic goal the desired outcome should be identified. For each strategic initiative, mapping to the goal(s) should be provided, as well as identification of the performance gaps that the initiative will correct. If there is an IT component in the initiative, that should be clearly identified. Each strategic initiative should then be hyperlinked to amplifying metrics information in the Performance Measures Cell, as well as related investments in the Business servIces column.
Business Rules Performance Measures Cell:
Here is where the IT performance gaps are again identified for each strategic initiative. Then the outcome and output measures are provided that will measure the success of each initiative. Tracking information on the measures should also be provided, beginning with the original levels of achievement in each measurement area (called the “baseline”), and subsequent levels of achievement, which will form a trend line that tracks toward a goal level of improved level of performance.


Business Products and Services Column

Business Process Model Lines of Business Cell:
Here is where the basic areas of activity (lines of business) for the enterprise are identified. The lines of business should support the enterprise’s strategic goals and initiatives, or there is no reason to be doing those activities … they are not adding value. To better show this, the lines of business should be hyperlinked to the strategic goals and initiatives that they support in the Strategic Initiatives column.
Business Process Design Investment Portfolio Cell:
Here is where the enterprise’s investments in IT are shown. When aggregated, these investments form an “investment portfolio”. This portfolio should be documented along with categories for investments in IT (e.g., IT operations, office automation, IT research and development, IT infrastructure). Information on the business case for each particular investment should be shown, to include how the investment supports a particular strategic initiative and/or LOB. Investment performance information on the overall portfolio and individual investments should also be provided in this cell.
Work Flow IT Projects Cell:
Here is where information on all of the active IT projects throughout the enterprise are shown. Project Management Plans and other associated documentation are the types of EA artifacts that should be archived in this area. Summaries of Earned Value Management information regarding project status are also helpful (e.g., planned vs. actual cost, schedule, and performance graphs).


Systems and Applications Column

Application Architecture Support Services Cell:
Here is where the overall view of business-related support services is presented in a format which promotes an understanding of how these resources are supporting the information sharing requirements of each LOB. There is a focus on supporting business operations in this cell. As was presented in Figure 7-7, an effective presentation format is a high level diagram that shows the applications being used within each LOB and across the enterprise, and shows this as distinct areas of support (e.g., databases, operating systems, websites, and middleware ).
System Design Front Office Systems Cell:
Here is where the overall suite of front office support systems and applications are presented in a format that promotes an understanding of how they support the enterprise’s information sharing requirements across all LOBs. This includes ERP solutions, supply chain management systems, customer relationship management systems, sales and marketing supports, manufacturing support, and on-line e-commerce transactions.
Component Model Back Office Systems Cell:
Here is where the overall suite of back office (administrative) systems and applications are presented in a format that promotes an understanding of how they support the enterprise’s administrative support requirements across all LOBs. This includes financial and accounting systems, human resource systems, a common email system, telephone, video-teleconferencing, fax, print, and copying systems. Also located here are the standard desktop, laptop, and personal digital assistant applications. Enterprises increasingly are distributed across multiple geographical locations, have individuals who are telecommuting, and have individuals in the field doing remote-site work and/or meeting with customers. This creates requirements for portable computing that should be documented in this cell, along with a clear picture of how information is being shared between these computing platforms to support LOB processes.


Data and Information Column

Semantic Model Knowledge Management Cell:
Here is where the enterprise’s approach to Knowledge Management (KM) is provided. Items to be covered include the overall concept for sharing knowledge, information, and data, as well as whether there is an acknowledged commitment to being a learning enterprise. A learning enterprise is one which has a process for evaluating LOB processes and the management of programs and projects, and continually incorporating the lessons learned into the improvement of those processes, programs, and projects. In this way a culture of learning is created which can lead to increased levels of performance for the enterprise. Documentation of this can be effectively accomplished through a combination of diagrams and text descriptions of the EA Components that are active in aggregating data into information and then into knowledge, as well as how that knowledge is shared (e.g., knowledge warehouses, data marts, storage area networks, and databases).
Logical Data Model Data Flows Cell:
Here is where the sharing and transformation of information and data is documented for all processes in the enterprise’s LOBs. Documentation should also reveal how the information and data is used within each LOB, in the form of requirements. Documentation methods should provide the structure of basic data entities/objects, the rules for relationships between these data entities/objects, and the flow of the data entities/objects through the various EA Components at the Information Level of the EA3 Framework. This includes EntityRelationship Diagrams and Data Flow Diagrams that document relational databases and are used in procedural programming languages such as CaBaL, FORTRAN, and C. It also includes object-oriented documentation using the Unified Modeling Language, which documents object-based databases that are created using event-driven programming languages such as JAVA, SMALLTALK, and C++.
Physical Data Model Data Dictionary Cell:
Here is where standards and the format for the enterprise’s data entities/objects are documented, and where a link is provided to a library (database repository) of those entities and objects. The library promotes the reuse of data entities and objects throughout the EA components, which increases interoperability and lowers development costs.


Security Solution Column

Stakeholder Model Policy and Procedures Cell:
Here is where a high level view is presented of the enterprise’s policies regarding IT security. Key extracts form the enterprise’s IT Security Plan are appropriate that link to specific Standard Operating Procedures (SOPs) to handle various IT security activities and the response to security incidents (e.g., password policies, access procedures, user agreements, virus protection, inappropriate material, and incident handling). The full text of the IT Security Plan and the SOPs should be available in this cell, and links to additional educational information on IT security should be available in this cell and links to additional educational information on IT security should be provided. IT Security on particular vulnerabilities should not be part of the documentation available in this cell, as it should be protected from all but those with a need-to-know. This protected information includes EA component security plans, risk analysis reports, security test and evaluation results, disaster recovery procedures, and technical diagrams of security hardware and software.
Organization Model Data Privacy Cell:
Here is where the enterprise’s policy on information privacy is presented. How information and data are collected, archived, and disseminated should be covered for each EA component at the Business Process Level and the Information Flows Level of the EA3 framework, with comments on how privacy requirements are being met. For example, in on-line financial transactions credit card information must be protected. For general sales and marketing databases, customer contact information must be protected.
Human Resource Model IT Inventory Cell:
Here is where an inventory of all IT resources (hardware and software) in each EA component throughout the enterprise is maintained. This inventory not only promotes effective IT security, but also enables EA planners to obtain information on the “as-is” business and technology operating environment. For example, to support a decision on purchasing an upgrade to a COTS product, it is important to know how many licenses are currently owned, and when the expiration date is. In another example, knowing how many desktop PCs of a particular type exist can help procurement decisions that accompany “technology refreshments” throughout the enterprise that need to occur every two to three years.


Networks and Infrastructure Column

Strategic Technology Model Common Operating Environment Cell:
Here is where information about the enterprise’s Common Operating Environment (COE) is presented. The COE is the integrated business and technology operating environment, wherein a seamless voice, data, and video network infrastructure hosts front office and back office services and systems.
Business Technology Wide Area Network Cell:
Here is where information about the enterprise’s Wide Area Network (WAN) is presented. An effective way to present information about the WAN is a map with WAN symbols for hardware and communication links that are hyperlinks, that when clickedon lead to a new level of detail about that part of the WAN (e.g., dedicated voice and data lines, wireless links, interfaces with service providers). Also appropriate for documentation in this cell is the connectivity for Supply Chains and/or information transfer via Extranets that connect to specific external business partners and/or remote office locations. Standards for voice, data, and video WAN components should also be available in this cell.
Physical Technology Local Area Network Cell:
Here is where information about the enterprise’s Local Area Network(s) is provided. There may be several LANs (also called Intranets) in the enterprise … perhaps in particular LOBs or at headquarters and several remote offices. In this case, the relationship of these LANs and their external linkage via the WAN needs to be shown. An effective way to present information about the LAN is a map with LAN symbols for hardware and communication links that are hyperlinks, that when clicked-on lead to a new level of detail about that part of the LAN (e.g., location of segments, interface points, and hosted applications, databases, and websites).

Cells in the repository check-list:

  1. Describe briefly the component (artifact) that you think should be in the cell. (If more than 1, make a list).

     Corporate strategy plan


  1. The audience – what person or role will rely on the contents of the cell for decision support?

     Corporate management team

     Enterprise Architecture team


  1. Why would the audience read the cell; what will they do with the information that they see (what general management process does it support)?

Strategic planning is a management process and the content of this cell

     drives this process.


  1. Where would the contents of the cell come from?

     Board of directors

     Chief executives of the organization

     Enterprise Architecture team


  1. What other cells in the repository are directly related to information in the cell?

Medium level “Strategic Initiativescell

     High level “Business Processcell

  1. 6. Briefly describe what is most important about the artifact in the cell (g. a certain format, level of detail, timeliness, etc.)

   The content of this artifact must be simple, qualitative and visionary.

     This content can be refreshed yearly.


QualiWare Center of Excellence

Farum, March 2014

For many enterprises operating in a dynamic market, it is a challenge to keep employees up to date on the latest research, the latest technology and the latest trends and hype. The enterprise’s agility, innovation and growth is at risk, and for the individual, the competition from colleagues, outsourcing agents and offshoring options are felt every day at work and raises questions like: “What if my knowledge and skills gets outdated?”, “Where should I focus my interests?” and “What kind of training do I need to stay a valuable resource for my employer?”. To react to those challenges companies will need to continuously monitor sources of insights and trends to maintain a knowledgeable and agile workforce; a program for self-studies, formal training, certification and assessment must be introduced enterprise-wide; and a culture of knowledge sharing at all levels and collaboration in problem solving must be established and maintained continuously.

That is why QualiWare has established the new QualiWare Center of Excellence.

QualiWare Center of Excellence allows customers, partners, consultants, researches and students to share knowledge and experiences on topics ranging from advanced academic research to practical user guides for tools and methodologies.

QualiWare Center of Excellence is responsible for researching, producing, assembling, compiling and editing knowledge products such as documents, videos, sample models etc. that will allow QualiWare customers to learn about relevant topics captured in research documents, books, academic courses, international and industry standards, and from evangelists and consultants.

The center will make knowledge available via a member website, as speakers at conferences or customer specific events, as contributors to public sites, communities and blogs and as face-to-face inspirational work sessions. QualiWare Center of Excellence will offer formal certification programs from famous universities, established and recognized organizations and from accredited partners.

QualiWare Center of Excellence is led by Dr. John Gøtze, the author of many books and other writings, and widely recognized as an international expert in enterprise architecture. He runs the Carnegie Mellon University Enterprise Architecture Certification Program in Europe. He teaches EA at the IT University of Copenhagen and Copenhagen Business School. He co-founded the Association of Enterprise Architects and was its International President from 2007-2010, and Chief Editor of the association’s Journal of Enterprise Architecture from 2010-2013. John holds a MSc in systems engineering and a PhD in urban planning, both from the Technical University of Denmark.