Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Agile Software Development Concepts for Enterprise Architects : Page 2

Incorporate Agile methods into your enterprise architecture process. The result will be an emergent architecture strategy that makes your projects adaptable and your developers happier.


advertisement

The Case for Emergent Design in Enterprise Architecture

When the design of an application is done in an emergent fashion, developers are given the flexibility to confront unforeseen issues as they appear. Many software projects have requirements that don't account for all the unknowns.

If your team can admit that there are a lot of unknowns at the beginning of the project, then they can rely on an emergent design strategy to assist in developing the ultimate architecture of your application. The checklist in Table 1 shows some of the major steps architecture teams can take to create good emergent architecture designs.



Table 1: Checklist for Enterprise Teams Considering Emergent Design

What

Yes

Action

No

Action

Admit there are unknowns upfront?

 

See next row.

 

Perform Retro/Lessons Learned

Plan for Emergent Design Using TDD

 

See Next Row

 

See Next Row

Use Automated Acceptance Criteria

 

Integrate in project

 

See Next Row

Begin Iterative Planning Cycles

 

See Next Row

 

See Next Row

Are there defects/changes in project deliverables?

 

Move back to Plan

 

See Next Row

Retrospective/Lessons Learned Action Items

 

Start at Planning

 

Your team is perfect!

The following sections provide details for each of the line items in the Table 1 checklist.

1. Plan for Emergent Design Using TDD

When your team has acknowledged that there are unknowns upfront, look into Test Driven Development/Design (TDD) as a way to inform your architecture. By using TDD in a rigorous and disciplined way, your team can design code with minimal upfront design. By always writing code with tests first, you ensure that any changes are informed by your unit tests. And by making minimal changes when coding, the simplest design usually is created using TDD.

2. Use Automated Acceptance Criteria

Automated Acceptance Criteria is another tool that puts testing before coding. Use this to ensure your architecture adheres to business realities. The types of acceptance tests or criteria to use could be fitnesse tests, behavior-driven development (BDD) tools like Cucumber, Raconteur, RSpec, and so on.

When architecture helps the team bake this automation into the development process, it provides a safety net to ensure new features do not adversely affect current architecture. For instance, take an application that has a hierarchical set of objects that can tree out to 7 levels. The stories never go over that level, and it was not necessary to create anything more robust. Later in the application's life, a new request that needs an 8th level is introduced. Those tests will catch that request assumption and alert architects and the team to the issue. Action can then be taken.

3. Begin Iterative Planning Cycles

Using Iterative Planning helps your team to adjust its architecture to changing realities during your project's development. By having a fixed point every two weeks where all team members validate the current application -- including product people -- you find architecture errors earlier. The architecture can then follow that Agile or Lean loop of plan, do, act.

4. Are There Defects/Changes in the Project Deliverables?

As mentioned in the previous section, you can adjust at the beginning of an iteration. If, as mentioned in the Automated Acceptance Section, a feature requires a change in the architecture, you need to plan for that. That means determining if the new feature is necessary, and if so, determining how to make the architectural changes. If your team has implemented the automated testing methods advocated here, then making these changes is usually doable in small chunks.

5. Retrospective/Lessons Learned Action Items

Use a Retrospective at the end of each iteration to improve the software development process. Use this standard process to make adjustments in how the architecture interacts with this process.

Use Lessons Learned at the end of the project to implement any action items that you have not implemented yet. While lessons learned is not strictly an Agile practice, it can be used in conjunction with retrospectives.

Make Your Architecture Agile

By incorporating these Agile methods in your architecture process, your architecture team can implement an emergent architecture strategy for your projects.



Eric Landes is a Project Manager/Project Lead for a large corporate IT department, specializing in coaching Agile teams. He has more than four years of experience using Agile/Lean techniques to bring customer value and a team focus to projects.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap