I have recently been reading the book “Free: The Future of a Radical Price” by Chris Anderson.  Well I am not actually reading it as I find I do not have time for reading books any more.  These days I do all of my “book reading” using audio books from Audible.com.  I find that by making a conscious effort to listen to a book every time I am driving a car, on a plane, in a cab, in a restaurant by myself on a business trip, etc, I can actually get about 45-60 hours per month of audio book covered using time that I cannot otherwise use all that productively.  This amounts to about 1200-1500 pages of book equivalent per month which is a lot.  Anyhow, I digress.  So I am “reading” Chris’s book and while I tend to agree with Chris on a lot of the trends and use cases cited in the book, the Financial Economist in me is screaming that there is a potential train wreck coming for the technology sector and consumer oriented Internet startups in particular.

For those who have not read the book, let me boil it down for you enough to understand where this article is coming from.

In a nut shell, Chris’s premise is that since the marginal cost of a computer program, web site, etc is close to $0 and given the expectations of Gen X and GenY that all things are available free on the Internet, that most software or web offerings will be forced in the future to have some form of Free version in order to get traction.  Furthermore the book is filled with examples and cases of how people have made a viable business by offering something for free and making money through an upsell, advertising, etc.

If you are in any way thinking of starting a technology company or bringing any product to market (particularly if its aimed at consumers under 35) then this book is a must read, as it makes some important points about the behaviors and mentality of today’s consumers.

Anyhow, what concerns me, particularly for consumer Internet apps is that it basically implies there will be only 2 viable business models going forward.

1. The core product is offered for free and is subsidized by advertising
2. The Freemium model, where you offer a scaled down free product and hope to convert a small percentage of users to a paid premium version

Now I do realize this is an over simplification but it’s sufficient for the purposes of this discussion.

What worries me about all of this can be broken down to the following few points:

Scale
Both of these models require huge scale in order to be viable as a serious business (by that I mean supporting more than a handful of employees in the business).  While I understand that its certainly possible to achieve huge scale with consumer Internet based apps, it’s very difficult.  What portion of applications on the web get to 1 million users never mind 10 million or more?  The bottom line is that if you cannot achieve this kind of scale,  then it will be very difficult for a business which relies on advertising revenue or converting 2-5% of users to a paid product to support more than a part time income or at best a handful of employees.

Reliance on Advertising
In the case of a business that relies on advertising from others to subsidize its product, I question the long term viability of this model for any one company, unless you are one of the few big success stories such as Google, and lets face it, although everyone wants to be, not all startups can be a Google.  Again, without huge scale It won’t be possible to generate enough advertising revenue to support more than few employees.  In addition,  lets do a small thought experiment (albeit one that is hopefully not too realistic or we are all in big trouble).  Imaging that all consumer oriented internet based apps eventually end up being free and that they are subsidized by advertising revenue. Who buys those ads?  If no one is making money directly through the sale of end product, then I argue that no one has money to pay for ads and the whole model fails.  The only way this model can work for more than just select point businesses within an ecosystem where at least some businesses make good money from direct sales of products, is if there is tons of external capital being pumped in to subsidize these business and to pay for those ads.  In this case its just a matter of time before that external capital dries up as its absolutely impossible for this system as a whole to make a sufficient return on investment at a systemic level.  That’s not to say some business won’t reap very good profits, My point is that as an economic sector overall using just this model,  its not possible to be profitable.  Therefore there must be at least some products for which the consumer is willing to pay for the product directly in order for this to succeed.  When you consider the average Gen Y doesn’t feel they should ever pay for anything computer software related, this is a big potential problem for the information economy in the future and the companies who hope to be successful selling to them.

The Freemium Model
I actually think this model is more viable but it has its own challenges.  Firstly,  you still need huge scale to support more than a handful of employees.  Lets assume we can achieve that scale for the sake of argument.  What I think is difficult here is determining what your Free product should be such that it attracts a large number of users, but still leaves them wanting more.  If the product is feature light, you will not attract a large enough user base.  If the free product has too many features, then people will feel no need to upgrade to the paid premium version.  This is a very fine line in my opinion and one which is very hard to discern.  To make matters worse I suspect that over time as more and more gets offered in free versions, the level of features that will need to be in the Free versions will constantly increase making it harder and harder to get people to convert to the premium product.  If this turns out to be the case this business model will also collapse in time as conversion rates will constantly be in decline and will eventually approach zero.

I guess the bottom line here is that if you are planning to build a consumer oriented internet application,  you need to think long and hard about your business model.  Are you doing this as a hobby, in which case you may not care if it makes money or are you hoping to make a living off of this effort, in which case you need to think about this long and hard before you begin or you will fail to be successful.

