Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


 
 
Posted by Sandeep Chanda on July 28, 2014

Express is a powerful, yet lightweight and flexible web application framework for Node.js. In this post we will explore how you can create and deploy an express application in Microsoft Azure.

Prerequisites

First and foremost you need Node.js. Once you have installed Node.js, use the command prompt to install Express.

npm install express

You can also use the –g switch to install express globally rather than to a specific directory.

In addition, you will need to create a web site in Microsoft Azure that will host the application. If you have the Azure SDK for Node.js then you would already have the command line tools, but if not, use the following command to install the Azure command line tool:

npm install azure-cli

Create an Express App

Once you have installed Node.js, use the command prompt to create the Express scaffolding using the express command. This will install the scaffolding templates for views, controllers and other relevant resources with Jade and Stylus support:

express --css stylus [Your App Name] 

Next, run the install command to install the dependencies

npm install

This command will install the additional dependencies that are required by Express. The express command creates a package.json file that will be used by the Azure command tool to deploy the application and the dependencies in Azure.

The express command creates a folder structure for views, controllers and models to which you can add your own. To modify the default view, you can edit the index.jade file under the views folder and add your own mark-up code. The app.js file under the application folder will contain an instance of express:

var express = require('express');
var app = express();

You can now use VERBs to start defining routes.

Deploy an Express App

In order to deploy the Express app in Azure, first, install the Azure command tools for Node.js if you don’t have the SDK installed. The next thing you need to do is to get the publish settings from Azure and import it into your Node.js application using the following commands

azure account download
azure account import <publish settings file path>

Next, you need to create a web site in Azure, and also create a local git repository inside your application folder.

azure site create [your site name] --git

You can now commit your files to your local git repository and then use it to push for deployment to Azure using the following command:

git push azure master

You are now all set. The express Node.js application is deployed in Azure.


Posted by Jason Bloomberg on July 24, 2014

Parenting is perhaps the most difficult job any of us is likely to have in our lifetimes, and we earnestly do our best as a rule. And yet, some parenting styles are clearly better than others.

The same is true of architecture. Even the best architects will admit that architecture is difficult, and even though we all try to do our best, in many cases architects are at the least ineffective, and at the worst, do more harm than good.

As it happens, there are some interesting parallels between parenting and architecting. Let’s start with the two most common bad parenting styles: too strict, and not strict enough.

The too strict parent lays down the rules. There are plenty of rules to go around, and breaking them leads to adverse consequences. Such parenting leads to resentment and rebellion from the children.

Unfortunately, most architecture falls into the overly strict category. Architecture review boards that give thumbs up or thumbs down on everybody’s work. Copious design documents that everybody is supposed to follow. Policies and procedures out the wazoo. A rigid sense of how everything is supposed to work.

The result? No flexibility. Excess costs. Increased risk of spectacular failure. And of course, resentment and rebellion from the masses.

However, the opposite type of parenting style is also quite poor: the “anything goes” parent with no rules. Sure, if you’re a teenager it sounds good to have such a “cool” parent – but with no guidelines, parents aren’t teaching their children the basics of living in society. The common result: antisocial or dangerous behaviors like drug use, promiscuity, etc.

The enterprise parallel to the anything goes parent isn’t anything goes architects – it’s no architects at all (even though some people may have the architect title). Without any guidance, the architecture grows organically into a rats’ nest of complexity. No rules leads to a big mess, as well as dangerous behaviors like insufficient attention to security, disaster recovery, etc.

The best parent, of course, is the happy medium. A parent who establishes clear but reasonable guidelines that don’t prevent the kids from living their lives as they like, but keep them out of serious trouble and help them establish behaviors that will make them successful adults.

Just so with the best architects. Focus on what’s really important to architect, like your security, disaster recovery, and regulatory compliance. Provide clear but reasonable guidelines for interoperability among various teams, projects, and software. Act as a mentor and evangelist for architecture, without limiting the flexibility that people need to do their jobs well. And by all means, don’t spend too much time on artifacts, documentation, rules, policies, procedures, and other “stuff.” Yes, you sometimes need these things – but good architects know that the very minimum “stuff” that will get the job done is all the stuff you need.


Posted by Jason Bloomberg on July 18, 2014

Making up new words for old concepts – or using old words for new concepts – goes on all the time in the world of marketing, so you’d think we’d all be used to it by now. But sometimes these efforts at out-buzzing the next guy’s buzzword just end up sounding silly. Here are three of the silliest going around today.

