He started off be describing what he saw as the typical development of an architect. One starts out, fresh from university all keen and eager to build some exciting and cool software. This is the "Enthusiastic Developer" stage. Unfortunately it turns out that what customers want is typically boring, boring, boring - "create a system that allows us to maintain Customers"; "create a system that allows us to maintain Products", and so on. This leads to the "Disillusioned Developer", repeating similar tasks day in and day out. Then, having seen that they are doing something that looks the similar each time, the newly minted architect decides to build a generic solution, a "maintain generic things" engine. Then we can spend just a little time (oh it will only take us a few months to get the framework finished) and then there is only a small amount of specific configuration required, say 20% of the over all total effort. This is the "Enthusiastic Architect".
So they spend 80% of the time building this wonderful generic solution and then then remaining 320% of the project on the rest of it. The problem being that customer's don't really want generic solutions. The form that they want to use to maintain their customers has to behave differently from the one used for products (otherwise they'd use Excel right), it's all those little exceptions that one has to introduce to work around the generic solution, or to extend the generic solution into an all signing and dancing framework that takes the time. We've all been there, well at least all of us who are honest and will admit it. This leads to the "Disillusioned Architect".
He gave a fun little quote: "Some programmers when faced with a problem turn to a generic solution... Now they have two problems."