In which phase of TOGAF technology stack and platform(java, .net, mobile etc) is decided

288 Views Asked by At

I am reading about enterprise architecture framework TOGAF and have one query.

I understand that in phase C, application architecture is created. In this phase, application catalog is created and in next phase D (Technology architecture), Networking, hardware and other physical architecture are identified.

My question is, in which phase we define the tech stack for new application (if this is a custom application) and in what depth. Like, if is it going to be mobile, web or hybrid application. Which platform will be used to build it, etc. And if is a ready-made product/service, when do we finalize it.

Thanks In Advance

3

There are 3 best solutions below

0
On

Based on TOGAF Standard 9.2, while it is not explicitly stated, I think that the answer to your first question

in which phase we define the tech stack for new application (if this is a custom application) and in what depth. Like, if is it going to be mobile, web or hybrid application. Which platform will be used to build it, etc

is the Phase D Technology Architecture based on one of the outputs in Phase D:

Target Technology Architecture, Version 1.0 (detailed), including: … Technology platforms and their decomposition, showing the combinations of technology required to realize a particular technology "stack"

As to the second question:

And if is a ready-made product/service, when do we finalize it.

In TOGAF the Commercial Off-The-Shelf (COTS) products and third-party service providers are usually considered as re-usable Solution Building Blocks, which you will finalize in Phase E as one of the phase objectives:

The objectives of Phase E are to: ….Define the overall solution building blocks to finalize the Target Architecture based on the Architecture Building Blocks (ABBs)

0
On

TOGAF is an Architectural Framework.

Primarily used for Enterprise Architecture projects, deliveries and teams. Good Enterprise Architecture (EA) is design agnostic. EA is much closer to the business than technology. But it is crucial to the success because it defines the answers to the WHY questions. Why do we need a network? What kind of network? Why do we need distributed IT system? Or the opposite, and a such.

EA is generic in nature.

It does not deliver any kind of design, and especially no implementation. EA defines the requirements for the design, in terms of size, capacity, energy consumption, performance etc.

Analogy: town planning.

EA are like Town planners. They do not prescribe anything about the design of buildings. They define what kind of and where are the buildings going to be, how many people will they house per what amount of space, the kind of and transportations requirements in the future town and in its parts and a such.

TOGAF can be used (especially ADM) bellow EA macro levels, but that is largely uncharted territory for TOGAF.

TOGAF is primarily for developing Enterprise Architecture. With our EA "hat" on, when we say "Networking" (in the domain of EA) that is not the same as "Networking" in the domain of Technical or Solution Architecture. EA defines the existence of the network, its capabilities in abstract terms. But not more than that. And the most important EA deliverable: Answer to the question: WHY. For example, why do we need a network?

This all seems very abstract because it is. The capability of abstract thinking is most important for good EA. That is what makes EA hard.

Perhaps you might pick one of the popular Agile development methods for software design and development to guide you in selecting the technology stack?

0
On

It depends on your needs, basically. It's important to remember that TOGAF is just a framework that needs to be tailored to your current enterprise. You might not need all the stages of ADM to successfully use the framework.

...in which phase we define the tech stack for new application...

Having said that, it's usually Preliminary Phase/Phase A or Phase D: if your main goal of architecture work is to migrate to (or create) specific technology (java, .net, etc) I would advise to settle such decisions in Preliminary Phase or Phase A during development/updating of Architecture Principles. If this is not your main goal, but it supports your Architecture Vision, then it's usually Phase D - one of the outputs is updated Architecture Definition Document, specifically Target Technology Architecture, Version 1.0 (detailed): Technology platforms and their decomposition, showing the combinations of technology required to realize a particular technology "stack".

...and in what depth...

Depth of this definition also depends on your needs: it can be as detailed as you need it to be.

...if is it going to be mobile, web or hybrid application.

This decision is similar to the first one: if your main goal (for example, stated in Request for Architecture Work) to update your application to be mobile-friendly, then it should be settled as early as possible. But this need might also arise during Phase B - your stakeholders might state that it's crucial to make this app mobile-friendly.