7 Biggest Frustrations I Have Faced As A Lead Architect.

This blog lists the 7 biggest frustrations I that have experienced in 20+ years of working with architecture and some of my approaches to tackling them.

The frustrations I speak of come from different companies I have worked with over that time. I wanted to share these in hope that it helps other people; they are not frustrations I feel now!

1. The Idea Architecture has to be “hard”.

In my career i have spent a lot of time dealing with people who don’t embrace architecture because they see them complexity and not the benefit. It can be a bit overwhelming to the uninitiated. The best architecture is most often simple architecture; or a complex architecture that has been broken into consumable views. Sometimes its perceived as complex to do a formally structured architecture because architects have their own ways of doing things, which are not based on formal methodology, so there is a learning curve.

The more architecture you do, or the more you model with a language like ArchiMate, the easier it becomes. In some cases I’ve seen some architects spending much more time complaining about creating architecture than it would take to learn and do architecture.

To mitigate this I break things down into small consumable chunks. You may have noticed many of the ideas and things I present on this website are often simplistic – or miss some elements completely – For example in Planning Work – I didn’t mention Plateaus or Gaps. This is because when I talk about work planning I want to start with basics to get going. Sometimes you can achieve more by asking for less. Later on once people are more comfortable with some things I may introduce the next layer of complexity.

I give a lot of time in 1 to 1 sessions with architects – and I have a few people I mentor and spar with. To develop an understanding of architecture happens best when you have someone who actually has some experience and can explain not only what we do and how we do it, but also why. Those people I have mentored have gone on to teach many more architects.

2. Stakeholders not giving commitment

This one can be tricky, especially if the managers I am dealing with are ex technical people with a view of how things should be, what they want to do and how they will achieve it.

In immature organisations these guys want to just bypass architecture all together in order to get something out the door, or see architecture as just creating a technical view.

If stakeholders and resource owners don’t understand the value of architecture, and an EA is not a direct line manager of those architects, then architecture doesn’t get done. The consequence can be any or all of the following:

  • More incidents or major issues
  • Poor compliance to standards & huge costs when auditors come
  • Operational inefficiency
  • Poor scalability & automation
  • Poor business agility.

The best approach to tackling this is to show value directly to your stakeholders, by taking a few of their key problems and helping to solve them through architecture. You have to engage the stakeholders directly. At one point previously I had an architecture team and trained them in architecture discipline and had constant trouble with achieving anything. This was because although the architects saw value in what we were doing this value wasn’t getting properly communicated to the stakeholders, so I was never getting enough time commitment from the stakeholders that owned architects to show much benefit architecture can bring. I would say its better to engage stakeholders directly.

3. Business not Understanding the function of an architect.

Sometimes people get the Impression that architects just do technical solutions – which isn’t even true if they are technical architects. There are of course different types of architects with different functions – but in general, you have to understand the word solution.

To build a solution you need to frame the problem. An architecture isn’t complete unless it shows the requirements the solution must meet, how those requirements are met, and then the final solution. Requirements come from all directions – not only from the technicians themselves.

If you aren’t considering the needs in terms of the different aspects of architecture then its very likely your solution isn’t fit for purpose, If you are lucky at this point the technology is fit for purpose, but all the costs and the impacts of the changes haven’t been considered because you haven’t managed stakeholder concerns. When this happens inevitably there’s a cost overhead in communication, and often an additional overhead as we have to change the technical solutions when new things are raised as issues and you have general inneficiency.

Sometimes I have seen the opinion that project managers manage requirements; which is partially true. Project managers are concerned with understanding project status, and to do that they need to understand the status of requirements and their realization. For that reason requirements management may be laid down by a project practice. In organizations with immature architecture practices this leads to project management organizing and managing requirements. This can lead to overheads and challenges for the project managers who then need to start to get very technical to understand requirements realization. If a project manager needs very specific technical knowledge it normally means an architect is failing to do architecture somewhere.

This can be a disaster in large projects because there is an order to requirements and services. I have seen in some cases project managers take requirements and just assign them to different teams then each team takes responsibility for those requirements. This adds can be problematic because when a project manager manages the requirements work, the project is the focus, and not the development of the solution. In large projects this can mean architecture is worked on in isolation by different teams and when the pieces are put together at the end sometimes they don’t fit.

In addition to that, customer requirements and project requirements are not the only requirements that need to be managed – there are non functional security requirements, architecture requirements, as well as requirements from other teams. They all need to be managed together, and an architect ensures this happens by applying architecture discipline.

