Enterprise Architecture will become Agile
I collect in this post thoughts about a very interesting article from cutter entitled "Are Agile Methods and Enterprise Architecture Compatible? Yes, with Effort" that I found through Ed Gibbs’ blog who himself referred to a post in Dave Nocholette’s blog. Both have very valuable remarks on this article. I hope mine are worthwile as well.
First let it be clear that I really liked the article although I am not entirely sold on some of it’s premises, I concede that from a practical point of you in today’s world all of the advice it provides on Enterprise Architecture teams and Development teams is valuable.
I specifically use the term development team because, as noted in the article, Agile is a set of methods applied to software development and I believe most of the problems highlighted have a broader base than simply the agility of development. The main challenge that faces EA is to make itself relevant to development teams or be a nuisance or an ivory tower. Many recipes are provided in the article to achieve that in most current environments.
One of the premises of the articles is that teams that apply Agile methods do not handle environmental constraints well. There is nothing in Agile methods that supports that. I firmly believe that on the contrary, the phylosophy behind Agile methods promotes practicality over all. If it exists use it. Agile teams do that all the time with open source tools and libraries. Also I never met a developer, Agile or not that would want to rebuild his office’s network from scratch (there might be some but I never met them). I never met a development team that would develop a JMS implementation when it is already available in the company.
So to me, this article misses a great opportunity to harshly criticize EA efforts and the way they are thought of: as a general blue print because it is pretty and not an enabler for technologies in the company. I understand how useful EA could be but, all too often, it is a refuge for thinkers, it is open to political skirmishing and is adopted by teams to be ‘good corporate citizens’ (oops politics again). I can understand that cutter cannot say it like this to his clients. I believe that when EA acts as a technology enabler (doing all these pesky software evaluations, managing the installs, providing training for developers) it is very much liked by development teams and specifically by those who use Agile methodologies.
I would go one step further, EA if anything, needs to apply/adapt/adopt Agile methodologies. It will as soon as its success starts being measured and it’s failure rates evaluated (I can’t see EA have higher success rates than other IT efforts). It will then start to implement smaller chunks when they are needed by development teams (well starting a bit before, I will grant you that), strongly collaborating with development teams to constantly improve the architecture, even when it means redocumenting it. And by the way, Agile does not mean no documentation, it means that documentation must be very easy to maintain and cheap to produce (anybody said Wiki Wiki?). That implies significant changes in the coporate organization, just as introducing Agile methods in development did (or failed because it did not). These changes will take more time because EA is closer to the eyes (and heart) of upper management but, as more Agile practitionners join these teams the day will come.
So there you have it, it was really worthwhile for me (if only to read the original article and the comments cited at the beginning of this really long post). I hope it was for you as well. And if I am wrong, let me know, I promise I love to be wrong because it is a remendous opportunity to learn !
Next post: Agile, Leaders and the principles of democracy.