Anyhow, as always, comments are welcome both here and on Twitter (@TechMusings)

Well I have been traveling out of the country a lot these past few weeks so its been a while since I posted.  I will try and do better in the future.  During my travels I had a lot of interesting discussions with people about a wide range of technology issues, solutions, and technology acquisitions and one theme kept coming up again and again which is the misalignment of problems and solutions.  This got me thinking about a blog post Dave McClure did a while back titled “Your Solution Is Not My Problem” .

In this article, Dave discusses one of his pet peeves about pitches that he and other VC’s receive.  The net of his beef is that people always start off by describing their solution without having first defined the problem that the solution is intended to solve.  Dave’s point is that if he doesn’t understand or believe in the problem,  then telling him about your solution to it, is meaningless and a waste of time.  If you really think about this, you will come to realize that this is a really profound concept that applies not just to assessing an elevator pitch, but to many other areas as well.

Unfortunately,  I find that too often we go around saying “Here is my hammer.  Show me your screw!”

I can’t tell you how many times I see people selling their solution to clients without having identified if the client even believes they have a problem never mind whether your solution fits that problem.  It drives me crazy to have to constantly play the bad guy stopping sales reps from pitching a misaligned solution to a client or explaining how a proposed or worse yet newly developed product or solution doesn’t address a client problem and thus won’t sell.  Then, if and only if, the product or solution truly does address a well articulated, painful problem to which we can associate a dollar value, do we get to examine whether the solution we propose is truly able to solve the problem better than the alternatives.  If you cannot do that then you are in big trouble and you solution will fail to be successful.

The process, whether you are selling a product, solution or your company needs to be as follows:
1) Define the problem.  You and the target audience need to agree on what the problem to be solved is or else there is no common ground on which to have the rest of the discussion that’s needed to result in a transaction.
2) Once you have agreement on the problem to be solved, then and only then can you define your solution, and you better make sure that your solution is truly aligned with the problem as defined in step 1 or you are wasting everyone’s time
3) You need to convince the target audience that your solution is the best solution to the agreed problem.  Remember its more that just the software or product that is being assessed.  Your solution includes you, your credibility and the credibility and viability of your company to support, maintain and improve the solution for the time horizon the client intends to use it for.

So if you want to have a successful solution, you need to make sure you know its a screw,  whether its a Philips or a Robertson and that your solution is the right screw driver and not a Hammer.  Even better, convince them your solution is a powered screw driver.

I had a lot of questions from people after my last post on BPM and SOA about the layered SOA I proposed and whether it would be slow performance wise.  The answer I gave people was “It depends”.  In this post I will outline in more detail some of the considerations needed around performance when implementing an SOA or any system for that matter.

Firstly, I find over the last 10-15 years system architects and programmers often don’t consider the performance needs of their system enough when designing it.  The process most people follow is typically:

1. Code the system up (or at least a prototype)
2. Run a small performance benchmark
3. Size the hardware to get the desired performance

To be honest this drives me crazy as it often yields a very non-performent system and if the performance is not achieved with hardware at step 3 then its too late in most cases to do anything about it without going back and severely refactoring the code or worse yet rewriting it all together.

Years ago this was not the case because the hardware was too slow to assume you could easily find a big enough box to ensure you achieved your performance goals.  As a result programmers pre about 1993 thought very carefully about how they designed and implemented their code with performance front of mind before even a single function got coded.  But once the bigger SMP UNIX boxes started coming out, programmers got sloppy to the point where today most of the younger programmers (those who started commercial programming post say 1997 ) I come across, have not been taught how to evaluate the effects of their technology or programming decisions, when it comes to impacting performance.

In the old days programmers were taught that when implementing any function or procedure to consider the Order “O” of their algorithm.  We worried about whether it was Order N, N Log N, N^2 or God forbid N^3 or worse.  If we could replace an O(N^2) algorithm with one that was O(N Log N) we did.  The same mind set should be employed today as well when writing code, but more importantly it should be employed at a higher level when deciding the language, interface types, message formats, I/O pattern, network topology and database design.

Let me explain:

Consider our Layered SOA from the last post (shown again here for reference):

This is in principle a logical architecture which we can choose to realize in a number of ways and with a range of languages, interface protocols, hardware choices, network topologies, etc.

So the first thing you need to consider at a high level is whether you are designing the system for throughput, latency/response time or both.  This is important, because depending on what the system needs to achieve, you should be making potentially dramatically different technology choices.  For example, if I am building an ultra high performance stock exchange system that does 5 million transactions per second and has a response time target end to end of 100 microseconds, then certain technologies are out right off the bat They include but are not limited to:

