In the previous blog post of the Enterprise Architecture series, I discussed the role Enterprise Architecture plays on various levels of management and how architecture-oriented thinking can be found embedded in all managerial activities. In this final post of the series, let’s move this to a bit more concrete level by discussing the special role of conceptual modeling in facilitating architecture-oriented thinking. We’ll also take a practical look at how architecture-oriented approaches and Enterprise Architecture deliverables can help managers in tackling real-life organisational concerns across managerial levels.

Enterprise Architecture is essentially about applying systems thinking in order to structure the reality – making the complex world around us just a little bit more understandable. Various Enterprise Architecture models have always been a core part of the Enterprise Architecture practice, to a point that they sometimes tend to get viewed as almost a synonym to the Enterprise Architecture itself. The variety of modeling aspects suggested by certain Enterprise Architecture frameworks makes it easy to quickly become overwhelmed. At the same time, the Enterprise Architecture practice has repeatedly been accused of being too much about “drawing pretty diagrams that don’t really matter in practice”.

In fact, when discussing modeling, we should perhaps start putting more focus on the journey instead of the destination. The process of modeling is all about making the real-world complexity more understandable by conceptualising, abstracting and ultimately making things easier to process and communicate in a certain context. In a way, modeling enforces approaching the real-world complexity in a systematic and a holistic manner, facilitating both individual-level cognitive processes and dialogue between parties involved in a modeling effort. As a result, the modeling process has hopefully led to something that is a lot more than a diagram. It should have created a mental model, enabling an increased level of shared understanding about the reality – providing a baseline for further analysis, ideation and problem-solving. Modeling should therefore be approached more as a social rather than a technical process.

The systems modeling process described above could be summarised in a simple framework, such as the following:

  1. Identify the concern that we want to address. What is it that we want to understand better?
  2. Identify and define the things that we’re dealing with. Which entities play a role in our context? Depending on the concern, these can be anything from abstract concepts (an organisation within its environment or a system within the organisation comprising people, processes, information and technology) to tangible entities (the actual individuals, procedures, data objects and devices involved in making the system work).
  3. Identify and define the relationships between the things. How do these entities interact in our context? Depending on the concern, these relationships can be anything from structural (a thing is a part of another thing or encompasses other things) to behavioral (a thing interacts with or depends on another thing somehow).
  4. Use the gathered understanding in order to address our concern. What does the system look like currently? What do we need to change in the system in order to achieve our end goals? Do we need to add some new entities to the mix, modify some existing ones or get rid of some of them completely? Do we need to make the entities work together in a different way by adding new relationships, altering existing ones or removing redundant ones? What could the system look like in the future and would it make any sense in terms of our goals?
  5. Review, refine and repeat for any further concerns.

By iterating the above process for a set of concerns of interest, architecture-oriented thinking should ultimately produce actionable insight and support decision-making through an incrementally improved understanding of the holistic system of systems that is an organisation. The role of Enterprise Architecture deliverables is then packaging this understanding so that it can be used to address various managerial concerns. These will obviously vary in both their perspectives and levels of detail depending on the managerial context.

How can Enterprise Architecture help simplifying the complexity?

There is a long list of potential use cases for Enterprise Architecture deliverables, addressing a diverse set of managerial concerns:

  • Describing the current state of things – where are we now?
  • Defining the target state of things – where do we want to be heading?
  • Identifying and evaluating alternatives – what options do we have and how are they different?
  • Selecting, prioritising and sequencing activities – what activities should we initiate and in what order?
  • Assessing impact – what will be affected if things change?
  • Managing risks – what can potentially go wrong and how that could be mitigated?
  • Ensuring compliance – what needs to be done in order to meet various requirements?
  • Maintaining operations – what is essential for business continuity?

The deliverables don’t carry much value by themselves, which is why “model-obsessive” approaches to Enterprise Architecture work tend to fail. The key of successful Enterprise Architecture work lies in applying the Enterprise Architecture understanding at the appropriate time in various managerial contexts – exploring and formulating strategies and tactics, managing development activities in project portfolios, undertaking development initiatives and designing operative solutions, among others. These are all highly collaborative processes that require the participation of a diverse group of stakeholders coming from various backgrounds and levels of understanding. The central role of Enterprise Architecture models is providing a common language that can be used to address complex organisational concerns – convey ideas, discuss issues, solve problems and ensure commitment.

How not to make Enterprise Architecture sound too simplistic?

We have discussed applying conceptual modeling to facilitate sense-making using a systems approach. This is something Enterprise Architecture thinking can help organisational management with in a very concrete way. The role of an Enterprise Architect in this context is not resolving all the issues that are raised, “architecting the perfect organisation”, but providing a structured method to enable the inquiry. By doing so, we are able to reduce the complexity of the problem area – making it literally more manageable.

An issue we might face with such model-driven Enterprise Architecture work is that, if misunderstood or misused, this can paint a picture of an unrealistically linear process that starts from the strategy, proceeds towards tactics and operations and eventually results in the perfect architectural outcome. This can misleadingly imply that we could prescribe every single aspect of an organisation by creating a bunch of diagrams – just like for a building, we could create an architectural plan of the foundations, the walls, the roof, the doors, the windows, the piping and the wiring even before starting the build. As we know, in most situations, this is hardly the case with organisations.

This might also have a theoretical backdrop. Traditional systems thinking is in many ways based on the General Systems Theory (GST), carrying an assumption that everything can ultimately be split into systems and sub-systems and that by understanding the hierarchy of these systems, we should have a complete picture of the reality. Unfortunately, this does carry a risk of oversimplifying things a bit. Already earlier, we discussed architecting in the context of a building as a rather bad metaphor for architecting in the context of an enterprise. This is because as a socio-technical system, an enterprise is in fact much more like a dynamic living organism than like a static structure. The architecting process itself changes things by generating new understanding and creating new connections. The demand for agile approaches in Enterprise Architecture work is not a coincidence, but a result of the fact that the waterfall approach has often been found to be a suboptimal way of approaching complex organisational problems.

