Q&A Session - “World Class EA: Governors’ Approach to Developing and Exercising an EA Governance Capability"

Q: Do you recommend/have you seen any EA governance tools? We have technology governance

(registration and technology lifecycle management), EA repository, Application Portfolio Management

as well as reporting, notification, some business process management.

A: As discussed in the paper and mentioned in the webinar, there are four areas of Governance, viz,.

governance over target architecture, governance over implementation of architecture, governance over

value realization and governance over EA practice. A good EA repository, supported by a Portfolio and

Project Management tool will support the first three. However, there are aspects of governance over

target and governance over EA practice, that require a good organizational maturity and a process.

We also want to differentiate from use of EA to rationalize IT application portfolio and the use of EA to

guide a change in the organization. This whitepaper and the focus of our practice is to guide a change in

the enterprise.

We can discuss offline the tool suite we use in our practice. The Open Group is vendor neutral and it

would not appropriate for us to comment on specific tools.

Q: At what point do the architects listen to the Managers or Corporate Officers to align the

architecture to the Corporate Strategy and goals to generate revenue? Is there a standard which

discusses this?

A: The answer is simple: Always and well before a decision is made.

The EA practice starts with an understanding of the corporate goals and the change journey the

enterprise will have to take to achieve these goals. We suggest reading the Open Group white paper

W174 (https://publications.opengroup.org/w174), a guide for the Architecture Practitioner.

Most architecture initiatives are kicked off in the middle of a fiscal year – driving limitations to

availability of funds & resources. To develop the target architecture and for the leadership to

understand the value of the architecture proposed, it takes about 4 to 5 months. If you have that much

time to plan for the next fiscal year, start now. Else, target the following fiscal year. It is best for the

architect to aim for driving portfolio changes when funds can be reallocated without any constraint than

to create impact immediately. When operating under that philosophy and starting with stated

organizational goals (Annual Report supported by Value Chain or Stakeholder Value Map), the corporate

leadership will be receptive to changing the investments.

Q: "Design" the EA team: "Design" may not be a "suitable" term here.

A: We chose this term deliberately. It is very difficult to provide a universal composition of skills for an

EA team. Depending on the phase of the EA effort, the maturity of the organization, and the objectives

of the enterprise, the chief architect will have to “design” the skill mix – folks who can specialization on

relationship development, experience management, process design, and the domain architects like

infrastructure, communication, integration, security, business, application, solution, data and

information.

Q: Could you provide a specific example of a metric to measure the value delivered in an EA project

that the business and C level executives could understand?

A: If the EA team did it’s job – aligning to corporate strategy and identifying the right gaps to fill to

achieve the target state, no new metric is needed. Our internal code words are: (1) “guiding to build a

full bridge” – with its on-ramp, off-ramp, and all spans paved and (2) “time to latte” – architect’s job is

done when the architecture is used.

In our recent engagement, at the end of the sprint the C-suite asked “how can I replicate this

intelligence and thinking outside the members in this room?” The executive wanted to act on the

architecture, as it laid the right steps for him to achieve the goals.

If the executive asks “where do I start” instead of “when do I start”, the EA team has delivered value.

We think the metrics are very specific to each business, hence, we have not included any KPIs in our

whitepapers. To give an indication, here are some from our recent engagements:

a) Goal: Low Cost Operator; high quality customer service. Representative KPIs: No of

opportunities identified (and funded) to reduce costs; number of opportunities identified (and

funded) to improve cash flow.

b) Goal: Break free from a saturated market; shift work force from support to serve.

Representative KPIs: Time to reorganize to a product platform mindset; x% decrease in

customer churn.

Q: We need many examples of bad vs. good governance practices and details in W178 and

presentation

A: Use our questionnaire in Page 34, Page 37 and Page 42 of the whitepaper (W178) for specific

guidance for a good governance practice. When the architects don’t recognize when they are switching

