I have recently started a new assignment as a member of an architecture team, which had not happened to me in a while. In the past few years, I have been working as application developer and/or agile coach, occasionally fighting/collaborating with architecture teams. This new gig is interesting, in the sense that I get to experience first hand how technical teams create barriers around them.
Here is an example of a talk I had recently in the team.
- [colleague] so, we will have to deliver a repackaged version of Maven 2 to the application developers
- [me] why? it would be easier to let them use the official version, and explain them how to customize it. Besides, when I was working on projects that had architecture teams, I hated being handled repackaged and crippled versions of tools. It made how life harder and development slower.
- [colleague] that’s not how it works here; they are developers
- [me] ???
I think architects in their ivory tower are really a caste apart, while developers are the commoners. This is the same spirit that we can see in projects that use MDA (Model-Driven Architectures): “let’s have brilliant programmers as architects in a corner, and stupid programmers as application developers in another corner.” (on this note, if you can read French, please see my post on Valtech Blog)
The bright spot is that the head of the architecture team is going to attend a Scrum course soon. But our troubles are not over. Here is a excerpt of a talk I had with him:
- [me] so, moving from SOAP Web Services in Java 1.4 to SOAP WebServices in Java 1.6 is going to be a lot of work
- [him] hey, you know what, we should just deliver a intermediate version with no WS at all, just EJBs!
- [me] we can do that?
- [him] yes, no trouble; it is really easy to change the clients; besides SOAP sucks
- [me] yeah, it does. So… why we were using SOAP WS again?
- [him] because we were told to
It remains to be seen whether my position inside an architecture team will make it easier to change habits, or whether I’ll let myself adopt this attitude.
Rock’n’roll position…
Nice one Eric, I found a lot of déjà vues in your blog. There is a saying that you end up with slums when building cities without city planners and that the same holds for building enterprise IT without enterprise IT architects. While I agree that there is a grain of truth in this I also strongly believe that enterprise IT architects should work in “real” projects in order not to loose touch to delivering working software.
Want to change total software architecture and technologies without take consideration about the constraints of exist other business applications is very dangerous !
For me and when I see my experience, it’s easy to purpose quick changes…
But, it’s more difficult to purpose changes in a good process which can be integrate by software architecture, developpers and current business applications projects without add a big risk !
That is the real mission of a good architect : consideration of risk, management of migration in an exist multiple applications platform and stability insurance for risk reduct.
To evaluate the response of your architect, it should be interesting to know all constraints what he had managed to select his response about your opportunity change purpose.
Perhaps, you should complete the discussion with your architect and evaluate with more detail why he think great to manage changes with progress in his specific case ? And not simply think it’s a “ivory tower” management.
Investigations are good to develop our knowledge ;)
Olivier,
My point is not really whether it was right or not to replace SOAP with EJB or to deliver a replackaged version of Maven to developers.
What concerns me is that those conversations are evidence of walls between groups inside a company. This is very visible when there are talks of “them” and “us”.
In those examples, there were no attempts to communicate with the other parties to reach a potentially more useful options. That is really concerning to me.
The thing with technical architects is that they make things worse in at least 2 ways:
Also, I don’t see why we need to give a special title to this kind of people. If they really are more experienced and more competent, then they should not need any other title than ‘developers’ or ‘techies’.
Anyway, my opinion is hardly knew. For more details, please check out Martin Fowler’s article “Who Needs An Architect”. I must say that I completely agree with him.
At the very least, the people that are part of an “architecture team” should spend 50% of their time working on real projects that are directly relevant to the business.