There are various technology "holy wars" that have been fought throughout the years.
PC vs Apple
Thin client vs Desktop computing
etc.
Some have been resolved and some still continue to this day.
And now, as more digital / business transformation projects are adopting an agile approach to software configuration and development... another battle, albeit one that has been raging for some while, is growing in its intensity and prominence.... That of the agile approach vs the need to define architecture for a solution in advance.
As both a supporter of agile to create products & get feedback quickly, and an architect of digital products and services (both large and small) I understand both sides of this war.
Agile:
Wants to develop minimum viable products as quickly as possible, then get this in front of users and rapidly iterate towards completion. The focus is on "good enough" not excellence and likes the flexibility to change & improve features.
Architecture:
Designs those things that do not move... and the resemblance to buildings IS intentional. Architecture is usually fixed for the long-term and gives the foundations for other more nimble practices around it. Technical Architecture (what I define as the combination of the Enterprise Architecture and Solution Architecture disciplines) should provide general directions (e.g. public cloud/hybrid/private, buy vs build, etc.) and standards. Plus architecture should also make higher-level decisions on technology and principles which would be hard to change subsequently (e.g.coding language, integration methods, etc.).
Where things get messy is in the lower-level design of applications and their solutions. Here is where the agile versus architecture battle is waged. Where teams need to be empowered sufficiently to create products that meet the user stories... but also need enough guard-rails and check-points to operate within governance.
PC vs Apple
Thin client vs Desktop computing
etc.
Some have been resolved and some still continue to this day.
And now, as more digital / business transformation projects are adopting an agile approach to software configuration and development... another battle, albeit one that has been raging for some while, is growing in its intensity and prominence.... That of the agile approach vs the need to define architecture for a solution in advance.
As both a supporter of agile to create products & get feedback quickly, and an architect of digital products and services (both large and small) I understand both sides of this war.
Agile:
Wants to develop minimum viable products as quickly as possible, then get this in front of users and rapidly iterate towards completion. The focus is on "good enough" not excellence and likes the flexibility to change & improve features.
Architecture:
Designs those things that do not move... and the resemblance to buildings IS intentional. Architecture is usually fixed for the long-term and gives the foundations for other more nimble practices around it. Technical Architecture (what I define as the combination of the Enterprise Architecture and Solution Architecture disciplines) should provide general directions (e.g. public cloud/hybrid/private, buy vs build, etc.) and standards. Plus architecture should also make higher-level decisions on technology and principles which would be hard to change subsequently (e.g.coding language, integration methods, etc.).
Where things get messy is in the lower-level design of applications and their solutions. Here is where the agile versus architecture battle is waged. Where teams need to be empowered sufficiently to create products that meet the user stories... but also need enough guard-rails and check-points to operate within governance.
