1.2 Current state analysis

Before we perform a little software archeology, the first step is making sure we’re ready to begin our current state analysis:

Before starting

Current state analysis creates the detailed understanding you’ll need when building on — or replacing — an existing product. You’ll expose hidden requirements, risks, limitations and end-user desires that would otherwise resurface mid-project. The activity is largely interview-driven, so it depends on active involvement from stakeholders across the business — if the right people aren’t committed, the analysis will miss critical context.

It’s really important the team is fully informed and engaged. If anything from the DoR is missing, finish 2.1 Team mobilization first.

Guide to current state analysis

It may go against our immediate instinct not to just dive in and start fixing things. But, if we don’t measure the baseline, we won’t know if we are actually improving the situation — and the last thing we want is to reinvent an old problem. Most of the discovery done in this section is focused on exposing limitations in the old system.

The outcome of this activity will greatly improve our likelihood of success in the long run:

I find there are often two major challenges in this kind of discovery. The first is getting everyone active and involved. The second happens once everyone becomes active and involved, and ideas start flowing fast and furious: Not losing track of anything. With that in mind, a format that facilitates quick idea capture from each participant is ideal. Use what works best for you, but I find a “SWOT” style exercise is quite effective. “SWOT” stands for Strength, Weakness, Opportunity, and Threat (see the SWOT analysis guide for how to run one).

A SWOT exercise is typically used in a business analysis setting. I like using it here because it expands the space to include the business, not just technology. For example, we might identify that a threat to the business is its poor support for integration with third parties. Or we could learn that its strength is an amazing user experience that’s better than any competitor’s. Those are important things to know about the current state.

The SWOT exercise invites each participant to put their thoughts, ideas, and opinions on a collaborative whiteboard. Ideally, this happens in a highly interactive, discussion-driven manner. The desired flow is to empower everyone to throw their ideas on the board, capturing everything — and coming back to discuss and elaborate later.

You’ll want to capture weaknesses and threats in your risk log. Having an accessible risk log and treating your risks with priority is essential. Risks are unknown, existential threats to your project. They need to be prioritized and eliminated.

We’ll use a workshop setting to conduct our discovery sessions. Each workshop should be organized to facilitate active collaboration, so a SWOT exercise is a natural fit (but again, use what works best for you). These workshops form the basis for your information gathering.

The technical discovery template provides 11 discussion topics, enumerated below. The discussion topics provide a guide for exploring the current state architecture. Tailor the working sessions appropriately, based on the scale of the project and size and availability of the team. Discovery is often most effective if organized in the following manner:

• Introduction. This session will most likely be covered first and should include a wide audience. Discuss limitations, which could come from any quarter. Identify the overall scope and scale of the product, including user demographics, transaction scale, and basic volumetrics around data and artifact size. This is an excellent time to see a product demo.
  • You may want to include the following discussion topics in this session (refer to the template for more detail on each topic):
    • Current state limitations.
    • Application metrics.
• Requirements management. Should include project management and team leaders, at least. Discuss requirements, management practices, development practices and standards. Important for alignment on future state execution.
  • You may want to include the following discussion topics in this session:
    • Development practices.
• Software / application architecture. In depth review of architecture (system design, monitoring, boundaries, processing styles, structure, application traces). Likely makes sense to include integration and error handling (but may need to split into multiple sessions).
  • You may want to include the following discussion topics in this session:
    • Integration points and extensibility.
    • Error handling, logging and resiliency.
    • Performance and scalability.
• Infrastructure and security. Focuses on current state infrastructure and security practices. Important for ensuring forward compatibility with standards, policies. May impact future state infrastructure.
• Operations, CI/CD and incident management. Focus on continuous integration and continuous delivery, security, and DevOps or operations. Important to understand pipeline automation, testing practices (automation versus manual), CI/CD stage automation and standards, delivery and deployment. The operations discussion may be very revealing in regard to legacy systems runtime and maintenance concerns.

Inputs

As with early activities, executive sponsorship will be key. It’s important the team realizes this analysis has buy-in from the top. Ideally, executive level involvement will be a part of the workshops. Likewise, the team will need to understand the value in taking a pause and analyzing the past.

• A complete roster of all individuals with significant knowledge of the current state architecture, including:
  • Product owners or customer end-users
  • Business analysts
  • Architects (software, data, security)
  • Data and database specialists
  • User experience / user interface team
  • DevSecOps, operations, and security specialists
  • Any other individuals with strong product knowledge

Process

1. Set up your architecture umbrella wiki page. This is an index or umbrella page that organizes the entire current and future state architecture effort. You can use this template to get started.
2. Set up your current state technical discovery wiki page. This is where most of the current state analysis information will be recorded. You can use this template to get started. It should be linked to (or a child page of) the architecture review.
3. Tailor your working sessions as appropriate given the current state project, team, and future goals. Focus on optimizing everyone’s involvement to avoid wasting time, but still maximize the information gained from the sessions.
4. Schedule workshops with each of the teams or individuals that have knowledge of the current state system based on your tailored technical discovery agenda:
   1. Workshops should be sequenced in a logical order, typically starting with business knowledge (e.g., user journeys, business capabilities and functions).
   2. Workshops that focus on similar areas should include all stakeholders with appropriate domain knowledge (e.g., when discussing data sources, the database team, business analysts, and integration engineers may be appropriate).
   3. Try to keep workshop sessions to a reasonable length (2 hours is appropriate).
   4. It’s best to orchestrate the workshops with ample time in-between to transcribe details, request copies of documents, and organize your thoughts.
5. Conduct the workshops:
   1. Remember to make the workshops interactive. The best results happen when participants feel ownership and develop an investment in the outcome.
   2. Use your tailored technical discovery template to drive discussion. The template works best as a series of prompts that can lead into deeper discussion.
   3. If meeting in person, leverage an “active” working environment (use whiteboards, post-it notes, invite team members to stand up and interact). In remote environments, leverage a tool like Miro for an “interactive whiteboard” with video presence.
   4. Regardless of the environment, remember the goal is to get everyone talking and contributing.
   5. Capture weaknesses and threats in real-time, directly into your risk log. Make sure you have a system in place so they stay prioritized.

Using a tool to manage your current state analysis is a great idea. Tools such as Boss Logic’s proven Cloud Ready Assessment platform jump start understanding of current state. The Cloud Ready Assessment tool uses a database of 150 different data points to create actionable recommendations and document findings.

Outputs

• Architecture umbrella (wiki). Top level index and central hub for all future state architectural artifacts.
• Current state technical discovery. Detailed review of current state architecture.
• Current state documentation and artifacts. Collected artifacts that support the technical discovery (housed in the architecture umbrella).
• Project risk log. Discoveries from your SWOT exercise that highlight weaknesses and threats that you’ll capture in your risk log.
• Project delivery playbook index. Your top level project wiki page, linking to all other assets. Includes high level summary of scope, vision, team roster, schedule of ceremonies and team RACI.

The outcome of this activity is documenting the current state. This includes capturing limitations, technical architecture, and even “ways of working” that the incumbent team is familiar with. This information is crucial when building your future state. It exposes gaps, risks, and dependencies that could otherwise be easily glossed over.

Templates

• Architecture umbrella template
• Project delivery playbook template
• Current state technical discovery template
• Workshop invitation template
• Risk log template

Next activity

• 1.3 Product vision