• I can’t use Java or c# as the languages themselves and the implementations of the base language libraries do not lend themselves to low latency.  I could use them to achieve the high throughput but I will not get to 100 microseconds as a rule (there are some ways to get close by using Java like C, pre-compiling, ensuring no garbage collection is used, etc but its a pain)
• I can’t build it on windows at all, because of the overhead and the slow network stack
• I can’t use persistent queue based messaging
• No traditional database transactions in the critical path (in fact no on disk I/O at all)
• No XML anywhere
• And definitely no REST or SOAP Web Service Interfaces

The key is that while all of these technologies can be used in a high throughput system,  they are inherently not fast from a latency or response time perspective, so if you choose to use them for a system that needs ultra fast response times, you are dead from the word go because no amount of hardware will fix it.
It is important to keep in mind the time it takes for basic operations as well so that you can roughly gauge in advance what your system will be capable of.  Here is a list of rough performance measures for common operations.  Your mileage will vary based on specifics such as hardware, compiler, database, etc but the order of magnitude “O” will be about right regardless. These are approximations based on say a 2.8 GHz Xeon. Newer Nehalems, etc will do better.  Also these are for a single thread on a single core.  Most won’t benefit from multithreading.  Also keep in mind that to an extent the lower the latency or response time of the system the higher throughput it can handle per core as CPU’s free up faster, so getting this right is important for all systems.   So here they are:

