We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

Agile Architecture Revolution: a new buzz, a new dream, or a new reality? Part 1

Vote 0 Votes

Have you heard such term as "Agile Architecture Revolution"? I searched Google for it and found a few references only , and all them pointed to ZapThink. So, let's assume that ZapThing has coined this expression, at least it is in the title of new Jason Bloomberg's book that will be available not earlier than in a year.

Jason argues that this decade, up to 2020, is the time of technological revolution. Maybe he is right, maybe not; I am not going to challenge this prognosis and vision. However, the combination of 'agile' and 'architecture' is an interesting topic, IMO, at least, at the beginning of this decade.

First of all, I'd like to outline that enterprise architecture, if properly constructed, can help in making corporate business agile to market needs. Cascading, the Business and IT Architecture can help to agile business and technology parts of the enterprise to the corporate needs (objectives and goals). However, to make such agility happen, those who construct and maintain architecture have to know what real corporate objectives and goals are. It is sad to mention that corporate objectives and goals in departmental interpretation can easily become fluid, just a little. When they pass through the hierarchy of business and technology management, the probability that you learn what was initially said out about real objectives is not more than 50% (based on my personal experience).


So, if the relationship changes between an enterprise (business/technical) architecture and the enterprise itself or related market is meant by "Agile Architecture Revolution", I think it is a bearded news. And if we are talking about an architecture implementation via, e.g., RESTful solutions in the Clouds, we have to say this straight - it is not about architecture but about certain technologies.

Coincidentally (well, do we believe in coincidence?), the same day I read about "Agile Architecture Revolution", I saw a presentation on Architecture and Agile Development ran by Endava in the IASA UK Chapter. The speaker shared his rich consulting experience in promoting Agile Development on many occasions in different companies and industries and tried to wed Agile with Architecture. He "turned the plate" in many directions and every time he had to admit that agile architecture demonstrated efficiency not higher than at the project level. In other words, cross-project, programme, divisional and enterprise level architectures got in the Agile Methodology as a "square leg in a round hole". Why so? What happens with agile methodology when it gets into a contact with an architectural solution (not technology)?

This is not a short story. When a company is small or a start-up, every developer knows almost the same as the company "knows". Then, along with the company growth, a separation of labour takes place and developers eventually find that they know very small part of the company knowledge. It is not wrong - probably, nobody knows everything about everything in the company but some people (especially, in IT) still believe that they know better how to drive the company, or, at least, its IT. In the agile Sprint-meetings, development team discusses which automated "integration" is better; at the same time, an architectural board discusses whether any automation is needed at all and, if it is needed, which the simplest (in maintenance) one might be chosen.

Thus, the higher level of architecture is and the wider spectrum of tasks and concerns it has to address, the further it is from the level of competence of the development team.
Moreover, there are two quite negative effects accompany Agile development. The first one is a poor documentation. There is no time in the time-boxes of 2-4 weeks to produce any sustainable documentation. Agile Methodology even nominated this documentation-less style into one of its benefits. Indeed, the documentation requires time but why waste this time if in the next project the developer can easily restore what was developed using his or her "quick notes"?

This methodology omits one simple objective (which is typical for developers) - ownership. If you are not a Director of your own company, who told you that you will be in the company for the next project? If the managers of the company allow a documentation-less style of development, they simply set up their own companies; they cannot guarantee that the employee would be available when needed and the cost of restoring the reasons and logic of the implementation when the original developer is absent may triple the cost of the development itself.

However, this is not all, unfortunately. The business also quickly learns that IT, which practices Agile Methodology, delivers small pieces of working SW frequently and does not resist changes in the requirements. Based on this, some business people construct an idea that there is no need for accurate business requirements in agile development, that the documentation and analysis may be relaxed and given to IT in a haphazard manner, and that IT will deliver... something. Who even recall an architecture in here?..

So, I am dreaming about the time when the Agile Feasibility Study - the very first phase of any agile project - would be spent on answering a simple question: does Agile Methodology apply to this particular case or we have to forget about it for now? If Agile Methodology is the official development and management practice in the company, if there are only agile PM and BA, who would dare to admit openly that it may be not the right one for the concrete task in the hands? Yes, this is about a man with a hammer or about a method that drives the purpose.

Nevertheless, there are some areas of business tasks where Agile Methodology is efficient and should be applied. These areas, IMO, generally relate to the User Interfaces of different kind and to tasks like BI where business is not sure what it can gain from using such capabilities, where many small changes or enhancements should be implemented quickly. If the business task is more serious, we need to be very accurate in selecting appropriate development methodology.

(to be continued)




| Leave a comment

Referred slides are very interesting; I recommend looking into them. Thank you, Alexander.

However, agile approach to BPM still does not explain why we need a term Agile Architecture. Does it mean that if we have a non-Agile Architecture, it is just OK? I disagree.

A correct Architecture is always agile; otherwise it is incorrect.

- Michael Poulin

Sure Michael, "A correct Architecture is always agile". We just need a properly architected mixture of modern technologies -- http://improving-bpm-systems.blogspot.com/2011/07/enterprise-patterns-caps.html -- in such architecture.

I believe that there is no "...agile approach to BPM..." -- BPM is an integral part of the EA which has the high level of agility.


Unfortunately, I cannot agree with "BPM is an integral part of the EA" because a) management is not a part of architecture, and b) an automation form is only one of possible implementations of architecture.

BPM, as a method or automation, can work at any level in the enterprise and not necessary at the EA level. I think that coupling BPM with EA is just a modern trend that ties everything with EA because EA nowadays is a hot topic. Sorry about that.

Moreover, BPM (in any form) does not have a "high level of agility" by itself; it may be used as an instrument for agility while we see too many examples where it is used in right opposite direction.

I will rephrase "BPM is an integral part of the EA which has the high level of agility" to "In my experience, EA (which synergises BPM and SOA) can provide the high level of agility for the enterprise".

a) BPM as a management approach can be a part of EA via BA - we can architect business to be managed by processes
b) BPM as an automation technique can be a part of EA via SA - we can architect solutions to be based on executable business processes (same processes as in the previous item)


Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more


 Subscribe in a reader

Recently Commented On


Monthly Archives