Starting with a Discovery: An Enterprise Architecture approach to understanding the technology landscape and making actionable recommendations

The initial structured and investigative phase in any technology transformation is “Discovery”. Whilst there may be some foundational strategy or ideation in place, Discovery is when executives and stakeholders deeply understand the problems that need solving and the context in which this problem will be addressed. In essence, Discovery lays the groundwork for positioning the transformation for success.

The primary aim of the Discovery phase is to gain an understanding of existing processes, user needs, technology infrastructure, and business challenges before deciding on solutions or making significant changes. In the case of a digital transformation or strategic initiative, the Discovery provides the groundwork to be able to plan, scope, budget and prepare for enhancements.  

Discovery Duck

Simply put, Discovery positions the “Current State” technology environment.

This article explores the purpose of a Discovery exercise and how Enterprise Architects gather information across complex systems. We’ll also answer the key questions that executives care most about - “So What?” and “So What Next” – turning Discovery into actionable outcomes and measurable value.

Discovery is about uncovering how the Enterprise works - gathering critical information from across the Enterprise to present the full IT landscape and the challenges shaping it.

Enterprise Architecture (EA) in a BAU-state is responsible for maintaining architectural artifacts, recording changes and decisions, and leading governance to ensure the enterprise landscape is effective, efficient and secure. In an ideal world, EA artifacts can be used to present the business, solutions, technologies, data and integrations clearly and concisely.

During periods of transition (e.g. new personnel, new leadership, changes in systems or processes, updates to the organisation through M&A or transformation, etc), Enterprise Architecture assets can rapidly become outdated or difficult to maintain. With modern organisations already stretched, maintaining the EA repository is often overlooked amid continuous delivery and change. The result is that the utopia of having an always current source of enterprise is unlikely. Yet, at the start of a strategic initiative, having up-to-date and relevant information is critical.

Discovery exercises are usually requested by business executives who need to understand their Enterprise landscapes when there are strategic challenges that must be addressed. Examples are when a significant change/transformation is required; as part of an M&A or divestiture, where rationalisation or efficiency gains are needed; or when planning for future strategic activity. In all cases, there is a problem statement – the executives need to understand the current situation of the organisation to be able to address the problem correctly.

Discovery is the process to create a comprehensive view of the Current State Architecture of the organisation as part of a foundational phase towards planning future states and delivering transitions. Through Discovery, the context for the problem statement is understood, and sufficient analysis will provide the evidence and rationale for change.

An Enterprise Architect’s approach to Discovery will provide executive leadership with a broad view of IT solutions, platforms, infrastructure, data and programmes; and relate this to the business, finance, operations and strategy in a meaningful way. As ever, Enterprise Architecture will present the Big Picture of the Enterprise, and prepare leadership for what lies ahead.

Discovery must present the findings from documentation, interviews, and business and systems analysis in a structure that helps answer the Problem Statement.

Discovery will start with a document request that gathers critical information that may, or may not, exist in the business. From my experience, the response to a data request is often a good indicator of the organisation’s maturity and strength of foundations. Usually, I would request the following material in the initial data request:

• Business and Strategy alignment: corporate strategy, business plan, organisation charts, annual reports, investor presentations, business processes, company acronyms and glossary

• IT Operations: IT resourcing, IT budgets, policy standards and governance, security operations, audit reports, incident reports, service tickets and requests, IT projects history and backlog

• Enterprise Architecture: frameworks, capability models, enterprise governance, decision logs, stakeholder maps

• Applications analysis: Licensed software lists, software and asset management solutions, Active directory and SSO, Vendor lists, managed services agreements, departmental IT budgets, previous network scans and Discovery tools, helpdesk and support logs

• Solution architecture: business requirements documents, ERP and CRM architecture and reports, data models and flow diagrams, data and integration architecture.

• 
  

Whilst documentation is a good starting point, it is unlikely that a Discovery exercise would be needed if all this information is readily available. It is therefore the Enterprise Architect’s job to gather and collate this information from different sources. Usually, a significant amount of tribal knowledge and experience that is not necessarily documented can be found within the IT or Technology team.