Perhaps, more multifaceted systems theories, such as the Complex Adaptive Systems (CAS) theory and the Viable System Theory (VST) would provide better explanations of the complexity of socio-technical systems that we call enterprises. Such theories are better at recognising the fact that the interaction between the heterogeneous actors in a system plays a significant role in how the system as a whole evolves through the emergence of new relations. As opposed to the traditional systems thinking, the system becomes something more than just a sum of its parts. As models are essentially static representations of the reality at a certain point in time, this dynamic feature actually manifests better in the modeling process itself, through the evolution of thinking with every iteration and increment.

Read other parts of the Enterprise Architecture series:

Enterprise Architecture thinking – where are we coming from and where are we going next?

Enterprise Architecture thinking – not just the architects’ concern!

We at Gofore are at your service to help you manage complexity and tackle your organisational needs using architecture-oriented approaches. Please read more about our architecture consulting capabilities and feel free to contact us for more! Or, if you’re as passionate about architecture as we are, maybe you’ll wish to join us at Gofore.

Vladislav Ivanov

Vladislav is a Business Process Management, Process Architecture and Enterprise Architecture professional passionate about architecture-oriented thinking. He has several years of experience in method development and supporting organisational practices in these areas. He is currently researching the state of Enterprise Architecture thinking in Finnish organisations at the University of Jyväskylä.

Do you know a perfect match? Sharing is caring

In the previous blog post of the Enterprise Architecture series, I discussed the origins of Enterprise Architecture thinking as seen by the research. In this post, we’ll expand on the role of architecture-oriented thinking as an embedded part of management. Specifically, we’ll argue that Enterprise Architecture should not only be a concern of Enterprise Architects explicitly associated with organisations’ Enterprise Architecture work, but a concern of almost any manager in an organisation.

The idea of Enterprise Architecture as some detached practice, which an organisation either does or does not engage in, has been an outdated one for a while now. Not actively managing Enterprise Architecture does not mean that no “enterprise” and no “architecture” exist. They most certainly do, despite not always being managed through an Enterprise Architecture lens. Not having personnel in explicit Enterprise Architect roles does not mean that there is no one dealing with Enterprise Architecture management issues, either. Instead, this often occurs implicitly as a part of other managerial processes, not necessarily identifying themselves as Enterprise Architecture per se. On the other hand, having dedicated Enterprise Architect roles in place does not mean they are or ever should be the only ones responsible for dealing with Enterprise Architecture issues within the organisation.

Enterprise Architecture is still something that seems to be hard to grasp, which is manifested by the problems organisations continue to report in implementing Enterprise Architecture management practices or realising value from Enterprise Architecture work. This can sometimes lead to the term Enterprise Architecture being intentionally faded away in the organisations’ use of language. We’ve even seen this being done intentionally by Enterprise Architecture practitioners themselves as to avoid the stigma that has developed around the term.

Is this a bad thing? Not necessarily. In fact, implying Enterprise Architecture as some separate entity and outsourcing Enterprise Architecture management to Enterprise Architects is not likely to be feasible or lead to good results in the first place. Studies have shown time after time that management buy-in and support for the Enterprise Architecture practice constitute critical success factors in terms of Enterprise Architecture adoption and value realisation. A seamless integration of Enterprise Architecture processes with other managerial practices, which are actually responsible for manipulating the organisation’s Enterprise Architecture on a daily basis, is crucial in terms of success. While the notion of an Enterprise Architecture management practice can be useful to a point, putting an excessive emphasis on the practice itself instead of its end goals carries the risk of becoming counterproductive.

Here, we are actually moving from the idea of Enterprise Architecture as a distinct practice towards the idea of Enterprise Architecture as an underlying, architecture-oriented way of thinking [1] about an enterprise – providing management with a certain mindset, concepts, methods and tools for approaching complex organisational issues in a systematic manner by utilizing systems thinking.

How are Enterprise Architecture issues intertwined in various levels of management?

The classical management theories recognise that management is all about organising the resources available so that they function together in an optimal manner in order to produce capabilities needed to achieve shared goals. Here, we immediately face two questions – first, what are the resources we are talking about and second, how they should be connected through various relationships in order to work together optimally. Wait a minute, isn’t that what Enterprise Architecture is all about, as well?

In many ways, management is essentially about creating the best possible embodiment of an enterprise’s architecture by using the resources available at a certain time. Enterprise Architecture management as a practice does not carry any intrinsic value. The added value only emerges from enabling the management to perform better, which in turn should lead to improved organisational performance. Enterprise Architecture thinking facilitates this by providing a systems approach for understanding the components that management needs to deal with, and how they work together as a holistic entity. This is fundamentally about ensuring the existence of the required operational capabilities of an organisation (the ability to do what needs to be done currently and do it well) as well as enhancing the dynamic capabilities of an organisation (the ability to sense, seize and execute on future opportunities effectively) [2].

Thus, Enterprise Architecture concerns of various levels of detail can be found intertwined in almost all levels of management. Think about the following:

Strategic management is responsible for dealing with the organisation’s strategy. They need to understand the environment in which their organisation operates as well as their organisation’s specific resources and capabilities. They need to understand the various possibilities their organisation has and the organisation’s feasibility of seizing these possibilities. They need to identify, evaluate and select the most appropriate strategic choices for the future of their organisation and ensure that the high-level building blocks are in place to successfully enable the execution of the strategy. In many ways, they are involved in concerns related to their organisation’s strategic architecture.

Tactical management is responsible for guiding the organisation’s strategy execution. They need to understand what is actually needed to transform their organisation towards the selected strategic direction – where are they now, where do they need to be and what needs to be done in order to get there. They need to identify, evaluate and select the appropriate tactical actions as well as prioritize and sequence them in an appropriate order. They need to change the various configurations within their organisation in order to respond to the strategic goals. In many ways, they are involved in concerns related to their organisation’s tactical architecture.

