This is our first blog in a series where we interview our consultants about their projects, current challenges, and how they approach these challenges. We build up the story in three parts: first, we sketch the context in which the project takes place; next, we look at the assignment and responsibilities. Finally, we dive into the approach taken and lessons learned by the consultant. In this first episode, we interview Aino Andriessen, IT-Architect.
Meet Aino
Hello Aino, can you tell us something about your current customer organization, how it is structured, and about your position?
I am currently working in a secondment construct for a semi-governmental organization responsible for various governmental tasks towards citizens, which is, in essence, the execution of certain parts of Dutch law. It is a large organization with a workforce of about 25.000 people, of which roughly 10% work in IT-related functions. The organization is divided into multiple divisions. Seven of them have a primary business responsibility, while the others are responsible for secondary processes such as HR, Finance, Control, etc. The divisions themselves are rather autonomous, have their own management and are responsible for their own IT.
Most divisions are further divided into domains with their own business focus and their own IT. Each division also has a cross-domain IT department which addresses cross-cutting concerns and supports the IT functions of each domain. The architects are part of this IT Office. We identify business, IT and lead architects. In our domain, a business and IT architect together are responsible for the architecture of a specific domain, while the lead architect is responsible for connecting the domains to the division and the enterprise level. You can find the same IT Office structure at the enterprise level.
Assignment and responsibilities
Great overview of the context, Aino; what is your assignment and corresponding responsibilities?
As a domain IT-architect, my first responsibility is maintaining high-level design documents detailing the actual domain architecture. These documents describe the base architecture of the domain in terms of the technical landscape and the business capabilities provided by this landscape. In addition, I am working on the target architecture(s), that is, the envisioned and changing architecture in the coming years. There are currently two main drivers for this target architecture. The first driver is internal reasons, such as expiring licenses, end-of-life hardware, and end-of-life software. The second main driver for this target architecture is a reorientation of the organization from a law-focused organization towards one that focuses on the citizen and their journey when interacting with this organization.
The IT Systems in use are quite long-lived and have been built with a long life span in mind. The landscape has applications that are over 30 years old and have evolved into the current state. Although the end-of-life of these applications is nearing, they still fulfill an essential role in the organization's primary process and still serve many citizens. Functionalities, processes, and business logic are entangled in large systems, making it hard to isolate, change, and let alone replace them. Full replacement was attempted ten years ago but did not succeed. Consequently, there was even more hesitance to make significant changes or replacements. Slowly but surely, this resulted in a 'catch-22 situation' in which technical limitations led to business limitations and vice versa, leading to a culture of stagnation rather than innovation. With the new focus on the customer journey, more and more systems need to be changed because they can't serve the clients the way the organization wants.
It sounds like there is a need for both more flexibility in the IT landscape and a culture change. What is your involvement or activity in creating this flexibility and change?
Now, this is actually an interesting question as there's a formal and an informal side to it. The formal and official aspects are via the creation and alignment of architectural artifacts, mainly the domain target architecture and the project start architectures. The informal ones are by aligning architecture and realization via culture, habits, craftsmanship, and organizational aspects.
For the formal side of things, the long-term planning and organization of change is defined via the target architecture of the domain; for example, by changes made in legislation, there are changes elsewhere in the landscape and infrastructural changes. This target architecture is usually updated in a five-year circle. But then, the actual execution of these plans is done in projects. While the domain architect is responsible for the target architecture, the project architect is the one who writes a project start architecture that envisions the project architectural approach, and often, these are different persons.
Currently, two major projects influence the dynamics in my domain. One is about the technical modernization of a core system, while the other is about redesigning the primary business processes. This leads to complicated situations. We have domain architects responsible for the IT landscape's continuity. At the same time, multiple project architects are responsible for changing the same IT landscape. It's like a ship with multiple captains. It is essential to align all architects involved in order to influence the direction of change toward the envisioned architecture. In my opinion, this is a major responsibility of the domain architects.
I realized that to change the systems in the desired direction, it would be helpful if the culture, the organization and our way of working would change accordingly. 'If you continue to do what you always did, you'll be destined to get what you always got.' We as architects need to ride the 'architect elevator' and ask questions to create awareness of the envisioned organizational changes regarding the way of working and technology. Only if an organization is aware of its challenges can it start reasoning about the solutions. That means we architects must provide the right context by asking the right questions before considering the solution. I think this is an important, although less formal and visible, responsibility for architects.
I started seizing opportunities and asking questions, 'challenging' the current practices and responsibilities.
As architects, we have insight into the future direction of change. By asking questions, I create awareness of the future changes to be made in the organization, the way of working, and technology. Only when an organization is aware of its challenges can it start reasoning about the solutions. That means we architects must provide the right context by asking the right questions before considering the solution.
Approach and Takeaways
That sounds like a challenging environment, Aino. What kind of strategies or approaches do you apply to find a balance between an organization that focuses on stability while there is a clear need for change?
It is important to build a network of people to be able to align the direction of change, as mentioned before. I need these colleagues to have direct lines of communication next to the formal communication chains. With these people, it is important to focus on what issues or topics matter to address myself and to influence the right people around me to act on the other aspects. It is important to identify what aspects of the domain architecture impact the projects to ensure they contribute to the long-term continuity and flexibility of the organization.
It is essential that people don't just decide on their own but involve those impacted by their intended decision, cross-project, and on the level of architecture and stakeholders. Therefore, I challenge people and teams to make them aware of other needs in the organization, other directions, and opportunities and invite them to make better decisions by questioning the people in the organization, where the ideas originate from within the organization, which is much more powerful than me telling them what to do.
That is an interesting balance; to achieve your goals, some 'pull and push' is involved. As a final thought, do you have some key takeaways you can share with our readers?
Sure! Some takeaways for architects in similar organizations:
Communication is everything. Asking the right questions at the right time is essential and more important than providing all the answers yourself. Don’t take things for granted.
Make local initiatives fit into the greater organizational goal and direction; focus on global coherence over local optimization.
If you don’t involve people up-front, you get resistance later on.
The realization team is about the 'how,' the product owner is responsible for the 'what', and the architect contributes the 'why.'