Early conversations should help clarify the objectives of the Discovery and the problem statement that needs to be addressed. However, early conversations with IT stakeholders should also be used as an opportunity to form a broad understanding of information within the team and where gaps in knowledge exist. Themes for these conversations can often include:

• Context and background of the organisation: investors, leadership operations and style, changes in the business, key influences and influencers to the business, driving a need for transformation

• Strategic direction: business goals and strategy; business priorities; metrics and KPI; strategic risks and priority challenges to address

• Business and IT alignment: how IT serves the business, business unit and geographical splits, service providers and strategic partners, business operational structures and processes, budgetary processes and assignments

• IT capability: pain points, business challenges, requirements backlog, IT risks, run vs change, systems demands and challenges, data maturity, cyber maturity;

• IT architecture: level of architecture in the past, governance processes and maturity, IT strategy and vision, capability maps and maturity assessments, decision-making RACI and logs.

Once these foundations are gathered, the Enterprise Architect will then plan how to continue the Discovery process. A gap analysis of what is needed to fulfil the mandate for Discovery, plus the foundational information provided, will determine whether further details need to be gained through business Discovery (e.g. through interviews and stakeholder meetings), systems Discovery (e.g. reviewing application and backend configurations), or through a technical Discovery (e.g. network scans or code reviews).

Whilst information gathering is at the heart of the Discovery, the analysis and presentation of this information will drive the value for this exercise.  

In my mind, documentation from the Discovery must take two forms:

1. Answering the problem statement -  presenting the architectural narrative that simplifies technical and business stakeholders' understanding and identifies a path forward;

2. Create sustainable EA artifacts that increase the organisation’s maturity through clear records and democratised insights.

   
   

From a Discovery exercise, there are a number of relevant architectural artifacts that can be created. Whilst I practice Just Enough Architecture (e.g. focusing on developing what is helpful and relevant), the Discovery process enables Enterprise Architects to create deliverables spanning the architectural domains. These can include vision and strategy, stakeholder analysis, business architecture, application portfolio records, backlogs, registers and status reports.

The Discovery adds value byensuring that these artifacts are created in meaningful templates and are supported through governance cycles so that they are actively reviewed and maintained. For example, an application landscape will need to be regularly reviewed with key stakeholders to ensure that the analysis (e.g. business fit, lifecycle status, investment strategy) is refreshed within an agreed cadence.

Once the architectural assets are created, these must be presented back to the sponsor in a way that addresses the problem statement. , It is the Enterprise Architect’s role to create a narrative that stakeholders can engage with and understand. TOGAF and other frameworks propose suggestions of how a Current State landscape can be presented. Most importantly, the Architect must bring their knowledge and experience to present interpretations and insights of the Discovery, and provide recommendations to address the challenges identified.

Business analysis gathers the Discovery data; Enterprise Architecture turns the Discovery into meaningful insights.

The Discovery exercise will surface a significant amount of data, business knowledge, gaps and challenges. Whilst this must be presented back to the sponsor, from my experience, all executives really want to understand is the implications of this, and what to do with this. The value from the Discovery exercise will hinge on 2 critical questions:

So What? – what is the meaning of what has been discovered; what can we learn from this; what are the direct and broader implications that need to be considered.

So, What Next? – recommendations to address the gaps, opportunities or challenges identified; architectural roadmaps, actionable plans and quick wins; next steps in the journey towards transformation or capability uplift.

The Enterprise Architect will present these insights and recommendations alongside the Discovery, and with this provide the executive stakeholders with sufficient vision and strategy to drive their outcomes or KPI.

A Discovery will not deliver change, but it will provide the foundations for further growth and value creation.

The Discovery exercise provides a comprehensive view of the Current State landscape. The insights and recommendations allude to the Target State landscape and a

transformation or delivery plan to achieve this. At this stage, these recommendations are only hypothetical and will need a further round of analysis and pragmatic planning to create a realistic and achievable transformation strategy.

A Discovery exercise should provide a Proof-of-Value or high-level confirmation of the problem statement and strategy. The analysis and artifacts provide an important foundation for further work, taking technology from Architecture to Operations.