My biases were that in-house software development was perfectly appropriate (and perhaps even an advantage) for small to medium businesses.  After all, the SMB market usually didn’t suffer from the big bureaucratic SDLC that seemed to turn any development project into a 3 year initiative that would be outdated before ever going into production.  These organizations could leverage the latest tools, frameworks, and platforms to build whiz-bang applications that would be light years ahead of larger competitors.

While to a certain extent this remains true, my personal experience had led me to a different conclusion.  You see, in-house, custom applications are almost always built to a set of specifications that match the requirements of the business at a point in time.  While these applications may be state of the art in terms of user interface, programming models, etc. they are rarely designed with the same level of abstraction that is typical of a COTS solution.  Why? Economics.  There is obviously pressure to include as many features as possible during the development process.  Rarely is the time allocated to build in the configuration capabilities to evolve the application seamlessly with dramatic changes in the business.

This kind of capability takes significant investment, the magnitude of which the SMB can rarely afford or justify.  Consider the effort required in building a data backed web form.  Even with nifty component based frameworks like JSP or Spring+JSTL or Flex, developers are typically binding hardcoded object properties or fields with hand designed UI layouts.   Now consider how much more effort is required to build a layer of abstraction that allows forms to be generated or updated based upon meta data changes.  Don’t forget the validation and form processing logic!

The justification for a development effort has to consider the revenue and cost savings.  Unless the SMB is willing to sell the product to other potential competitors, it is difficult to rationalize the investment required to build a level of abstraction such as this throughout the application.  Good COTS must have this level of abstraction as it is the ONLY way they can sell the software to more than one customer.

Since these features are rarely incorporated, the SMB commonly finds itself in a position of weakness after a few curves in business plan.  Incremental “quick fixes” become the norm until one day the application starts fighting against the business model.  Changes start to feel “awkward”.  Data elements appear in contexts that don’t seem to make sense.  Code complexity starts to spiral until one day everyone acknowledges that the application is crap and we need to build a new one.  Of course, this usually occurs well before the payback is achieved.

This leads to an even greater risk to the SMB: the loss of key employee.  Because the SMB development staff is small or even outsourced, the ability to make changes reliably begins to rest in the hands of one or two surviving developers.  Not only does this hamstring effectiveness, it also exposes the SMB to a great deal of business risk in the event of a departure, retirement, etc.

When does in-house development make sense for a SMB?  Obviously, if the business model is so specific that no COTS exists in the marketplace, the SMB has no choice but to turn to in-house custom development.  Another reason for doing in-house development is when a co-founder or key stakeholder is the primary architect and technical resource in the company.    In this case, there MAY be a certain degree of confidence that continuity will exist at least through a liquidity event.  If the key stakeholder is a passionate technician and keeps the software model in lock step with the inevitable changes in the business model, this strategy may end up becoming a real advantage.

It is always difficult to look at software license costs or maintenance fees and not be tempted to “build it yourself”.  However, be careful in considering the risks that this path will surface over the long run.

However, as IT strategists we must also recognize the benefits of layering when it comes to looking across applications.  After all, most organizations (including Storeroom Solutions) rely upon a large number of applications to perform its responsibilities.  Most of these applications were assembled over the years based upon the requirements and business strategy at that time.  Rarely do enterprises have the opportunity to build everything at once (oh my, how I miss the dot-com days when it seemed everything was green field).  The same way layering within an application can improve modularity and maintainability, layering of applications can increase business flexibility without spiraling increases in complexity and cost.

Say, for example, a service provider offers an application that it has developed over the years to perform procurement and inventory management functions for clients.  It has proven to be a real competitive advantage, especially for those seeking a turn-key solution.  The application has also proven to be relatively low maintenance and trouble free.  It looks like this:

Alas,  times change and the number of new clients seeking a turn-key solution starts to dwindle.  Fortunately, the company has developed some real expertise in its procurement capabilities that are attractive to an entirely new segment of the market.  This segment already owns an inventory management application but wishes to tap into the advanced procurement features offered in this application.  The company is faced with a challenge.  Because application layering wasn’t considered in the original design, separating the functionality is a problem.  In order to overcome these challenges, the company must aggressively re-factor its procurement/purchasing functions to allow inputs from a source other than its embedded inventory application.  In fact, it may be easier to re-write the procurement application, leveraging the existing business rules. The new application topology may look something like this:

What is this advantage of this approach? In this case, this application layering approach allows for new business opportunities that would have otherwise been difficult to serve.  Furthermore, by employing SOA concepts and maintaining a disciplined API in its procurement application, the company can keep maintenance manageable.  After all, its internal inventory application could use the same API as the external inventory application to communicate!

