Responses to Audience Questions for our Webinar on Practitioner's Approach to TOGAF ADM

A Practitioners’ Approach to Developing Enterprise Architecture Following the TOGAF® ADM

1

03-May-2017 Webinar Questions and Answers Do not do other's work - that is interesting.. How do we ensure this in a world where EA is invariably taken as senior technical chap. Furthermore, normally orgs confuse EA for a senior tech arch... With the granularity you have touched here i.e., solution delivery, you seem to re-affirming that fallacy?

Let’s start with a clear distinction we make in our paper – job title is not relevant, role is. If you are not acting as an architect you are not an architect. We can guide to role. What we typically see is people with the title architect act like subject-matter-experts and implementers. For the distinction have a look at page 118 of the paper. Now, granularity. We suspect you have blurred “solution delivery” with ‘architecture to support solution delivery’. Here the Gaps, Work packages from a roadmap, and all relevant architecture constraints support solution delivery. Supporting solution delivery is critical – this is where the goals, objectives and hopes are realized. Architecture teams that don’t support realizing hopes and dodging fears are “ivory towers” or “librarians”. We are not talking about them. The primary goal of the EA function is to guide effective change. Note the words “guide” and “govern”. We are not talking about “perform” or “deliver” the solution. If the “EA” is actively and deeply involved in the “delivery” of the solution, we are back to “job title not matching the role”. And, in most organizations the senior technical chap is a subject matter expert. So, feel free to burst the bubble of the senior technical chap – you will be helping the EA profession and your organization a great deal.

Architect to support solution delivery - isn’t that a bit too low for the level of EA? Don’t these 2 level of architecture sound a bit too low level for EA?

Not at all. Again, we suspect a blurring of Solution Delivery with Architecture to support Solution Delivery.

Supporting solution delivery is critical – this is where the goals, objectivess and hopes are realized. Architecture teams that don’t support realizing hopes and dodging fears are bluntly hoping that a miracle will occur. Support requires clear statements of Gaps, Work


2

packages from a roadmap, and all relevant architecture constraints support solution delivery.

By bringing solution delivery in scope of this exercise, aren't you diluting the level and vision of EA? Solution delivery would be more apt for tech lead/tech architect

We think this is answered above, but will restate: perform architecture to support solution delivery or pray for a miracle. Please take the time to read the white paper. Developing or delivering the solution is different from developing an architecture to support solution delivery. There is a significant difference.

How to develop and use EA using agile methodologies? How avoid long (traditional planning) and predecible project to develop EA, and starting using an agile approach?

First, let us distinguish develop EA using agile from using EA to support agile. In the first, develop EA using agile method – this is what we do all the time. We deliver each of the four purpose driven architectures in sprints that last <7 weeks. At the end of each sprint, there is something tangible – a product, that the enterprise can use. The foundation of of Agile methodology. The tangible thing is an architecture: a set of work packages, specifications, and controls that will push the organization at least an inch closer to the target. Supporting agile development, or any using of agile in implementation is tied to 2 distinct use cases. Architecture that guides and constrains Sprint Design / Backlog prioritization and Architecture that supports Solution Delivery. We find the set of questions that say ‘isn’t supporting solution delivery too low’ and the set ‘how do you play with agile’ interesting. Playing with agile is supporting solution delivery. First, get in front. Where did the backlog come from? What criteria are to be used to prioritize? What things must be done for success? What things must not be done? (Another way of saying Gaps, Constraints & Controls) Frankly this requires a much longer answer. We are working on a case study to talk about this and a specific guide for agile (4 use cases)


3

How do you deal with a large Agile project where the architecture usually deals with the governance but many times the development usually designs and implements the solution?

In our presentation and in the whitepaper, what we mention as the solution delivery phase is where most agile teams operate.

Let us start by saying the method an implementation team chooses to deliver is not necessarily the concern of an EA. The implementation team may be free to choose a water fall, agile or other delivery method they believe will deliver the intended value and benefits best. The hedging here is because the business architecture of solution delivery organization may specify agile. In fact, we just completed a project where the strategic architecture called for a complete overhaul of the delivery organization to align it with saleable product instead of IT-oriented systems. This architecture had a substantive gap in the ability to manage products and specified agile. Once the deliver is underway agile, waterfall, etc., are not that different. All delivery teams, agile or waterfall or whatever, are accountable for compliance to the approved target architecture and to the delivery of those intended benefits regardless of delivery method chosen. Let us talk about few things: a) Governance – the architecture team is expected to guide the

