e-Business Infrastructure

Learn how to envision, build, and deploy an e-Business Infrastructure that supports your e-business' model.

Introduction:

Last week we discussed the role of e-Business in shaping the business model of organizations. Our focus was on the value proposition of e-Business or, in other words, the "promise". The "delivery" against that promise is enabled by the technology infrastructure - data, applications, and technology/tools.

This week we will introduce and discuss the decisions surrounding e-Business Infrastructure:

• How are infrastructure decisions related to business goals and strategies?
• What are the key features of the infrastructure?
• What is the appropriate application architecture?
• What toolset should we use to build/maintain the infrastructure?
  • Hardware: Generic versus Branded? Configuration? No. of processors? Size?
  • Hosting: In-house or outsourced?
  • Operating System: Microsoft versus Linux?
  • Web Host/Engine: IIS versus Apache versus Web Sphere?
  • Application Engine: Should we use one, BEA for example?
  • Browser Compatibility: IE versus Netscape? Which versions?
  • Integration: How will we integrate with legacy applications?
  • Security: Who has access and to what? How do we secure access to our network, data?
  • Personalization: Should we use cookies or other means?
• Operations: Keeping the site up; maintenance: when is it up or down?
• Should we build a custom application or implement a package?
• Should we build/maintain or buy some or the entire infrastructure?
• Should we operate some or the entire infrastructure?
• How can weblogs help us make better decisions?

The big picture:

Even the best strategy does not amount to much if not enabled by successful execution. We have all heard (and experienced?) horror stories of "pies-in-the-sky" strategies that just cannot be implemented or implemented profitably. Assuming that our strategy is sound, i.e., we did our work last week, what must we do to make our execution successful?

Building a technology capability must not follow a sequential path with implementation following strategy. Robust technology capability, especially in the internet space, is built iteratively. There are no endpoints, only milestones in a perpetual process of doing and learning. There are no "hand-offs" between strategy/business and technology. There is only one team, comprised of competencies - from strategy to technology. The "team" works together from start to finish. It succeeds or fails as a whole.

Consequently, infrastructure implementation steps in the loop are:

• An assessment of the technology requirements
• Vendor and tools selection
• Building/implementing the solution.
• Operations
• Maintenance

Although operations, chronologically, come after the solution is built, one must consider the implications upfront. Infrastructure capability has key elements, such as:

• Portability: Can this component be run on different hardware?
• Interoperability: Does this component work with other hardware and/or software?
• Scalability: Can this component handle increasing workload such as more users or run time?
• Maintainability: How often does this component require service? How often does it break (MTBF)? Once broken, how easy is it to fix (MTTR)?
• Security: What are the assets we are trying to protect? Who are we trying to protect them from? How can they be compromised? What is the maximum possible loss? How can we mitigate this risk?
• Etc.

Unfortunately, vendor promises aside, given current options, one cannot "maximize" all of the elements, especially when we throw cost in the mix. Consequently, infrastructure decisions try to "optimize" capability by balancing the trade-offs associated with these elements. Through my experience, I want to highlight some issues and analyses related to e-Business infrastructure decisions.

In particular, I will leverage the following: VirtualPrimeVendor.com: In 1996, I Co-founded and managed an e-business that created a "virtual" organization to roll up the $45b, highly fragmented, IT contracting marketplace. This unique business model used key elements of strategic sourcing, value-based partnerships, B2B exchanges, web-enabled processes, and supply chain integration to create value for key stakeholders. We folded operations in 2001.

Know your business drivers:

Before a single infrastructure decision is made, one must understand the industry and the existing model, strategy, processes, organization, etc. Knowing that the most efficient Prime Vendor had an SG&A of 19% and could not disintermediate their sales force without killing their business gave our business model credence and the infrastructure drivers. Our business model was to make money on high volumes and low margins. Specifically, our business had to: · Automate all processes · Push the manual functions to the user; · Support thousands of end-to-end transactions a day · Connect to suppliers and customer systems · Provide workflow features · Etc. Identify infrastructure implications: Given these business requirements, our infrastructure had to:

