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?
- 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 the web logs 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 do we need to 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 end points, 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.
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 a different hardware?
- Interoperability: Does this component work with other hardware and/or software?
- Scalability: Can this component handle increasing work load 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?
Unfortunately, vendor promises aside, given current options, one cannot “maximize” all of 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 of the issues and analysis 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 which 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
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 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 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 technology personnel and teams to our clients. We would be wasting precious money, time and energy building a capability in applications 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 weapon and creates an entry barrier for competitors. Can we trust an outsource partner with this capability?
- Complexity: Can an outsource partner create the design of an absolutely new concept that we are discovering as we go?
Who should we outsource this to?
- Cost was a factor as we did not have a lot of 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 integration of 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 with access to the US market. Additionally, splitting the implementation between firms made the task of putting together the puzzle harder!
Identify infrastructure options:
Since we were a startup, legacy infrastructure issues did not complicate our decisions. However, we were faced with a very risky decision without the benefit of legacy learning!
Hardware: We needed to balance the capability, price, 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.
A good infrastructure is critical to the success of an e-Business. Infrastructure must be viewed as 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.