delivery team, accelerate the delivery of the solution, and protect the value the project is expected to provide for the enterprise. Often the “accelerate” is misunderstood as “perform” the work. So is governance – misunderstood as approving the “design”. We are very clear that the governance is about conformance to do “all of the work” necessary to fill the gap. Suggesting “patterns” and “reusable” solutions is one of the ways to help accelerate the delivery of the solution – not demanding the validating that these solutions are being used.

b) Development – The architect has to facilitate the solution delivery to innovate. Unless you are perfect you can’t know everything and stop trying. Focus on what must be & what must not be, provide organizationally preferred patterns, and get out of the way. The architect that gets involved in solution delivery are actually performing the role of a designer.

c) Bad Governance – creating and enforcing use of standards or running mandatory reviews that actually adds more overhead and paper work. Don’t get us wrong – we are all for documentation. Documentation outlives the architects and the delivery team. Demand only just enough documentation to support future decisions and removing dependencies.

If the architecture team is focused on what we call “bad governance”, they are working their way to obsolescence. The line of business


4

managers who are looking for value realization with a fixed timeframe will start ignoring the architecture team. If you are part of the architecture team and can’t correct the course, find a new job. If you are part of the development team, wait for the chips to fall. If the architecture team is focused on early identification of dependencies, risks, suggesting reuse, empowering innovation, then they are doing their job. There is nothing to “deal with”. These architects are cognizant of the complexity a large agile effort – managing multiple concurrent moving parts. Embrace them and learn to love them.

What is the relationship and overlaps between an Enterprise Architect and Portfolio|Program Manager/Service manager and Strategy Manager and other relevant roles associated to Strategy/Portfolio/Project/Solution?

It is pretty simple. Strategy Manager is joined at the hip with the enterprise architect when the architect is developing the architecture to support strategy. Once the architecture is created and approved, the strategy manager becomes the champion of the roadmap. The strategy manager and the enterprise architect bring the portfolio manager into the fold to create the architecture that supports portfolio. Once the architecture to support portfolio is created and approved, the portfolio manager / program manager / service manager becomes the champion of the architecture. When creating the architecture to support project, the portfolio manager and the enterprise architect enroll the project manager. The project manager is provided with sufficient information to protect the backlog items / work packages that deliver the maximum value and never to descope them.

Can you provide some examples of stakeholder 'decisions' where EA can provide valuable information prior to decision being made? Since these decisions should be common across companies, are there any references that provide a list of these decisions?

Let us start with answering the second question first. The list of common decisions are (not all comprehensive): 1) What change efforts to invest in, so that we can improve margins,

market share, create new products or services, be quick in responding to market needs?

2) Having decided on the change efforts, what are the essential foundations? What are the most valuable steps? What are the long lead time efforts? And so on


5

3) Having identified the essential foundation, do I have the right organization structure, skill set, technologies, partnerships to execute on them?

4) Having identified the technologies, how can we be efficient? Learn from the industry?

5) Others are: How soon can the architecture team provide essential minimum and comprehensive information so that the decisions can be taken as soon as possible and necessary?

Most leadership decisions are directional. Most operational decisions are pointed and aimed at avoiding mishaps. Understand the context and provide the information to the decision makers. As mentioned during the webinar, one of our clients decided to act on our recommendation about a BPM engine as soon as the sprint for architecture to support strategy was completed. Another client decided that needed to change their development practice – to instrument for telemetry – even before embarking on an effort to break monolithic applications. Few others are: decision to buy a beta software, decision to create a new effort to target hospitals – buyers, instead of venture capitalist, and integrating customer research as part of sprint work – alongside developers. All of these are based on the information – “gaps” and “work packages” our EA team provided.

What is the reason for focusing more than into the Solution into the practitioner guide (SDN) and not to have more emphasis into the stakeholders and the value provided by EA?

