Re: Can architecture emerge from continuous refactoring?

Recently I've been asked this question "Can architecture emerge from continuous refactoring?" and since this topic is very close to what I do professionally I wanted to share my thoughts about it.

What is software architecture?

I see software architecture as a parallel to a traditional architecture: it consists of knowledge about everything that is required to build a successful software product as in to successfully construct a building. In a context of a particular project architecture eventually results in a team vision and a set of documents that guide the team towards the successful completion of a project and achieving the goal. From this point of view it is obvious that if the goal itself or any of its dependencies and prerequisite are not envisioned and well defined then a team simply will not know where to go and never reach the point of success.

Can software architecture emerge successfully from continuous small refactoring?

Often there is some legacy software in place and there is not enough time to redo the whole project from scratch so the only way is to apply small refactoring steps in order to make software better from the architecture standpoint.

Hence software architecture can and should emerge successfully from continuous small refactoring. For me this is not a theory but a proven fact since that is what most of my job as a Software architect consists of: I am orchestrating my development team to apply continuous changes and refactoring to the code base in order to shape the architecture into the right direction.

Factors of success and failure of a re-architecture project

The main reason for success is for a team to be persistent and consistent on the way and for an architect to have a complete vision, fully understand the final state of the re-architecture process and the way of the architecture transformations.

Opposite to the above when an architecture transformation is not a priority target and a team is not given enough time to work on the necessary changes then the new architecture will not emerge. It's not a "rocket science" and it's exactly the same process of achieving a goal as in any other human activity.

Some other reasons of re-architecture failure could be lack of the architectural vision, poor management, lack of architecture transformation understanding but I don't consider those to be the primary reasons bur rather the missing prerequisites for a re-architecture project.

Lessons learned on the way

Even though it's somewhat useful to learn from mistakes but I'd rather learn from successful implementations since what you can learn is a way to actually achieve the success.

Re-architecture methodologies

Some people are convinced that using a right tool will guarantee the success and therefore focus on comparing and selecting the "best of the best" methodology. Lately the "agile" word became very popular in regards to that.

From my experience any agile method is just a tool that may or may not help depending on a use case. Agile for me in this context is only a synonym of "continuous, persistent and consistent" way of moving towards a project's target. Whatever method is embraced by a team will work for me as long as it allows a successful completion of a project.