AT#54: How to Open the Negotiation Space

AT#54:  How to Open the Negotiation Space

Viewpoints of many different disciplines need to be considered in order to implement a holistically designed enterprise. Interests of disciplines closer to purpose and customer value (like service- or UX designers) must be negotiated with disciplines closer to feasibility (like business- or software architects). Designs of those groups can be conflicting, drafts of UX designers, for example, might not be feasible with proper software design or due to limited budgets.

Today those disciplines are having hard times with each other. Designers are often frustrated because their designs are never implemented in the way they envisioned. IT-Architects are frustrated because everybody perceives them as not willing to implement a certain design. Executives are feeling that the money they invest hardly ever leads to the intended outcomes. A lot of misconceptions and conflicts between designers, architects and executives arise that are usually resolved by corporate politics, not the best way to optimize overall enterprise design. Read More

AT#58: Information? Data? Content?

AT#58: Information? Data? Content?

If you work in IT, you are probably familiar with data modelling. Even terms like data and information architecture may appear familiar to you. But what do they mean to you and is it really important to understand the difference?

Reintroducing “Information”

I started thinking about it in the context of the most recent projects I’ve been working on, which happened to be in the fields of web content management and e-commerce. If you are familiar with these worlds, you probably know that digital practitioners use the term Information Architecture with a somewhat different meaning compared to what more traditional IT specialists may do (according to some surveys [1], half of IT professionals do not see the difference between data and information. Well, at least did not see it back in 2013 when that particular article was published).

So, what is an information architecture in a digital context? I would define it as follows:

Information architecture (or IA) is a process and an artefact of designing the structure of meaningful information in a way that maximises the efficiency of interaction between the user (the consumer of information) and the medium.

When we are talking about web technologies, IA often manifests in the design of navigation menus and pathways that ease the pain of finding the information for the users. It also includes matters like labelling and search systems for the same purpose[2].

The definition implies that to be considered an information object, a piece of data needs to deliver value to the user in the specific moment of interaction. The same data presented in a different part of the customer journey or on a different stage of the business process may lose its value, thus stops being considered as “information”.

If you are after a formal definition, I find this one really good [3]:

Information is any collection of data that is processed, analysed, interpreted, organised, classified or communicated in order to serve a useful purpose, present facts or represent knowledge in any medium or form.

I love the part about “a useful purpose”, it unifies the way UX designers think about information when designing digital experiences and the way enterprise architects should think about information when dealing with business matters. The same paper defines information architecture as:

Information architecture is the means of providing a structured description of an enterprise’s information, the relationship of this information to business requirements and processes, applications and technology, and the processes and rules which govern it

OK, this is one may already be a bit too governmenty and over-enterprisey, so probably let’s stick to the first definition given above 🙂

Now, how is it related to the term “content”?

Today, if you are even remotely close to marketing, you will hear this word everywhere hundreds of times a day. Everybody is talking about content management, content development, content strategy, content delivery, etc…

I came across this definition the other day [4]:

“Content is the presentation of information for a purpose to an audience through a channel in a form.”

Which made me thinking: how is it different from the definition of information that we introduced before? Not really, for a small nuance — when we say content, we usually mean something specifically crafted for its purpose.

My answer (again, probably biased towards web projects) is that:

“Content” can be defined as information purposefully and consciously produced and curated by an organisation.

In the marketing world, examples of content by this definition are articles, ads, product descriptions and so on. In the technical world of IT, it may be user manuals or process specifications. In a broader sense (and giving kudos to Apache Jackrabbit and JCR [5]), software code can also be classified as content, but let’s not debate about it here 😉

So when we are talking about “Content architecture”, we are talking about organising the information for the ease of production, so that later on it can be converted into information architecture for the ease of consumption.

Let’s take any website as an example. It has a navigation menu and search and filters on the front-end — all the instruments for the website visitors to find what they are looking for. This is defined by the information architecture (IA) of the website.

At the same time, if you are logged into the back-office, you will see a set of content folders and labels and so on. This organisation is created by and for the people producing the information via a given tool; therefore it will be guided by the “content architecture”.

Where is “data” then?

If we assume all the statements above as being true, what is left for “data”?

Unlike “information”, “data” can be considered as raw records requiring processing and interpretation to become valuable.

Unlike “content”, “data” is captured and recorded but not necessarily crafted by the organisation.

