Giving names to two different roles within Corporate IT Governance

There is a difference between simplifying a porfolio and creating a system of behavior that favors and produces a simple portfolio. These are different animals, as different as law enforcement and economic regulation.

Just as the police are there to remove criminals from open society, you need a set of 'simplification cops' who will find egregious cases of PROJECT TEAMS that want to break the rules and work within a judicial process to produce consequences.  On the other hand, just as auditors provide an air of transparency for corporations, allowing investors to make wise choices, you need a system of funding, governance, measurement, and transparency that examines APPLICATIONS with the goal of making a simplified portfolio obvious and transparent.

Perhaps this is just the more traditional seperation between Project Portfolio Management (PPM) and Application Portfolio Management (APM).  If this is the case, it is not being described this way within the company.

In Microsoft IT Enterprise Architecture, both roles are falling to our team.   From what I am able to tell from other websites, that is common across Industry.  The question I want to ask today: should both roles fall to the same person within Enterprise Architecture? 

I need to establish some terminology just to discuss the problem. 

If an architect is performing the law enforcement aspect, what term should we use?  The word "enforcer" is simply too muscular, while "architectural overseer" tends to get misunderstood as a technical activity.   We could continue to refer to the people with a generic term (Enterprise Architect) and simply call the activity a "Compliance Review."  Right now, we use the much weaker term "Risk Assessment," a term that I used to respect but now find ill-fitting.  For the sake of discussion, I'll call these people "project reviewers."

As for the transparency aspects, same problem, different clothes.  If we stick to the generic "Enterprise Architect" but call the auditing process "Funding Review" or "Alignment Review," then we essentially devalue the individual skills needed to perform this task correctly and limit scope to a single stage of an SDLC process.  On the other hand, if we create a unique role, what would we call it:  Governance Auditor?    Solution Domain Manager?  Domain control manager?  For this discussion, I'll use the less-than-perfect term: Domain manager.

Back to the core problem: should we seperate the roles in Enterprise Architecture?  In other words, should there be seperate teams within EA or should each architect simply wear two hats? 

To be fair... I don't know what is 'right' but I suspect that, as our team matures, we will end up discovering that some folks do one role well but not the other, and that it would be very very difficult to build a program on the premise that we will create a team of unusually well-balanced folks.  Also, these people need to be assigned differently.  A project reviewer should probably be assigned to a project based on the technical stack and product mix that the project needs.  A domain manager should be assigned based on the business capabilities being delivered.

On the other hand, until we reach that level of maturity, we may not be able to seperate these roles because we could introduce communication hassles between the teams that slows us down at a time when we need to show value.

So for now, my thinking is this: while a team is young, and until there is enough work and buy-in to justify it, each EA should be a jack-of-both-trades.  This reduces the need for additional communication processes and allows one person to speak to both aspects in a particular area.  However, as a program matures, the roles should seperate into two dedicated teams, both within Enterprise Architecture.

What do you think?  I've made a lot of assumptions.  Do you question any of them?