Operational management (people managers, development managers, portfolio managers, program and project managers, service managers, you name it) is responsible for implementing the organisation’s tactics. They need to understand what is expected of them and how what they are doing is aligned with the organisation’s bigger picture. They need to create operational solutions that respond to the tactical needs. They need to understand how the decisions they are making affect other components of the organisation and organise their work so that it is in sync with other activities happening around them. In many ways, they are involved in concerns related to their organisation’s operational architecture.

What about the Enterprise Architect then?

The view of Enterprise Architecture as a distinct practice may unintentionally carry the notion of Enterprise Architects as the sole managers of an organisation’s Enterprise Architecture, and Enterprise Architecture as something that is mostly the realm of the Enterprise Archtiecture practitioners – just like a building’s architecture is a sole responsibility of the architect. This analogy does not translate well to the context of an enterprise. Needless to say, as Enterprise Architecture concerns are deeply embedded in all management activities, this approach is not very realistic or likely to result in success. Instead, Enterprise Architecture issues belong to the agenda of all levels of organisational management, be it explicit or not. The need for a tighter coupling between architectural and managerial concerns gets even more highlighted as the scope of the Enterprise Architecture practice is moving from its technical origins towards increasingly holistic socio-technical and ecosystemic stances.

The above also has implications towards the skillset required of Enterprise Architecture practitioners [3]. A traditional view of an Enterprise Architect is a senior professional with deep knowledge of the domain substance in addition to the competence in the Enterprise Architecture discipline. While these characteristics are still undoubtedly important, a modern Enterprise Architect can be seen as having even more crucial responsibilities as an advocate of architecture-oriented thinking across the various levels of organisational management or a provider of means needed to tackle complex organisational issues. Soft skills – such as communication, facilitation, training, coaching and providing hands-on support – become increasingly valuable as Enterprise Architecture practitioners shift from a subject matter expert role to a more of an enabler role.

Read other parts of the Enterprise Architecture series:

Enterprise Architecture thinking – where are we coming from and where are we going next?

Enterprise Architecture thinking – from modeling theory to models in practice


  1. Winter, R. (2014). Architectural thinking. Wirtschaftsinformatik, 56(6), 395-398.
  2. Van de Wetering, R. (2019,). Enterprise architecture resources, dynamic capabilities, and their pathways to operational value. In International Conference on Information Systems. AIS Electronic Library.
  3. Ylinen, M., & Pekkola, S. (2020). Jack-of-all-trades torn apart: Skills and competences of an enterprise architect. In Proceedings of the 28th European Conference on Information Systems (ECIS). Association for Information Systems.

We at Gofore are happy to discuss how Enterprise Architecture practices could support the management of your individual organisation. Please read more about our architecture consulting capabilities and feel free to contact us for more! Or, if you’re as passionate about architecture as we are, maybe you’ll wish to join us at Gofore.

Vladislav Ivanov

Vladislav is a Business Process Management, Process Architecture and Enterprise Architecture professional passionate about architecture-oriented thinking. He has several years of experience in method development and supporting organisational practices in these areas. He is currently researching the state of Enterprise Architecture thinking in Finnish organisations at the University of Jyväskylä.

Do you know a perfect match? Sharing is caring

Enterprise Architecture is a practice sometimes perceived as something mystical, old-fashioned or perhaps even a fad from the past, at least if you ask outside of the community of Enterprise Architecture practitioners themselves. To disrupt this stigma a little bit and better understand the value of Enterprise Architecture today, it is good to take a look at the historic origins of Enterprise Architecture, how our thinking on Enterprise Architecture has evolved and what can we learn from that in building a modern Enterprise Architecture practice.

As the development of Information Technology became more rapid during the 80s and the 90s, information systems grew in both their complexity and business criticality. Needs started to emerge to find ways of managing this complexity and ensure that the information systems were aligned with and supported the business in the most optimal way. Enterprise Architecture emerged as a practice of facilitating this by providing an understanding of various components of an enterprise as well as various relationships between these components. This thinking is essentially at the core of various systems theories viewing the world essentially as a system of systems. Enterprise Architecture in that sense is about understanding the various sub-systems of an organisation (such as functions, processes and IT components) and how they should work together as a holistic organisational system. This foundational thinking is also very valid to this day in managing almost any organisation.

Even though Enterprise Architecture has been practiced and studied academically for several decades now, there is however still a lack of solid agreement both on the very definitions and the underlying theoretical foundations behind Enterprise Architecture. This has led to several specific flavours of Enterprise Architecture with fundamentally differing approaches, making it sometimes hard even for the practitioners in the field to discuss and further develop the discipline. This, in turn, could have contributed to issues we have seen with the value realisation of the Enterprise Architecture practice. We may have set up Enterprise Architecture practices that have been scoped, positioned or managed inappropriately against the true circumstances and needs of each specific organisation, leading to a low level of buy-in and achieved benefits.

There could be some value in gaining additional understanding about the flavours of Enterprise Architecture and their theoretical underpinnings in order to understand where they are coming from and what they can offer to a modern Enterprise Architecture practice, instead of prematurely declaring the ideas behind Enterprise Architecture dead. We also need to understand that as with any flavour choices, there is likely no single right answer that would suit every situation.

What do we know from the research on Enterprise Architecture?

Some research has been done on the various traditions behind Enterprise Architecture, providing explanations for the different approaches that have been taken towards the Enterprise Architecture practice. One of the most-cited taxonomies is provided by the study by Lapalme [1], proposing three distinct schools of thought on Enterprise Architecture. The essence of these schools of thought is summarized briefly in the following.

The technically focused Enterprise Architecture school has its roots in IT engineering. As IT became a more and more important part of the business, IT engineers needed new ways to understand and align the relationships between the IT and the business, which led to the concept of Enterprise Architecture. Still, the business aspects remained seen primarily as a contextual factor for IT, provided for the IT to adapt to, more or less as given. Having a primary focus on the IT aspects of the enterprise and applying a reductionist approach, this incarnation of Enterprise Architecture seems to be where the discipline first originated from.