A great example of “data” is records collected by web analytics engine, such as Google Analytics. Those are merely recordings of observed phenomena. In order to become valuable, they need skill and expertise to be interpreted and presented in a way that will allow making weighted decisions.

This leads us to the concept of data architecture [6]:

Data architecture is composed of models, policies, rules or standards that govern which data is collected, and how it is stored, arranged, integrated, and put to use in data systems and in organizations.

Let’s bring the three together

Concluding, the content architecture will guide the storage and structure of the content that the organisation is producing so that it can be navigated and managed by the content producers.

The data architecture will structure the storage, collection, and management of observations made by the business.

And finally, the information architecture will define how you pull, transform and represent the content and data in a meaningful way that allows consumers of that information to find it easily in the moments when it matters.

Read More

AT#54: How to open the Negotiation Space

AT#54: How to open the Negotiation Space

Viewpoints of many different disciplines need to be considered in order to implement a holistically designed enterprise. Interests of disciplines closer to purpose and customer value (like service- or UX designers) must be negotiated with disciplines closer to feasibility (like business- or software architects). Designs of those groups can be conflicting, drafts of UX designers, for example, might not be feasible with proper software design or due to limited budgets.

Today those disciplines are having hard times with each other. Designers are often frustrated because their designs are never implemented in the way they envisioned. IT-Architects are frustrated because everybody perceives them as not willing to implement a certain design. Executives are feeling that the money they invest hardly ever leads to the intended outcomes. A lot of misconceptions and conflicts between designers, architects and executives arise that are usually resolved by corporate politics, not the best way to optimize overall enterprise design. Read More

AT#47: How to Make EAM a Management Instrument Part 3 – Connect with Multi Project Management

AT#47: How to Make EAM a Management Instrument Part 3 – Connect with Multi Project Management

In nine out of ten companies I worked as an EA, IT implementation projects were used as the key element used in strategic planning. Boards were used to budget and prioritize goals based on project status reports. They had to decide whether to invest in project ‘ABZ’ or ‘Leo New’ (both quite cryptic names for them) – not the best way to keep oversight over their strategic goals.

The Architectural Thinking Framework includes the concept of “Strategic Fields of Action” (SFAs) (introduced in our last blog post) that addresses this problem. SFAs connect the strategic goals of the company with the implementation projects. Thus, they are the link between the operational planning of projects and the architectural skeleton of the company.   Read More

AT#46: How to Make EAM a Management Instrument Part 2 – Connect with Strategic Goals

AT#46: How to Make EAM a Management Instrument Part 2 – Connect with Strategic Goals

Defining a compelling vision should usually be the first step to start a digital transformation journey. Your executives craft a vision of your transformed company: what your company will stand for, how it will operate, which technology it will use to improve customer value. That vision highlighted some of the major landmarks on your transformation journey.

Derived from this vision, companies should define strategic goals that bring the vision to a more operational level. Read More

AT#45: How to Make Enterprise Architecture a Management Instrument Part1 – Digital Governance

AT#45: How to Make Enterprise Architecture a Management Instrument Part1 – Digital Governance

To unleash its enormous power, Enterprise Architecture (EA) must be implemented as a management instrument that is the basis for important strategic decisions. In practice, however, EA is still a mystical discipline, ruled by vague frameworks and done by a small EA group far away from executive boards. In most companies, EA has no or very limited impact on strategic business decisions. Enterprise Architecture SHOULD be a management instrument but fails in practice. Read More

AT#36: How to be Successful with Strategic Information Technology Landscape Planning

AT#36: How to be Successful with Strategic Information Technology Landscape Planning

We have written many posts at the Architectural Thinking blog that deal with the business aspects of architecture. Business architecture is at the core of Architectural Thinking and must be connected to vision/strategy and solution development. Business architecture drives IT architecture, not vice versa. This doesn’t mean, however,  that the technology landscape of a company does not need to be governed! Technology is the basis that supports applications that support the business as shown in the meta-model of the Architectural Thinking Framework: Read More

AT#34: How to be Successful with Application Landscape Planning

AT#34: How to be Successful with Application Landscape Planning

We have written many posts at the Architectural Thinking blog that deal with more strategic topics like vision, strategy and business architecture and how to connect this to solution development. The common aim defines the direction the company shall go, based on a vision statement created by executives. After that, business architecture comes into play and make the vision more operational. The upcoming posts show how strategic planning of the application & technology landscape can be operationalized using two simple architecture maps: application map and technology map.

Read More


1 2 3