Architecture Prototyping vs Application Prototyping
Validating product architectures during the early stages of development lifecycle is very critical in order to deliver high-quality products that ensure optimized sustenance costs. Architecture Prototyping is an effective technique that helps engineering teams identify high-risk areas during early stages and validate product architectures, even in the agile methodology.
Technical Architecture is one of the key determinants of the long-term success of software products. Software Product Engineering (SPE) is so complex these days that architects need to deal with the past, present and future in terms of compatibility, compliance, interoperability, regulations, emerging technical trends and various other factors. Software architecture plays a prominent role in the Internet era where software products reside on n-tiers and involve multiple technologies and platforms.
Typically, architecture prototyping is done after building all key components of architecture framework and it could bring out an “evolutionary” prototype (or a “throw away” prototype) or a set of useful code that would be used at later stages in the project. Architecture prototyping involves implementation or prototyping of architecturally-significant requirements or use cases or user stories on a given architecture framework. Such user stories involve significant level of complexity or high frequency of usage or high performance needs or broad coverage of the architecture framework. Undoubtedly, they reveal the strengths and weakness of technical architectures.
It is evident that an architecture prototype could be used to unearth risks and issues related to several factors such as integration of components/sub-systems, usability, maintainability, performance, exception/error handling, persistence, compatibility, interoperability, compliance, etc. Architecture prototyping may result in one or more of the following decisions.
1. Sub-system refactoring resulting in minor changes.
2. Rewrite of few sub-systems resulting in major changes.
3. Abandon the current framework and find a better one.
I remember, during early 2000, our project teams and customers used to practice ‘Architecture Prototyping’. We used to follow RUP (Rational Unified Process) during those days. Nowadays, agile practitioners do validate technical architecture in small chunks by prioritizing user stories. Those who practice non-agile or non-RUP based methodologies consider proofs-of-concept to check the viability of an approach or a tool or a technical infrastructure. They focus on a single dimension (such as compatibility or viability) where as architecture prototyping covers a broader set of critical aspects.
My take on this subject is that architecture prototyping is a key concept that needs to be remembered and practiced. When some of the architecturally-significant stories get implemented during the middle or end of development lifecycle, we do see major changes to product architecture and design. Changes like these impact schedule, cost as well as product quality. So, if you come across unimplemented architecturally-significant user stories, implement them in the current or next iteration itself. They help you figure out flaws in the architecture at early stages! In essence, architecture prototyping provides immense value-add to all architecture intensive systems in SPE.
Have you had a chance to do Architecture Prototyping? What are your views on the value of Architecture Prototyping compared to the effort spent on it?