• Network hop from desktop to remote web server                                              50-500 milliseconds
• Persistent Message (small) per hop                                                                       15-30 milliseconds
• Non-Persistent Queue based messaging (small) per hop                                2-5 milliseconds
• Database Insert (Complex)                                                                                     15-30 milliseconds
• Database Insert (Simple)                                                                                        3-10 milliseconds
• Database Select (Complex)                                                                                    10+ milliseconds
• Database Select (Simple)                                                                                       500 microseconds-3 milliseconds
• Binary Write to Traditional Disk                                                                        2-5 milliseconds
• Binary write to SSD                                                                                                25 microseconds
• Screen Refresh                                                                                                          10-15 milliseconds
• Web Service Call inside a Web Server (Small Payload Java or C#)         1-5 milliseconds
• Web Service Call using GSOAP or Systinet (C no server)                           200-400 microseconds
• Binary RPC Call (small payload Java or C#)                                                 50-100 microseconds (local machine plus network roundtrip if remote)
• Binary message based function call (Small, C , Infiniband)                     1-2 microseconds in shared memory space, 5-10 microseconds remote through a switch

Anyhow this list is by no means exhaustive.  Response times will increase with the size of the message payload, amount of XML to serialize/deserialize, complexity of the database query, etc.  What’s important to the system designer is the order of magnitude of the performance given the non-functional targets for the system.  Knowing what is possible for a given operation or technology should shape both your design and technology selection.

So armed with this,  lets revisit the questions I got re the performance impact of the layered approach vs a non-layered one to see what happens.  Let assume the following:

• We implemented the physical architecture exactly as the Logical one is laid out with each service component on a separate machine
• We used SOAP web services for every public function call
• Assume 1 Gigabit Ethernet networking in the data center (worst case)

So lets look at the effects of layering on the Customer Service which adds an extra layer in the proposed design.

Lets assume we just want to retrieve a basic customer record.  In a single layer design with one database behind the service we have the following main costs:
Network Hop Application to Customer Service                                                                  200-500 microseconds
Find Customer Web Service Call                                                                                            1-5 milliseconds
Complex query doing a join across multiple tables for name, addresses, etc           10 milliseconds
Internal Logic Code execution                                                                                                Implementation and Process dependant

Now lets look at the layered costs:
Network Hop Application to Customer Service                                                                200-500 microseconds
Find Customer Web Service Call                                                                                          1-5 milliseconds
Parallel Network round trips                                                                                                200-500 microseconds
Second Layer Parallel Web Service Calls                                                                          1-3 milliseconds
Parallel Simple Queries                                                                                                          500usec – 3 milliseconds
Internal Logic Code execution                                                                                              Implementation and Process dependant

And I would contend that you can do better by using a binary call for internal Component to Component calls, reducing the 1-5 milliseconds down to more like 50-100 microseconds.

So if you add it up,  you will see that not only did the layered approach potentially improve total end to end latency but it definitely improved throughput of the system.  You should now be scratching your head wondering how that happened.  There is at least one major assumption here and that is that each Service Component had its own independent database.  This allowed the queries in the Layered approach to happen in parallel and the queries are themselves dramatically simpler with potentially no joins, etc.  If we still have one single database,  then performance will be bottlenecked there are we won’t see as much gain.  Even then at worst, if the queries take the same 10 milliseconds, we added about 1-3 milliseconds to the total end to end time.  Depending on the amount of time spent in the implementation specific code, that’s about 10-20% slower latency worst case (and still less than the cost of a single screen refresh so a user won’t notice it unless its enough to cause the total system to queue up throughput wise) but in return we got much better throughput and much more reuse.

Anyhow,  the point is, when designing a system and coding it,  you really should think about these types of things before you get so far down the road that you realize you have a problem only when you’re in it up to your neck and can’t easily do anything about it.

Feel free to fire away with the questions here or on Twitter (@TechMusings)

I was having a Twitter conversation with Brenda Michelson (@bmichelson) and Todd Biske (@toddbiske) about the tight coupling in peoples minds between BPM and SOA, and why I find that when people take a BPM centric approach to SOA, it usually ends up not delivering the goods.  So today’s post is about how to properly layer your SOA to include BPM while still yielding all the flexibility and reuse that is the promise of a well done SOA.

For this discussion I will build on the terminology defined in the post entitled “Anatomy of a Service Oriented Architecture”.  I will also use 2 simplified application examples to illustrate some of the pitfalls.

So here is our base example.  Imagine that you need to build  a very simplified Point of Sale System.  It needs to be able to log people in, update customer records and perform a transaction, including updating inventory.  For the sake of argument, I will propose it should look something like this (not 100% accurate but best I could do in 20 minutes).  Sorry the pictures are a bit hard to read.  I need to change templates to get something wider.

Furthermore, I will contend that people following a BPM centric approach to SOA are usually likely to design it like this:

and that too often with SOA design we see something like this (which is really bad)

So lets look at these starting from the bottom one which, sad to say represents about 75+% of “SOA” implementations I tend to see.

Point of Sale – Badly Done Case:
This last example is what you get when people decide they need to be SOA, but frankly have no idea how to decompose a problem or do component based design.  It is also what you get when people decide SOA means you just slap a web service interface onto a monolithic legacy app so you can call it SOA to please senior management who have heard all the buzz, and decided they just have to have an SOA by next week to save cost, etc.  This approach buys the company absolutely nothing and in fact only slows down the performance of the existing system and certainly provides no flexibility and reuse at all.

Point of Sale BPM Centric Case:
In the BPM case we will have identified our main processes:

1. Customer Lookups, etc
2. Authenticating a User
3. Processing a Transaction

We would then set about to design service interfaces which align to those and they would look something like this:

1. Customer Service:

1.1 Create Customer
1.2 Update Customer
1.3 Lookup Customer
2. Authentication:

2.1 Create User
2.1 Update User
2.3 Delete User
2.4 Login
3. Transaction:

3.1 Record Transaction
3.2 Void Transaction

Each of those service interfaces more often than not end up being tightly coupled to a back end database which exposes stored procedures which are also tightly aligned to those process services. Its basically a client server design behind the service interfaces, and while I drew them as 3 separate databases supporting each service,  more often then not I will see no decoupling under the covers and it will be one big database.
Now, in this case we have a better design (but still not good) which shows some process orientation and some componentization. This design will offer some reuse, albeit limited.  In addition this system will suffer from some data duplication (consider Paul Michaud as User and Paul Michaud as Customer.  This design would store the records twice for Paul Michaud) which is not desirable in a good SOA.

Point of Sale – Layered Case:
I will contend that this design is optimal (or at least as optimal as I could draw in 20 minutes).  It provides for the same level of BPM support,  but does not require any data duplication and allows for the maximum reuse.  I am not going to go into details on how one would come up with this design in this post but I will come back to that in another post soon.

To prove the point, lets now consider the need to create a second application to do simple contact management.  We would ideally like to reuse our SOA and layer the new application on top of what we already built.  I will contend that for this second application only the layered design would offer any reusable components for this second application.  I will propose the following simple design for the Contact Management Application using SOA.

Contact Management:

Notice that we are using the party service not a Customer Service or anything else.  A contact may be a Company, Organization, Church, Personal friend, etc.  If we had only build Customer Services as in design 2 & 3, which is what the BPM approach would have identified we would not have had a foundation on which to build this second application (unless that second application was very similar to the first one).

Anyhow,  the point is that by focusing on the process we usually fail to identify the necessary Foundation Services or the Fundamental Data Objects on which the SOA should be operating.  I will elaborate on this further in a later post.

As always feel free to leave comments here or on Twitter.com (@techmusings).