Amazon has targeted the mobile application space with the creation of it’s own Amazon Marketplace, has locked in some exclusive deals with android application developers to move profits out of Google and into Amazon, and it now might be creating it’s own tablet device that will squarely point users directly back to Amazon.

Amazon is clearly signaling it’s intentions that might as well be considered a nuclear first strike, so how will Google respond?

To win a fight you have to first admit you are in one

Google has a limited opportunity to successfully apply some high impact tactics to take control of the fight. They could for instance court the developers by dropping  the market fees dramatically, creating a better QA filter on the Market, do a much better and more transparent job of promotion for top quality applications etc. in other words address all of the concerns that developers have.

They could make the Google Android Marketplace the most lucrative place for developers to deploy to, making those developers that made exclusive deals with Amazon wish they had never signed on the dotted line. That would be a painful experience for Google perhaps but I suspect not as painful as a later stage fight.

If on the other hand Google dismisses the threat and simply sits back and watches then all things being equal developers will deploy to any and all market platforms without prejudice, and that means Amazon will probably win or at least tie which is about the same.  You might think that Google would be highly tuned into this but there are hundreds of cases where the giant sits back and yawns while Jack raids the place.

So while it seems unlikely there are precedents for Amazon to win vs. the owner of the platform.

Hearts and Minds

Amazon has something that the Android  Market doesn’t.  Namely a few hundred million users that love it’s single point of contact, trusted,  high quality brand.  Amazons users (just not the kindle owners ) can be cross promoted and more importantly these people are used to paying for things vs. just getting them for free.

Savvy developers will quickly figure out which market pays more and try and move their user base to that market. Developers care about market penetration or profits dependent on their own strategy’s. Which means that they prioritize by a few simple metrics

1. Total Customers  Which market Sells / Downloads much of my Apps
2. The Math               Which market has the better profit sharing deal
3. Air Time                  Are my applications getting a fair shot in front of users

While consumers make the final decisions both of these companies should take a page from Microsoft’s success and realize that Developers and Customers are in a symbiotic relationship, without one the other is useless. You have to keep both sides of the pipe happy to make that lucrative brokerage grow.

If I had to guess I would say that Google will be slow to respond because they won’t take this as seriously as they should, which will give Amazon some time to make this all happen. Once Google finally realizes it’s in a real fight they will start swinging wildly and Amazon will be ready and take things up a notch.  Apple of course will sit back and reap the rewards if that happens.

Market Wars, Map Wars, Device Wars, Social Wars, it almost feels like 1995 again …

In Part 3 I will give an overview of the new Android Marketplace initiative that addresses a few of the key shortcomings of the current market that was presented at Google IO 2011

Technology Musings - Thoughts about Technology and Startup's Android – Rise of the Amazon Marketplace, Part 2

War and Pieces

Welcome to the android  marketplace wars.  The opening salvo by Amazon was in first creating it’s own Marketplace for android applications, and then grabbing some high profile applications exclusively for the Amazon Marketplace for Android.

That’s only half the equation though because most Android devices have the Google Android Market pre-installed which gives it some advantages

• Trust                  If it came with the device it must be ok
• Access              If access is easy and it’s not broken most users will just use what’s on the device
• Interest            The typical user might not even know or care that there is another way to purchase applications

Amazon had to have realized that kindle has a limited lifetime and their “no-glare” commercials fall flat from a potential iPad users perspective. It’s also apparent that a single use device may have minor benefits but it’s hard to rationalize carrying around 3 or 4 devices just on the chance that you might be reading in bright sunlight.

So the latest rumor has it that they will be developing their own Android tablet, quite honestly I am surprised it took this long. One can hope that after all that TV commercial time the device will arrive with an anti-glare screen

The real story here is that selling applications will be analogous to selling books in regards to profitability and you can bet they want in on that game, so what will it take to for Amazon to hit a home run?

• Produce a fairly killer device in terms of price and feature set (and for goodness don’t cheap out and forget the GPS!)
• Pre-populate the device with great applications, even if they have to build them internally or contract out for them
• Incent developers to publish there vs. the Android Market
• Do a better job of QA on applications than the Android Market has to date. 10,000 usable apps beats 100,000 crappy ones any day

A fight between Amazon and Google over how to do a proper market will be a good thing for everyone in the end because competition always is, but in the short term Google and Amazon should take care not to allow this to produce even more fragmentation. Doing so will inevitably let the iPad continue to solidify it’s hold in this space and that won’t help either company.

Guerrilla Tactics

In some ways Amazon is the underdog in this and can play the role of the Guerilla fighter by using Androids open source stance against any power plays Google might use to control it’s efforts to be the dominant market place. On top of this since Google doesn’t actually have it’s own tablet and bringing one out might potentially alienates it’s partners, in other words Google is in a fairly fixed position while amazon is free to maneuverer.

It’s true that Google owns the platform and has apparently brought a lot of pressure on partners in the past and undoubtedly will do the same with Amazon. This is somewhat of a paper tiger though because as mentioned If they push too hard in that regard they will get a lot of open source backlash.

