Interesting diagram. Where I work, Enterprise Architecture is certainly a common progression from one of the other disciplines. Most, perhaps all, of the chief architects (i.e. the real big hitters) are enterprise architects.

We don't have the concept of a systems architect, so it is hard to map your diagram, but one way you could also look at it is the sort of questions you would expect each type of architect to answer:

• Lead Developer: What persistence framework should we use? What inheritance pattern should we use here?
• Application Architect: Should we store data in this database so it can be reported on? Which product should we use here? What persistence framework should we use?
• Infrastructure Architect: How many machines do we need? What network zones should they sit in?
• Information Architect: What sort of data warehouse is applicable to these requirements? What sort of schema should it have?
• Enterprise Architect: What should be our strategy on email? Network convergence? Document management? etc

So if you believe that, an Enterprise Architect is still technical, but at the strategic level, not at the code level.

Tom

• What is our middleware strategy?
• Can the current systems meet our future business growth?
• How do we consolidate our multiple disparate systems?
• How can we migrate off our legacy platforms?
• etc.

Currently, enterprise architecture exists on the CIO's direct staff in many companies. While this is a very important position from a strategic planning point of view, it's still weighted towards technology implementation.

I think it would be better to tie enterprise architecture and portfolio management at the hip; the former's interest is doing the right thing for the business while the latter's interest is doing the thing right for the business. Placing the combined office on the staff of the COO or CFO now makes them directly accountable to the business. This also embeds the function directly into strategic business planning and budgeting which, by design, directly "aligns IT with business." (I hate that buzzphrase)

What I have found when I have worked in an organization where there was a CIO heading up IT is that I had a great understanding of the problems we had trying to solve the business problems with technology. When I have worked in organizations where a CFO was the head of IT, I had a great understanding of the business problems we were trying to solve with technology.

Here's a skeleton from my past. In one company I worked at, we were implementing a new accounting system and IT was run by the CTO. We did it for all the usual reasons like single view of the data, faster processing, unified reporting etc. The roll-out was a marginal success. The following year, IT was headed up by the CFO after a re-org. During phase 2 of the implementation, we found out the real reasons for needing the new system included the desire close the books on the 30th or 31st of every month instead of the 35th or 36th of every month, process expense reports during the payroll period they were submitted for and to accurately forecast sales. We had a lot of re-factoring to do. The result was the revised system became a catalyst for revenue generation. The dev team-lead received a standing ovation from the sales and accounting departments at the annual company meeting.

Others have commented on the existence of the Infrastructure Architect role, and I agree on that. The System Architecture section of the diagram essentially consists of both the Infrastructure Architecture and also the Application Architecture. If these roles are being done by different people, as they often are, then they need to work closely together to make sure that the requirements are being met properly. A combined role could also be called Solution Architect, perhaps?

The parent company that used to own my company is a large telecoms company and they had Solutions Architects. But in my mind these were actually Infrastructure Architects because they didn't have anything to do with the application software itself, which in most cases was just something that lived on the box labelled "appserver01" on their diagrams.