1.       Human-to-Human, aka H2H. This one came from Bryan Kramer of PureMatter. According to Kramer, “there is no more B2B or B2C. It’s H2H: Human to Human.” In other words, H2H is the evolution of eCommerce after business-to-business and business-to-consumer. The problem? Commerce has been H2H since the Stone Age. The next generation of eCommerce is two people haggling over a fish?

2.       Business Technology. This winner comes from a recent article by Professor Robert Plant in the venerable Harvard Business Review. Dr. Plant espouses that “we should no longer be talking about ‘IT’ as a corporate entity. We should be talking about BT—business technology.” Business technology? Seriously? How long have businesses used technology? Earlier than punch card readers. Earlier even than typewriters. Perhaps blacksmiths’ tools? IT – information technology – is a worn out term perhaps, but at least we know it has something to do with information.

3.       Digital. This one is all over the place, so it’s hard to point fingers. But I will anyway: this article from MITSloan Management Review and Capgemini Consulting, for example, which defines digital transformation as “the use of new digital technologies (social media, mobile, analytics or embedded devices) to enable major business improvements (such as enhancing customer experience, streamlining operations or creating new business models).” What, pray tell, does the word digital mean? It refers to a computer that uses bits, as opposed to analog computers that use, what? Sine waves? In other words, 1940s technology.

Ironically, in spite of the digital silliness, the aforementioned article is actually quite good, and I highly recommend it. Even more ironically, I find myself describing what I do as helping organizations with their Digital Transformation initiatives. I guess if you can’t beat ‘em, you might as well join ‘em.


Posted by Jason Bloomberg on July 9, 2014

Nowhere is the poor architect’s quest for respect more difficult than on Agile development teams. Even when Agilists admit the need for architecture, they begrudgingly call for the bare minimum necessary to get the job done – what they often call the minimum viable architecture. The last thing they want are ivory tower architects, churning out reams of design artifacts for elaborate software castles in the sky, when the poor Agile team simply wants to get working software out the door quickly.

My counterpart in Agile Architecture punditry, Charlie Bess of HP, said as much in his recent column for CIO Magazine ominously entitled Is there a need for agile architecture? His conclusion: create only an architecture that is “good enough - don’t let the perfect architecture stand in the way of one that is good enough for today.”

Bess isn’t alone in this conclusion (in fact, he based it on conversations with many Agilists). But any developer who’s been around the block a few times will recognize the “good enough” mantra as a call to incur technical debt – which may or may not be a good thing, depending upon your perspective. Let’s dive into the details and see if we’re asking for trouble here, and if so, how do we get out of it.

Technical debt refers to making short-term software design compromises in the current iteration for the sake of expedience or cost savings, even though somebody will have to fix the resulting code sometime in the future. However, there’s actually two kinds of technical debt (or perhaps real vs. fake technical debt, depending on who’s talking). The “fake” or “type 1” technical debt essentially refers to sloppy design and bad coding. Yes, in many cases bad code is cheaper and faster to produce than good code, and yes, somebody will probably have to clean up the mess later. But generally speaking, the cost of cleaning up bad code outweighs any short-term benefits of slinging it in the first place – so this sloppy type of technical debt is almost always frowned upon.

In contrast, type 2 (or “real”) technical debt refers to intentionally designed shortcuts that lead to working code short-term, but will require refactoring in a future iteration. The early code isn’t sloppy as in type 1, but rather has an intentional lack of functionality or an intentional design simplification in order to achieve the goals of the current iteration in such a way that facilitates future refactoring. The key point here is that well-planned type 2 technical debt is a good thing, and in fact, is an essential part of proper Agile software design.

The core technical debt challenges for Agile teams, therefore, are making sure (a) any technical debt is type 2 (no excuses for bad code!) and (b) that the technical debt incurred is well-planned. So, what does it mean for technical debt to be well-planned? Let’s take a look at the origin of the “debt” metaphor. Sometimes borrowing money is a good thing. If you want to buy a house, taking out a 30-year mortgage at 4% is likely a good idea. Your monthly payments should be manageable, your interest may be tax deductible, and if you’re lucky, the house will go up in value. Such debt is well-planned. Let’s say instead your loser of a brother buys a house, but borrows the money from a loan shark at 10% per week. The penalty for late payment? Broken legs. We can all agree your brother didn’t plan his debt very well.

