All of us have heard the mantra “Speed, Quality, or Cost…pick any two that you like” but when it comes to a specific software release you are usually only left with the speed and quality levers to pull.

The reason you only have these two is that budgets are generally set annually and even if your budget were instantly doubled you could not hire developers or QA staff fast enough to make a difference on the target release in question. So that leaves us often asking the question, do we want the release out quickly or correctly? In some organizations this question is asked every release. What is the right answer? We believe the single correct answer is “it depends”. I know, that sounds like a copout but really “it depends” on things like what type of software are you are developing, (e.g. shrink-wrapped or SaaS), how tolerant are the customers, how many open production bugs do you currently have, etc. The following is a quick look at some of these dependencies with the intent of informing better decisions regarding their trade-offs in the future.

The type of software you are developing is a critical element in the decision between speed and quality. If you have one shot to get it right because the software is being pressed onto DVDs then we argue that the decision is obvious: you have to skip your delivery date if the quality is not there. If you are developing SaaS type software the question is a bit more complicated because some services are fine to be a little buggy, such as a beta version of a report. Others, like transferring money in a banking application, are not. The user of the software is another critical element in the decision. If the application is for internal sales reps, bugs can be managed much more easily than if the software is for external sales reps.

The current or expected quality of the application is another factor to consider when making the decision to trade speed or quality. If you have very few bugs currently in production it may be fine to release a less-than-perfect version and clean it up over the next week, providing that your customers are tolerant of this type of deployment. It may be the case that the new functionality will rapidly create barriers to entry for your competition or switching costs for your users which in turn may allow for a higher defect density in the initial release. We have often had internal customers tell us this exact comment when we were building features to improve their efficiency or productivity.

When considering the tradeoff of speed and quality, consider your user’s willingness to tolerate defects in a release, the importance of quality in the release given the industry (our example of banking being a low defect need industry) and the business need for speed in the specific functionality contained within the release.

Two architectural approaches commonly applied today are the Service Oriented Architecture and the Resource Oriented Architecture. When considering these as a basis for your platform, the decision is not whether one is better than the other but rather which is more appropriate for the intended functionality, portion of the platform or entire platform. We will start by defining and explaining each of these architectures and then give some advice on how to make the right decision in light of your specific needs.

Service Oriented Architecture describes designing a system by modeling business processes as services or “actions”. Each service is a distinct unit of functionality and does not interact with the other services. In other words, calls between services are discouraged. As with object oriented programming wherein a major goal is reuse of code, the goal of SOA is to allow large chunks of functionality to be rearranged to form new applications. The size of the chunk of functionality is important because the more functionality that is included in each service, the fewer interface points that are required to implement a particular functionality and the fewer interface points there are in any particular functionality the lower the probability of transactional failure and improvement in performance. That said, very large chunks of functionality may not be granular enough to be easily reused. SOA is geared towards applications that are activity-based, such as a banking application where users are most interested in performing transactions such as deposit, withdrawal, open accounts, etc.

Resource Oriented Architecture is a term coined by Alex Bunardzic in his August 8, 2006 blog entry. It is now generally considered a specific set of guidelines for an implementation of REST. REST, or Representational State Transfer, comes from Roy Fielding’s Doctoral Thesis “Architectural Styles and the Design of Network-based Software Architectures” and describes a series of constraints that exemplify how the web’s design emerged utilizing the Hyper Text Transfer Protocol. It is difficult to discuss REST without blurring the lines between the technology of implementation and the ROA architectural principals. ROA is ideal for applications that are resource-based such as an RSS reader where feeds are the “resource” that the user is interested in getting information about and then updating the status of that resource.

A closely related technology decision is whether the implementation will be REST, SOAP, RPC or various other technologies. As discussed above, REST is often associated with ROA while SOAP is often associated with SOA. However, they are not mutually exclusive, in that it is possible to implement an SOA architecture through a RESTful implementation. Another confusing point is the difference between SOAP and SOA. SOAP, which originally stood for Simple Object Access Protocol, is a protocol for implementation whereas SOA is an architecture. The SOA and ROA concepts are the structure of the application and what information flows – they are descriptions of how something should work. REST, RPC, WS*, and other technologies are how the application actually works, or how they are actually implemented. We will talk more about these technology implementations in a later article.

