How can you use the TOGAF Architecture Development Method (ADM) to solve business problems?

TOGAF isn’t a problem solving method; the high-level question is framed incorrectly. TOGAF (intent) is a standard method for designing and implementing large-scale architectures. Whilst problem definition forms part of phase A, other methods such as DMAIC are better employed upfront to determine the business problem and root causes. This can be used as the context for Phase A.

Well first up - you determine whether the business problem has architectural significance rather than just requiring a plan & design approach. If so: reflect that in architecture requirements, then develop the business, IS & Tech architectures (ADM phases B-D) ensuring alignment with higher level architectures (EA) then set-up and engage a project (with a PM and Technical Lead) to make it happen. Simple really ! Above all that the company may well have adapted the ADM to their own ways in advance which applies to all solution architectures.

You will have to tweak the architecture vision into a business discussion with relevant stakeholders on the business side of the company. Sadly, most of the time vision becomes a technology vision, and not a business vision to be realized by the purchase or development of new technologies. The ADM can be used to structure the themes for the workshops with the business stakeholders, but be open to tweak the ADM as-well to implement it in your organisation.

The TOGAF Architecture Development Method (ADM) provides a structured approach to solving business problems by aligning IT with business goals. Start by understanding the business vision (Preliminary Phase) and defining the architecture vision (Phase A). Analyze the existing architecture (Phases B-D), identifying gaps and opportunities. Develop target architectures that address these gaps, ensuring alignment with business objectives. Implement the architecture through effective governance (Phase E-F), and continuously monitor and adapt (Phase H) to meet evolving business needs.

TOGAF is a framework that companies can adapt to by tailoring its inputs, outputs, and methodologies to meet their specific needs while maintaining the core structure of the ADM phases. Understanding the interdependencies between phases and reviewing them in context is crucial for effective adaptation. While the vision plays a critical role in guiding the entire process, all ADM phases are essential and must be considered holistically to achieve a successful outcome.

Making it sweet and simple. Step A: Current application portfolio —> Existing business capability ( use a component Model to map this) Step B: Future need of application portfolio —> Future capability state or Target state ( use the same component model from step a and map with needs) Step C: Identify gaps on Step A to reach Step B —> Input for developing/updating IT Architecture, Business processes to support target capability . Call this Strategic Baselining Focus more on business process and supporting org model

Conway’s Law is a great axiom that can be used as a looking glass into why most business value initiatives fail - the basic premise here is that there is a disconnect between what the business does today versus what it wants to do and the primary reason for this is lack of interoperability between people, processes and systems. When dialed backwards to its root cause (source), we arrive at business design and processes which are fragmented, siloed and not digitalized (i.e, inconsistent, unreliable, expensive). ADM via business architecture enables process lineage and end to end traceability by creating standardized reusable patterns for executing business processes linked to information architecture (enabling data fabric, Semantic AI etc.)

I personally find that the Business Architecture layer often misses some of the human factor considerations that capabilities like Service Design can bring. I like to map out the long running value chains using a customer journey framework (discover, research, commit, establish, use, evolve, depart). This can be evolved to suit more internal facing value chains. This often shows gaps in the business capabilities in between the touchpoints. I then map the touchpoints to the departments / roles that complete the internal business processes along the way. Beneath these I map to the systems and artefacts currently used to enable those processes. I also like to add tags for opportunities as well as key metrics along the value chain.

Business architecture design is key to enterprise architecture, and according to Gartner this is the most significant part of whole EA. Meanwhile I would avoid sequential approach when you describe the current state of everything and then target state of everything. It doesn’t work that way. Take the strategic view first on decent level of abstraction, then prioritise capabilities and pick few to dig deeper. Further you may delegate design to the teams responsible for each business function.

This is the most common ADM activity that must be performed in any enterprise and it must be done the right way. With data regulatory laws, it is important that the sub-systems exchange only the required but sufficient information. A common information across the business capabilities gives guidelines for integration of applications, resolves the dependencies and prevents redundancy of data. With upcoming demand of data for machine learning models, right information model becomes more critical.

This is the phase where the ADM has an advantage as a process model. The outcome of this phase will mainly be minded for the IT-staff and to be consumed by business projects and by the IT-operations specialists, when needed. To keep the information relevant then keep the document short, technically relevant and model oriented; However, remember that this phase really has to be KISS oriented, since you should only produce deliverables (artefacts) that other stakeholders prefers to consume and are not forced to consume.

