Ten Scenarios to go cloud

 

With everyone speaking about cloud and talking about developing applications, sometimes it is confusing to identify if our application really needs to be on the cloud.

If you are an ISV, the answer may be relatively simpler (of course after reading my previous blog  :-) )

If you are looking to develop an application to solve a Business problem or if you are looking to automate any of your business process, the first thing that comes to our mind as of today is, should be develop this on the cloud or are we fine keeping the software on premise.

The purpose of this blog is to provide ten most common scenarios where it may be wise to use the Cloud computing to develop the applications. Please note that these are NOT THE ONLY scenarios for exploiting the cloud platforms. The benefits of cost & maintainability do not form the part of this discussion.

1) SaaS offering

As mentioned in my previous blog, if you are an ISV, then you may want to offer your product as a SaaS rather than selling it as an on premise application. There are various business & technical benefits in doing so, but this is a complete chapter in itself. Developing a SaaS based application from ground up, or building it using a PaaS is again a different discussion. But surely a SaaS is a cloud offering in itself or / and may be build using a PaaS which is also a cloud offering.

2) Scalable Web Application

If you have a very large web application for your enterprise or planning to develop one  or if you have an e-commerce site and it needs to be highly scalable (as scalable as a SaaS application), this can be an ideal candidate for going cloud using a PaaS. PaaS provides flexibility of provisioning for spikes in user load. It provides a cost effective way of using more servers and load balance during load and can get back to minimum configuration when the load goes down. Moreover because PaaS or for that matter even IaaS is offered on pay per use basis, it saves a lot of maintenance as well as operational cost.

3) Dynamic requirement of resources

If you have a requirement for large number of resources and the need for the same is highly dynamic, then the best option would be to accomplish the same using a IaaS. E.g. Assume there is a need is to build a data replication tool and lets assume you may want to test the tool to ensure that data is replicated smoothly across 100 servers. A huge amount of investment has to be made to buy a 100 servers and if you are not able to justify the spend or having a 100% utilisation of each one of them, then its a huge hit on the expense. You may opt to have 10 physical servers and create 10 each virtual machines on them, but again as long as there is a very large business benefit, doing so would not be ideal. Using a IaaS like the Amazon EC2, it is extremely easy and cost effective to hire as many server instances as possible. The same can be released if not required and thereby saving money on resources not utilised. Another similar likely scenario – To perform a physical load-test of an application with 10,000+ users on the portal and would like to gradually increase the load to know the breaking points of the system.

As you may recollect, there are many obvious advantages of using IaaS – no upfront investment, Pay per use, Ready to go server instances, on demand scalable model and many more.

4) High processor intensive application

Assume a requirement of an application that requires High end computing power to likes of 8 CORE processors with 32 GB RAM to run the CPU intensive calculations and it is estimated to have 20+ such servers to accommodate the desired throughput.

The same can be easily accommodated using IaaS as well as PaaS and all the benefits of going the cloud route like the no upfront investment and pay on demand model help us achieve the ultimate goal rather than going for a large upfront capital investment. Cloud is very useful in scenarios where time to market is one of the key requirement. Recently Microsoft showcased Pixar’s application called “Renderman” uses cloud to get the best benefit. Similar application requirements which need extremely high processing power can go cloud way either through IaaS or PaaS.

5) Provide a centralised high volume (yet highly secure) Data access

Application Storage Needs for applications to the likes of On-Demand Training Platform of a company are increasing significantly day by day.  The storage requirements are already in Several Terabytes (TB) (1 TB = 1024 GB) and growing at the rate of 100 GB/month. There is a need to have scalable storage solution at the same time stay close to the cost. A PaaS would be ideal in this case as it will save on a very high upfront investment on servers and maintainability, provide a very high scalability and also a guaranteed reliability,

6) Hybrid Applications

If there is a need to provide an application which has a on-premise version of the software as well as a web version of the same and both need to share the same data source, then hosting the database for such hybrid applications on the cloud is an ideal option. Both types of front-ends can be in sync and there is a huge save on the money spent on the infrastructure to accommodate connectivity from anywhere.

7) Central Data Repository

Similar to the previous type of application, if there is an application (on-premise or web) deployed and used by thousands of users from across the globe (may be from many different branches of a very large multi-national company), then having the database at a central repository makes sense. Although the same functionality can be achieved by hosting the database server on a secured local intranet and making it available for all the branches to connect, this requires a complex infrastructure setup and a huge investment which may or may not be the best option. Instead, having the database deployed on the cloud using either IaaS or PaaS may be a viable option.

