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 , 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 . 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 . 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  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:
- Lapalme, J. (2012). Three schools of thought on enterprise architecture. IT professional, 14(6), 37-43.
- 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.
- 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.
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.