Insight

EA3.0 & ABODE Transformation Method

EA3.0 stands for the third paradigm implementation of Enterprise Architecture. The first implementation is based on the famous scheme that Zachman created. It displays the first insight that IT is part of a greater whole and what distinctions are important. The second paradigm is based on the integration of the components and defining artefact symbols for each component. However, alignment of all business layers is very rough, strategy is only a reference and many parts and components are not integrated into a single concept.

In EA3.0 all relevant parts for business transformation are brought together, even organizational culture

EA3.0

EA3.0 is a further, but revolutionary, development of the Enterprise Architecture. When we define Zachman’s famous Framework as EA1.0, we can distinguish a futher development in the Enterprise Architecture Area called EA2.0. In it some efforts are towards integrating the business (mostly business processes) and in some cases even the strategy. But altrough many IT specialist think this is it, Enterprise Architects states that EA2.0 mostly starts in the middle: with Business Processes, while other organizations and institutions see no difference between a Business Process and an automated information system.

For example look at the definition of BPMN where about 30 different types of events or triggers can be found. While business owners and enterpreneurs are not interested in BPMN models, those business people that are confronted with them are completely flabbergasted.

In our view Enterprise Architecture should form the blueprint for business transformation. To understand what this means we should look at the essence of any organization: a ministry, a governmental institute, a global enterprise, or even the small shop around the corner. This means that we cannot talk about companies, shareholders, customers, products and services, etc.alone and need a broader view.

Therefore we define the essence of any organization that it creates value with their proposition for their stakeholders. To do this it needs certain capabilities, competencies, and capacities – the so-called Management Charter. These essential issues, amongst many others of course, should be embedded in the Enterprise Architecture.

Our Enterprise Architecture called EA3.0Ô (with Zachman’s framework as EA1.0, contemporary Enterprise Architecture as EA2.0) translates the strategic choices into different models, of which the most important are the Business Function Framework, the Proposition Model, and several Business Value Models.

Another thing of high importance is the following. Before and during large business transformations a lot of new concepts, ideas, models, approaches, etc. are developed, but also a lot of already carefully developed concepts, etc. are ‘lost in transformation’. However, for organizations the importance is very high because this knowledge is collected during – sometimes the total – history of the organization. Because they represent value and contain knowledge, they are called Knowledge Assets. Within EA3.0 these concepts all belong to the Strategic Architecture domain.

Based on the principles, ideas, concepts, models, etc. of EA3.0 our proposition has been developed with which value is created for our customers with several products:

GEFFÔ – Generalized Enterprise Function Framework that enables reuse, acceleration, and Knowlegde Asset Management
A³ KAMÔ – the Know Asset Management approach that integrates Augmented, Actionable, and Architecture Knowledge
ABODEÔ – our business transformation methodology
A Tools – several sets of transformation and management tools that accelerate business transformation
Business Solution Models – predefined, highly adaptable, combinations of business processes and solutions, that can instantly be used
ICT Solutions – solutions that can be used in the ICT departments to integrate with our Knowledge Asset Management toolsets

GEFF™

GEFFÔ or the Generalized Enterprise Function Framework was first published and presented on July 2013 during the ITHEA conference in Varna, Bulgaria. The GEFFÔ is used to structure all so-called Enterprise Functions. An Enterprise Function is any activity that an organization must perform to accomplish their goals and objectives. An enterprise function is an activity defined without its organizational context. So no relations are made towards the organizational structure, to actors that should perform the function, with what means or resources, and resulting in what products or services.

Note: in the US an Enterprise or Business Function is often called a Capability. However, because Enterprise Architects uses the term Capability for that which an organization is able to do (or the As Is ability) Enterprise Architects uses the term Function, that has been used as such for over thirty years now. Contrary to the Capability is the Competency: that which an organization should be able to do (or the To Be ability).

The GEFFÔ structure is defined in layers and columns. The layers represent the strategic, tactical, and operational enterprise functions. Because not all functions can be determined as part of one of these layers, an extra layer called Enterprise Support has been defined. There are nine columns that have been explicitly defined to support the definition of enterprise functions. Through the use of these columns the modeler can intuitively recognize that some enterprise functions are still missing, while others are duplicated.