8) Temporary requirement of Datacentre space

Most datacentres do not have a business model by which they provide server space on a need basis or on a temporary basis. Ideally they would want us to provide a minimum 6 month or in many cases a 1 year commitment to use their space so that they have a return on their investment. If your situation demands that you may want to use a datacentre only on a need basis and that too for a period of 1-2 months at a stretch or it is unpredictable, going the IaaS is the best option. IaaS providers like Amazon provides a flexible and cost effective mechanism to configure, host and release the server resources on a need basis.

9) Experimental Applications

If you have an idea to build a SaaS application (or would like to test the waters of building a SaaS version of your existing on-premise software, you may not want to put a high upfront investment if you are not sure of it’s success or failure. Using PaaS to develop your SaaS application idea or prototype provides a very high level of flexibility and safety to ensure you have a strong Business case to go back to your management to build a full blown SaaS application.

10) Freeware

If you are into building Freeware, you may want to keep your cost as low as possible, since the most likely scenario for building your brand would be only after there are too many (happy) users of your product. Keeping the cost low till the time would be key to success for your business. Building your application and / or hosting the same at a PaaS provider or an IaaS provider gives you a minimum till you sense the light of success.

 

The idea of this blog is to give people some food for thought about whether to build an application the conventional way or to build it for / on the cloud and there are too many reasons to go for it or even to go against it for each of the above types of application. But in most scenarios mentioned above, going the cloud way is surely a potential option.

Go cloud – An ISV perspective…Part 2 – PaaS

 

This blog is in continuation to my previous blog entry “Go cloud – An ISV perspective…Part 1 – SaaS” which discussed, if ISV needs to go cloud and offer their products as SaaS, the quicker ways to do so.

Just to keep this article independent, I have copied and pasted below the section which sets the context, to make it easier to read. If you have read my previous blog entry, you may directly jump in to the next section “PAAS”.

Typically as the name suggests, an ISV (Independent Software Vendor) could be one of the following:

A) Traditional Software Product companies: Companies who build and sell software products

B) Web based Software companies offering their products as “Services” typically known as SaaS companies

C) Software intensive companies offering services to a market using a software. The main business of such companies is not to sell Software or even SaaS but to “use” them as their tool to sell their services. A typical example of such a company would be one providing “subscription based” clinical information, or a subscription based access to a vast patent database and so on. In such cases, they do not sell software or service instead they sell “information” using a software.

D) A start-up company who intends to become one of the above three.

For the purpose of the article and for ease of reference, let us refer the above as – A-type ISV, B-Type ISV , C-Type ISV or D-Type ISV respectively.

This article is an attempt to provide a clarity to these ISVs as to which of the cloud services they need / should / may need to consider to embark on for the success of their business.

As briefly explained in one of my previous articles, there are three different aspects to cloud computing i.e.– SaaS (Software as a Service), IaaS (Infrastructure As a Service) & PaaS (Platform as a Service). If you are a B-Type ISV,  then I am sure you do not need any more explanation of what SaaS is. Also if you are C-Type ISV then too, you may not be too interested in SaaS as selling software isn’t the main business you are in to. But may be you wish to know more on these other aspects such as PaaS & IaaS.

So this is an attempt from me to put few points across to provide a clarity to all the ISVs out there.

 

PaaS

Using PaaS to build an offering or a SaaS product may be the fastest and the most cost effective way of doing so if you are a Type-D ISV (A start up company). As a start up you may have a fantastic product idea in mind which you think of offering it to prospective customers as a SaaS rather than an on-premise software, but you may not want to take a huge risk of doing the whole thing yourself.

By choosing a PaaS, effectively one gets a rapid application development platform to build the software along with an ease of deploying the software on the datacentres of the the PaaS providers. Because the ISVs do not have to own anything, there is no upfront investment. It is a Pay-as-you-use model and the charges of the PaaS providers can be accounted as an OpEx. This model is very useful if you are not sure how many customers you may procure during your initial years. Also, because most of the PaaS providers provide the flexibility of allowing you to increase the servers on demand, it is extremely simple to manage the spikes of customer growth.