Downsides? It is is easy to gloss over the downsides but they are rarely greater than the benefits of moving to this layered application approach.  One practical downside is the complexity that could be introduced to some users due to the new architecture.  For example, if users were accustomed to a single application with an identical look and feel they may be exposed to a little more variation due to the new modular approach.  However, even this can be managed through Single Sign On technology and common libraries and standards between the teams responsible for maintain their respective applications.

While this approach may seem to be a “no-brainer”, I continue to encounter architectures where little, if any, emphasis is placed on “application layering”.  Hopefully, more architects and CIO/CTO’s will start to place greater value on the benefits of this approach.

Regardless of the size of the organization, I have observed 2 qualities that significantly increase the likelihood of success: focus and discipline.  Others may say “operational excellence” or “people” are the biggest factors in driving success, however my experience suggests these attributes are by-products of focus and discipline or, at the least, difficult to achieve when there is a lack of focus.

Some of the basics I learned at Columbia Business School related to the fundamental discipline of market strategy, often hammered home via writings from Harvard’s Michael Porter.  It goes something like this:

1. Identify (and validate) a market need for a product or service
2. Assemble a set of products and services that specifically address these needs
3. Attack the market with unwavering discipline and focus
4. After you’ve had a chance to assess the prospects for long term success, re-evaluate and repeat

Unfortunately, most companies skip step 3 or, at the least, compress this cycle into a [almost] daily activity.  Usually, the temptation of a prospect with deep pockets or some other distraction will divert the focus of the organization while it branches out into a self-rationalized engagement.  Meanwhile, resources of the organization are re-directed away from the original focus, watering down the ability of the organization to deliver best in class products and services to that segment.  Unfortunately, saying “no” takes discipline and far too many CEO’s lack this quality in today’s short term world.

Of course, at some point you have to evaluate step 4 above and ask if you are on the right path.  However, this should be a rigorous process executed with the implication that a change in course requires a significant investment over an extended period of time.  This evaluation shouldn’t occur at weekly staff meetings or in response to a sales prospect that appears on the radar screen and wants something “a little different” than what you offer.  If the sales prospect is too large to be ignored, then the organization should decide at that time if this new offering is the better way to move forward and re-channel its energy in this direction.  Again, if this is done too often, employees will become confused and frustrated and you’ll have little change of actually developing any intellectual property or expertise.

When we started Kemper Auto and Home in 1996, as a direct marketing subsidiary of Kemper Insurance, we were certain that direct mail was the way to go.  After all, that is what we knew and it seemed like a reasonable model if we could keep expenses down.  Unfortunately, we learned within the first few months that times were changing and our assumptions regarding response rate were way off.  We executed step number 4 at that time and decided to focus on the internet.  We invested heavily in the web site, hitting remote rating servers, real-time communication with underwriting agencies, etc.  Within 2 years we became one of the leading providers of auto insurance on the web (through relationships with portals such as Insweb).  We did a nice job of adjusting course and focusing our energy.

However, we didn’t follow this formula about 2 years later.  We allowed the prospect of writing a big chunk of business through an airline carrier affinity relationship to divert our attention.  We weren’t in the affinity insurance business (a completely different underwriting and pricing model) and we got burned.  We lost focus.  It almost brought the company to its knees.  Fortunately, we were able to scramble to get out of the relationship and re-direct the resources back to the internet business before it was too late.  But it set us way back in our plan and schedule.

This experience had a profound re-enforcing impact on my academic learning.  Unfortunately, I see it occur over and over.

Yesterday we learned that U.S. GDP shrank at a rate of 6.1% in the 1st quarter of 2009.  This follows a 6.3% decline in the 4th quarter of 2008 and marks the first time since the 1974-75 recession that we saw 3 consecutive quarters of negative GDP growth.  Things seem bad all around.  

As leaders during this turbulent time it is important to remain focused on the end goal and not become distracted by the “radiation” of the economic slowdown.  Sure, dips in revenue make it difficult to imagine launching that new infrastructure project or hiring that new employee.  However, while most are hunkered down or retreating in a futile attempt to meet short term budget or executive compensation goals, long range thinkers see this as an opportunity.  

Rather than running for the hills, we should be utilizing this opportunity to cut the fat from the organization and reallocate those resources on projects and personnel that will prepare your organization to capitalize on the eventual turn in the market.  It will happen, trust me.  Someone else in your industry will be thinking this way.  If it isn’t you, you’ll become a dinosaur or at least seriously left behind.

As technology executives, we shouldn’t be afraid to let our CEO’s know when we think we are looking in the rear view mirror rather than through the binoculars at the distant horizon.  Be proactive in suggesting appropriate savings opportunities, while simultaneous revisiting the CBA (Cost-Benefit-Analysis) for the most promising projects.  Be a champion for these initiatives.