Just so with technical debt. Over time the issues that result from code shortcuts start to compound, just as interest does – and the refactoring effort required to address those issues is always more than it would have taken to create the code “right” in the first place. But I put “right” in quotes because the notion that you can fully and completely gather and understand the requirements for a software project before you begin coding, and thus code it “right” the first time is the fallacy of the waterfall approach that Agile was invented to solve. In other words, we don’t want to make the mistake of assuming the code can be complete and shortcut-free in early iterations, so we must plan carefully for technical debt in order to deliver better software overall – a fundamental Agile principle.

So, where does this discussion leave Bess’s exhortation that you should only create architecture that is just good enough? The problem: “just good enough” architecture is sloppy architecture. It’s inherently and intentionally short-sighted, which means that we’re avoiding any planning of architectural debt because we erroneously think that makes us “Agile.” But in reality, the planning part of “well-planned technical debt” is a part of your architecture that goes beyond “just good enough,” and leaving it out actually makes us less Agile.

Bloomberg Agile Architecture™ (BAA) has a straightforward answer to this problem, as core Agile Architecture activities happen at the “meta” level, above the software architecture level. By meta we mean the concept applied to itself, like processes for creating processes, methodologies for creating methodologies, and in this case, an architecture for creating architectures – what we call a meta-architecture. When we work at the meta level, we’re not thinking about the things themselves – we’re thinking about how those things change. The fundamental reason to work at the meta level is to deal with change directly as part of the architecture.

In order to adequately plan for architecture technical debt on an Agile development project, then, we must create a meta-architecture that outlines the various phases our architecture must go through as we work our way through the various iterations of our project. The first iteration’s architecture can thus be “just enough” for that iteration, but doesn’t stand alone as the architecture for the entire project, as the meta-architecture provides sufficient design parameters for iterative improvements to the architecture.

However, it’s easier said than done to get this meta-architecture right. In fact, there are two primary pitfalls here that Agilists are likely to fall into. First, they may incorrectly assume the meta-architecture is really just a part of the architecture and thus conclude that any effort put into the meta-architecture should be avoided, as it would be more than “just enough” and would thus constitute an example of overdesign. The second pitfall is to assume the activities that go into creating the meta-architecture are similar to the activities that go into creating the architecture, thus confusing the two – which can lead to architecture masquerading as meta-architecture, which would actually be an instance of overdesign in reality.

In fact, working at the meta-architecture level represents a different set of tasks and challenges from software architecture, and the best choice for who should create the meta-architecture might be different people from the architects responsible for the architecture. These “meta-architects” must focus on how the stakeholders will require the software to change over time, and how to best support that change by evolving the architecture that drives the design of the software (learn to be a meta-architect in my BAA Certification course).

Such considerations, in fact, go beyond software architecture altogether, and are closer to Enterprise Architecture. In essence, when I talk about Bloomberg Agile Architecture, I’m actually talking about meta-architecture, as the point to BAA is to architect for business agility. Building software following Agile methods isn't enough. You must also implement architecture that is inherently Agile, and for that, you need meta-architecture.


Posted by Sandeep Chanda on July 8, 2014

The Microsoft Open Technologies team announced the support for Cordova tools in Visual Studio 2013 Update 2 during Tech-Ed US. If you have been building cross platform apps using Apache Cordova, you would know that it is a great tool for leveraging your existing skills and assets in HTML5 and JavaScript, and then use them to package the assets for building native apps in Android, iOS, and Windows Store/Phone.

You can download the Cordova tools for Visual Studio here. An important pre-requisite to note is that it will run only on Windows 8.1. The multi-device hybrid apps that you create using the tools support the following platforms:

  1. Android version 4+
  2. iOS 6 and iOS 7
  3. Windows 8+ Store
  4. Windows 8+ Phone

Once you install the tool, the additional dependencies will automatically be downloaded to support debugging and running the apps from within Visual Studio for various devices. Some of the significant dependencies are:

  1. Node.js
  2. Android SDK
  3. Apache Ant
  4. Java SDK
  5. SQLLite
  6. Apple iTunes

For Android apps, you can use the Ripple emulator to run the app for devices of various form factors. For iOS apps, you need to run Visual Studio from a Mac with support for Xcode 5.1. The tools, however, provide a remote agent that can be used to configure a remote Mac to allow you to remote debug. To set up the remote agent, you need to first install the ios-sim node module and then start the build server with the allowEmulate option set to true. In Visual Studio, you need to configure the port and address of the remote build server using the Multi-Device Hybrid Apps in general settings under Options.

You are now all set to create your first Cordova project. You will find the project template under JavaScript to create a new blank Cordova project. You will find that the default solution structure has been organized into folders to store the CSS files, Scripts and Images. In addition, there will be a folder called Res to store the platform specific assets and certificates. There will also be a folder called Merges to add platform specific code.