It is very important for any ISV to ensure that their products offer a high quality of service and hence managing the non-functional Requirements is the key. And since the system is hosted on a PaaS, most of these non-functional requirements are already taken care by the PaaS providers. The ISV just need to align their Service Level Agreements they provide to their customers to the Service Level Agreement offered by the PaaS providers.

All good so far, but is PaaS a long term solution from the ISV’s perspective? May be and May be not.

If you already are a Type B ISV, i.e. you offer your product as SaaS, and if you are successful at it, there is no specific need to move your application to a PaaS. In some cases it may make sense but in most cases it would not. The only advantage of moving an existing SaaS application would be to reduce the infrastructure maintenance effort. Moreover if you already have a huge customer base, moving your system to PaaS would mean more charges / OpEx you may end up paying to the PaaS provider for each of your thousand users. Hence the cost benefit analysis needs to be done between moving the offering to a PaaS provider vs. Continuing to host (or using a Data centre) privately.

For Type A ISVs, it could be a good option to try their business model by creating a SaaS version of their product on a PaaS and sense the market reaction. As mentioned in my previous article, one option for the Type A ISV would be to reuse as much existing on-premise code as possible and build a SaaS version of it using methods mentioned in the article.

The more safer option would be to try a separate version of their product to be offered as SaaS, using a PaaS. This would mean they could treat this part of the Business as a start up and all the advantages that a Type-D ISV enjoys using a PaaS, can be exploited. And most of the PaaS providers provide a huge amount of flexibility to reuse existing code and make minor changes to make it available to be hosted for PaaS.

Type-C ISVs don’t need to worry about the PaaS immediately if they are happy with their current business model. The only reason they may or may not switch to use a PaaS would be cost as their customers are not users of their “software”. Their customers are users of the “information” provided by the software. As long as they are able to comply to the Quality of Service and their SLA agreements with their customer, the need to move to a PaaS would only be a Cost benefit in a long term and also their TCO for the business.

For an ISV (as our current focus is only ISV) whether to go PaaS or otherwise, is not an easy choice to make, for the sole reason that going PaaS means paying for each user using the system hosted on PaaS. SaaS is all about acquiring more users using the system which means more payment to PaaS providers. Hence it is extremely important to do a cost benefit analysis to evaluate if the CapEx investment + the OpEx maintenance cost for Self- hosted (privately hosted at a Datacentre), equates a lower TCO as compared to a TCO in case of having a permanent OpEx as charges to the PaaS providers.

Non-Functional Requirements for SaaS

All software products are built with a set of Functional as well as Non-functional requirements. The key role of the Business Analysts and the Business owners is to define / articulate the need for each and every requirement whether functional or non-functional. Functional requirements are surely the must haves and it is a prime responsibility of the Business owners and the analysts to define it or at least justify the need for it.

It is very important, one must also define Non-functional requirements and give equal importance to it along with functional requirements.It may not be appropriate but surely certain lenience in defining Non functional requirements can be incorporated in case of a on-premise software.

If you are an Independent Software vendor who would like to provide your Software as a Service, or if you would like to extend your current offering to a different market on the cloud by providing a SaaS version of the product, then the game changes completely.

In most cases, a SAAS solution is a SINGLE CODE BASE, with a SINGLE LOGICAL DATABASE serving 100s of customers and potentially 1000s of users with completely different usage patterns, different individual tweaking requirements, different requirements for interfacing with their in-house systems and so on.

Hence it is one of the top priorities to not only define the functional requirements, but also define and design the system to cater to a very clearly and strongly defined non-functional requirements. A non functional requirement as the name suggests does not provide any “business functionality”, but instead they glue the functionalities together better. Although there are too many things that can be defined as a “non-functional requirement”, I would like to highlight the most important ones that any SaaS Architects or Analysts should keep in mind, define them and most important “architect & design” the software to ensure it addresses these requirements.

Please note that there isn’t any specific priority order for each one of them and the importance of one over the other is completely dependent upon the business need and the type of the software to be delivered as a SaaS.

Also please note that not all of them may be a key requirement for every software and hence it is up to the Analysts and the Architect to define the same. The below list may also be used as a check list for the designers of the system to ensure they have it covered in their definition.

--

Security

No software can escape from the need for security whether SaaS or on-premise. But when it comes to SaaS the requirement turns out to be more stringent. As an ISV, the responsibility of the security (whether data security, network security or intrusion prevention) all of it lies with us. Any subscriber to a SaaS would expect assurance that his information and data is secure enough more since they are not under their own radar but we are the custodian for the same. In a multi-tenanted environment, no one would want their data to be visible to other companies using the same system. This is upmost important and should be one of the key points to be considered while defining the data structure for the software.

