How do you prioritize architecture changes based on urgency and value?

This article goes from "Assess the current state" to "Define the desired state" with only a casual mention of alignment with a business strategy. Unfortunately, this is how many IT projects go and why often the results are less than stellar. Gathering requirements/input for an architecture redesign should include not only input from the management team but also from much lower in the corporate hierarchy. Filtering/matching lower level business requirements with corporate business direction provides a potentially better solution while at the same time building company-wide acceptance of new processes.

Not everyone has to be excellent at everything. Instead of relying on standard maturity models or generic industry templates that can impose unrealistic goals, map out your unique business architecture. Explore the dynamics and relationships between enterprise elements to spot ? high potential impact on products, organization and customer or employee experience ? suitable leverage points for change such as changes to capabilities or assets.

Assessing the current state of Enterprise Architecture (EA) is a foundational step before proposing any changes. It involves a comprehensive evaluation of existing frameworks, processes, technologies, and their alignment with organizational goals. Key components of assessing the current state: Framework Evaluation: Review the effectiveness of the existing EA framework, considering its ability to support business objectives, adaptability, and scalability. Compliance & Risk Assessment: Review the compliance of the current EA with industry regulations & assess potential risks associated with the existing architecture. Performance Metrics: Establish and analyze KPI's related to EA to measure its impact on organizational goals and outcomes.

To prioritize architecture changes effectively, we first assess the current state by evaluating system performance, user feedback, and strategic goals. Defining the current state establishes a baseline for improvement. Prioritization hinges on urgency and business value; urgent changes with high impact take precedence. Sequencing involves a strategic roadmap to implement changes cohesively. Clear communication ensures stakeholders are aligned and aware of the transition plan. Continuous monitoring and evaluation guarantee that the architecture evolves in sync with business needs. This approach optimizes resource allocation, driving impactful transformations while maintaining agility.

Prioritizing Architecture Changes 1. Balance urgency and value by using a matrix: a) High Urgency, High Value: Immediate attention, critical to business success. b) High Urgency, Low Value: Quick fix, but re-evaluate long-term strategy. c) Low Urgency, High Value: Plan for future implementation, align with strategic goals. d) Low Urgency, Low Value: Consider postponing or eliminating. 2. Additional factors: a) Risk: Evaluate potential impact of inaction. b) Cost: Assess resource allocation and budget implications. c) Dependency: Consider interconnections with other initiatives. d) Alignment: Ensure changes support business objectives. Regularly review and adjust priorities based on changing business needs.

Keep in mind, the Desired or Target State may be a long way off. Be sure to include directions on the path you're charting. The migration path is defined with Transition States. They need to be first-class citizens primarily because many can exist as Current State for quite some time. Transition States become both milestones and your wins along the way.

We would define the services for managing and maintaining the Enterprise Application Architecture. Define the To-Be services catalog based on the identified opportunities during As-Is phase. Development of Baseline Architecture done during this phase. The To-Be State Design will be done for, o Business Architecture o Data architecture o Application architecture o Technology architecture o Security architecture

The Future State of an organizations Enterprise Architecture should be aligned with business objectives and core values. The current EA analysis helps in identifying the gaps for areas that are not being addressed in the Current State in order to realise the Future State EA.EA practice should be able to create lineage to each of the EA parts to get the business values and by developing the Future State EA. One should assess and propose the medium-to-long term EA realization that includes work packages to transit towards the Future State EA which includes the detailed EA Plan with a 3-5 years’ timeframe to define target for business, data, application, and technology architecture.

To prioritize architecture changes, first define the desired state. Assess urgency by evaluating impact on business goals and user experience. Then, prioritize based on potential value added. Embrace agility and adaptability to respond effectively to evolving needs. Remember, clarity of vision guides strategic decision-making for optimal outcomes.

In my experience, techniques and tools are useful to develop, communicate, and validate enterprise architecture, but enterprise architecture toolsets are complex and expensive, and I tend to gravitate towards frameworks and tools for each architecture domain. For business architecture, I prefer ArchiMate for business, capability and value-stream modelling. For application architecture, I use landscape diagrams, process models, swim-lanes, component diagrams, class diagrams, often produced in MS-Visio or draw.io. For data architecture I rely on data models and dataflow diagrams, often produced in MS-Visio or draw.io. For technology architecture I rely on infrastructure, network, and environment diagrams often produced in MS-Visio or draw.io.

Having worked with product orgs that are always feature hungry, it is hard to get space for this non-feature work i.e. "tech debt" or "O&M" (operations and maintenance). Here is a rubric that I have found useful: 1. Can you calculate an ROI for this work. If yes, you are in luck. Easy decision. 2. If no ROI, then you have to look at 2 other "subjective" measures and come up with a simple heuristic (dont over-engineer) 2a - Future loss avoidance - Does this work prevent loss e.g. reduced incidents frequency means devs get to write more code, i.e more features. 2b - Future developer efficiency - Does this work improve dev efficiency. e.g. a build takes 50% less, spinning up a cluster is self-serve etc.