The socio-technically focused integrative Enterprise Architecture school is what we currently most likely perceive as the core of Enterprise Architecture. As IT became more and more embedded in business, information systems sciences emerged taking a more socio-technical stance towards information systems, comprising both social and technical aspects treated as equals to one another. Having an integrative focus on the various aspects of the enterprise, this approach to Enterprise Architecture strives towards holism and ensuring that all the enterprise aspects are properly integrated and work together as a whole.

The ecosystemically focused Enterprise Architecture school has received some attention in the recent Enterprise Architecture research. In addition to the organisation itself, this approach takes into account the organisation as a part of its environment, and recognises that the environment is not only something that an organisation needs to deal with, but something that an organisation can actively affect via its strategic choices. As enterprises grow in their complexity, crossing organisational boundaries and increasingly becoming multi-organisational networks or ecosystems, this perspective also gets highlighted.

The research trends seem to indicate that while the Enterprise Architecture discipline is traditionally rooted in the technical perspective and is currently most typically perceived from the socio-technical perspective, the ecosystemic perspective will become more and more prominent as there is a growing need for ecosystemic adaptivity, which is better supported by this approach [2]. However, it is still somewhat unclear to what extent this shift in Enterprise Architecture thinking is happening on an ideological level and to what extent it is actually happening in real-life practice.

What do we expect for the future of Enterprise Architecture?

It can be assumed that different kinds of Enterprise Architecture approaches result in different kinds of Enterprise Architecture capabilities. It has also been argued that technical or even socio-technical approaches have certain limitations in how much added value they can provide and what kinds of problem spaces they are able to address [2]. Failures of Enterprise Architecture implementations have sometimes been attributed to scopes that are not holistic enough, that focus too much on the IT aspects of the enterprise and that do not receive sufficient buy-in from the general management as a result. On the other hand, an Enterprise Architecture implementation can also fail by trying to apply a scope that is too ambitious, take on everything at once and not being able to deliver as a result.

One interesting question is whether the Enterprise Architecture practice is actually moving from the technically oriented approach towards the socio-technical and the ecosystemic stances as proposed by the theory, or whether Enterprise Architecture practices still seem to be somewhat associated with the IT side of the organisations. Another interesting question is whether Enterprise Architecture in its wider sense should be seen as a separate practice in the first place, or whether it should be even more seamlessly integrated into general management systems, which already address many of the same sets of issues that can be seen as being within the realm of the broader Enterprise Architecture approaches.

In the end, we should not make the error of approaching Enterprise Architecture as a detached practice, a rigid framework that should strictly adhere to a certain approach, “the single right way of doing EA”. Instead, we should focus on utilizing what is perhaps the most significant value-adding component of the Enterprise Architecture paradigm, which is a fundamental way of thinking [3] enabling to address organisational issues in a systematic manner by applying a systems approach, and utilising it to an appropriate extent in tight integration with the organisations’ general management capabilities. This can also be seen as one of the underpinning ideas behind the recent “lean” and “agile” Enterprise Architecture movements.

Read other parts of the Enterprise Architecture series: 

Enterprise Architecture thinking – not just the architects’ concern!

Enterprise Architecture thinking – from modeling theory to models in practice


  1. Lapalme, J. (2012). Three schools of thought on enterprise architecture. IT professional, 14(6), 37-43.
  2. Korhonen, J. J., Lapalme, J., McDavid, D., & Gill, A. Q. (2016, August). Adaptive enterprise architecture for the future: Towards a reconceptualization of EA. In 2016 IEEE 18th Conference on Business Informatics (CBI) (Vol. 1, pp. 272-281). IEEE.
  3. Winter, R. (2014). Architectural thinking. Wirtschaftsinformatik, 56(6), 395-398.

We at Gofore have professionals experienced in helping organisations setting up Enterprise Architecture practices tailored to suit their individual circumstances and needs. Please read more about our architecture consulting capabilities and feel free to contact us for more! Or, if you’re as passionate about architecture as we are, maybe you’ll wish to join us at Gofore.

Vladislav Ivanov

Vladislav is a Business Process Management, Process Architecture and Enterprise Architecture professional passionate about architecture-oriented thinking. He has several years of experience in method development and supporting organisational practices in these areas. He is currently researching the state of Enterprise Architecture thinking in Finnish organisations at the University of Jyväskylä.

Do you know a perfect match? Sharing is caring

Hi developer, have you ever been really disappointed with the content of your work? Namely, I was and I want to make sure that you did not do the same thing. This is how it is done at Gofore.

Background story – My disappointment

I slipped myself working for Gofore as a “career exchanger” about seven years ago. I wanted to learn web development with a modern stack.

I was already an experienced developer of industrial and mobile Windows desktop applications. I wanted to learn how to make modern web applications including Node, Angular, React, and Java. I chose Gofore because I rated the company’s development opportunities as the best, even though there were other offers on the table with a better salary.

The start at Gofore was a small surprise. Because of my background, I ended up doing maintenance for an application that was implemented with Java 1.4 for Windows CE. In a way, a pretty hardcore development that could have been fun, but in addition to the end-of-the-lifecycle technologies, the project was one man’s maintenance with another vendor’s developers. So I was there mostly alone with the neighboring company’s collared shirts.

All’s well that ends well. I used company time to study new technologies alongside my project, I attended a Scrum master’s degree with company money and since then I have ended up with really interesting projects, later as People Person and now lastly to connect developers and projects.

When I got to say how developers and projects are matched in the future, I wanted to make sure others would not get the same experience.

And this is how it’s done!

1 – Express your wishes

Gofore’s system for connecting projects and people is Hohto (Shine). It is our self-developed system that accommodates customer needs and developer profiles among some other cool features.

There are two ways to portray a developer’s interests: skills and free description.

Skills ⭐️ describe the level of competence and ❤️ one’s own interest in technology. For example, I still like C # myself and master the technique well, so I have marked 4 ⭐️ and 5 ❤️ in Hohto.

In addition to this information, there are much more difficult interests to model, so the free text is better suited to describe them. We have a ready-made eight-question battery that we ask every developer to fill out.

For example, “what kind of role you want to work in” already provides a good opportunity to describe your own dream role much more broadly than just skills.

This information is crucial for the next phase which is project matching.

2 – Project matching

In Hohto, all customer needs are transparent to everyone and everyone has an equal opportunity to get to the project they want. The same Hohto card can be viewed by everyone from an office assistant to a finance manager.

For all freed-up and new developers, their own people person (aka caregiver) will suggest suitable projects. People Person know their own people best and already know how to spot suitable projects.

Proposing is therefore important to maintain an active grip in matching projects and people. This way, everyone gets to the appropriate cards (they can also come and suggest themselves) to the appropriate cards and have a say on their project.

In many cases, there are many good options, and then we expect the developer to prioritize the needs so that we can make choices when winning multiple bids.

3 – Project rotation

Did we fail the project match? It happens sometimes because the information is not available or updated. Also, people’s interests, needs, life situations, and development interests change over time.

The solution for this is project rotation. You probably guessed already, but it happens also in Hohto with the help of People Person.

Want to know more about the kind of projects we can offer? Send me a message on LinkedIn or check out our open positions.

Juho Pentikäinen

Juho has a background in software development and he takes care of Gofore's People and recruiters. See you on a bike ride.

Linkedin profile

Do you know a perfect match? Sharing is caring

Creating wellbeing with real-time public data

It’s not news that all families are different with different needs in daily life. However, it has been a challenge for municipalities and cities to serve families based on individual needs as the information has been scattered around in different systems and the decision makers have not had the right tools to develop services from the families’ point of view.

Six municipalities in Finland (Tampere, Vantaa, Pori, Ylöjärvi, Vaasa, and Laihia) decided to take on this challenge in Advanced Family Analytics project and used Gofore’s digitalization expertise to create a detailed picture of 80,000 families with 132,000 children under the age of 19. The information was gathered from ten different national registers and the analysis combined information from experts, artificial intelligence, and ethical evaluation.

“The number of families is not essential in the construction of services. Because of the diversity of families, municipalities need to understand the diversity of the needed services and support. Family type or family background does not determine what kind of services a family needs. Depending on the municipality, the family may need the support of a social network, help in employment situation, or support for situation of a multi-challenging family,” says Petri Takala, Gofore’s leading consultant.

In the analysis, 100 different family types were defined and cross checked with 11 phenomena that affect a family, like the income level, education, health, and the socio-economic situation.

Although it was an expected finding that families have very different needs, the diversity of families was still a surprise. The mere result of the analysis and information about where or who needs what kind of support is not enough to bring about change, but a new kind of management skills and the ability to organize in a customer-oriented manner are needed to support the situation. In addition to digitalization expertise, the project utilized Gofore’s change management expertise. The range of means includes e.g. increasing interactivity and dialogue, bringing new management methods and practices to the organization, experimentation, service design and, in particular, modeling how and where the value experienced by the customer is generated.

With the help of the situation picture and new operating methods and information, municipalities will be able to operate in a more customer-oriented way and more efficiently. At the strategic level, the service network can be better designed when it is known in which target groups or geographical locations support or special expertise is needed. This will allow capacity to be managed and prioritized more effectively. The situation also enables equal treatment of customers, when both management and those doing practical customer work have the same information about the need for support, regional differences or even surprising target groups, such as the large number of young people living alone that the Advanced Family Analytics project revealed.

Advanced method combined with ethical reflection

Gofore aims to be, not only an expert in digitalization but the pioneer in ethical digitalization. Advanced Family Analytics project was a perfect example of ethical digitalization development where information handled can be very sensitive and the results have real effect on the analysis subjects.

The project is pioneering the way and methods of combining researched knowledge, expert knowledge, and artificial intelligence to obtain concrete results and form a situational picture.

“We have succeeded in modeling registry data with artificial intelligence and teaching the algorithm to work with researched and empirical data from experts. It has also been essential from an ethical point of view that man has led the process all the time. A similar approach to modeling can be used to analyze the well-being of Finns in other population groups,” says Petri Takala.

Ethical evaluation has been a key part of the project. Gofore’s analysts have guided the processing of the information and ensured that the data is handled responsibly, ethically and that privacy is maintained. It has not been possible to identify individual families from the data.

“The ethical review ensured that the results were interpreted correctly, and we were able to respond quickly to emerging ethical considerations. In addition to information security, we paid attention to, for example, our own preconceptions when interpreting the results, and to the fact that we do not inadvertently strengthen social dividing when communicating the results. Together, we have created operating methods for ethical evaluation that can also be utilized by other actors,” says Anna Seppänen, CEO of CoHumans Oy, who supported the project’s ethical process.

Come meet Gofore at Tampere Smart City Week Expo!

The experts at Gofore are more than happy to find out what kind of needs your organization faces when aiming to provide better targeted and optimized services. Meet the crew at Gofore stand at Tampere Smart City Week Expo and see Petri “Pepi” Takala on stage June 14 at 14.30-14.45 talking about how real-time public data can be utilized in serving all the different kinds of families.




This article was originally published at Tampere Smart City Week website on February 10th, 2022.

Petri Takala

Petri works at Gofore as a principal consultant in the field of data-supported leadership and management. He has an extensive experience in data-enabled decision-making practices and organizational systems design. He is an expert in customer-/ market-centric ecosystem management and the needed data-enabled platform services. Petri’s thinking is applied and taken into use widely in several areas of Finnish society, e.g. in AuroraAI, Finnish ethical AI-based service ecosystem development. Before joining Gofore Petri worked 15 years in Nokia as a senior analyst and development director, as well as the product lead in Efecte Plc.

Linkedin profileTwitter profile

Do you know a perfect match? Sharing is caring

We have always had a culture of learning at Gofore and to help, we have Gofore Academy supporting our employees.

In today’s world, a lot of learning happens through work. We believe that working and creating together is the best way to learn new things. The best solutions and brightest ideas are usually born when we do things together.

Gofore Academy: to remove obstacles to learning