4. Not having architecture discipline

Doing architecture once you know how is not hard. Its getting to that point that it is second nature that can be tricky.

By architecture discipline I mean giving the time to do architecture things. Architects need to manage concerns, document decisions, and and either model or document things. If they aren’t given time or don’t give priority to those things bad things happen.

Firstly the value architecture brings to the overall organization is significantly diminished. There’s a lot of benefit you can get out of an architecture model. Not tracking key decisions in one place, or tracking how requirements are being managed leads to a huge overhead.

Firstly if someone else is trying to understand whats going on – they cant. It means extra meetings, extra time, extra cost.

Secondly over time we lose reasons why things happen. Architects and other project resources change. Even if they don’t – sometimes remembering why i did something yesterday is a challenge, thinking back to three projects ago a year back, is hard.

A third point here is that we lose the ability to collaborate. Its possible for a group of architects to work together – one on technical design, one on standards compliance, or to break down a project between all manner of dimensions. You lose the ability to do this effectively if you do not document.

Time has to be given to do full architecture, or development work may be inefficient or may drag on for extremely long time periods due to bad scoping.

Many people consider proper architecture discipline to be a pain in the ass, but it is MUCH cheaper than having to waste time correcting things after. Correcting things will take a lot of people a lot of time.

Its possible for good technical specialists to create end to end solutions without practicing architecture discipline. But when that happens you are suddenly reliant on that single resource, and you will find that adding extra “architects” to a project wont help get things finished faster – because the architecture doesn’t scale. The extra resources will have a diminished return because they simply dont have the knowledge of the people in the project and no way of getting it, other than to ask a lot of questions, that they may or may not get answers to.

The only way I manage this is to be clear in my communication with stakeholders. To identify what is needed in terms of discipline, and the risks of not having it.

5. Not having the skills

I’ve spoken at length about the benefits of different things, such as architecture, and ArchiMate. Architects need to understand how to structure and communicate architecture.

A common architecture language such as Archimate is essential. Its not enough to understand what a view looks like, its essential to understand the meaning of each element and meta-models that are being used to structure an architecture. Do that – and suddenly communication can become a lot more efficient and we can start to share and communicate architecture, and leverage some benefits of scalability.

Technical specialists are not architects and shouldn’t be confused. They are really important, but rarely do they think far beyond the borders of technology. You cannot take someone who’s worked 10 years in technology and just expect them to suddenly understand everything about architecture methodology. Anyone who has ever done any fly fishing will know there’s a lot of difference between observing it and actually doing it – even if you have spent 10 years fishing with a reel.

If you want to really leverage the benefit from architects they need to be trained, and they need to be working the same way. In situations where a company has several methodologies a mechanism needs to be put in place to align them.

If you don’t train architects to understand your common languages such as archimate consistent communication is challenging. Its much like putting 4 resources in a room that speak different languages and asking them to collaborate to solve a complex problem. As a Swedish Speaker i may be able to understand a few words of German, or as an English speaker I may have to figure some kind of sign language and resort to a pen and paper. English and Finnish are very different to Swedish and German. I may be able to figure out whats needed and solve the problem, but I may not be 100% accurate, and it would have taken a lot of effort and frustration.

Have architects mentored or trained.

6. Creating Architecture at the end of a project.

I’ve done a whole blog on reasons not to leave architecture to the end of a project. To sum it up in a sentence – when you leave it to the end of a project – its not architecture its archaeology.

Just don’t do this, and communicate to stakeholders the reasons its a bad idea.

7. When you see all above.

Sometimes there can exist a situation where all of the above can exist. When that happens its very hard to lead an architecture team. It can be hard to get management commitment for resource time to do anything because they don’t see the value of architecture. Because they don’t see the value, and they don’t prioritize it, discipline isn’t practiced so the value is diminished. This leads to architecture being left to the end of a project, which effectively kills off most of the benefit.

In these cases all I can say is chip away at the problem one frustration at a time. We need to be close to our stakeholders and to help them understand the value we as architect can provide to them.

Architecture isn’t the enemy of management. Its there to enable management, not place roadblocks for it. It’s only slow and ineffective when its not fully embraced. Once you have a good architecture team that is committed, running common languages, and a good repository, you can start to provide business intelligence and tools to management that can help them in ways that many managers I have met in the past could not imagine.