Leveraging Design Thinking in an Enterprise Architecture Practice

Enterprise Architecture and Design Thinking evolved from very different foundations, we may associate design thinking with product marketing or logical problem-solving. This may seem like a stark contrast to the world of Enterprise Architecture (EA) – but in actual fact, there is a connection.

If we think of EA as a digital transformation program, delivering products, the concept of design thinking can be a real value add. Before we dive into the specifics of how these disciplines complement each other, lets look at the stages of design thinking:

  • Stage 1: Empathize: Research your users’ needs
  • Stage 2: Define: State your users’ needs and problems
  • Stage 3: Ideate: Challenge assumptions and create ideas
  • Stage 4: Prototype: Start to create solutions
  • Stage 5: Test: Try your solutions out

Stage 1

Clearly design thinking is not about implementation, which is something that is also true of EA, but rather designing better solutions – a shared goal of both disciplines. Looking at the empathize phase of design thinking, enterprise architects commonly have a rigid mindset, a necessity in EA. Design thinking encourages architects to converse with stakeholders with an open mind, something which can really help to design better end-products.

Stage 2

The define stage also has some genuinely valuable approaches for architects, specifically around tracking engagement and proving out ideas. Where architects can struggle with the adoption of design thinking techniques is in the ideate stage, which encourages stakeholders to commit all ideas, without concern for practicality. When working with technical stakeholders thinking tends to be grounded very much in reality which be barrier to real blue-sky thinking. Clearly outlining to participants a desire to process ideas at the end may be required, so that unrealistic ideas may be discarded.

Stage 3 & 4

The prototype and test stages of design thinking propose potentially useful ways to help stakeholders to understand a proposed product, this enables us to move faster through the design process and on to the detail of the design.

Stage 5

In summary, design thinking and EA can be complementary. EA frameworks offer no shortage of structured, delivery focused methods of design but design thinking brings something different to the table. So the next time you are reviewing your EA methods, why not consider including some elements of design thinking

more blog posts...

Blog

Why Can’t Financial Institutions Ignore TOGAF Anymore?

Banks and insurance companies operate in increasingly complex technological and regulatory environments. Gabor Sulok, CEO of Bdat Solutions with 20+ years in the Enterprise Architecture (EA) industry explains how TOGAF helps align EA with business goals and compliance. 1: Architecture is becoming mandatory In several countries, financial regulators now explicitly require or strongly encourage the use of TOGAF or TOGAF-based frameworks, especially in sectors classified as critical infrastructure.  Failing to demonstrate architectural maturity in such environments can delay licensing, increase regulatory scrutiny, or result in operational penalties. Which regions have most recently been affected? Hungary: The Hungarian National Bank (MNB) refers to TOGAF-based enterprise architecture as a foundational element in its regulatory expectations. The MNB’s published methodological guide to IT system integrity specifically emphasizes the need for structured architectural documentation and planning, citing TOGAF as an accepted model for enterprise alignment. Saudi Arabia: The Digital Government Authority (DGA) mandates the use of TOGAF-aligned principles through the National Overall Reference Architecture (NORA), which is binding for public and financial sector organizations operating in the Kingdom. Nigeria: The National Information Technology Development Agency (NITDA) has introduced the National Enterprise Architecture Framework (NEAF) based on TOGAF, with the aim of modernizing digital governance across key sectors including banking. Finland: Public sector IT procurements must be grounded in enterprise architecture. While not limited to TOGAF, the national guidance strongly reflects TOGAF principles and methodologies. European Union (DORA regulation): While the Digital Operational Resilience Act (DORA), effective from January 2025, does not name TOGAF explicitly, its enterprise-wide ICT risk management requirements align closely with TOGAF’s structured approach to architecture and governance. 2. Cross-border operations require consistent architecture Multinational banks and insurers often operate in multiple jurisdictions, each with unique compliance requirements. TOGAF provides a standard, adaptable architecture language that ensures internal consistency while allowing for localized extensions. Whether expanding into the Gulf region, complying with EU legislation, or integrating systems post-merger, TOGAF enables organizations to scale without fragmenting.  3. Strategic alignment of IT and business capabilities One of TOGAF’s strongest values is aligning technology initiatives with business strategy. In financial services, this means ensuring systems contribute directly to priorities like credit risk modelling, ESG reporting, or customer onboarding optimization. The TOGAF Architecture Development Method (ADM) guides this process from high-level goals to detailed execution steps.  4. Modernizing legacy systems with minimal disruption Legacy systems are common in the financial sector, but replacing them is risky. TOGAF helps organizations define a Baseline Architecture, design Transition Architectures, and work toward a clearly articulated Target Architecture. This staged approach reduces risk and helps manage cost, change resistance, and data migration challenges during core banking or insurance platform modernization.  5. Faster adoption of national and sectoral architecture mandates Organizations that already use TOGAF internally are better positioned to align with national frameworks and sector-specific mandates. They can map their internal architecture models to external requirements more quickly and reduce the time and cost of compliance. To summarize, current examples where TOGAF or TOGAF-based frameworks are institutionalized or expected include: Hungary – MNB regulatory architecture guidance Saudi Arabia – DGA’s NORA framework Nigeria – NEAF framework under NITDA Finland – National enterprise architecture standards European Union – DORA ICT architecture expectations United Arab Emirates – Digital Government Architecture Framework, a TOGAF-based model required for public and quasi-public entities, including financial services South Africa, Egypt, Estonia – National architecture efforts strongly inspired by TOGAF principles Of course, every business is different. This is why, even with TOGAF’s explicit guidelines, you can still modify it for your needs, which we always recommend.  In conclusion: For financial institutions, TOGAF is no longer just a best practice; it is becoming a compliance tool, a strategic alignment framework, and a competitive necessity. In a world where regulators expect full architectural transparency and digital change at scale, TOGAF delivers the structure to evolve confidently and consistently.  🚀 Get TOGAF-qualified: Gabor offers TOGAF courses as an accredited instructor. Get in contact here. 🚀 Have TOGAF loaded in your EA software in just two clicks. Book a demo with Enterprise Insight to see how. Load TOGAF into your architecture in a couple of clicks.  Reliable and always updated so you can spend time on what really matters. Book a demo

Read More »

Sign Up today for a Demo

Please fill in the below form and we will get back to you with your demo with 24 hours