The language analogy is that SOA focuses on exposing many verbs (actions) and ROA is focused on exposing many nouns (resources). Of course most applications, like sentences, are not all actions or all resources but rather they are a combination of both and have actions and resources. The predominance of the application should dictate the architecture. If you find yourself in a position of having a platform requiring a mix of actions and resources it may be useful to consider blending (albeit in separate environments) the two architectures. For instance, you might have a site that has reporting functionality that is primarily resource based and commerce functionality that is primarily action based. In this case your site could be comprised of two separate and distinct architectures that form a holistic client service including both commerce and reporting.

Ardent adherence to one architecture or another is not prudent. As we mentioned in our posting on Technology Agnostic Design (TAD) the professional technologist chooses the right tool for the job as should be the case for architectures, technologies, design patterns, programming languages, etc.the professional technologist chooses the right tool for the job as should be the case for architectures, technologies, design patterns, programming languages, etc.

If you have had a good or bad experience with either architecture let us hear about it

Have you ever heard someone describe a design or platform architecture by using the names of the third party systems used to implement their platform? The discussion starts with a question: “How are you architected?” and ends with a statement like “We use ACME web servers running on PLATINUM computers connected to our own internal application running on ACE application servers. We use BESTCO databases to maintain state and store information and they run on FASTCO SMP servers connected to a BESTSAN storage area network. Our network is all FASTGEAR and SAFE supplies our firewalls”.

The statement is innocent enough, but it does not address how a site is architected; it is rather a statement of how that architecture is implemented using technology.

Mature technology organizations understand that there is a very big difference between architecture and technology. The architecture of a platform describes how something works in generic terms with specific requirements and the technology describes how it is implemented and what it is comprised at any point in time.

The aim of technology agnostic design, or TAD, is to separate design and architecture from technology and implementation for the purposes of reducing cost, decreasing risk and increasing both scalability and availability.

TAD and Cost
It is unlikely that you will see an architect of a house label trusses, beams and supports with the vendor’s name. More likely the aforementioned objects will be labeled with sizes or specifications for load bearing. One reason this is so is that the architect recognizes that most pieces with which they will design a house are “commodities” or things that can be easily swapped out and which might be purchased primarily based on price.

Most technology solutions also ultimately suffer from the effects of commoditization. This is to say that as a good idea starts to become successful it is bound to attract competitors. The competitors within the solution space initially compete on differences in functionality and service but over time the differences in functionality and service start to decrease as the most useful feature sets are adopted by every provider in the competitive landscape. In an attempt to forestall the effects of commoditization, providers of third party systems and software try to produce proprietary solutions or tools that interact specifically and exclusively with their systems in order to create switching costs for the users of their systems, hardware or tools.

While there are always exceptions, as a rule we believe you are better off maintaining the flexibility of using nearly any provider’s solutions where there exists competition for that provider’s product offerings. The ability to replace one vendor’s product with another fairly easily gives you significant leverage in negotiating prices long term. We don’t mean to imply that you should never leverage proprietary functionality; rather you should understand that the use of such an embedded toolset has hidden and long term costs.

TAD and Risk
Designing for a particular vendor’s solution also creates a great deal of risk for your product and for your company. What if the provider of the solution goes out of business? What if the provider finds themselves being sued for some portion of their solution that does not exist in other similar solutions? What if the viability and maintenance of the product relies upon the genius of a handful of people within the company of the provider? What if the solution suddenly starts to suffer from quality problems that aren’t easily fixed?

Technology agnostic design reduces your risk by increasing your ability to quickly move to other providers without the problems identified above.

TAD for Availability and Scalability
As discussed above, as competition increases between providers of software and hardware and before commoditization completely sets in, providers of software and hardware attempt to differentiate themselves on functionality, performance, and service. During this period of attempted differentiation there might be significant performance, quality, and functionality differences between the providers. Ensuring that you can easily switch between the providers gives you the ultimate flexibility in leveraging these differences to the benefit of your platform.

The TAD Approach
Implementing technology agnostic design is fairly simple and straightforward. At its core, it means designing and architecting platforms using concepts rather than solutions. Pieces of the architecture are labeled with their generic system type (database, router, firewall, payment gateway, etc) and potentially further described with characteristics or specific requirements (gigabit throughput, 5 TB storage, ETL cloud, etc). The first, very simple test is to see whether a 3d party vendor’s name is tied to the system described on paper in any given architecture or design. Data flows, systems, transfers and software that are specifically labeled as coming from a specific provider should be questioned and where possible the system should be designed to allow any provider of a service to exist in that area.