roles (see Architecture Governance Roles) – most specifically between subject matter expert,

stakeholder agent and implementer bad things happen.

Good suggestion, but discussed best in a non-public setting.

Q: how do you get the whitepapers mentioned today?

A: Visit https://publications.opengroup.org/w178

Q: Value and benefits realization tend to be larger in scope that the typical mandate of an EA

organization. How does governance of EA value realization dovetail with larger organization value

realization mandates and processes?

A: Great question. Good enterprise architecture always defines a path to achieve the organizational

target state (value proposition to customers and investors). However, along the implementation path,

there are transition states. The effort to deliver the solution for a transition state may be complete

before value could be realized from the solution delivered. In our practice, we always add work

packages that start after the delivery of the solution to guide & measure the impact of the solution. In

our approach, a portfolio has three distinct stages: project initiation & dependency management,

project execution and delivery, value measurement, reporting and architecture change management.

Q: Is a whitepaper that includes this list of questions to ask during architecture work available?

A: Yes. Visit https://publications.opengroup.org/w178 for the whitepaper. It has all the questions

mentioned in the presentation.

Q: How change management and governance can be handled in an effective way so the final

implementation can be compliant with the architecture and be agile at the same time and address the

ongoing changes?

A: A well-defined architecture leaves ample room for innovation and pursuit of alternatives. It also

defines when the outcome is needed by and how it measured. So, the implementation approach can

follow any of the agile variants or waterfall methods. By governing the implementation against the

target architecture (or the transition state) for value delivered and pains eliminated, the solution

delivered will be compliant to the target.

Q: Please elaborate more on implementer and change management

A: Enterprise Architecture defines outcomes, dependencies, controls (what not to do), and suggestions

for reuse of existing assets to accelerate time to market (occasionally, cost reduction). The implementer

is the project execution team or externally sourced service providers (normally called contractor,

professional service provider, managed service provider), who deliver the final solution as defined by

the target architecture specifications. Good architecture leaves room for innovation and buffers in cost,

time to support innovation. It also isolates impact of innovation as narrow as possible to the

organization. However, things happen – the delivery may not meet the expected goals or may impact

more teams than initially anticipated.

Using the governance checklist, governance reporting and stakeholder decision, changes to the target

architecture or initiation of new efforts are identified. This results in either target being changed or

portfolio being changed. These decisions, impacts, and rectification actions are change management

activities. These can be tracked using a good EA repository and project level solution delivery notebook

(SDN), which supports TOGAF Phase H.

Q: How to Govern implementation changes to the architecture?

A: This is a very detailed topic, with lot of variations to consider. Here is a short answer: (1) Create

architecture that guides implementation and not “control” the implementation (2) Be clear about

outcomes, integration & interfaces, and operational aspects and (3) Instrument sensors and triggers to

identify opportunities for providing relief as soon as possible. The instrumentation is the critical part – it

has to trigger escalation whenever the implementation team senses that anything in (2) cannot be

achieved.

It is best to apply the same measurements & contractual commitments for internal implementation

teams as one would normally do with external implementation teams. Have clear definition of reward

and penalties. With internal teams, penalties could be tricky – so be as creative and as specific as

possible.

Well, start with our checklists in the whitepaper.

Q: How do we manage the challenges related to a federated business where EA Governance is a PLC

based function?

A: A good question. We use a policy based governance model and have found it to be very effective. Be

very clear about EA’s charter. In most federated models, the objective is likely to be enterprise

acceleration and enabling the ability to spin-off new lines of businesses using existing assets. Most of

the governance will and should happen within each of the federated unit and the centralized EA is

looking out for the corporate to sustain, grow and maintain its value proposition to its customers and

investors. To operationalize this, use the stakeholder concerns map in W174

(https://publications.opengroup.org/w174) Appendix D for each of the business unit, ask for relevant

parts of the solution delivery notebook (SDN) and a governance reporting record.