Planview Blog

Your path to business agility

Enterprise Architecture

Continuous Architecture: Delay Design Decisions and Architect for Change

Part 2: Six Principles that Guide an Agile Mindset 3 and 4 of 6

Published By Jeff Ellerbee
Continuous Architecture: Delay Design Decisions and Architect for Change

In the first blog in this series, “Continuous Architecture: Architect Products Not Solutions and Focus on Quality Attributes,” I shared two of the six principles that guide an agile mindset, influenced from the book, “Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World.” This blog highlights principle #3, Delay design decisions until they are needed, and principle #4, Architect for change. Let’s jump in.

To achieve greater business agility, consider three and four of the six principles that guide an agile mindset.

  1. Delay design decisions until they are needed: EAs must establish principles, quality attributes, and guidance upfront, and wait to make the design decisions in the execution stages. Here’s the debate:

Supporters of a waterfall approach to planning and execution argue that time spent in designing is a worthwhile investment – with the hope that less time and effort will be spent fixing a bug in the early stages of a products lifecycle. Critics argue in a business environment where priorities, features, and demands change rapidly, waterfall assumes that designers can foresee problem areas without extensive prototyping. They argue the design decisions should be made later when more information is available and required.

For continuous architecture, design decisions should be made “when they must be made” rather than at the beginning when articulating the vision of a product. The quality attributes of integration may be known early on, but with advancements in technology, the appropriate solution for the design may change. By making decisions in the execution stages, you avoid choosing an outdated technology if your strategy is 5 years ahead.

PPM demo

Whether you choose to make design decisions early or late, Planview Portfolios allows you to use our modeling tool or other modeling tools like Visio – in one solution.

  1. Architect for change: Many EAs do not architect their organization – they architect solutions. For business agility, you must architect the organization. According to the book, true business agility is the ability to redirect the organization based on dynamic internal and external events. Therefore, the architecture must be configurable, rightsized, and provide a level of independence. This helps EAs understand which business capabilities, products, services, and platforms frequently change in the organization. When EAs understand that, they then architect using independent components, appropriate integration, and microservices. This enables them to change many architectural elements independent of other architectural elements – helping them adapt to change.

Planview Portfolios allows you to take a holistic view instead of a “one project at a time” view of your business.

The Planview Portfolios portfolio-centric approach allows EAs to capture all the components of any size organization, providing impactful architectural views — from high level summaries for executives, down to detailed design of individual systems.

Do you see how this all flows together to support business agility in today’s modern enterprise? Read the next blog in this series where I summarize principle #5, enabling continuous delivery, and principle #6, promote interoperability. If you are interested in learning more about how work and resource management solutions like Planview Portfolios can support business agility, register for a demo today.

Related Posts

Written by Jeff Ellerbee

Jeff Ellerbee, Solutions Consultant for Planview Enterprise One Capability and Technology Management. Jeff has helped customers be successful with CTM in the US and UK for 14 years. Jeff is a technical sales leader with more than 19 years of experience creating and selling software. He has designed, built, and successfully marketed five enterprise software products and a healthcare automation device for several venture-backed companies. Jeff is a software engineer turned sales engineer who has progressively shifted toward greater revenue generating responsibilities, taking on new challenges, creating more value for his customers and earning greater personal rewards.