The purpose of Gofore Academy is to pave the way for Goforeans in professional development matters or as we put it: to remove obstacles to learning. Gofore Academy offers specially tailored internal trainings to our employees. Academy also helps to find information on external learning events and trainings, what are the hottest certifications in our industry now, and what to do if you quickly need to learn a new skill.

At Gofore we have a wide variety of domain expertise needed in the IT consultancy business. We have developers, designers, testing specialists, management consultants, project managers, and more. The skills needed to master one’s domain are supported through guilds, teams, and other peer support groups. Gofore Academy serves all our specialists regardless of their domain.

Gofore Academy’s internal training offering is focusing on skills needed in consulting work. Some might call them soft skills, but in fact, they are the most complex skills there is when your job is to work together with other people. The ability to look at things from the other person’s perspective is the core skill we believe everyone should master. For a successful collaboration to happen we need to understand each other better.

Finding your own intrinsic motivation

We respect and value all individuals and their uniqueness and different wishes. Everyone has their own learning dreams, and we encourage everyone to take time to find out what tickles them and makes their eyes sparkle. What motivates you? After you have found that out, plan your journey and start taking concrete actions towards that goal. Of course, help is provided for making the personal development plan. Having a plan is a baseline for all development actions. And we do hope that once people have made their plans, they also share them internally with People Leaders and colleagues to help the dreams come true.

Internal trainings bring our people together

Gofore Academy has a good network of trainers that we collaborate with. Both internal and external ones. Having trusted partners who know our company, our values and ways of working is important. The reason we love the internal trainings so much, is the fact that they bring our people together, from different parts of organization, roles or even countries everyone has an equal opportunity to participate. Internal trainings are constantly being praised for introducing people with each other.

Some skills we have covered in our internal trainings organized by Gofore Academy are:

  • presentation and communication skills
  • influencing and interacting with people
  • social media
  • self-leadership skills
  • facilitation skills
  • basics of agile
  • understanding customer experience

In 2021: over 50 internal trainings, and over 600 participants

In 2021 Gofore Academy organized over 50 internal trainings. The trainings had over 600 Goforeans as participants. We have chosen the training topics from the needs arising in the company. We are constantly keeping our eyes and ears open for the current and future training needs which serve Goforeans in the best possible way.

For example, we have wanted to support our feedback culture and have tailored a special training for giving feedback. And even though we work together and have support from each other, the work of a modern knowledge worker is independent, and you need the skills and tools to lead your own work-life balance and wellbeing. For that need, we also offer a training series.

In addition to instructor-led internal trainings we have provided an online learning platform to our employees to help them learn i.e., technical skills when there is a need for that. With the help of an online learning platform, it is easy for you to take over maybe a new programming language when you can fit it into your schedule and study at your own pace.

Learning and renewing continuously

We want to offer Goforeans learning and development possibilities they need and wish. And when succeeding in that, people can learn new skills relevant to their development at their time in Gofore. We are learning in everyday work and having support from our colleagues sharing knowledge with each other through teamwork, in guild happenings, hackathons, and other peer support we have going on. And spice that up with learning possibilities that Gofore Academy offers. Sounds like a good combination, doesn’t it?

We continuously promote exploration of new ideas and technologies. Come develop your skills with the industry’s top experts. Read more!

Elina Seppänen

Elina is passionate about continuous learning and curious about all the fine things in life, from nature to arts to literature to science. In her work with Gofore Academy, she is happy to help people find ways to grow and master new skills.

Linkedin profile

Do you know a perfect match? Sharing is caring

It’s the end of March and many companies have published or are going to publish soon their annual corporate sustainability reports. What happened last year within the sustainability theme? Did we achieve the targets that were set, and most importantly did we focus on the right things, the most valuable impacts to increase our positive impact towards the society and environment? In fact, how do we identify sustainable business within our organisation and predict our sustainability actions, instead of just looking into the rear-view mirror?

In many companies it seems that sustainability is lacking behind in digitalisation and data-driven management. Even though there is an enormous amount of work behind the sustainability reports, sustainability related data is in many cases scattered around, the figures are collected and analysed largely by hand (e.g., manpower) from multiple sources and separate IT tools or systems. A lot of new information would be required also along the value chains. Why are things like this?

This year came into force the EU Taxonomy (a classification system for sustainable actions) and it seriously kicked some speed in aligning sustainable business operations and unifying the CR reporting related to it, and the new Corporate Sustainability Reporting Directive (CSRD) will expand the responsibility for reporting. In the Taxonomy, from the six environmental objectives only first two ones (climate change mitigation and adaptation) have been approved. The Taxonomy will develop further, and more detailed assessments of each business units and company operations will be needed. I can imagine that this won’t work anymore by handling Excel spread sheets.

The economical pillar of sustainable development is becoming more important, and the new obligations will require an unified approach in handling sustainability related data alongside with the financial reporting. The amount of required data is huge, and it must be incorporated to the existing information systems and decision-making. In any organisation, wouldn’t we want to simplify this and if possible, do the data gathering and required analytics automatically?

Companies that start developing data management and digitalisation within sustainability can perform better and be more reliable in the eyes of investors, financial institutions or other stakeholders. Planning the sustainability targets and measures based on reliable data is also a key in increasing the much-needed transparency and building customer or consumer confidence. This is the final call for companies to seriously invest in the sustainability data gathering, developing the processes and management systems and digitalisation capability in sustainability, instead of increasing manual labour or buying new sustainability tools.

ESG issues are important for Gofore as well and like before our company is aiming for increasing the portion of impactful projects. Pay attention to our newly published sustainability report 2021.

Want to contact our experts?

Teija Hakaoja
Head of Design.
+358 50 3257 207
Minna Tontti
Service Designer.
+358 40 1602 650
Kristiina Härkönen
Chief Sustainability Officer.
+358 40 7423 411


Minna Tontti

