Welcome again to our EDS Touchpoints, where we talk about about Enterprise Design Services. Enterprise Design Services is a one-stop-shop for delivering Enterprise Architecture, Business Design and Information Management. These three practices all intersect in a sweet spot when you, as an example, develop new customer facing digital services.
We are Nils and Julia, two members of the Enterprise Design Services team, and we are writing this blog to discuss about recent topics in the fast paced, changing, more and more digital world. We interview experts on their field of specialty and want to understand what it takes for businesses to make it in today’s competitive world.
In this post we interview Riikka Huttunen, an Enterprise Architect in the Enterprise Design Services (EDS) team, to learn the importance of defining a common language and how to avoid a language barrier.
I work as Enterprise Architect specializing in Information Architecture and data management in the Enterprise Design Services Team. I have collected over 10 years of experience in several similar roles.
Information architecture revolves around the data that organization handles, needs to operate and to make decisions.
As an information architect you often need to go to the most profound concepts and terms of what a business is working with. So, for example how they understand their customers, what kind of products they offer and how do they offer their products or services. It’s not just about the data in systems, even though that is also important to understand.
Common symptoms are repeated misunderstandings between different organizational units of a company. People think they talk about the same things but still understand those things differently. For example, sales might think about a customer in much broader terms than accounting.
This especially shows during larger IT-projects. When even organization’s business units do not have a unified understanding of common core concepts it makes it particularly challenging to form requirements around those concepts and implement those into IT system correctly.
In my experience a method that works well to form a common understanding is conceptual modelling. In the process of forming a concept model (also known as conceptual data model), you define what are the core concepts and terms that are important to the business and how those concepts relate to each other and what are the rules between them. One example of a business rule would be how many accounts a customer can have.
A natural way to start forming mutual understanding and building a concept model is to talk to business area experts and ask them what the things are they work on, what information do they need to do their daily tasks, what do they see on their reports and how do those things relate to each other.
Conceptual modeling should never be done from a purely IT perspective and alone at IT department. Close collaboration with business in e.g., workshops and review sessions are essential to get to a good conceptual model.
It usually is with the most essential concepts that are the hardest ones, where people in the beginning assume mutual understanding. They span over the whole organization and are connected in many ways. Common examples are customers, products or services – at the core of what the organization does.
For example, when the CEO wants to see a report of the number of customers, understanding CEO’s perception of customer is essential. To implement these kinds of KPIs starts with defining data that is needed to form the KPI and understanding the data content correctly. Concept model helps with this.
Not necessarily, there are usually some generic concepts that can be used. In many cases there are also good repositories available for certain industries, which can serve as a good basis for organization’s own concept definition work.
And there are, of course, many concepts which are valid across companies and industries, like generic customer information, for example.
I have recently supported one customer in a core system renewal project – a system specific to the industry the customer is working in. The existing architecture descriptions were mostly on technical part, so both business and information architecture definitions were missing or insufficient on the target area. Our approach was to start the target area’s information architecture work by conceptual modelling.
I created the first draft of the concept model from the existing documentation of their current system and took that as a basis for workshops on selected areas of the model with the business. We refined the conceptual model of the target area and related areas around it and found many questions for business owners to solve related to how they define things they talk about.
I would say that I am generally a well-organized person, everything has their place. I also tend to ask people what people mean with a certain term. For example, “ready” is a term that can be on a broad spectrum for some people.
It would be interesting to hear about miscommunications and results due to misunderstandings of terminology. I bet it happens very often when working with IT projects.
Read here our other EDS Touchpoints Blogs.