Posted by Jason Bloomberg on July 7, 2014

Sometimes random thoughts in the blogosphere coalesce into a strange synergy of ideas. When this happens, my natural impulse, of course, is to blog once more. In this case, no sooner had I written my last blog post about the need for a well-architected balance between the RESTful API management headache and excessive governance, when Jim Franklin of SendGrid published this article on developer-led innovation, where rule #8 calls for setting standards for coding RESTful APIs.

Add to this confluence an article from the latest issue of Fast Company Magazine on the rise and fall of Facebook’s “Hacker Way.” The Hacker Way – move fast, break things, and code wins arguments – helped drive Facebook’s culture until it got too big for the hackers to run the show. As a result, Facebook has been learning the hard way that hacker-led innovation has its drawbacks as well as its positives.

Fair enough, but what works (or doesn’t work) at Facebook won’t necessarily play in the enterprise – and the enterprise is my focus, as well as Jim Franklin’s. So, let’s put all of these ideas in a pot and stir, and see what kind of stew we end up with.

Superficially speaking, the enterprise alternative to the Hacker Way is simply the opposite of each statement: instead of move fast, the enterprise moves slow; hackers break things while the enterprise leaves things alone because they’re fragile; and instead of code winning arguments, business stakeholders win arguments.

But there’s more to this story, as the chart below illustrates.

The Hacker Way

What They Mean

The Enterprise Alternative

The Bloomberg Agile Architecture™ Way

Move fast

Agile development focuses on short sprints. Write good code as quickly as possible to drive innovation.

Move slowly - release cycles take months

Architect software to be inherently flexible so speed is driven by business need

Break things

Continuous iteration and rapid prototyping. Code until all tests pass.

Leave legacy alone - it's too fragile and important to mess with

When abstract models drive business capabilities and the underlying software provides affordances, people can prototype rapidly without breaking anything important

Code wins arguments

Developers drive innovation. Working software trumps discussions about software capabilities or business needs.

Business stakeholders drive innovation. Business strategy trumps code.

Innovation is a team effort. Business stakeholders must understand what technology affords them, while developers must focus on providing affordances to the business

 

In the chart above, the second column is my interpretation of what Facebook and perhaps other people mean by the principles of the Hacker Way. The third column is the traditional enterprise alternative to those principles.

If those columns were the whole story, we’d have nothing more than an example of how hackers and enterprises don’t see eye to eye. But from my perspective, Agile Architecture brings hackers and large organizations together. Hackers want to roll out new capabilities quickly, while enterprise software moves slowly. Bloomberg Agile Architecture (BAA) calls for inherently flexible software: the underlying code can move slowly, while the resulting application functionality can be as dynamic as the business requires.

The central technique here is to separate software capabilities from affordances. The underlying platform and associated infrastructure provide affordances – in other words, it’s up to people (hackers and others) to create different things with the platform depending upon their needs or desires. Software capabilities, therefore, are shifted toward users, enabling rapid prototyping without breaking the software. “Break things” thus becomes an overly simplistic principle, as BAA allows organizations to break what they need to break as part of the innovation process without breaking the underlying stuff that you don’t want to mess with nearly as often.

BAA thus addresses the question as to whether you want your developers to drive innovation in the enterprise. Argument for: techies are more likely to understand the power of today’s technologies than the business users. Argument against: it’s the business users who better understand customers and the marketplace the enterprise competes in. Conventional wisdom: business users and techies struggle to communicate with each other, and don’t like each other much in any case.

BAA navigates a course past this impasse. Yes, business stakeholders and developers must work as a team to drive innovation. But this isn’t just an unstructured Kumbaya Moment here. Rather, developers should focus on affordances while business users should focus on capabilities. Once everybody understands the difference (and it’s really not that difficult), then we finally have a recipe for technology-supported innovation in even the stodgiest of enterprises.


Posted by Jason Bloomberg on July 3, 2014

Perhaps the most successful part of Representational State Transfer (REST) to date has been the simplification of Application Programming Interfaces (APIs). We no longer need a language-specific protocol that depends upon sophisticated network controls under the covers. Today we can take HTTP for granted, and a simple request to a URL suffices to establish any interaction we care to implement between any two pieces of software we like, regardless of language. What could be easier?

 Easy, yes, but with easy comes a dark side. If something’s easy, then anybody can do it. And if anybody can do it, then anybody will do it. And when that happens, you’re more likely to have chaos than orderly integration. And therein lie numerous, often unexpected problems.