Minna works at Gofore as a Service Designer focused on sustainability. Her main goal is to help companies and organizations seize the opportunities of circular economy and create solutions that will help us reach the 1.5°C climate target. Minna has a strong 16 years of experience in the energy sector, traditional engineering, and consulting for various industry sectors. Her inspiration for design originates to developing tools and practices for reducing environmental impacts and considering different stakeholder groups there. In her free time, she’s an active participant in her community and volunteers for child welfare.

Linkedin profileTwitter profile

Do you know a perfect match? Sharing is caring

How would a general rise of 2.31% sound like? The company-specific collective agreement we made at Gofore in early 2022 has attracted widespread interest. In my opinion, the most interesting thing about the collective agreement is its salary settlement, where the general rise and, more broadly, the minimum amount of salary rises are based on the Gofore Group’s profitability and growth. The salary settlement also allowed the Gofore collective agreement to be made valid until further notice, instead of having to be renegotiated every year or two like other collective agreements.

However, the salary settlement is not entirely brand new. About a year ago, the Gofore chief shop steward, I was negotiating a local salary settlement for Gofore, and CEO Mikael Nylund presented us with an interesting idea: What if the size of the salary rises depended on Gofore’s profitability and growth? Mikael wanted the salary rises to reflect Gofore’s financial success. When Gofore is doing well, it can pay better salaries and the rises should be higher. At economically worse times, salaries could rise less.

Together with the shop stewards, we found the idea interesting, and we started creating a salary settlement based on it. We finally came up with a solution where salaries are increased quarterly based on EBITA% and organic growth for the previous quarter, according to the following formula: (EBITA% – 10 %) * 0,07 + (organic growth% * 0,0125). Furthermore, as such a solution would delay the general rises compared to the backstop settlement in the collective agreement, it was decided to pay a general rise of 0.6% in February to compensate for this.

The salary settlement was calibrated so that, if the previous year’s figures were reached, the earnings in 2021 would be approximately equal to the earnings of 1.2% general rise in February which was the backstop settlement. If we did worse, the rises would be lower, and if we did better, the rises would be higher.

(What does a backstop settlement mean? Collective agreements stipulate that certain matters may be agreed upon differently through local agreements, and e.g. in the IT service sector collective agreement, salary rises must be negotiated primarily locally. However, if no agreement is reached, the settlement in the collective agreement i.e. the so-called backstop must be followed. The backstop for salary rises in our case was a 1.2 % general rise in February plus a 0.8 % company-specific element, which the employer can distribute as they wish. At Gofore, this 0.8% element had already been distributed by the beginning of the negotiations, so we only discussed a general rise.)

We still voted with the staff on whether they would prefer a 1.2% pay rise in February or the salary settlement described above. With clear numbers, the employees chose our settlement.

How did we do over the year?

Gofore’s last year’s results were announced at the end of February, and we were finally able to calculate the general rise for the last quarter of the salary settlement. Was our salary settlement worth it or should we have stuck to the backstop?

The general rises during the year were as follows:

February: 0,6 %
2021Q2: 0,37 % (April)
2021Q3: 0,32 % (July)
2021Q4: 0,32 % (October)
2022Q1: 0,68 % (January)

The total increase from these will be (note the compound interest) ~2.31%. The graph below helps compare the 1.2 % February rise to our salary settlement. If a person’s salary in January 2021 was 4,500.00 €/month, with the 1.2% general raise their salary in January 2022 would have been 4,554.00 €/month and 4,603.98 €/month with our salary settlement.

However, the overall increase does not tell the whole story, as you also need to look at cumulative earnings. As can be seen from the following graph, with a starting salary of 4,500 €/month: one will start by earning less than with the 1.2 % February rise. At worst, in June the difference is € -84.75, but by January 2022 the difference of cumulative earnings is a positive € 34.74. In other words, the wage settlement was worth it from an employee’s perspective if they were employed still in January.

The biggest winners here are those who only started their work during or after February and would thus have missed the general rise in February. However, due to Gofore’s salary settlement, they received their first general rise as early as April.

Of course, general increases are only part of salary rises. In 2021, the average salary of Gofore employees increased by as much as 4.9%.

The Gofore collective agreement signed earlier this year made the salary settlement even better: the organic growth coefficient has been increased 0.0125 → 0.015 and in addition to the general rises, at least the same amount of personal salary rises must be distributed.

During the year, we’ll see how good salary rises we’ll get with the new salary settlement. Looking good so far!

Juho Salmi, Gofore’s shop steward, 2020-2021

Juho Salmi

Juho is a hard-core leadership nerd spending his working hours on agile, product and systemic leadership.

Linkedin profileTwitter profile

Do you know a perfect match? Sharing is caring

There are no dull days at Gofore. There is always something to learn and chances to challenge me. When one project ends, there is always a new opportunity to choose the next interesting project. As a software developer, I’m constantly interested in learning more, and hey now I have also seen what large-scale Spring Boot projects look like.

When we were having discussions about open projects in Gofore I saw there was an opening in Aimo Park. After hearing about what the project was all about and stuff that I would be doing I was completely sold. One could say Aimo Park project had a parking reservation in my heart after hearing what the project was all about. ?

Few words about Aimo Park for those who don’t know them. Aimo Park is a leading parking company in the Nordic region with close to 370 000 parking spaces. Gofore has been working with Aimo Park since 2016.

“I’ve fallen in love with doing backend stuff”

So, what I’ve been up to in Aimo Park project? I have been working as a backend microservice developer for the mobile application team. My job consists mostly of implementing features to microservices that the mobile application needs. The technologies that I have been working with most are Java Spring Boot microservices. As I said before, I had really focused on frontend technologies and learning about JavaScript’s quirks, and so on. But with this project, I’ve fallen in love with doing backend stuff more and more. ?

