Saturday, December 16, 2000, 1:00 pm 
[Follows 10:00 am to noon CPCUG presentation: ColdFusion: Local Resources] 

From Vision to Product:
Technical Architecture and Building Your Core Technology Team
Speaker: Vince Sabio, Chief Technology Officer of Return Path, Inc., and technical advisor to Topica.com, NetCreations.com, and Lyris Technologies, Inc. 

One of the most significant challenges facing any early-stage startup is the definition of the technical architecture. Finding the right technical leadership, selecting the most appropriate technologies, defining the top-level architecture, and building the core technical team are the first key steps toward launching a successful product.

Even the best business plan can be thwarted by the lack of a suitable technical foundation upon which to build the business. In this talk, we will discuss the process of guiding a company from initial business plan through a successful launch, including a complete technical architecture and building of the core development team. We will also cover the less tangible aspects of technical leadership, such as the role of the technical team when working with the rest of the company, and the issues that can arise in a hybrid techie/non-techie environment.

NOTE--Speaker Vince Sabio will mold his presentation to meet the interests and needs of meeting attendees. This is your chance to pick his brain. Read the presentation background information and formulate your questions--Vince will welcome questions on any of the topics outlined. And Vince will continue the dialog with us at a late lunch at a local eatery following the meeting.

Presentation Background | Speaker Information | Meeting Agenda | Location | RSVP

Defining the Core Services, Requirements, and Top-Level Architecture 

Many startups begin with an idea ("We will sell pet food over the 'Net"), but then fail to define the technical side of the business.

Step 1. Decide what your core services will be, and how they will be delivered to your customers. The question might seem obvious, but there are many hidden "gotchas" that can trip up an otherwise solid business idea. 

Step 2. Define the requirements for delivering those core services. Will you be accepting credit card transactions on your Web site? Do you need secure socket layer (SSL)? Will you be sending e-mail confirmations? An e-business is typically more than just a Web server. Failure to understand and properly engineer an end-to-end system has led to the failure of many startups. 

Step 3. Build a complete top-level architecture for the system. Based on the core services and requirements, what are the key functional modules for the system? What are the interface requirements between those modules? How much data will they have to process? Properly defining the top-level architecture will eliminate many potential surprises down the road. 

Defining the System 

Once the top-level work has been completed, the component-level requirements can be defined. 

Step 1. Estimate the database size and transaction rate. Ideally, these will grow over time, so that growth must be taken into consideration. If the initial estimates are too high, then the system will be over-engineered, costly, and will probably require a greater lead time to launch. If the estimates are too low, then the site will be slow, will not scale well, and could even be completely dysfunctional. 

Step 2. Define minimum requirements for scalability, reliability, availability, and security. Scalability estimates will be based, in part, on the database estimates in step 1. Reliability and availability will define, for example, the level of redundancy that you build into the system; the operating system platform(s) for the system; the number of servers, and server types and sizes; and whether you will need to co-locate the system at a hosting service. 

Step 3. Develop a functional block diagram and complete logical flow through the system. This will help to crystallize the module definitions, and will permit an accurate assessment of the time and personnel required for development. 

All these decisions must be made within the financial constraints of the company. Failing to adequately define requirements within the available resources will put the company at risk of an early failure. Conversely, underestimating the system can lead to an inability to serve customers, which can have similarly disastrous results. 

Building the Team 

One very important question that must be asked at this point is whether the job will be done in-house or contracted. In the simplest sense, the tradeoffs for this decision are as follows-- 

• Outsourcing is generally faster, more expensive, and leaves you without any in-house development expertise. It is thus usually reserved for projects that do not require a great deal of ongoing development, or for companies that are located in places where hiring the appropriate technical team is difficult. 
• In-house development requires building a technical team, a time-intensive process that can delay launch. Team members are not always hired in the ideal order for development--though this problem can often be mitigated if the company can afford to begin the hiring process sufficiently early. There are also office space, capital expenditures, and day-to-day management issues. At launch, however, there is a fully trained team on board, and further development can proceed relatively smoothly. 
• A hybrid approach is often a good compromise. An outsourced firm can be used to initiate development, and then "rolled off" the job as in-house developers are hired. This needs to be made clear to the contractor from the start, often resulting in a much higher price tag.

IMPORTANT NOTE: Speaker Vince Sabio does not recommend waiting until this point to begin building the team. In fact, what appears to be a serial engineering process is actually highly parallel, and even somewhat iterative--but this is the logical point at which the entire team can be defined. 

