Organizational architect as fixer

In his post Hire An Architect, Seth Godin thinks of the organizational architect as a kind of fixer.

"Organizational architects know how to find suppliers, use the cloud (of people, of data, of resources), identify freelancers, tie together disparate resources and weave them into a business that scales. You either need to become one or hire one. The organizations that matter are busy being run by people who figure out what to do next."

You can now buy a lot of the stuff you once had to build.

"It used to be that if you wanted to build an organization, you had to be prepared to do a lot of manufacturing and assembly--of something. My first internet company had 60 or 70 people at its peak... and today, you could run the same organization with six people. The rest? They were busy building an infrastructure that now exists."

Of course this trend exists in IT as well as in other aspects of infrastructure. As more of the IT requirements of the modern enterprise can be satisfied by packages and cloud, the emphasis shifts from overseeing development to overseeing procurement.

Thus the architecting and procurement of IT is becoming increasingly similar to the architecting and procurement of other aspects of the organization's infrastructure.

Who does this job? (See my post Who Architects The Organization?) The implication of Seth Godin's portrayal of the organizational architect is that this is may be an experienced dealer/manager rather than a technical expert. We may note that venture capitalists often bring in experienced managers as CEO or COO to complement a technically brilliant but managerially inexperienced venture. Thus it was venture capitalists who persuaded Larry Page and Sergey Brin, the founders of Google, to recruit a much older and more experienced CEO - Eric Schmidt. According to Google's website, Eric Schmidt focuses on "building the corporate infrastructure needed to maintain Google's rapid growth as a company and on ensuring that quality remains high while product development cycle times are kept to a minimum" (via Wikipedia). That sounds to me a lot like enterprise architecture.