Prior to this project, I had experience with Java from school, and I had done a small internal project with it in my previous workplace. I was excited to see what large-scale Spring Boot projects would look like in Aimo Park. And I must say that I’ve been loving it. My only gripe with Java was previously how verbose it can get in some parts (getters, setters, etc.). Luckily, we use Lombok which in my opinion makes Java so much nicer to develop. It strips down, for example, all the verbose parts with special annotations that make it also much cleaner. Plus, other features that I probably haven’t even discovered yet. If I’d have to say something negative, one thing would be that I slightly dislike how much Spring Boot Automagically™ does behind the scenes. I’ve also had a chance to try out my TypeScript skills briefly in a couple of tickets related to mobile application development, which has been really nice change of pace.

A big part of my role also involves communicating with the microservices team about implementation details and so on. This also means that my merge requests are reviewed by people in the microservice team as I mostly work on their domain, and I must say that I’ve learned a lot from their comments and advice in merge requests. I love how everyone always helps me when I have questions about some business logic or something related to code. It’s also nice to have somebody who I can ask “dumb” questions about inner workings of Java and Spring Boot if I can’t find something with just Googling. I only have positive things to say about people that I’ve been communicating with (be it from my team, microservices team or somebody from Aimo Park business side).

Best: taking breaks together with the team

Besides other positive things in this project, I would say my favourite one is the Mandatory Fun event that is hosted on Tuesdays and Thursdays. There we get together to play some entertaining games with all the people from the whole Aimo Park project for 15-20 minutes. Games have usually been either Kahoot or Skribbl but new suggestions are always welcomed with open arms. My absolute favourite is Skribbl, as there I can bring out my artistic side with my laptop’s touchpad ? These events lighten up the mood in the project and I get to meet up with people that I don’t usually work within the project.

Overall, as a recent graduate, I would give Aimo One project 10/10. I have learned so much from the project’s domain and the people working there. There is always something new to do and research and the daily workday never gets dull.

Want to know more about the project opportunities Gofore offers? We hire Java developers for projects of different sizes in both the public and private sectors. Check out more!

Tuukka Juusela

Tuukka is a solid coder who has graduated from Tampere University of Applied Sciences with a Bachelor of Business Administration. Web development and JavaScript are close to his heart. Tuukka also enjoys disc golf and reading during his free time.

Linkedin profile

Do you know a perfect match? Sharing is caring

Designing services that leave no one behind is the right thing to do. For many of us this makes sense, but the how can be a trickier question. In this post I aim to give you as a designer something to think about when designing digital services for a more equitable society. Recently my colleague Maija wrote about the need for diversity, equity and inclusion in the digital transformation of our societies, I recommend you read her post before you continue with this one. !

For us to understand the vast differences in our lived realities as individuals, we need to have difficult discussions about who we are, what drives us and where we come from. These discussions can be awkward because we’re not used to them and quite honestly often times our differences are things that we try to mask or at least diminish. Let’s try to change that!

Diversity, equity and inclusion, DEI for short, is often seen as something that belongs under HR, in innovation units or frankly, somewhere else but on our own plates. But in fact, DEI needs to be intertwined throughout our businesses in everything we do, in our strategies, in our HR, in our communications, in the way we serve our clients. This is where I’d like to challenge you! As a first step, have those deep, awkward conversations with your colleagues and note what the things are that both differentiate you and connect you as a team. Once you see your differences, learn to celebrate them! After looking inwards, it’s time to look at the services you design. In the following section I will give you some pointers to think about when designing with DEI in mind.

5 tips on how to design services that account for diversity, equity and inclusion[1]

1. The service design process is already inclusive, when given enough time and resources

If you’re a designer, you’re most likely already using human centered design methods in your work. At its core the service design process, its tools and methods are inherently inclusive, but they do need to pay particular focus and earmark resources (time+funds) on DEI. For example personas work well in showing the needs and goals of minorities, but if you don’t pay attention you might oversimplify when developing personas, which often times means that the voices of minorities are excluded.

2. Strategically recruit for user research

Five groups of people are more often excluded from the design process of digital services than the general public: ageing people, language and cultural minorities, people with disabilities, people with lower socioeconomic status and people who are not comfortable using digital services. This is not necessarily on purpose, but people are easily forgotten or not included because of convenience reasons. So, every time you plan user research, ask yourself “who are we leaving out if we don’t pay attention”? To recruit diverse participants you can for example find relevant groups on Facebook or other social media where you can advertise opportunities or build longer term collaborations with NGOs.

3. Make the participation of minorities meaningful

When you speak to minority participants, make sure to actually use the data collected, even if the number of participants is small. Can you remember a situation where you’ve managed to include less participants from a certain demographic than you initially planned? I know I can. In these situations, it’s important to not disregard the input from these participants, making sure their needs and goals are also reflected in the process and outcome. Consider building additional validation/testing in the project, specifically for minorities. Work together with minority experts by experience, NGOs and use DEI and accessibility experts for evaluations.

4. Make the participation of different groups as easy as possible

Offer different ways of working, so people can choose the most comfortable option for them. Need a translator? Prefer face to face or virtual? Location (home/office/other)? Also remember to allocate more time for collaboration with minority participants.

5. Look inward and both include the minority perspective in the design team and build capacity of designers

Earlier in this post I challenged to you have awkward conversations. The next step from there is to look inward and build your project teams as diversely as possible. Include people with first hand minority experience but also different educational and career backgrounds, designers from different regions etc. Last but not least, educate yourself on DEI issues, attend trainings, follow public discussion, read blogs and listen to podcasts. And dare to have those difficult discussions, at work, at home and anywhere where people will listen.


Does it all still sound complicated and confusing? Don’t worry, we can help! These are issues that we have been thinking about a lot at Gofore as a part of developing our ethical capability. If you need a hand in getting started on designing inclusively, let’s have a chat and make it happen!



[1] The tips are derived from my MBA thesis research, the full thesis is available at:

Michelle Sahal Estime

Michelle works at Gofore as a Service Designer. Throughout her career, she has focused on reducing inequalities working at the UN, in NGOs and academia. In recent years it has led her on the path of digitalization, service design and user-centric design and she is particularly passionate about ethical and inclusive design. On her free-time Michelle likes movies, gardening and spending time with her family and friends.

Linkedin profile

Do you know a perfect match? Sharing is caring