As before: Supporting solution delivery is critical – this is where the goals, objectives and hopes are realized. Architecture teams that don’t support realizing hopes and dodging fears are bluntly hoping that a miracle will occur. We will refer you to the table of contents of the Solution Delivery Notebook (SDN) included in the whitepaper. We suggest the SDN as an example of TOGAF’s very useful Architecture Contract concept. As mentioned in the webinar, EA delivers value as soon as the stakeholder is able to make a decision, with the information provided by the EA. Time can do two things – make one forget the rationale or help build more supporting information. Solution Delivery Notebook is a mechanism for folks to keep their eye on the rationale for the target, the work packages to achieve the target and all of the stakeholder concerns that are being addressed. The SDN captures the list of gaps, risks, controls, work packages and specifications, as well as stakeholder matrix, concerns and trade-offs. The idea is to provide the gap, the control and the constraint so that good governance can occur, design choices can be assessed against the value to be realized or protected. The focus is not on the SDN, but


6

how to build the contents of the SDN, so that stakeholders and decision makers can continuously make highly informed decisions to achieve the objectives of the enterprise.

I would like you to address - 1) Why organizations are struggling to adapt TOGAF - what can you suggest to spread awareness internally and show value 2) How is Architecture/TOGAF relevant in Agile methodology. Is this considered Sprint 0?

For Question 1: There are several reasons. Here are some of the typical reasons we have come across: a) Organizations think ADM is process model, often sequential. Even

the organizations that think ADM is iterative, they define the scope of the iteration wrong.

b) Completely ignore Preliminary phase – misunderstand the context for the EA function.

c) Assume EA = EITA The best we can say about spreading awareness about right way to do EA is to start with the Open Group white paper World-Class Enterprise Architecture, and then understand the practitioner’s whitepaper – what this webinar was about. In order to show value, the answer is simple, show up at the doors of the decision maker, with sufficient information well before decisions are made. How do you identify the timing of the decisions – look at business cycle. For Question 2: When you talk about Sprint 0, it is normally in the context solution delivery phase – development or implementation. We are not talking about Sprint 0. This whole paper is about how the Sprint 0 is being informed and constrained. See our responses to earlier questions about agile delivery of EA.

Also, please share some examples of Controls and Constraints you mentioned in the earlier slides.

Constraints: When one of our clients decided to buy a beta software, they were protecting long term value. A beta software is work in progress – a continuous negotiation between supplier priorities and that of our client. Until the software matured to deliver the long-term value, every effort will have to plan for mitigations against any short fall in features. With a decision to buy a BPM software, the EA team had to adjust the architecture to support portfolio to accelerate the work packages related to use of BPM. Controls: These are typically defined against risks. When pursuing continuous operations (Continuous Integration, Continuous Delivery, and business

https://www2.opengroup.org/ogsys/catalog/W102

https://www2.opengroup.org/ogsys/catalog/W102


7

continuity), there is a possibility of a component not working – resulting in an application not being available. A control would be use of Canary testing before scaling. For one of the earlier questions we mentioned that our client mandated user research to be included to inform product features and during product development (solution delivery phase). It is an example of a constraint and a control. The client wanted to maintain the stickiness of the product from v1 through IPO, so that time to IPO can be shrunk and they are build sufficient barrier to entry for other players in the market. Having decided to use the user experience research method, organizational design had to be changed, solution delivery has to find ways to get early meaningful feedback for the researcher to guide backlog prioritization for the next delivery sprint.

What would be a profile of a good enterprise architect as a professional. Would it be someone with a mix of knowledge and experience of business strategy and information systems infrastructure, database and applications background?

In our team, we have architects who by education are political scientist, power engineer, hospitality manager, aircraft mechanic, and law enforcement officer, etc. In our experience, a good EA by skill is good at decomposition and analysis; has a talent to break complex problems into addressable chunks and has an executive presence; and is knowledgeable in architecture development method, governance, and technologies. Knowledge and experience in “Information and Communication Technologies” does not preclude someone from becoming an Enterprise Architect. But it definitely does not automatically qualify them to be an Enterprise Architect.

Another pitfall of understanding architecture and why organizations fail in adopting TOGAF ADM What is the actual role of EA into the Digital business era?

The digital era, if anything, has incredibly shrunk the time to value. It has made the barrier to entry very low in certain industry verticals. It has also caused a lot of confusion for brick-and-mortar enterprises. In the digital era, the EA, the individual, performs three different roles. As a stakeholder proxy, investigates the market for trends and impacts – to protect the enterprise and to guide the change. As a subject matter expert, evaluates techniques, solutions, and partners to accelerate time to market. As an EA, builds the target architecture.

What is your preferred EA Repository platform/tool?


8

This is a question for offline conversation. The Open Group is vendor & tool agnostic. We have pretty high bar for a tool to support analysis and manage a repository in multiple states over time.

When you are talking about EA Governance it sounds more near to control (concerns, faults...etc.)? What about assurance and continuous improvements?

During the webinar, we had very little time to cover a vast subject like governance. We are working with the Open Group to publish a separate 130-page white paper on EA governance. One word of caution – do not confuse quality assurance with governance. Governance is about protecting value, making sure appropriate processes were followed before a decision was made. Quality assurance and continuous improvements are stakeholder concerns.

In ADM how do we "control" sabotage by stakeholders of ICT Islands? How do we handle negative our outright anti-CMM capability maturity stages? Like in politics and sometimes military?

We have found that push back or outright sabotage comes from a stakeholder who is not being listened to or they feel they are being negatively impacted or that their concerns are not being addressed. This is where a well-established Stakeholder Concern Matrix can be a very useful tool. Our example in the webinar is typically used in the private sector, a stakeholder matrix for a public agency will be quite different. When dealing with public agencies your stakeholder groups may contain, Politicians, Service Recipients, Benefit Recipients, Impact Recipients, Funder etc. and their set of concerns may include Perception, Mandate, Change Impact and more. Understanding your stakeholders and ensuring their concerns are addressed can go a long way to resolving negativity to your architecture. Remember, a stakeholder is someone or a group of someone’s that have decision authority and that addressing all your stakeholder’s concerns is complex and difficult. Trying to resolve this problem without using an architecture approach to resolve concern conflicts would be next to impossible. If the negativity is coming from non-stakeholders, then this is likely a management problem that an architecture approach cannot resolve.

At what level would you see the efforts to mature SOA (using the OSIMM) in an Enterprise – Strategy level?

Let us first separate “service oriented architecture” from “service oriented enterprise”. We select and use appropriate model to guide the


9

maturity in adoption. And yes, we agree with your view that maturity models are to be used at the strategy level.

Calculate the negative value of IT and goodwill from architecture?

Not sure what is being asked for here? Where do we prevent, address big-time errands by so called project managers. Imho they fail frequently.. How as architects we cope with that? Define the value of ADM architecture plateau level achievements made already?

If you are running errands for the project managers, it is likely that you are not performing the role of architect. When you guide decisions, empower decisions makers, it will be natural for the project managers to ask the advice and guidance of the architect than “direct” the architects to run errands. Simply put, change what you deliver. In our practice, each transition state is a value realization state. It means, the organization has achieved a level of benefit and potentially they can abandon rest of the change effort – adjust their target to be the transition state. It is an architecture plateau. Our advice, do not define your transition state by time or effort or cost – define them by “achievable” and “perceivable” value achievement.

Will we talk about ADM? This webinar and the paper is about how to use the ADM. We will not explain the ADM.

Could you share some case study? Maybe by anonymizing company specific details...

We will be presenting a case study, jointly with our client at the Open Group Ottawa conference. Stay tuned.

Is architectural debt a mandatory "user story" in agile EA?

It is not a story. Your whole effort in developing an enterprise architecture – agile or otherwise, is about not accruing the debt. We define architecture debt as the “inability to realize value within the planning horizon”. Develop appropriate controls to address all “things” that can prevent the enterprise from realizing value. And we define the controls as specifications or work packages. So, you are not creating a story about “debt”, but a set of stories aka work packages to not accrue debt.

Business

Responses to Audience Questions for our Webinar on Practitioner's Approach to TOGAF ADM