REST, after all, is rather vague about many of the specifics of its implementation. Data formats, URI conventions, and how the hypermedia constraint is supposed to work, for example, are all subject to interpretation. As a result, many organizations have a plethora of different RESTful API styles, leading to incompatibilities, code maintenance issues, and even potential security risks.

For numerous vendors, of course, chaos means opportunity, and the API Management market is exploding as a result. You’d think as the API story shifted over the last decade from Web Services to RESTful interfaces that the core challenge would have become simpler. Au contraire: REST’s inherent flexibility has actually exacerbated the management headache, to the detriment of many IT shop’s API strategies.

The most obvious solution to the problem of easy APIs is to crack the whip. Establish rigorous, formal policies for how everyone must build their APIs, and then firmly enforce those policies. In other words, introduce governance into the development shop. Follow the rules or else!

Unfortunately, this heavy-handed approach to governance is usually counterproductive. It lowers morale and productivity among the development team, and can also limit the flexibility of the resulting software, which can adversely impact the agility of the organization.

What then is the best approach for managing the easy API problem, without falling into the traps of a management headache on the one hand or “Big Brother” governance on the other? The answer: a well-architected balance between these two extremes.

By “well architected” I mean first, that architectural decisions must be business-driven, and second, they must empower inherently flexible software – in other words, Agile Architecture. Yes, API management tools, especially when they support a dynamic API abstraction, are an important enabler of Agile Architecture. But then again, so is an automated governance approach that encourages consistency in the application of API approaches while allowing flexibility. Bloomberg Agile Architecture strikes this balance. Learn more in an upcoming Bloomberg Agile Architecture Certification course.


Posted by Jason Bloomberg on July 1, 2014

At Intellyx we break down business agility into three core business drivers: responsiveness, resilience, and innovativeness. This perspective on business agility, however, is not universal. In fact, most people separate innovation into its own category.

On the one hand, leaving innovation out of the business agility equation misses the strategic importance of agility, as resilience and responsiveness are only tactical benefits. Innovativeness, however, means the ability to intentionally introduce change into the business environment in order to achieve strategic advantage.

There is more to this connection between responsiveness and resilience on the one hand and innovation on the other, however, depending upon your point of view. I came to this conclusion during a conversation with a consultant who focuses on providing innovation to her clients. The challenge she faced wasn’t providing innovative products and services for her clients. The challenge was how to get them past their fear of the change that such innovations represented.

Fear of change, of course, is the primary roadblock to business agility in any organization. Many organizations, unfortunately, have no effective means for dealing with such fear. Management consultants speak of developing a “culture of innovation” or some such, but fail to provide an effective means for fostering such a culture. Bloomberg Agile Architecture can help.

Considering innovativeness to be one facet of business agility provides a different route to resolving the fear of innovation conundrum, as innovativeness is only part of the agility story. Resilience is also essential for business agility. We define resilience as the ability to respond to adverse change in the business environment – essentially, being able to bounce back when bad things happen. To increase your organization’s resilience, the first step is analyzing the sorts of bad things that might happen and how likely they are – in other words, you must conduct a risk analysis.

In the case of the fear of innovation, you must analyze the risks inherent in making the change under consideration as well as the risks of not making the change. The second part of this analysis is the most important, as you cannot create a risk profile unless you consider all sides of a decision, including the risks inherent in not making it.

Risk profile analysis, of course, is a central part of traditional information assurance – the risk management that goes on all the time in those parts of organizations that are familiar with quantifying risks. Credit card companies, for example, know how to calculate the risk of fraud, and balance that risk with how much it costs to combat fraud. The analysis should lead to the local optimum: the right balance between the cost of fraud and the cost of fighting it.

Just so with innovation. Calculate the risk of introducing a change – maybe customers don’t like the new product, maybe it cannibalizes existing revenues, etc. And then calculate the risk of not introducing the change – the competition’s innovations take your market share, the opportunity cost of leaving money on the table, existing product lines reach their saturation point or lose favor among customers, etc. Run the numbers and make your best guess as to the optimum balance between action and inaction (or in practice, among all the alternatives under consideration).