Amazon is probably betting on a limited response from Google for a number of reasons and they are probably right, so the question becomes can Amazon produce a superior device?

One of the reasons I think they can is because I know Jon McCormack who is the VP of software for Kindle. I haven’t asked if this is his project, and he would not comment if it was but I know he has enough experience developing this type of thing to succeed.

Jon was at Liberate ( The failed Google TV of the dot.bomb ) where the team did some great things that were never seen because I was there with him. He is not the only guy that could do this but he has a lot of notches in his device belt so I know without a doubt that if he is the guy in charge that he could pull this off.

The only question I have is whether Amazons kindle DNA will get in the way of producing a truly useable all around product that appeals to users outside the book reader category, that though has more to do with politics than technology or design savvy.

The only real question is will Google ignore it, put down the rebellion quickly, or perhaps try and come up with a mutually beneficial scenario?

Let’s take a look at that in Part 2

Technology Musings - Thoughts about Technology and Startup's Android – Rise of the Amazon Marketplace, Part 1

So completeness can mean a lot of different things.  In this case I am going to define a piece of data as being complete if the description of the data contains all of the available information about the item in question and if that description is captured in a manner which represents a true representation of that object in a context neutral manner.  In my experience,  this is the single biggest cause of the data issues in the enterprise.  In fact if this was done well the issues listed in the first article of this series would be much less likely to occur.

To read the complete article, you can find it on the Nebility Blog.

As always, you can reach me through the comments, at Nebility, on Twitter, LinkedIn or by using the Ask the Experts form.

Technology Musings - Thoughts about Technology and Startup's Real Life Issues With Big Data In The Enterprise – The Issues With Data Completeness

Large Enterprises face huge challenges when dealing with their Big Data.  In this article I am going to outline some of the common challenges with Big Data I see firms dealing with on a day to day basis.  This is a continuation of the discussion that was started in the article titled “The Challenges of Dealing With Big Data”.

In the previous article we discussed how a lot of firms and discussions, in and out of the press, are focused on how to analyze and gain insight from Big Data (whether it be on Twitter or in the traditional Enterprise).  Furthermore, I outlined how, in my personal experience, the root of the true problems with big data are often not in how or what tools we use to analyze the data, but more so in how we capture, or fail to capture it in the first place.  In essence, our failure to capture the data accurately and consistently often renders analysis of it a meaningless exercise due to the Garbage In = Garbage Out (GIGO) principle.  To make this issue more clear, I am going to provide some real world examples of some of the Big Data issues I come across with my clients on a regular basis.  Unfortunately, as I started writing this it was getting more than a bit long so I have broken it into three shorter posts of which this is the first one.

The full article can be found on the Nebility Blog.

As always, you can reach me through the comments, at Nebility, on Twitter, LinkedIn or by using the Ask the Experts form.

Technology Musings - Thoughts about Technology and Startup's Real Life Issues With Big Data In The Enterprise – The Issues With Data Consistency (Or Lack Thereof)

Big Data poses many challenges to those firms who have to deal with it on a regular basis.  On the flip side,  those who do it well and can use it to feed their analysis and gain insights into their business, customers and market trends will reap huge rewards for their efforts.

I have just posted an article which will most likely be the start of a series on this topic over on the Nebility Blog.  The article was inspired by Semil Shah and a Twitter request (@semilshah) he made looking for people with Big Data expertise and a subsequent post he pointed me too that he had done discussing ways to create value from big data.  I would encourage you to read Semil’s thesis and the article over on Nebility.

The complete article can be found here.  Enjoy!

As always, you can reach me through the comments, at Nebility, on Twitter, LinkedIn or by using the Ask the Experts form.

Technology Musings - Thoughts about Technology and Startup's The Challenges of Dealing With Big Data

So as we relaunch the Technology Musings blog,  we have added a new feature to it called “Ask The Experts”.  You will find the link to this at the top of the Technology Musings blog.

This came about because a lot of people who read this blog have over time tracked me down through Twitter, LinkedIn, and other means in order to ask me specific question about something of interest to them or about a particular problem they have with something.  As a result we decided that we would add a simple form to the blog which would allow people to ask these questions without having to jump through hoops to get to me and my colleagues.  So we would encourage you to use it to ask your questions.  We can’t  promise to be able to answer them all but we will do our best to at least respond to every request.  Things we would expect to get through this mechanism include, but are not limited to, the following:

• Requests for a blog article on a certain topic
• Questions about something we already wrote about but that people felt were better served through a direct question instead of the comments (but we encourage you to use the comments so others can learn as well)
• Specific questions related to some challenge you may be having with a project of your own.  See note below on this one.
• Anything else you folks can come up with

Where appropriate we will try and put the answers to question into a blog post either here or on the Nebility Blog depending on the topic and how it aligns with each blog.  We will of course anonymize anything we use for a blog article and make it more general, unless you give us specific permission to use you name/case as is.

NOTE: while we will try and answer every request we receive through this “Ask the Experts” mechanism, we cannot guarantee to be able to answer everything either because we don’t know the answer, don’t have time or the question is too specific to someone’s particular system issue and requires too detailed an answer to respond quickly.  In these cases we will at least try and get back to you to let you know we can’t answer and why.