Prioritizing architectural changes requires a structured process that considers both the urgency and value of each change. This process helps ensure that resources are allocated effectively and that the most critical changes are addressed first. Identify any necessary changes, whether resulting from user feedback, business requirements, technological innovations, performance issues, security needs, regulatory compliance, or market evolutions. Prioritizing architectural changes requires a balance between urgency and value, taking into account available resources and risks. By using a systematic and iterative approach, such as an urgency-value matrix, you can ensure that the most impactful changes are addressed in a timely manner.

Hold collaborative meetings or discussions with relevant stakeholders to review and discuss the urgency and value of each proposed change. -Categorize the changes into different groups based on their overall scores. For example: High-Urgency, High-Value Changes: These should be addressed immediately. High-Urgency, Lower-Value Changes: Consider addressing these as resources allow. Lower-Urgency, High-Value Changes: Plan these for implementation in the near future. Lower-Urgency, Lower-Value Changes: These may be deprioritized or bundled for efficiency.

Prioritizing architectural changes based on urgency and value involves a number of considerations and practices. Evaluate the value each change will bring to the system or company as a whole. This may include improving performance, reducing costs, increasing security, or adding new features that improve the user experience or bring competitive advantages. Consider the risks associated with each proposed change, including technical, operational, and financial risks. This can influence the prioritization of changes, giving greater importance to those that mitigate critical risks. Prioritizing architectural changes based on urgency and value requires a approach that takes into account business value, and system and stakeholder impacts.

I use the McKinsey 3x3 evaluation method for most prioritizations, including architecture. The Y-axis represents value, and the X-axis represents cost (and often risk). All other dimensions are aggregated into either of these two. Then, each change is assessed 1-10 on the value and cost dimensions, and plotted on a matrix. I prefer the 2x2 view, where one quadrant is high value/low cost, which is what you should do now. One quadrant is low value/high cost, which is what you should probably never do (unless you have to for regularity or similar reasons). And then you have two remaining quadrants, high value/high costs, and low value/low costs. The organisation's strategy will guide towards one of the other.

Sequencing the changes is an excellent tool for optimizing a project. It is particularly effective when used with enterprise-wide programmes. I would categorize them as (a) Chronological/conventional and (b) Out-of-the-box/unconventional. Chronological sequencing is ideal for dependency management. However, sequencing with out-of-the-box thinking will reduce overall costs. This would be majorly situational, depends on a number of factors, including the nature of the change, the project programme, the organizational context, the technology involved and the wider ecosystem in which the project is situated.

Once changes are prioritized, sequencing them logically and optimally is essential. Consider dependencies, interdependencies, resource availability, and potential trade-offs. Use tools like Gantt charts, Kanban boards, and agile methods to organize the sequence effectively. Ensure the plan maximizes value, minimizes risk, and maintains coherence. In my experience, creating a phased plan that allows for incremental improvements and mitigates disruptions to ongoing operations is key. This approach ensures smoother implementation and better alignment with project goals and timelines.

In my opinion use of solution train or agile release train etc. SAFe methods for portfolio related OKRs, organizational goals and objectives driven delivery planning sets cross teams including EA teams off to a good solid start. Use of Azure DevOps, Jira, Miro and Microsoft Planner like tools are a great agile ways for Enterprise Architects, Solution Architects to plan, organize via Kanban boards to prioritize and deliver Architecture artifacts (design reviews, risk assessments) in line with sequence of changes, hence maximizing value and minimizing risks.

After prioritizing the changes, sequence them in a logical and efficient order. This sequencing should consider dependencies between changes, resource availability, and potential disruptions to ongoing operations. The goal is to create a phased plan that allows for incremental improvements, minimizes risk, and ensures stability as the architecture evolves.

Depending on where one is starting the gap b/w required & current state is generally significant. Architects & designers need to be innovative so as to break the large changes into smaller parts which can be accommodated within scoped business programmes while still delivering incremental value to business and products through gradual march towards architectural vision. Being pragmatic and sensitive helps to secure buy-in for a gradual , methodical and sustained progression. I have seen it personally, that being greedy by pushing too many changes together makes approach less likely to be supported & difficult to sustain. Define big picture, break into actionable parts, find opportunities to sequence it, harvest value , learn and continue

Capability maps are one of the best ways to structure your communication to leaders. Business leaders are only interested in their business capabilities and when they are being delivered. They rarely appreciate the technical enablers needed to provide the business capabilities. The starting paragraph is conflating program roles & responsibilities with the architectural changes. I would keep clear separation between the architectural changes and the program structure. Business leaders love to know how their KPI will be impacted by the business capabilities being delivered. This is a great way of establishing the important stakeholders in a program. The roadmap may impact different KPI at different times.

