The layered architecture of architects vs. the onion
Posted on January 28, 2016
I have previously blogged about Onion Architecture, in relation to mobile application development, but is it also applicable to the architecture stack of your organisation? I guess it is!
Beware! I will be boxing architects, knowing that in the real world, they might a little more flexible than I try to make them. But very often, they are quite square! So if you want to start the S***storm, please do. I’m wearing my raincoat so it washes right off.
Larger enterprises often have a number of different architect-roles organised in a layered structure. On top is the enterprise architects that have an overall and very strategic look at the different systems and the domains of the organisation. They have absolutely no idea of the actual code being implemented by the delivery teams.
Below the enterprise architects, typically a solution architect is placed. These have the overall architectural responsibility for several applications that together provide a business solution. The solution architects look at the responsibility for each of the applications in the solution and how they interact. They have a little more knowledge about the code being implemented, especially the parts that communicate between the individual applications.
Even lower is the application architect. He/She is looking at the individual layers of the application, how they are secured, how they communicate, how they log etc. This is very application specific, as one application might have a requirement for high performance and as such needs to be architected in a way to support this, while another application need a high level of security (Read more in my post on Non functional requirements as the basis of the application architecture)
Parallel with the enterprise, solution and application architects, typically you’ll see an infrastructure architect and maybe even a security architect. They look at the systems and domains from yet another perspective and provide knowledge and guidelines on how applications should be implemented.
At the lowest level, we find the delivery team. These are the people who have to translate all the ideas that have been grown in the architectural “ivory towers”. They have to translate the architecture into software design and code. This is the place in the value-chain where value as actually added!
The big issue, as I see it, is that the communication rarely jump more than one layer. The enterprise architects communicate to the solution architects, the solution architects communicate with the application architects and the application architects communicate with the delivery teams. In this process, a lot of information is lost and the reason why decisions are made, will disappear. The delivery team will be forced to do certain things without knowing why and that is extremely de-motivating. If you don’t understand why you should do things in a certain way, there is a huge chance that you will actually not do it in that way. I have seen real life situations where the developers – and even some of the application architects did not know the names of the enterprise architects – even in relatively small organisations (<1000)
But how is an onion solving this issue? In the agile world, the concept of cross functional teams are central. In order for a team to be able to deliver, the team must have all the resources needed available in the team. Usually, the team does’nt really need the enterprise architects in the delivery phase, but in the architectural runway before the delivery is starting, it can be very beneficial to organize the architects in a cross functional team. The central part of the team must always be the delivery team. Because if they don’t understand the thoughts and ideas coming from the architects, they simply won’t be able to implement them. The strategic architecture decisions must be made operational, otherwise they are worthless.
The “architectural runway” concept, where a cross functional group define the initial architecture before the development sprints start up, is a brilliant place to gather all the people and make sure the knowledge is passed on to the delivery team. This is the time and place to explain why the responsibilities of one application is defined as they are, why they must communicate the way they do and why they must work the way they do. These are all parts of non-functional requirements. While the functional requirements are elaborated by a product owner next to the team, the non-functional requirements will not be as easily elaborated during the development sprints as the higher level architects typically is harder to access. But the non-functional requirements are also a lot less dynamic and as such, the architectural runway is a great place to elaborate and implement them.
One could argue, that the “higher level” architects just should be available during the delivery phase. This is also correct, but availability also requires that the delivery team actually knows the architects. And having worked together during the architectural runway will increase the social binding and make it a lot easier for the development team to approach the architects.
And who knows.. Sitting in the same room as the delivery team, might give the architects some feedback that they can actually use to improve their ideas.