TOGAF ADM for an e-commerce company: 1. Current State: Disconnected customer databases, outdated e-commerce platform, no integration between inventory and sales. 2. Identified Gaps: Scalability issues, data inconsistencies, slow website performance. 3. Target State: Unified customer database, scalable cloud-based platform, integrated inventory and sales systems. 4. Roadmap: ? Short-Term: Begin database unification, initiate platform upgrade. ? Mid-Term: Implement integrated data management tools. ? Long-Term: Complete transition to a fully integrated, cloud-based platform. 5. Benefits: Improved platform scalability, consistent data management, enhanced customer experience. 6. Documentation of target architectures, transition steps

Es importante en esta fase corroborar si se estan siguiendo los estandares tecnologicos de la empresa o no. Y sino se estan siguiendo, enumerar e identificar las razones para la desviacion y/o introduccion de una nueva tecnologia.

The ADM has a minor advantage here; however, the deliverables of this phase will usually be consumed by stakeholders who will make use of the information when the technical landscape is on fire. Consequently all deliverables should be kept short and technically relevant.

Phase D for a healthcare provider: 1. Current State: Aging servers, limited cloud infrastructure, fragmented network security. 2. Gaps Identified: Inadequate server capacity, poor disaster recovery capabilities, security vulnerabilities. 3. Target State: Robust cloud infrastructure, upgraded servers, integrated network security. 4. Roadmap: ? Short-Term: Implement enhanced security protocols, start server upgrades. ? Mid-Term: Migrate critical applications to the cloud. ? Long-Term: Complete transition to a fully integrated, secure cloud infrastructure. 5. Benefits: Improved data security, disaster recovery, scalable infrastructure. 6. Documentation This aims to modernize infrastructure, security, scalability, and efficiency.

I find using Harvey Ball Analysis is a great way to facilitate and support the decision making process. Harvey Balls, are a visual representation of qualitative information, that can be utilised during the Opportunities and Solutions phase of the TOGAF ADM to enhance communication and decision-making. When comparing multiple solutions, Harvey Balls can be applied to represent the relative strength of each solution. I often use Harvey Balls to illustrate the extent to which each solution aligns with the organisation’s business objectives as well key criteria such as feasibility, risk, cost, and benefit.

Phase E for a retail chain: Evaluate tech solutions for inventory management, prioritize cost-effective AI tools, and initiate a project for AI integration.

The biggest challenge here is that too often architects sit in their proverbial ivory tower and produce a migration plan, expecting others to execute. Reality couldn’t be farther away from this. This activity is all about pragmatism and compromises. It’s Communication and influencing skills are crucial. At some point or another, every initiative needs to find savings (time and/or cost), and architectural short cuts are easy, so contributions to the target architecture should be ranked to ensure the key ones are protected. Some progress is better than no progress.

Focus on ROI and what makes most sense to support Technology Architecture. Balance between security, availability and performance. Portability should be preferred and avoid technology stickiness for maximum returns and future capability. Weigh on end result and metrics and re assess capability gap model to understand business success. Have we made our life easier by adopting enhanced business processes

Aqui es donde veo importante la definicion del tipo de metodologia de proyecto que se utilizará. Muchas veces el tipo de arquitectura objetivo a desarrollar deberá utilizar metodos o bien ágiles o bien de cascada . Cada arquitectura tiene su metodo. No hay uno para todos

A previous boss once told me: as an architect you get only 3 bullets a year to underline architecturally significant “must-dos”. Choose carefully when to use them.

- Understand Business Goals -Preliminary Phase -Implementation Governance -Architecture Change Management -Requirements Management These phases also should be added to aspect that is mentioned above!

A different way of putting this is to define and detail the Process Architecture, Information Architecture, Functions Architecture and Integration Architecture using a levelled approach i.e. Contextual, Conceptual, Logical and Technical levels. Process, Data, Functions and Interactions need to be considered at the same time in the analysis. At a certain stage usually after the Conceptual level is defined, the SW components are decided and the Logical and Technical level are based not just on the business capabilities but also the technical capabilities of the selected SW components.

Change Management is a key factor used in the TOGAF ADM. Business architecture facilitates effective change management by providing a roadmap for implementing changes. It helps organisations plan, prepare and execute transitions in a controlled manner, minimising business disruption and maximising the chances of successful outcomes. Without change management business problems will remain unsolved.

Study/learn about TOGAF ADM, reflect what could be beneficial for your context and then adopt what makes sense - use common sense though Apply, check, communicate, listen, adjust, and then restart your efforts