While as a enterprise prioritizing architecture changes involves assessing urgency and value with a high focus on critical systems and immediate risks, evaluating business impact to prioritize high-value improvements, it is very important to communicate changes clearly to stakeholders, explaining the rationale, benefits, and implications, as well as roles and responsibilities. We can use reports, run workshops, and newsletters for consistent and engaging communication. We can design systems to support change, making them adaptable and intelligent.

While traditional methods like reports, workshops, and newsletters are useful for communicating the changes. Emphasizing story telling might be more effective and impactful. Craft a compelling story that explains the "why" behind the changes, not just the "what." Connect them to the organization's goals and challenges, painting a picture of the journey and desired outcome.

EA communication plan is a “life-blood” of EA activities. It requires relentless follow-up and execution. To ensure EA remains aligned to the business strategies, effective communication need to address the following, ? Help people understand how EA applies to them and impacts them ? Educates staff on the tools and training ? Keep all participant/stakeholder groups informed on EA progress ? Define all participants role and responsibilities pertaining to the development and use of EA assets with respect to communication Various tools used for the EA communication are, ? Knowledge Management Portal ? EA Repository ? EA Training ? EA Printed Documents ? E-Mails ? EA Short Videos ? EA Workshops/Seminars

Change communication involves effectively communicating architecture changes to stakeholders within the organization to ensure understanding, alignment, and support. This includes informing employees, management, and other relevant parties about why the changes are necessary, what they entail, and how they will be implemented. Change communication does involve providing training and support to help employees adapt to new systems or processes. This could include offering workshops, tutorials, or online resources to help employees familiarize themselves with the changes and learn how to use new tools or technologies effectively.

Prioritizing architecture changes involves a careful consideration of both urgency and value. Urgent changes address critical issues that could significantly impact current operations or future projects. High-value changes, on the other hand, deliver significant benefits to the system's functionality, maintainability, or scalability. By plotting changes on a urgency-value matrix, we can prioritize those that address pressing needs while also delivering long-term gains.

To ensure the effectiveness of your enterprise architecture changes, consistently monitor and evaluate their impact. Start by setting clear KPIs and using dashboards to track performance metrics against strategic objectives. For example, if a new system is implemented, track its uptime and user adoption rates. Use scorecards to simplify result analysis and adapt swiftly. Conduct regular reviews to gather feedback and identify areas for improvement. Incorporate lessons learned into future projects, ensuring continuous alignment with business goals. This ongoing evaluation process helps mitigate risks, capitalize on new opportunities, and maintain a robust and dynamic enterprise architecture.

We use scorecards that make it simple to see what the results are early. KISS when it comes to iteration because fundamentally it's about pass / fail

To go beyond mere implementation, the monitoring and evaluation phase of architectural changes should be closely integrated with the organization's strategic objectives. Metrics and KPIs should be deployed to track not only technical performance but also the impact on business outcomes, such as customer satisfaction, operational efficiency, and revenue growth.

Once the changes are implemented, it's essential to monitor their impact and evaluate their effectiveness against the defined objectives. Use KPIs, OKRs and feedback from users and stakeholders to measure success. This ongoing evaluation validates the changes and informs future improvements, ensuring the architecture continues to evolve in alignment with the organization's needs.

Urgency evaluation should also be considered in this process to help prioritize changes effectively: - Risk Mitigation: Prioritize changes that address security vulnerabilities, compliance issues, or significant operational risks. - System Stability: Focus on changes that improve system reliability and performance, preventing potential downtimes.

It is important to not miss on the softer aspects needed to enable and sustain support for architectural vision and progression. Being realistic and committed to focus on dimensions like “how much empowerment, influence and connect architects themselves have into organisational ecosystem” is very important. Being (or being perceived as) just top down and big picture do not help, EA & architects would need to find means and honest energy to bring connected at a bottom up level with product / project delivery leads and engineers , in order to meaningfully join the dots between moving parts and big picture. Otherwise, inspite of best intent, be ready for attribution of being a ivory tower architect(ure) and many a times lazy attribution

"Hyper Care phase" - After rolling out the major change, it is crucial to enable hyper-care for a few weeks to handle any production issue and provide timely solution to end-users.

Always prepare for a "hyper-care" phase post-implementation. This means dedicating resources to monitor and address any issues that arise shortly after changes go live. Additionally, involving end-users early in the process through feedback loops can uncover hidden requirements and potential issues. Also, consider incremental releases for large updates to mitigate risks. Finally, stay adaptable and be ready to reassess priorities as new business needs or external factors emerge. Balancing flexibility with strategic planning is key to successful architecture management.

Based on the #TOGAF Framework, you can prioritize requirements once you understand the EA As-Is domains and diagram the EA's future according to the strategy and goals; the next step is to determine GAP and solutions to close all of them to prioritize my recommendation is the business goals/strategy as mandatory, you can conduct a workshop with business and based on business capabilities to add or enhance you can prioritize the sequence of solutions implementation to enable them, and then produce transitional architecture views and its implementation roadmap including budget and cost/benefits of the solutions. Make sense? #TransitionalArchitecture #EA #TOGAF #Transformation