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?
- 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 · 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 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
- 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 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 technologys 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.