Agile Architecture

Often, in a proof-of-concept level project, you will make some explicit trade-offs where you omit features or even whole elements of your conceptual tool chain in order to research suitability, performance, or just to make a sale. Eventually, if your applications are to be maintained in the market place, you'll need to ensure for their legacy by effecting an orderly transition to a fully featured product on a technology stack you can plan to maintenance. This article, the first in a series aimed for syndication via, explores the initial planning stages of such a project. More specifically, developing blueprints and roadmaps for our application features and distribution.Blueprints are like diagrams; essentially drawings which represent our current/before business and technology architecture. Moving forward, versions will be generated to reflect change options in terms of their effect on business capability, technical liability (e.g. system, network connection, or something else that might break), or sometimes just to provide additional context on the current architectural portfolio. This allows to maintain agile architecture as we plot our changes moving forward with our software.

Roadmaps reflect the culmination of several current state and proposed future state blueprints, and identifying them in terms of strategic objectives resolved by specific practicable changes. As such, our road-maps will be one part diagram/calendar showing our proposed changes and the delivery objectives, and one part graph/table identifying the change details from both the technical perspective (what will be changed and when), and from the business perspective (what will be available and when.) This allows us to target the key areas the need more developement, and release new application features in a timely and stable fashion for our customer's use.

We look forward to updating this article over the coming weeks and months. Thanks for your support of and for your interest, comments, and help!