ADM new look?

ADM new look?

Introduction

TOGAF is often perceived as waterfall approach to Enterprise Architecture. One of the reason for this is that its core part - ADM (Architecture Development Method) is usually shown as circle with phases. The makes the impression that the phases are realized in sequence. The word phase is frequently interpreted as "project phase".

ADM phases - what they really are

Let us look closer to the phases descriptions in TOGAF. The phases are actually lists of activities that are performed. Unfortunately they are also called steps - which implies sequentiality - with steps you make one step after finishing earlier one.

Is ADM wterfall? NO!

The answer to the question: wheter phases and steps are sequential (and if ADM is waterfall), is in ADM and Guidelines for adapting the method. TOGAF must always be tailored - this is explicitly said in the method. Tailoring should be corrected every time there is such a need. That means, that sequence of phases and steps within phases should be tailored.

New look?

So now let us look at TOOGAF in more general way (not from waterfall perspective). Phases are groups of activities that may be performed whenever it is appriopriate. What we should remember is the philosophy that underlies ADM.

I propose to look at TOGAF phases in following way.

Type of phases (by the way the work is performed)

There are 3 groups of phases

1. Phases which are usually done is sequence, these are namely: BCD - creating architecture, EF - migration planning. They are also usually performed in iterations.

2. Phases which are done continuously during the whole ADM - G (migration governance), H (Architecture?Change management), RM - Requirements Management.

3. Phases which are done sporadically?- Preliminary (at start and every time there is a need to change Architecture Capability), Architecture Vision - we do not usually change every day high level aspirational vision (if we change vision to often then maybe it is too detailed and is architecture not a vision).

Taking this into account?we got the following picture:

No alt text provided for this image

Description

Preliminary

Preliminary is at the start - we need to start with Architecture Capability to do architecture. That is why it is at the beginning. Because it is reentered every time there is a need to correct Architecture Capability - it is also shown at the end.

?Architecture and planning?

Architecture creation and planning are depicted as iterations. They are separated but connected, because I can imagine at least following situations:

?1. Both are present: we create architecture and plan migration.

2. We create vision and some architecture but in fact it is not a base for migration planning but for architecture governance. We create target architecture and use it as a way to control ongoing initiatives.

3. We have vision which is enough for high level migration planning. We do not create detailed architecture.

?Why decoupling architecting from planning?

Decoupling both cycles gives us more agility and freedom to combine those cycles. Therefore architecture and planning iterations may be realized independently.

Requirements Management

The base, that is present all the time is Requirements Management. It is used for any other activity: there are requirements for architecture but there are also requirements for Architecture Capability, requirements for planning.

?Architecture change management

It is worth mentioning that nowadays, when the role of enterprise?architecture in organization is changing, then I would say, that the most important phase for architecture work is phase H. Despite its name (Architecture Change Management) which suggests this is only change management procedure - there is much more important work in this phase. Phase H is the place where the ideas of new things are discovered. Here is the place for collaboration with business - Architecture cannot be IT architecture alone. This is the place where technology becomes business or business becomes technology. This is the place for monitoring outside of organization - trends and new opportunities in business and technology. Enterprise Architects should remember, that tools and technology alone will not make you successful, and business idea are the not when the IT supports business but when technology is intrinsic part of business. There is also the place where experimentation and learning should have its start. This is the phase, where opportunities are spotted and decisions go/no go are made.

?Governance

?Governance is one of the most importat part of Enterprise Architecture. Without governance the EA becames only nice idea on paper. I do not wnt to enter into details how to establish proper EA governance - espiecially in Agile environment. One thing is clear - governance is present all the time.

?Comments?

The picture is my proposition of how ADM could look like. I would be happy to hear - what you think about such view of ADM? Does ADM look better if you look at it this way? Do you like it or not?

Graham Berrisford

Director and Principal Tutor, Avancier Limited

3 年

I prefer the graphic in TOGAF that shows the iterations.

回复
Daniel A.

Security- & ICT Architecture - Solutions for the future of your company

3 年

Great explanation!

Chris Lockhart

Strategy & Advisory Consultant | Host of Consultants Saying Things | Author of "The People Problem"

3 年

To be honest, I think both pictures are entirely useless. In fact, TOGAF itself is increasingly (always has been?) a thought project that misses the forest for the trees. The pictures are nice to look at though.

Nihar Ranjan Mahapatra

Principal Solution Partner, TOGAF 9 certified Enterprise Architect, SAP S/4 Solution Architect, SAFe 5.0 Certified Scrum Master and Agile Practitioner

3 年

Agree to the fact what has been depicted with ADM in agile way On a second thought, B, C, D can also run in parallel based on the fact that process, application, technology does not change too frequently… with vision drawn for a longer term… usually for about 5 years or more… Would love to learn others view/ inputs to take it to the next level…

Nick Malik

Fractional CTO, Chief Architect, and Digital Transformation Program Owner

3 年

I think we should separate into two diagrams: one for EA and another for technology solution development. Trying to do all of it in a single model is forcing two different concepts together.

回复

要查看或添加评论,请登录

Miroslaw Prywata的更多文章

社区洞察

其他会员也浏览了