Agilists vs. Architects - Can they be friends? - need input!

Agilists vs. Architects - Can they be friends? - need input!


Mike Jones and I were just watched talking about a very interesting presentation by Martin Fowler and Rebecca Parsons on engaging the Architecture team into your Agile methodology. The presentation is titled "Agilists and Architects: Allies not Adversaries" and the summary points out that "As Agile becomes more accepted, concerns from architecture groups are increasing. Traditional ways that architects engage with development groups conflict with Agile methods."

With architecture being a core component of the OutSystems approach to Agile application development and the role of Delivery Manager, we thought it would be interesting to share this presentation and ask the OutSystems Community how you have embraced architecture while practicing Agile in an Enterprise setting.

For example, I know that many of you are successfully delivering a high degree of reuse while focusing on delivering individual applications. While OutSystems' Agile Platform provides a solid foundation for refactoring code and adjusting architecture in progress, I suspect that there are many instances where your Corporate Architecture team needed to play a role in moving the application delivery forward.

So, if you are a Delivery Manager or Architect it is time to share your experiences of working together in an Agile application development project. How much education was required? Did you feel resistance? What were the lessons learned?


I've been doing software architecture work for quite some time. Both with and without OutSystems platform, and in the recent year adopting agile methodologies.

What I seem to find out is that Agile goes hand in hand with large and distributed systems architecture. By nature these systems already change a lot. We've been trying to reach patterns since the beggining of ages that allow for easy maintenance, no (or low) impact on performance, and most of all, accelerated development. This requires design both at a high level as well as a low level.

Yes, we're agile. However, we cannot drop the high level design up front. We need to have a (not very clear) vision of what we are going to need. And agile copes with that. I found out, when moving to OutSystems, that you are provided with the most relevant patterns from scratch. The very nature of the platform extension mechanisms won't let you easily fail. It also provides you a kind of Domain Specific Language approach from the beggining, that will force you to create (and all developers to follow) well defined guidelines. All the assynchronous design patterns are also easily mapped to the patform potentials in timers. When coping with external systems or a corporate company architecture definition there's not much to trouble us as well. We're either at SOA (which OutSystems fits like a ring) or some other kind of integration pattern, for which you know you'll have an integration layer only for transforming/transporting/auditing/etc., that will be either implemented out of the box, or via a simple extension. All this facilities reduces the effort in defining the high level architecture, assuming you're confortable with the usual design patterns. This way you don't have to go very deep on the initial architecture definition. Just focus on business components/modules decoupling.

I am now in a software factory with a very large architecture basis. The only thing required is that, whenever a new requirement appears, you do an overall architecture impact analysis. If you have the above topics considered, you end up in having a new component. If the business requirement changes (and you'll adopt it "immediately" because you are an agilist), it will probably fit in its own business component, or have relatively low impact on the surroundings.

What about when there's a requirement that reaches all levels? If you've decoupling from the start the Core entities (business domain core - the ones you usually specify the DSL for) from the business components/processes on top of them and also from the integration layers, there's no big issue. You'll probably end up in refactoring some core processes to decouple even more, so that the new requirement fits in an isolated way.

This proved me that agile will make you good architectural choices. And if you know from the start you're going agile, the architecture will come out much stronger and maintainable, just because of the fact that you're thinking, from the beggining of ages it will be ment to change.

Kind regards,
Gonçalo Borrêga
Gonçalo, I did not understand the following:

What about when there's a requirement that reaches all levels? If you've decoupling from the start the Core entities (business domain core - the ones you usually specify the DSL for) from the business components/processes on top of them and also from the integration layers, there's no big issue. You'll probably end up in refactoring some core processes to decouple even more, so that the new requirement fits in an isolated way.

Can you elaborate?

As we all know, the main reason for becoming agile is that it is not the way we do (and architect) IT software that changes... but business. To explain better what I meant by having the need to change core entities I'll give two examples, one that is a huge case of core business change and one other that happened to me.

First one is about UPS (the "shipping" company). They started by simple pick and delivery. In the last few year they changed their business to a full logistic consulting firm. They are now the ones who actually do HP support when you return your broken printer. Instead of picking it up, tranporting it to their hub, moving it to the nearest HP factory for repair and then doing it the whole way around back to you, they actually have their own teams who fix it right in their hub. Same goes for special packaging on internet shpping companies. They are the ones that pack together some of the holiday season sets of products that you get discounts when you buy a camera+case+batteries charger at once. They even wrap it and bill it to you all at once. Now, I don't know their system, but I imagine that this was way out of scope on the initial platform. This also required UPS to change the way they work and relate to customers in their core business. Although this is "just" one more business process, it certainly affects their core business so much that if it was me pulling the chords I would certainly change the core entities to reflect this whole new way of doing business. After all this will affect their accounting, CRM, human resources and will probably bring along a whole new set of integrations with their "new partners" (previously customers). This is certainly a design decision that may be controversial but I think architecture is not - yet - rocket science and there is some personal input that we have in the way we design software.

The second example comes from the nineties when I was starting my work as a developer. I started working in a very small company (me and 3 other guys) that had to change very often in the beggining to adapt to our demanding (few) customers. We started developing a product for general retail of franchised shops. We had POS software for the malls and management software for the offices that was able to gather info from all shops. It was quite good but we couldn't get much further because there were already some larger companies there. We then found our niche. It turns out that having 3 extra dimensions for categorizing a product was a huge benefit for clothing retail. They all considered the size, color and (in some cases) length of a product information as important (or more) than the model or description of that product. We made the largest refactoring of all times for that product to include this information in all related processes. Every kind of analysis was around those 3 so called "dimensions". All stock management was around that. Pricing was changed (and in some cases automated) to take the dimensions into account. The "integration layers" with printers and bar code scanners were changed to work with dimensions. The whole product was optimized for those 3 little fields. This was my first requirement to change a set of core entities that touched a bit of all surroundings. Back then we never heard the word agile, but coping with this change allowed my former company to be a leader in Portugal for clothing sales software.

Summarizing, sometimes we do need to change the core entities. When you do that, one of two things happen: you see the business change and you adapt to it or it is really you that change the business supported by your system (when the system is the core support for the business). Funny thing is that an agile methodology, and an agile software architecture, facilitates this a lot.

Kind regards,