• Have web-enabled applications for order entry, inventory, financials, etc.
• Ease of use for the uninitiated to super users; operate on different browsers and versions, security settings, etc.
• Scale from the smallest to the largest customer
• Interoperate with different protocols, platforms, and applications
• Provide and Integrate workflow with the applications

As you can tell, this affected the entire infrastructure, from hardware to software and networks. In the case of an existing business, this is further complicated because of the existing infrastructure. Identify infrastructure capability: Which one of these things can we do ourselves? Our business model provided the guidance:

• We were in the business of providing competent technical personnel and teams to our clients. We would be wasting precious money, time, and energy building a capability in application development.
• Since we were a startup, we did not want to take on a lot of full-time employees.
• We could not possibly get all processes automated in a reasonable amount of time; We had to buy off-the-shelf applications and components.

Which should we outsource?

• Security/Trust: Design and integration is a potential competitive weapons and create an entry barrier for competitors. Can we trust an outsource partner with this capability?
• Complexity: Can an outsource partner create the design of a new concept that we are discovering as we go?

Who should we outsource this to?

• The cost was a factor, as we did not have much money to burn on infrastructure.
• Who can build such as complex application in time?
• Since this is the core of our infrastructure, we need to build a very strong, mutually beneficial relationship with the vendor.

Consequently, we decided to design and integrate the application internally and outsource the building of components to firms in India and Ukraine. They balanced our need for cost, complexity, and speed, and we provided them access to the US market. Additionally, splitting the implementation between firms made putting together the puzzle harder!

Identify infrastructure options:

Since we were a startup, legacy infrastructure issues did not complicate our decisions. However, we faced a very risky decision without the benefit of legacy learning!

Application Architecture:

The key consideration was splitting the functionality between the layers.

• Should the application be client or server heavy?
• Should we have an application processing layer separate from the data layer?
• Should we use cookies for security and personalization?

We ran into a lot of browser compatibility issues. Consequently, we had all the functionality slit between an application and a data/web host. The client just displayed information and did not use any scripts. We used style sheets to solve the compatibility issues with the different browsers.

Hardware:

We needed to balance the capability, price, and availability with the cost of operations. We decided to buy and co-locate our hardware at a hosting company. This gave us the benefit of getting the hardware of our choice, depreciating assets, and 24x7 monitoring at a variable cost. Software: We had to balance a database that could scale from the smallest to the largest at a reasonable price.

The other factors which influenced our decision were: Component interoperability, compatibility with Internet Explorer (70% market share!), ease of development, availability of talent, future support and growth, etc. Microsoft Visual Studio toolset met all these needs.

Build the applications:

We had a choice of methodologies and toolsets. Our past experience has proven the benefits of:

• Object Oriented Methodology as being superior from concept to implementation. Additionally, the availability of people well-versed in this also affected our decision.
• Joint application development: The business users and developers worked as a team, and there were no hand-offs nor separate success factors.
• Iterative development: A prototype was built and reworked till the team was in agreement

Deploy the infrastructure:

We did not build the entire functionality before launch. Through research and discussions, we arrived at a release schedule that built high-value components first and got the business in motion. Those revenues paid for subsequent development. We like to think of this as the "self-financing" model of building and deployment. Big bangs are rarely, if ever, successful.

Summary:

A good infrastructure is critical to the success of an e-Business. Infrastructure must be considered part of the overall picture, not a stand-alone component. It must be tightly coupled with all other components, such as strategy, processes, and organization. However, infrastructure decisions are sometimes taken in isolation. That results in "technology for technology’s sake". The best hardware or software is often not the best for every situation. Much like Rolls Royce might not be the "best" car for a farmer in Idaho. Business requirements should drive infrastructure selection. A complete and thorough analysis that weighs in key factors such as portability, scalability, existing skills, future direction, and cost should result in an infrastructure that is the "best" one for that situation.