The structure of the GEFFÔ forces the modeler to define process model as a communication and behavioral process between the organization and its environment. In this way the modeler will find that he or she will have to define other Business Functions that were not foreseen in the initial process model to complete both the process model and the GEFFÔ. Parts of the Proposition are also embedded within the column structure, making the GEFFÔ applicable for all organizations, although they have a very different proposition.

Of course, ministries, NGOs, banks, insurance companies, industrial or trading companies are not comparable. This is why the GEFFÔ structure has been stratified. At the top level the generic model and its generic enterprise functions, are defined. At the next level a decomposition based on the Line of Business (LoB) is realized. For each LoB type a further decomposition has been developed. At the lowest level, the level of the individual organization, enterprise functions are specialized for that individual organization.

Because of this generic structure, the GEFFÔ is applicable to any organization. Hence, it makes the GEFFÔ ideal as an instrument to manage and maintain knowledge, but especially to reuse already developed knowledge for other organizations: when the knowledge (Actionable, Augmented, and/or Architectural) has been defined it can be applied in other organizations.

A³ KAM™ – Triple A Knowledge Asset Management

Organizational Knowledge, according to Enterprise Architects, is about understanding how information can be used in an optimal way or finding this optimal way. Organizational Knowledge has many aspects. Some characteristics of organizations hardly change. They are valuable, because they represent business knowledge. In the eyes of Enterprise Architects they represent Knowledge Assets. This makes them useful and valuable as building blocks for the architecture and design of any enterprise.

Because they formalize and describe content we can (re)use them to describe the current and desired organizational behavior. And thus we create the foundation for change. Enterprise Architects recognizes the following Knowledge Assets:

Events & Results - they initiate and finalize a Business Process. Events & Results will hardly change in time, especially when they are related to lifetime events of stakeholders.
Enterprise Functions - actions described independent of the organizational context in which way they are insensible to change and can be reused
Enterprise Functions can be “enriched” with explicit knowledge in two ways:

Describing knowledge about how functions should be executed from a documentary way
Describing knowledge about what the functions need to do for information processing

Enterprise Objects - data sets such as invoice and orders will change in time, but data sets described at a higher level (Enterprise and Business Objects) are less sensible to change
Configuration Components - components of complex things like projects, ships, buildings, airplanes, etc. that can be reused/replicated; for this area Enterprise Architects developed the Component Configuration Framework, distinguishes several different types of knowledge, and is working on several different solutions for configuration replication
Business Rules - business rules govern the behavior of an organization and will change, but are a source of knowledge for the organization; also Business Rules turn Knowledge into Actionable Knowledge

Added to that, historical offerings of the organization can be of real value while they often represent engineering and construction knowledge of specific applications or configurations. For example the complete electro-mechanical installation of a submarine. Not only the knowledge of the engineering and construction project can be maintained for reuse reason, but also, the maintenance knowledge of the submarine’s installation, or even how the submarine should be decomposed in the retire or abandon phase of the ship.

Enterprise Architects BV distinguishes knowledge engineering from knowledge management. The first forms the structural, highly automated part, the latter the more process-oriented part. Within knowledge engineering data (the values) become facts (the attributes or properties, together with their values), and facts become knowledge when first the context or knowledge management rules are described and second the total can be interpreted by an inference engine leading to conclusions.

Likewise we can say that for humans information is about understanding the context of data. If information is to become knowledge humans have to understand how to use this information. Business knowledge is a further distinction of knowledge.

How do we make organizational information or knowledge applicable? Nowadays this is often performed by designing and developing Business Processes and automated Information Systems. To understand how they work we document these processes and information systems. Business Processes are formalized activities that are “chained together” in a formalized way. Decisions, or gateways change the directions of flows within these Business Processes.

These Business Processes and their flows can be managed by workflow, case, and business process management systems. The formalized activities, when automated, can become information applications directing the user how to manage the information. In case of manual activities, these activities can be formalized as mechanized activities with employees handling machines, for example in production processes. Fully manual activities, like accepting the daily post, can be formalized by describing how to perform these activities.

