Architecture as a Separate Function

Back in 2006 we wrote about how Architects are Part of the Team and shouldn't sit in ivory towers. This entry addresses some of the problems that arise when this is not the case.

In several organisations that I have been exposed to the architects sit within a completely different organisational area to the development team. Whilst I can appreciate this from a budgetary and reporting perspective (to an extent), it causes a number of very visible problems.

Problem 1: Perception
It is very easy for the development team to see a group of architects sitting in a corner, and think that they are sitting in an ivory tower coming up with unimplementable ideas for the sake of it. This puts you at an immediate disadvantage when trying to communicate an idea to the development team, as you are starting from a losing position. It is also very easy to actually become an Ivory Tower architect in this situation.

Problem 2: No ownership
If the architects are not involved in the project development as a matter of course - with appropriate power and responsibility - they can not be expected to own the deliverables coming out of that function. This is particularly a problem with non-functional requirements where there is no one else that can own them effectively.

Problem 3: Communication and Responsibility
In the situation where an architect has no formal relationship with the development team day to day, developers and project managers are free to ignore architectural advice that they are given, and even not bother to ask for it. The architect has no formal responsibility for the success of the project therefore why bother to consult them? Developers may also be more inclined to "muddle though" rather than seek architectural advice. This can result in a very poor deliverable (especially with relatively junior teams), and with architectural decisions being made by project managers and developers.

Problem 4: Firefighting
Architects effectively become fire fighters. There is a likelihood that the architects only hear about problems once they have happened - often after something has reached production. This can mean that they spend a lot of their time going back and fixing problems that would never have occurred with a better structure and earlier, more effective input.

Problem 5: Trust
In this situation architects may lose trust in the development team to deliver their vision, and as such feel that they must take on all architecturally significant development themselves. This can lead to a further lack of trust - this time from the developers and project managers to the architects and a vicious circle arises.

Solution
Clearly the absolute ideal is that architects are part of the core development staff and share the same management reporting lines. However, if this is not possible for various organisational issues, the development process MUST support architectural input at every step and a code-review and sign-off process should be instigated.

How are things structured in your organisation? What problems/benefits do you find with that structure?

About the author


Sam is an independent Technical Architect working in Central London. His speciality is Enterprise Java Systems, with which he has architected and developed systems for the Financial Services, Retail, and Logistics industries.
He has co-written several books on the subject of Enterprise Java and is a keen speaker at conferences.

E-mail : sam.dalton at codingthearchitecture.com


Re: Architecture as a Separate Function

I've known teams where the architect is integrated into the team yet still fails to own the solution, communicate the architecture, be trusted etc. While sitting in the middle of a team of developers you can still be in a metaphorical corner, isolated by your demeanour.

I'm sure I'm not alone in sometimes seeing (ok, and occasionally being) an architect that busies themself, as part of a team, with writing isolated framework code or complaining about code quality without bringing in any process to address it.

I've no doubt this is not a problem specific to architects but it does highlight that a role is often as much about temperament as it is about experience. Perhaps this is exacerbated by considering "architect" as a title of rank rather than as a role?

Re: Architecture as a Separate Function

Hi Sam,

I haven't worked as a software architect within a company. My company provides architecture services (amongst other software engineering services) to other companies, and we usually have no authority whatsoever over our client's decisions; even when regarding architecture questions. We can only offer advice, and it is the client's choice to take it or ignore it.

1) Perception

Being an architect is a mediator role. Architects should be part of a client's team monitoring development, as much as they should be part of the development team working to that client's requirements. Architects shouldn't be perceived as members of either group. If this is the case, they've done something wrong. They should be perceived by either group as a champion for the other.

2) No ownership

I haven't come across a client yet, that wanted to own the non-functional requirements. This is usually the first thing we look for, and take ownership of. Formally, the NFRs are still owned by the client, but they are more than happy to go with our advice in this area.

On the other hand, if they want to own the NFRs: Good.

3) Communication and Responsibility

Communication is the most important part of the job.
Communication is the most important part of the job.
Communication is the most important part of the job.

As mentioned above, we don't have any authority over our client's decisions with regard to architecture. But you can imagine, we bear the brunt, if too many things go wrong. Therefore, I'm afraid to say, it doesn't matter how well the architecture is coded, if you don't get the communication right.

4) Firefighters and 5) Trust

As architects we can't - and shouldn't - try to fix anything when software has gone into production. Being an architect is a planning role, not a repairing role.

Solution:

The architect is a mediating, communicating, planning role (with a strong background in computer sciences). No wonder there are so few of us.

I hope that my perspective has provided valuable information to you. Yours definitely made me think about the way I am being perceived by my clients.

Best regards, Kai

Re: Architecture as a Separate Function

Everything you said resonates with my experience although I would argue that the architect does have a role to play during transition and operational support.

While it might not be part of the architect role to be involved in fire-fighting, it's natural that anyone with experience of the system (or any technical chops at all, for that matter) might be called upon to save the day. As experienced techies we have a lot to offer when things need urgent attention and our job title shouldn't stand in the way of doing what's required.

If we're evangelising the idea of breaking down the barriers between groups can we exclude ourselves from production support?


Add a comment Send a TrackBack