Step 1. Do a complete, top-down definition of the skills mix that will be required to complete development. Skills can be grouped: for example, looking for a C and PERL developer, or a C++ and Java developer can make sense. But looking for an Oracle and C++ developer will probably be a long shot, requiring premium payment for this skills mix, and making the entire company dependent on this one person. 

Step 2. Decide how you will do the recruiting--outside agency, in-house, or both. Doing both will usually maximize the chance of finding the right people. Will you use retained search or contingency? Again, doing both will usually maximize success. Remember that the first few hires will define the atmosphere for the rest of the company; it is usually a bad idea to settle for someone who isn't quite what you're looking for simply because the timelines are getting short. 

Step 3. Turn a group of developers into a close-knit development machine. Outside observers would think the team had been together for years. Unfortunately, this is akin (and, not coincidentally) to raising a child--it sounds easy enough, but is truly a significant undertaking requiring a great deal of understanding and dedication. 

Building the Product 

Remember, our goal here is to build and launch a product--we must not lose sight of that. Unfortunately, many technical teams do lose sight of that goal, and either never launch, or continue to delay indefinitely. 

Step 1. Define a reasonable development timeline, bearing in mind the skills mix and experience of the team. Do not make the schedule aggressive, or you will fail to meet it. One very good approach is to define the development time required at the component level, then roll it up into an end-to-end development schedule, bearing in mind that there are multiple developers, and that some projects can proceed in parallel. 

Step 2. Schedule regular technical meetings to ensure that issues are being voiced. Ensure accountability against the development timeline, at the component level and at the system level. 

Step 3. Put the system through quality assurance (QA) testing. Using a dedicated QA team or outsourced QA contractor is ideal. Having developers do their own QA is a recipe for disaster. (Not so much because of a conflict of interest, as one might guess, but mostly because the assumptions made in development will just naturally be the assumptions made in QA. A "fresh perspective" is required for truly effective QA.) 

Different developers use different terms for "alpha," "beta," and "launch." The definitions Vince Sabio uses (and recommends) are--

• Alpha Development: Development of new functionality occurs; pre-QA, no bug fixes. 
• Beta Development: All new functionality has been implemented; product enters QA and bug-fix cycle. No new functionality is added at this point! (This is a very important point, and many developers and product managers fail to understand the significance of it--until they have deployed a buggy product.) 
• Launch: General availability of the system to customers.

Keep this phase short, as Version 2 is right around the corner . . . 

Presentation Background | Speaker Information | Meeting Agenda | Location | RSVP

Vince was with Science Applications International for more than 2 years and with the Department of Defense for 14 years. He was the technical lead for the Network Cloaking System, a novel network-security protocol with U.S. and international patents pending and current development funded by the U.S. Government. 

Vince Sabio earned his BSEE/MSEE from the University of Maryland. He also founded the Clio Listmom Cartel, a site for publicly accessible mailing lists. Vince Sabio is also moderator of HumourNet: "Anyone Without a Sense of Humor Is at the Mercy of the Rest of Us!"

Join us for this meeting, guaranteed to mix fun with information you can use. 

Vince Sabio may be reached at vsabio@vjs.org.

Presentation Background | Speaker Information | Meeting Agenda | Location | RSVP

Agenda
1:00 pm    Welcome
1:05 pm    Accounting Tips/Tax Updates, Jina Etienne, CPA
1:15 pm    From Vision to Product: Technical Architecture and Building Your Core Technology Team, Vince Sabio
2:40 pm    Q&A
2:55 pm    Closing announcements
3:00 pm    Informal queries, conversation, networking
Later        Late lunch/networking/socializing with Vince Sabio at local (Bethesda, MD) eatery (all pay for own selections)

Presentation Background | Speaker Information | Meeting Agenda | Location | RSVP

Free Parking: There's construction underway at NIH, so try to arrive a little early. (There are traffic police on the NIH campus--observe the signs--speeding or rolling through stop signs, for example, can result in tickets.)  You may park in the inside parking garage of Building 10. Enter from Memorial Drive and park on the P3 level. Watch for and observe the signs, including those about types of cars permitted in
certain spaces (such as "handicapped" driver and "small compact" only.) Tell any parking attendant you are attending a CPCUG event (there will be no charge). You may also park in the many outdoor parking lots.

Metro--Medical Center Stop on the Red Line (about 3 blocks across the NIH campus) 

Free (any door prizes are usually for CPCUG members only) 

RSVP: Not required to attend, but if possible, please RSVP via e-mail to bconn@cpcug.org. (Sometimes we have handouts, giveaways, or both, and try to have enough for everyone.)

November 22, 2000