We see that activities are related to two types of business process knowledge. On the one side we see formalized knowledge of manual or automated activities concerning transforming materials and/or data, which we can call the data processing knowledge, and on the other side the explicit knowledge as a description of how these activities should be performed and managed, which we can call documental processing knowledge.

So on the one hand we have knowledge completely contained within the formalized activities and on the other hand we have knowledge contained in the description of how to perform and manage the activity. To address things clearly, we will define the first knowledge, the knowledge of the activity, as Actionable Knowledge, and the latter knowledge, the knowledge describing how to perform and manage the activity as Augmented Knowledge. The Enterprise Architects Knowledge Asset approach is called A³ KAM – Triple A Knowledge Asset Management. Let’s go deeper into that.

Most of the applicable knowledge is implicit – in the heads if people – and will stay implicit as long as there is no necessity to use this applicable knowledge. But of course we can distill this applicable knowledge and transform it into explicit, actionable, and augmented knowledge. How we describe both types of knowledge can be distinguished as a separate, third type of business knowledge:

Architectural Knowledge.

This Architectural Knowledge describes the coherence of the different types of components used in Actionable and Augmented Knowledge. This completes the Triple A Knowledge Asset Management (A³ KAM) approach around business functions.

Augmented and Actionable Knowledge make use of the BFM. With the AFM and related tools, see below, both types of Knowledge can be maintained and managed. By defining all Knowledge components in the same database, as defined in the ADOBEÔ Metamodel, including the architecture components of Information and Application Architecture, also Architectural Knowledge becomes available.to specific situations that vary in different types of organizations. The BFM is also independent of the organization structure, making it an ideal and most important part of KMS or Knowledge Management System.

Augmented Knowledge

The Augmented Knowledge components are mostly focused on knowledge that the user can use when he/she has to fulfill the job. It describes, in procedures, relationship tables, or documents how Methods, Techniques, Tools, Models, and Business Services are related to the Business Function.

Actionable Knowledge

When the planning of a solution as a business function needs to become Actionable, Business Rules are used. In the example below the Business Function has an incoming and outgoing Parameter, with which Business Functions can communicate with their predecessor or successor functions.

Several tools are available to manage and maintain these different types of knowledge. Also other types of application are foreseen in which way the knowledge assets can be dynamically accessed and interactively managed.

In our Proposition two different frameworks are used:

The GEFF or Generalized Enterprise Function Framework, and
The CCF or Construction Configuration Framework.

At this moment A³ KAM is only connected with the GEFF. However, Enterprise Architects have started developments in which A³ KAM becomes available on different mobile devices in combination with the CCF. In this way knowledge management will not only be A3-oriented, but also mobile. Enterprise Architects believe that this will change the way people use knowledge dramatically.

ABODE

ABODEÔ stands for Architecture Based Organization Design Environment. ABODEÔ is the Enterprise Architects BV business transformation methodology founded on EA3.0Ô and making optimal usage of the supporting tools.

ABODEÔ is focused on intrinsically changing the organization to make it more agile and flexible,while changing the business and ICT transformation processes drastically themselves.

It is thus supportive to other transformation approaches like socio-technics, business reengineering, etc. These and ABODEÔ can very well cooperate while delivering synergetic results.

The starting point of ABODEÔ is the already defined strategy with its strategic choices concerning:

The group of relevant stakeholders, including customers, employees, shareholders, suppliers, etc.
The value creation approach: how the organization is looking to create value for each group of stakeholders
The contemporary and future proposition with which the organization wants to create value
The Management Charter or necessary competencies, capacities, and capabilities necessary to realize the value creation

If these are not totally clear, using ABODEÔ can help with preparing them to the right detail.

Based on strategic choices EA3.0Ô architecture domains are developed, first with the strategic architecture, which lays the foundation for further investigations and developments.

Next two parallel roads will be followed. The first being the analysis and planning of business transformation itself – either completely based on the ABODEÔ approach or in combination with another one.

The second-line analysis on the architecture domains, like the business architecture, the organizational architecture, the information architecture, the ICT architecture and the technical architecture can all partially be performed in parallel.