Design up front or let your architecture emerge?

Colart Miles over at Business Analysis Diaries asked:

“What’s the best philosophy for an Enterprise Architect… Design upfront or let your architecture emerge?”

Colart asked the question in the context of a project which was to use Pegasystems’ PRPC. You can click on the link to his blog above to read what he had to say, but I will just pick out a couple of key points here:

“I was particularly concerned about the base class structure knowing from experience that this is the part to get right at the start.”

“The clear steer I got from the Pega team (including Alan Treffler) was to hold true to an agile philosophy and allow the architecture to emerge.”

Colart got several excellent replies and my own response was as follows:

I would argue that the business and information architecture need to be analysed and stable before even choosing a technology such as PRPC. However, “stable” does not mean “fixed”, as the technology might bring along some benefits that would make changes to those architectures worthwhile.

I would agree with The Open Group that those two architectures need to be in place before defining the technology architecture. I assume Pega were talking about letting the technology architecture emerge, rather than the whole enterprise architecture.

I think analysis has to be largely waterfall up to the production of the high level system requirements (i.e., the statement of scope), but thereafter, requirements and data analysis should be approached iteratively.