The network security and intrusion prevention is not the point of concern for the provider of a traditional on-premise software since the responsibility of deployment and network security then is the responsibility of the client rather than the software provider. When it comes to SaaS, these things are equally important for it to be considered.

I had attempted to provide a simple security checklist in one of my previous blogs which may be used by all parties involved in SaaS whether it be an ISV providing the software or it be a company subscribing to it or a user using the system.

Scalability

Scalability of the software takes a completely different turn when it is a software delivered as SaaS. Any software (whether SaaS or on-premise) would have to consider scalability when it comes to handling “volumes”. And since SaaS is eventually all about multi-clients with multi-users using a single code base, volumes are inherent characteristics of the software. There are no second thoughts to not to consider a Scale-out architecture along with a Scale-Up architecture for any SaaS system. The better the software more number of clients and more number of users are bound to signup for your service.

The software at the architecture level has to natively support a Scale-out architecture whereby you should be able to expand your system to virtually any level up to the theoretical maximum. We never know if our software / service is successful, we could be the next billion dollar salesforce.com :-)

Availability / Reliability

As the case applies to security, the same applies to availability or reliability of the software. It is one of most important factors / characteristics that must be inherently be part of the skull of any SaaS product – Reliability.

A very clearly defined SLAs (Service Level Agreement) has become a norm these days for any SaaS offering and not adhering to it may even have legal implications. With more and more improvements in the technology and also increase in competition, customers expect a 99.99% uptime of the service and no longer just 99.9%. So that mathematically equates to 1 hour of downtime per year. Everyone is aware of the fact that no software can be 100% bug free but at the same time, the software needs to be architected and designed to ensure that the downtime scenarios are well handled and there would be no / minimum data or business loss to the clients. And most importantly ensure your SLAs are aligned to the SLAs of your hosting provider / partner. Always use a hosting provider. Never DIY.

Performance

One of the prime reason Google Search engine and Google’s web browser Chrome is a hit is because of its speed to respond. Although no one would expect your software to be as quick as Google (although if you could get there then nothing like it :-) ) but in terms of response times to any business operations, they have to be quick enough to an extent the users do not get a chance to think about the speed. Defining a clear SLAs for response times is also key for any SaaS offering. Although defining a higher response times in your SLAs to avoid legal implications and to play safe may be a good idea to an extent, but not at the cost of users realising the system is slow and start disliking it.

Perform frequent checks for ensuring the performance is at the top of the agenda. Cache the most frequently accessed metadata, service your database by optimising your queries and ensure all the queries in your database uses the most appropriate indexes. Minimize the network operations, use compression where appropriate. Load balance your web servers and if other factors permit, localise your server location.

And most importantly do not over engineer your software. The above points like caching, database indexing etc., may not always be the solution for performance and hence should be done as a calculated exercise,

Configurability

One of the critical success factor of any SaaS application is configurability. It is even more important to ensure configurability to a great extent is taken on board for a SaaS product since its native characteristics of having a single code base. Configurability in SaaS aims to provide customers with a multitude of options and variations to provide a unique experience. Not just that but having the system configurable allows you to sell different services based on various different licensing modes / editions, e.g. Software – Lite, Software – Professional, Software – Ultimate and so on. Ability to switch on and off a particular feature or an option to change the way a user uses the functionality or even ability to change background colour of a screen, may not be the most important thing to have within a software, but surely it is one of the key differentiators / selling factor for your offering. As mentioned above, providing different editions to different target provides an option to expand market share more easily.

Also since every customer would want to use the system in a different way to suit more to their internal culture, more the configurable your offering the better.

Flexibility / Extensibility

Software offering never ever ends at Version 1. It is relatively easier to incorporate or add functionality / remove / modify functionality from an on-premise software since the consequence of doing so would not affect your other customers. They have separate copies of your system and providing more “bespoke” tweaking is possible in such cases. A SaaS offering is a single piece of software catering to all your customers. Hence the architecture should take in to account an ability / room to extend the software with more features and functionalities to provide more value to your offerings in the future.

The most important point one must avoid for a SaaS offering is to provide bespoke implementations for different customers (with switches). Ensure the software is extensible enough to avoid such scenarios.

