Phy-gital Roundtable: Breakfast Roundup from Germany and Netherlands

02 May '15 | Debjyoti Paul

German Shoppers: Meet Them in the Fast Lane to Phy-gital

15 January '15 | Ralf Reich

Shoppers Will Share Personal Information (But They Don’t Want to be “Friends”)

15 January '15 | Anil Venkat

Modernize or Perish: Property and Casualty Insurers and IT Solutions

14 January '15 | Manesh Rajendran

Benelux Reaches the Phy-gital Tipping Point: Omnichannel Readiness is Crucial

13 January '15 | Anil Gandharve

The New Omnichannel Dynamic: Finding Core Principles Across Industries

13 January '15 | Debjyoti Paul

Technology does not disrupt business – CIO day 2014 Roundup

02 December '14 | Anshuman Singh

Apple Pay – The Best Is Yet To Come

02 December '14 | Indy Sawhney

Digital transformation is a business transformation enabled by technology

01 December '14 | Amit Varma

3 Stages of FATCA Testing and Quality Assurance

06 October '14 | Raman Suprajarama

3 Reasons why Apple Pay could dominate the payments space

18 September '14 | Gaurav Johri

Beacon of Hope: Serving Growth and Customer Satisfaction

05 August '14 | Debjyoti Paul

The Dos and Don’ts of Emerging Technologies Like iBeacon

30 July '14 | Debjyoti Paul

What You Sold Us On – eCommerce Award Finalist Selections

17 July '14 | Anshuman Singh

3 Steps to Getting Started with Microsoft Azure Cloud Services

04 June '14 | Koushik Ramani

8 Steps to Building a Successful Self Service Portal

03 June '14 | Giridhar LV

Innovation outsourced – a myth or a mirage or a truth staring at us?

13 January '14 | Ramesh Hosahalli

What does a mobile user want?

03 January '14 | Gopikrishna Aravindan

Architecture Prototyping vs Application Prototyping

Posted on: 27 June '10

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.

Application prototyping has been used heavily in Software Engineering in order to improve stakeholders’ understanding of project requirements in terms of user interface design, report formats and various such elements. Architecture prototyping is different from application prototyping as it covers the architectural aspects – essentially the coexistence and coordination of various sub-systems of the architecture framework, as well as the aspects related to interfacing with external systems. It is very critical to demonstrate the strengths and weakness of technical architectures at early stages. Architecture prototyping is an effective means to do this.

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?

Mindtree Blog Archives

Mindtree blog Archives are a collection of blogs by various authors who have independently contributed as thought leaders in the past. We may or may not be in a position to get the authors to respond to your comments.

  • Bhushan

    cudn’t agree more.

  • tony

    totally agree…although i am not a fan of what is known as eXtream prototyping, where the prototype artifacts evolve into production code…primairly as it’s ‘just in time architeture’ in my mind.

  • Tony, eXtreme Prototyping is a way to go when product requirements are highly evolutionary. For example, in small Product Engineering startups or R&D Labs of medium/large product firms, eXtreme Prototyping works well – this is because, most of the times requirements are incremental and evolutionary in nature.

    Architecture Prototyping is a way to go when we have a high-level understanding of a good number of usecases or user stories to begin with.

    In both techniques the underlying theme is to implement architecturally significant usecases or stories proactively. Both techniques provide an opportunity to find technical risks early in the game.

    Thanks for your comments!

  • Thanks for some quality points there. I am kind of new to online , so I printed this off to put in my file, any better way to go about keeping track of it then printing?