Stage 2: Discovery Phase

Purpose: Establish the facts to ensure the correct action is taken.

Although the problem is defined, the causes might not be properly understood, nor might there be a clear idea of how to solve the problem

3 Activities:

Architecture inputs: Gather facts about the current situation using existing artefacts.

Stakeholder engagement: people who will be contributing to design through their specialist knowledge, and decision makers.

Establish business requirements: represent the criteria by which solution will be judged, and are the basis for designing a solution

Establish business requirements

Understand existing architecture

Stakeholders

Stage 2: Discovery Phase – HowTo

• Architecture inputs
  • May or may not be available in the enterprise arch repository depending on arch maturity, whether the problem area has been examined before (in which case there may be some artefacts already), clarity of understanding of the problem (if the scope isn’t well defined may not identify not enough – or too many – artefacts as inputs).
  • Depending on the above, some may need to be produced/reworked before they can be used as inputs, but this phase does not actually do that work/rework, just identifies the gap
  • Produce a catalogue of architecture inputs that can be used for reference in following stages – they don’t need examining in detail yet.
  • Each artefact that is identified can have the reason for its selection identified by linking to an element or concept in the problem domain.
• Stakeholder engagement
  • Identify them from various sources, including:
    • Solution vision statement
    • Stakeholder registers for similar solutions
    • Architecture inputs for this solution
    • Investigation of the problem domain – in doing this investigation, individuals and groups will surface who are involved or impacted  by a solution in that domain.
  • Produce a register identifying the potential and confirmed stakeholders, along with roles, responsibilities and concerns.
• Business requirements
  • They can appear throughout the lifecycle,. There needs to be a way to manage requirements effectively and efficiently. Identifying as many as possible as early as possible is best, otherwise it might involve reworking designs later.
  • Need to undertake the following activities:
    • Capture: gathering them from stakeholders in a concise way. Can be through various techniques, including use cases, user stories, data models, business scenario planning
    • Validating: checking that each requirement is clear, unambiguous, correct,
    • Verifying: testing that they are genuine requirements for the solution and do not conflict with other requirements.
  • Produce a requirements catalogue, with details such as ID, description, justification, category, status, change control details. This is useful as a central reference point, but also to allow more detailed system requirements to be linked back to the business requirement later.