Understanding Enterprise Architecture and Agile

Enterprise Architecture and Agile - Guide Backlog in Sprint

Strong agile teams find the most effective path forward. Longer-term planning and budgeting exist because of ecosystem complexity. The challenge is bridging longer-term planning and agile creativity. Bridge top-down planning and bottom-up execution.

They need to be told about organizational priorities in terms that can be brought into backlog management.

Agile exists because people closest to the solution can find the most effective path. Successful organizations perform prioritization and trade-off. Without reaching the preferred future in the time and resource constraints, no work should start.

An EA Team needs the ability to support Portfolio and Project to guide backlog in sprint.

Predictable Problem: Ensuring that expected outcomes, value, cascaded performance expectations and constraints guide the release and product development.

Hard bit: Too many agile evangelists are surprised that organizations adopting agile remain deeply committed to planning and longer-term budgeting. We often have to overcome mythology that there are cultural preference for waterfall.

Roadmap to Guide Product Pattern

Predictable Problem: Having a comprehensive product roadmap, instead of a feature release cycle.

Approach: Using an architecture roadmap technique where the product, or product family, stand in place of the Portfolio. Ensure normal product reporting includes activity towards transition states.

Hard bits: Excellent product management will deliver a comprehensive product roadmap. Too many bottom-up product owners do not have experience managing the lifecycle or integration across an integrated product suite. The EA Team will need to fill-in, or fall-back, based on the skill of the product organization.

Too many architecture teams fall into the trap of artificial precision or imagined omniscience. Both are fancy ways of saying waterfall thinking. A classic architecture roadmap will speak of transitions, gaps, and work packages. This will be incomprehensible to a product team. Change the language to product and agile terminology. The product owner needs to understand the constraints they are operating within.

Building the roadmap requires enough architecture. The only scalable approach is ‘just enough.’ Just enough means enforcing organizational priority and dodging predictable problems. Just enough means staying out of the product design. Use architecture patterns that deliver across the portfolio. Just enough means ignoring potential synergy. Just enough means focusing on predictable problems. The value of dodging predictable problems is high. Just enough means not being afraid to use creative destruction.  Use a concept of expected lifecycle to drive aggressive refactoring (greenfield and revolutionary approaches).

Use of the techniques with the product owner helps bring organizational priorities and constraints into the product roadmap.

• • What product or key features to pursue given different criteria – Architecture Roadmap Type 4: Scenarios
  • What products, or features, will deliver value (benefit, work, and uncertainty – Architecture Roadmap Type 1: Heatmap
  • When are product and platform changes needed – Architecture Roadmap Type 2: Lifecycle
  • What is the dependency & impact of work and change – Architecture Roadmap Type 3: Impact & Dependency

Roadmap to Guide Epic Pattern

Predictable Problem: Using epics to implement top-down outcomes and constraints into the product.

Approach: Using well constructed transition states in an architecture roadmap technique where the product, or product family, stand in place of the Portfolio. Ensure normal product reporting includes activity towards transition states.

Hard Bits: Requires tightly integrated, or tightly constrained products. The area of focus needs to be on the integration or points of constraint. Multiple products coexisting within an ecosystem and sharing reference data is a simple example.

It is common to fall into the trap of up-front design. The focus should be on the areas where your software developers need to limit their creativity because of ecosystem or external requirements. Ideally this should be done upfront rather than a reaction to technical debt.

When we have made this succeed, we have actively adopted the language of methods like SaFE and framed the roadmap in terms of strategic themes and architecture runways.

Enterprise Value Pattern

Predictable Problem: Ensuring the critical success factors included within transition and target states guide agile backlog grooming and epic planning.

Approach: Translate top-down measures and objectives into consumable criteria for agile backlog grooming. Ensure normal product reporting includes activity selection and completion towards stated value.

Hard Bits: The top-down measures must be definitive and easy to assess. For example, the agile the team cannot be asked to develop a nuanced balance between time-to-market and resiliency. Unambiguous terminology is required.

Any changes to top-down measures will cause confusion. This is especially true if a transition state has been reached.

For internal products, we always make sure we have a solid cost model for digital products before introducing cost measures. Without a cost model, operational and platform cost will be lost and all costing will be justified on implementation cost. Plan on helping internal product manager with understanding ITFM. By contrast, product managers of external digital products normally have a very strong understanding of cost.

Constrain ‘bottom up’ Product Owner Pattern

Predictable Problem: Product owners viewing the entire enterprise through the lens of their product and its direct users.

Approach: Document product and role within the ecosystem. Document constraints that apply to the product. Document assessment criteria. Ensure normal product reporting includes progress towards transition states and activity aligned with enterprise value.

Hard Bits: Product owners of internal digital products are often a weak link. Common challenges include not understanding:

• • why their product exists
  • role of product in the ecosystem
  • criticality of enterprise constraints
  • who are the decision-makers (funders)
  • how to obtain guidance on enterprise priority and value measures

EA Teams supporting Portfolio and Project are most likely to need to constrain ‘bottom-up’ Product owners. It requires a deliberate effort and staff assignment.