Usability

Usability Engineering is a vast area in itself and over the years companies have started taking User experience more seriously rather than just providing “a” User interface they think is appropriate. It becomes even difficult to implement a good user interface and interaction for a SaaS offering since the spectrum of users increases more than ten-fold. A single software instance needs to provide a unique experience and functionalities to different customers and in turn various different users of each customer. It is advised for every SaaS offering to undergo a Usability engineering exercise before getting the Graphics team to define the user interface for the software.

Interoperability

And last but not the least, no software can work stand alone. There is always a need for integration of our systems with other systems providing specialised services. E.g A Purchase Management system may need to provide a facility to interoperate with a financial accounting system. If you are providing a Financial accounting system as a SaaS offering, the need for interoperability would be even higher than the other kinds of business software for obvious reasons.

The key solution to address this non functional requirement is to implement a Service Oriented Architecture. It is important to expose most of your key interoperable business functions in the form of well documented Web services to allow other systems to interact and interoperate with your system. Since we are talking about a SaaS offering, and as mentioned earlier, the requirement of individual customers may differ and hence the SOA layer to the software needs to be well thought of and well documented to avoid any need for bespoke implementations. Also it may be required to consider a facility natively part of the system’s architecture to provide a facility to import and export of raw data to allow other related systems to make the best bonding with your offering. Needless to say, interoperability should not be provided at the cost of security and hence due care needs to be taken to ensure both marry well within the system.

--

There may be many more points which may be considered important as non-functional requirements, but the above ones are the most important and common ones which almost all the software delivered as SaaS needs to consider and take in to account in their design and implementation.

The success of a software (especially delivered as SaaS) depends not only on its functional requirements but also to a very great extent the….NON-FUNCTIONAL REQUIREMENTS.

Security concerns with a SAAS system

SAAS – Software as a Service can be defined as "Software deployed as a hosted service and accessed over the Internet rather than a product deployed at the customer’s premises for each customer."

Today, SAAS applications are expected to take advantage of the benefits of centralization through a single-instance, multi-tenant architecture, and to provide a feature-rich experience competitive with comparable on-premise applications.

Software as a Service (SAAS) is transforming the way traditional ISVs do business as providers of applications to the market. This new deployment and licensing model will fundamentally change the business model of the ISV, impacting many parts of the organisation – marketing, the sales force, presales engineering, deployment, support, finance, and product engineering and maintenance.

But all sounds good for the ISVs run this Business model. The main point here is to get a customer convinced to go for a subscription based software rather than on-premise software.

Customers surely see lots of business advantages by using a SAAS based product over an on-premise product. The reasoning no longer is a business decision. It is more a technical decision. The key technical factor that influences the customer to take a decision whether to go on-demand subscription-based or to buy an on-premise software is – Security.

Since the data is multi-tenanted in a SAAS environment, the fundamental question that comes to the customers mind is – How secure is my data (since it is not in front of me)? What is the guarantee that other customers of the same service do not have access to my data?

The customer should ideally be asking the SAAS providers the following questions to be convinced. It is not necessary that all the question is expected to have a positive answer for the customer to take a decision. It also depends upon what type of business application is being offered as SAAS. But “knowing” the answers is a “must” before taking a decision of going the on-demand route or on-premise route.

Here’s a list of questions I think should be asked by any customer to a SAAS vendor before subscribing to their service. The same set of questions can also be used as a check list by a SAAS vendor.

Data Access Related Questions

• Is the Database Multi-tenanted?
• How many people in the entire chain have the Database SA password?
• Is the data for one customer securely away from another customer?
• Do the Data-Centre engineers have access to the database through SA?
• Can anyone in the entire chain in a position to access / copy / change / destroy critical data of any customer?
• In a system where 3rd Party integration is involved, is the Data communication secured and restricted to only the required exchange of information?
• What information is stored in the Audit log?
• What arrangements are made for Database backup?
• What types of data are encrypted and what is the encryption mechanism used to ensure it is safe?

Infrastructure Related Questions

• What SLA do you the SAAS provider have with their Data Centre?
• What is the hardware redundancy arrangements made by the vendor?
• Does the data centre have WAN backup? i.e. The data centre is replicated in 2 different continents as a backup?
• If yes, Ask all the Data Access Related Questions again with reference to this second Data centre
• How many people from the SAAS vendor organisation have the network administrator password within the data centre?
• How many people have the Shut-Down permission on the Server?
• How often are the servers need to be restarted?
• Does the SAAS vendor align with the Data Centre's SLA within their own SLA?