Fair enough, but what does this approach have to do with Agile Architecture? Remember, such architecture should focus on organizational, process, technology, and information design choices that support the agility drivers of the organization. The discussion up to this point has focused on organizational and process change. But without the appropriate supporting technology and information, it would be impossible to calculate an accurate risk profile analysis. The “running the numbers” step above is easier said than done, after all, as the necessary data might very well be the result of the appropriate application of Big Data analytics. Supporting the business agility goals of an organization by connecting them to the technology and information required to achieve those goals is the purpose of Bloomberg Agile Architecture. Make sure you’re not missing any of the pieces.


Posted by Sandeep Chanda on June 30, 2014

In line with the Cloud First strategy, the Microsoft Azure team is aggressively working towards creating a Connected Systems and Devices platform using the Azure Service Bus, called the Microsoft Azure Intelligent Systems Service. This will enable enterprises to aggregate data from a variety of devices and sensors, and other lines of business applications. The data can then be made as a source for big data analytics using Azure HD Insight.

With all the scalability and performance attributes of Microsoft Azure in play, the platform could address the needs of industries such as transportation, manufacturing, supply chain, retail and healthcare, and enable the creation of smart cities and buildings. The idea of the Internet of Everything is to be able to support more efficient use of resources by providing insight on the data aggregated from them. As Todd Holmquist-Sutherland and Paolo Salvatori included in their Build 2014 conference session, the significance of Internet of Things (IoT) is in building the business of data driven insight. In addition, the significance is not just limited to getting business insights, but also to take appropriate action using the platform. For example, in a smart grid, the system could decide based on insights, the power consumption trends of house-holds and take action to control the ingress.

The Azure IoT stack provides a Cloud Gateway that acts as a secure boundary for communicating with the backend services. The gateway interprets messages from proprietary protocols and sends it to the Ingress Messaging Layer. The Cloud Gateway supports two patterns for communication. A Device Direct pattern where the IP Capable Devices are able to communicate directly with Azure Service Bus for storage and notification, or the brokered Custom Gateway where a set of Cloud Services broker the communication. The gateway allows partitioning of resources that are assigned to specific population of devices, allowing the ability to scale on demand.

The Cloud Gateway interacts with the Azure Service Bus using a topic based publisher subscriber pattern. Messages from the telemetry pump are split into alerts and data, and are sent to the alert processor and storage pre-processor respectively. This video from Build provides a quick preview into what's in store for the future of IoT with Microsoft Azure.


Posted by Jason Bloomberg on June 26, 2014

I read with interest JP Morgenthal’s recent post on how SaaS represents the commoditization of application functionality for enterprises. He points out that based upon a recent GigaOm research report, enterprises are in large part shifting away from on premise, custom software solutions to one-size-fits-all SaaS alternatives because businesses are realizing that “they can achieve the same goals with the commodity item as they can with the unique one.” JP goes on to say that businesses are still willing to pay the higher costs of bespoke solutions if they deliver sufficient value – but SaaS alternatives are increasingly carving out a larger portion of the enterprise app pie.

The reason I found this post interesting (JP’s scintillating insight notwithstanding) was because I just wrote a blog post on how software customization limits agility. I conclude that with proper architecture, it’s possible to build software flexible enough to support the organization’s business agility goals, even when those goals require a high level of personalization and customization, without falling into the high-cost bespoke software trap.

These two perspectives appear to be at odds with one another. JP is basically saying that as SaaS gets better, enterprises are more likely to settle for commoditized capabilities because of the cost savings, while I’m saying that as architecture gets better, enterprises are more likely to take advantage of high levels of personalization and customization, because Agile Architecture will enable such flexibility while keeping costs down. So, which is it?

The answer: both. With the proper architecture, commoditized software (even SaaS) can still be highly flexible. There’s nothing about my argument that wouldn’t apply to SaaS; in fact, I would expect an increasing percentage of well-architected software to be available in the Cloud (either PaaS or SaaS depending on which software we’re talking about).

Today, the ability to customize public SaaS offerings is limited primarily to user interface personalization, turning capabilities on and off for different users, and a modest level of configurability of the application functionality itself. But the writing is on the wall. Enterprises will only settle for “one size fits all” commoditization of SaaS apps if the cost savings outweigh the limitations, and if there’s nothing better on the market. Once the SaaS vendors figure out how to offer full-fledged mass customization while maintaining a commoditized code base, enterprises won’t have to settle for any color as long as it’s black any more.

If you’re a SaaS vendor, the rules are changing as we speak. Building your entire business on offering commoditized software will eventually be a losing value proposition, as downward pricing pressure will catch up with you sooner or later. But if you don’t figure out how to scale mass customization without driving up costs, you’ll be eaten alive. The secret, of course, is to get your architecture right from the beginning.


Sitemap