Can Architecture be Agile?

mcronin Feb 25, 2016 Agile

Enterprise Architecture and Delivery have never been the easiest of bed fellows...

Architects frequently believe that delivery teams, project/program managers, lack the big picture while the delivery people are prone to believe that architects have lost touch with reality, up in their ivory tower.

In classic “waterfall” delivery cycles it always seemed to me that architecture was “squeezed in” – like a last minute guest at a wedding. Oh God who will we put him sitting beside? He’s your relative – put him between requirements and detailed design. Make sure he doesn't embarrass us.


Indeed some might argue that the Scrum methodology all but gets the architect out of the room - with only the elite delivery people having a seat at the Scrum table and the architect being left in his ivory tower.


Scrum and TOGAF

Scrum is an iterative and incremental agile delivery framework. It defines "a flexible, product development strategy where a development team works as a unit to reach a common goal". It challenges assumptions of the traditional waterfall approach to project delivery. It needs to be tailored for an organization.

It is a series of “sprints” (typically 2 or 3 weeks), during which a complete delivery cycle is performed as per “the definition of done”.

Scrum engages the business through the program, defining the themes, epics and users stories (requirements / work packages) and assigning corresponding business value. These stories become the product backlog for the release identifying the Scrum “Minimum Viable Product”. The product backlog is continuously refined by the product owner.


It’s strength is in how its used. It is not a silver bullet.

TOGAF is an iterative agile framework for enterprise architecture providing a comprehensive approach for designing, planning, implementing, and governing an organizations enterprise information architecture. Though TOGAF is an architectural framework it is very delivery focused and, like Scrum, needs to be tailored for an organization.

The keystone of TOGAF is ADM (Architectural Development Method), a series of iterative phases in which scope, requirements and milestones are all re-examined. Each phase reconsiders assets from the previous phase, re-validating scope, business requirements & principles, risks and milestones.

The first 6 phases of TOGAF take place before delivery, the final 2 during and after delivery.

The first 2 phases closely examine the business environment, business requirements, principles and architectural capability and maturity for the project.

The next 4 phases closely examine the baseline (existing) architecture and target (desired) architecture. Consolidates the gaps, solutions and risks. Identifies the target architecture for implementation. From this “transition architectures” are recognized that can be implemented within the scope of a program.

The final 2 phases supports the organization through delivery and ensures that the target is implemented and/or supports change to meet business requirements.


TOGAF and Scrum have a lot in common;

Both greatly challenge the traditional waterfall program delivery method.

Both require continuous refinement of scope.

–In case of Scrum through story and backlog refinement

–In the case TOGAF through continuous iteration through the ADM phases and specifically in phase H (change control)

Both involve continuous collaboration with the business and both require tailoring for your organization.

Both assign business value to work packages, supporting the creation of an optimum release.

–In the case of Scrum this is the business value at story level and assigned by the product owner, these work packages are an input to sprint planning.

–In the case of TOGAF this is occurs in phase F as an output from capability planning and in preparation for the implementation. This activity enables the prioritization of work packages and projects. It also estimates resource requirements, project timings and the project (transition architecture) in which this can be delivered.

Entarchs recommends Scrum and TOGAF should be tailored with the other framework in mind, not in isolation.

In your organization rather than investing in a delivery team to tailor Scrum, while across the hall the architects are tailoring TOGAF in their ivory tower - invest in tailoring both methodologies together by a common team to meet your organization's needs.

This means involving an architecture stakeholder in your delivery group and involving delivery in TOGAF ADM tailoring.

It is key that they are not tailored separately to avoid a “pick and mix” approach by delivery teams and programs.

All Scrum programs should ensure that TOGAF to phase F has been implemented before starting Sprint 1.

This would ensure that large programs have solved:

  1. complicated technology before the sprints begin (in the baseline/target architecture gap consolidation of phase C – Information Systems Architecture)
  2. Infrastructure would have been evaluated and selected in phase D (Technology Architecture)
  3. Phase E, transition architecture, would help define and contribute to the Scrum “Minimum Viable Product”
  4. It would mean that the work packages/stories would have had a correct business value associated to it (phase F), supporting the product owner

This would result in phase G (TOGAF) and sprint 1 (Scrum) aligning, with a true product backlog of IT and business related stories with appropriate business value defining the minimum viable product for the release. Greatly reducing impediments and delays and aligning IT and business organizations.

Previous Post Next Post

Similar Posts You May Like