Anyhow, what we are hoping is that people will use this opportunity to ask questions about any topic in the following broad categories:

• Technology in General
• Systems Design and Architecture
• Systems Implementation
• Enterprise Data
• Large Scale Systems
• User Experience Techniques and Technologies
• Technology Startups
• request a blog article on a specific topic
• or any other question or request which may fall inside our sphere of expertise

So think of the questions you may have that we could possibly answer and start asking away.  We can’t promise to be able to answer every question that comes our way as we may not always have the time to answer every question or the expertise to answer it.  That said, we will try to at least respond to every request as soon as we can.

So go ahead and “Ask The Experts”.

As always, you can reach me through the comments, at Nebility, on Twitter, LinkedIn or by using the Ask the Experts form.

Technology Musings - Thoughts about Technology and Startup's Introducing Ask The Experts

Well looking back at the last blog post I did, it’s been over a year since I wrote it and I thought I would provide some insight into why the long hiatus.

As any of you who read my Bio here on the blog know, I had been working for IBM as Executive IT Architect for Financial Services when I wrote the last post, a role which I really enjoyed. One of the problems with the role though as it pertained to this blog was that I found myself constantly having to abandon articles out of concern about whether someone at IBM would feel it was against the official company party line. Particularly, since a number of IBM executives subscribed to this blog. Now in IBM’s defense they never gave me any grief over this blog and in fact encouraged myself and others to blog openly so this was more my choice to stop for a while in an attempt to remove any potential conflict of interest.

Another factor that made me stop blogging was the fact that I was already considering starting a new company and was being particularly careful about what I did or wrote during my employ, again to make sure I did not violate any potential IP agreements or other implied contracts. This is an area, if any of you read blogs from Venture Capitalists such as Brad Feld, Mark Suster or others, where many founders are not sufficiently careful and can get themselves and their new firm into trouble, before it even starts. So when combining these two issues I felt it was best to take a vacation from blogging until such time as any potential conflict of interest was removed.

Now is that time.

As of the end of September 2010, I have left IBM and started a new company with a couple of senior colleagues of mine, who will be introduced here over time.

The company is called Nebility and it will be focused on a couple of areas:

1. We will be designing both custom and shrink wrapped commercial software which we will offer as both stand alone and as Software as a Service (SaaS) offerings
2. We will be doing some consulting to other firms where it is focused on helping them design and build custom Service Oriented Architecture (SOA) based applications
3. We are developing an integrated library of enterprise caliber, prebuilt service components for a range of uses which acts as an accelerator for 1 & 2 and which we are calling NebulaBlocks.
4. We are also developing some very advanced, proprietary technology which will help us do items 1, 2 and 3 and which we believe provides us with a game changing competitive advantage. So for now I will remain quiet about it .

So, what does all of this mean for this blog? Well it means:

1. I will be back to blogging and this time with fewer restrictions than before.
2. We will also be starting a blog on the Nebilty web site at www.Nebility.com and will be dividing articles between the two depending on their focus. More on this to follow.
3. Some of my colleagues in this new venture will also be blogging on this site and the Nebility blog and will thus provide additional perspective reflecting our individual areas of expertise and specialization

So you may be wondering how will the two blogs TechnologyMusings.com and the Nebility.com blog be divided? While we don’t think there will be a really hard and fast rule our plan is as follows:

1. TechnologyMusings.com will cover a range of topics including discussions of technologies including our experiences as we play with new technologies that we are evaluating and using for nebility.  Technology Musings will also have material on startup issues and considerations were are deliberating as we go through this startup journey.  It will also include general rants and wide ranging discussions about whatever strikes our fancy on any given day.
2. The Nebility.com blog will attempt to focus almost exclusively on business and technology discussions,  how-to type articles at both the design and implementation level (much like I have done here on this blog in the past).  On the Nebility blog we will also discuss a lot about business and technology strategy, Service Oriented Architecture (SOA), Software as a Service (SaaS) and issues and challenges in specific application verticals we are working on.  In addition we will also cover general issues and frustrations experienced by ourselves and our customers with enterprise software and other related topics.

We will post a link to any articles which are posted on the Nebility bog, here on TechnologyMusings where appropriate, but we would encourage you to subscribe to both blogs to be sure to catch all of the articles.

In addition, you will notice that there is a new layout to the blog and some new features which we hope will allow you to reach us and interact with us better.

Well that’s about it for now.  I hope you enjoy the new articles on both blogs.

As always, you can reach me through the comments, at Nebility, on Twitter, LinkedIn or by using the Ask the Experts form.

Technology Musings - Thoughts about Technology and Startup's Back From The Dead

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 Gen Y 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)

Technology Musings - Thoughts about Technology and Startup's The New Economics of Technology Startups?

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.

Technology Musings - Thoughts about Technology and Startup's Here is my hammer. Show me your screw!

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)

Technology Musings - Thoughts about Technology and Startup's Consideration For The Technical Implementation of an SOA