Internet based Security Threats

• Is the Site hosting the SAAS system SSL enabled?
• Is the Database server on the internet or behind a DMZ?
• If, Yes it is exposed to the internet, then Why?
• How is the system protected from SQL injection?
• (If in case the hacker gets access to Database) Are the critical data encrypted?
• Does the Application User security tightly aligned to the data security?
• Last but not the least, Does the SAAS vendor / provider get their system audited by Security Auditing authorities?

Typically all these (or most of them) are covered in the SLA provided by the SAAS vendor but this is something to my mind is a must for any customer to be aware of before signing as a customer for a SAAS offering.

Agile, SAAS, NFRs & Architecture

For quite sometime I have been trying to get a grip of the agile methodology to develop applications. Somehow I am not 100% convinced (although I am 90% convinced) that Agile is the way forward.
I am still in a state of mind that Agile does not solve 100% of all the software development problems. This article is my effort to highlight few of my view points on this subject.

Agile : I would not go any deep in to this topic as it is a known and a well established topic.
If would like to know more about Agile, there are tons of articles on this subject. All you would need to do is google or (in Microsoft terms) bing it :-)

The Agile Mantra says...

• Individuals and Interactions - over process and tolls
• Working software - over comprehensive documentation
• Customer collaboration - over contract negotiation
• Responding to change over following a plan

In short Agile means - "Iterative Design & development".

So far so good.

But the key point to note here is - its "Design & Development". The process starts at "Design".

For large scale systems such as high availability, high concurrency, highly scalable systems, the key way forward starts at "Architecture". May be there are cases where a good Design does not require a strong architecture pre-thought but not always the case.

Architecture is NOT Design. Architecture is a process of looking at the entire system from a high level and providing a blueprint of how large scale systems are built.

Architecting a complex product such as a SAAS offering goes beyond just designing. SAAS systems invariably has stringent Non Functional requirements such as Availability (99.99% uptime), Scalability (x Thousand Concurrent users), High Performance response times (X transactions per second), Configurability (Meta data driven configuration), Extensibility (NOT CODE extensibility but product extensibility).

All the above elements have to be well thought of for a successful implementation of a high performance solution such as a SAAS offering.

As the name suggests, these are "NON-FUNCTIONAL REQUIREMENTS". They cannot be "automatically" captured as "User stories". Even if we capture these things as a part of User stories, which sprint do these stories belong to? How do we cater to this in a particular sprint? Should this be pushed to the last sprint? How do you split these requirements within each sprint? Most applications (even enterprise scale) may not worry much about these non-functional requirements. An enterprise application can wait for a half hour down time but a SAAS system, these things are fundamental. A SAAS system is a different game all-together.

There is no doubt that Design and development is key to any software development. But equally important is Architecture. This makes me wonder if there is something called as a 100% pure Agile project? If there is a 100% pure agile project, can this be used to build a SAAS solution with stringent NFRs?

To my mind the answer is NO. The first 10-20% of the time goes in conceptualising and "architecting" the system and then the system can be developed in Sprints (which is rest of the 80%). Architectural Patterns such as Zachman, RM-ODP, Rational Unified Process etc. (or fr that matter any Architectural patterns) wouldn't have existed if it had no use and the same can be done using a Agile methodology by directly jumping into design and development.

I am not sure how this article will be received, but this is just an attempt I thought I should make share my mind to fellow architects in the software world. I do love Agile. Agile is the way to go. There is no doubt about that.

The attempt here is to highlight the fact that - "There is nothing called as 100% agile software development"

Especially if you are thinking of developing a SAAS solution with extremely stringent NFRs, ensure you cover these NFRs within your Architecture and then start development using any Agile methodology.

For an Agile evangelist, a product development life cycle is - Sprint + Spint + Sprint + Sprint.

To my mind it is - Conceptualising & Detailed Architecture + Sprint + Sprint + Sprint + Sprint.

As I have been emphasizing, I am not sure if this arcticle would be well received by Agile Evangelist, but I thought this could be a good food for thought.

I have been involved in building SAAS applications with Stringent NFRs and hence I am able to relate this to agile development.

Await for my next blog on NFRs and its importance in designing a software solution.