CONFIDENTIAL © 2000 – iRapid - [email protected] 1 Company Positioning A Position Statement Luis Blando September 10, 2000

© 2000 – iRapid - [email protected] Slide 1CONFIDENTIAL

Company Positioning

A Position StatementLuis Blando

September 10, 2000


Outline

After Saturday’s meeting, I feel that it would help if I outline what my position with respect to iRapid’s strategy and vision is. This is a brief document that explains how I think we should approach the problem we are trying to solve. I have tried to keep legitimating tactics to a minimum, but being a personal position documents some will surely get by. For those I apologize in advance.

This entire document needs more work, and I am sure you will find holes in it. However, I am writing this in the best spirit to solidify iRapid’s foundation. Needless to say, comments are welcome, expected, and required.

Luis


Type of Sought Projects

Attracting, developing, and keeping the best people and business partners (iRapid’s Corporate Values) How?

• Good money

• Good projects

• Good colleagues

Focus on “new economy” projects

Semantics: a new economy project differs from an old economy project in that it contains an “interesting” level of complexity, uses up-to-date technology, and in general creates interest in the mind of our employees. This is entirely my personal definition to refer to software development projects that involve thinking up ahead and building down the road.

Rationale: good people like to work in good projects. Good projects (in the mind of the geeky) are those where you get to solve interesting problems using tools (preferably of your choosing). In addition, these projects are the ones that usually derive the most value-add for the clients, as they are usually more complex and involve more than embodying one (or many) already existent modules. For instance, developing a reservation system for a cruise company is a good project, changing all the “goodbyes” to “adios” in a payroll application is not.

Geeky people like to work in geeky things!!Never underestimate this,

especially if we want to treat our foreign engineers as we would a US based one


Technical Consulting

A simplified view of a consulting engagement in the “new economy” can be broken down in the following three phases:(1) Strategy: Identify the client business problem, and propose a business solution, with a potential technological embodiment. Includes branding, etc.(2) Architect: Translate the business solution into a technical embodiment. The vision for the technical solution is drawn and designed.(3) The developers and their leads implement the solution

Strategy Architect Build

“new economy” projects

(usually)

The interface between phases is usually a set of document(s). The whole point of this slide is the following: while it is possible (though not advisable) to physically decouple your team between strategy and the rest (and use a document as the interface), it is wrong to separate Architect and Build in the same fashion, as this two are very closely tied to each other. Some companies do this, and they usually fail miserably (except in the simplest of projects)

Generality of solution

Need for cohesiveness(lack of tolerance for impedance mismatch)

Rationale: the architecture phase is where most of the technical creative process happens, and therefore the need for cohesiveness between Architect and Build is much higher than between Strategy and Architect. In other words, the output of Strategy is a set of requirements, where the results of Architect are a set of (inherently under specified) blueprints. In summary, it isvery difficult to

guarantee a complete understanding between Arc. & Bld through docs.


Our Positioning (and theirs)


Tata, Prayuta, Crosslinks(a.k.a. Body Shops)

CTP, CSC, EDS, {AC, DC,many more}(a.k.a. System Integrators)

McK, BCG, Bain, others(a.k.a. Mgmt. Consulting)

Mostly independentpractices (Ravi, Luis, etc)

Zefer, Primix, Viant, Scient, AC, DC, PWC, many more(a.k.a. e-Consultancies)

iRapid

“Provide highly qualified technical people and unmatched services in all phases of

the system development lifecycle” (iRapid’s Mission)

Relentless focus on quality (iRapid’s core

values)

+ +


Scarcity and Complexity


Scarcity (today)

Complexity

Today, there’s scarcity in both Architect and Build resources. However, given the substantial different in the complexity of the two tasks (hence the skills of the people), scarcity of architects is far greater. The bottom line is that software is very difficult to build (note that we have already established the types of projects that we are attacking). In order to build software well, you need architects and developers. Architects are, by definition, scarcer than developers. The lack of proper architectural, design, and leadership skills has been traditionally and consistently the source of pain to many consulting engagements. Examples abound.

In my opinion, software is intrinsically difficult to write, and might not be completely “industrializable” or commoditizable. Maybe the “build” aspect of software development will be, but the crux of successful software solutions is not necessarily in build, but rather in design and architecture, which will essentially depend mostly on good brains. For more information about my position, review the attached reports.


The Skills Curve

Complexity

Technical Complexity Distribution

Creative Front End SysAdmin Developer Tech lead Architects

The classification shown here is somewhat simplified and intended only as an overview. The reasoning, however, is that the complexity required for design/architecture implies certain skills that might not be present in the entire population. Other disciplines require different degrees less of that particular technical competence. Notice that we are distributing the population on technical complexity ONLY.

Technical Skills Normal Population Distribution


Scaling “on the curve”


Creative Front End SysAdmin Developer Tech lead Architects In order to preserve quality, we would staff only with “true” architects… But this means that our teams should be substantial. (Please note that the staffing shown below is for the technical people ONLY. That is, there’s no QA, no front-end design, no infrastructure, no project management, nothing).

What usually happens is that projects tend to be much smaller (from the client’s $$$ perspective) and therefore you end up staffing the architect alone in one project, and maybe two teams of two tech leads in another two projects. For the latter, the architecture and quality suffer.

2.5%13.5%34%34%13.5%2.5%

Another approach is to staff the architect only during the Architect and the start of the Build phases. In this manner, you are able to satisfy more clients with good quality but your utilization rate falls because the “second” team is waiting for the architect to finish her engagement in the first project to move to this one.

The bottom line: in order to truly preserve quality for projects of interesting complexity we should only accept projects that are huge. Said in another way, our client should be willing to pay for one architect and five designers without blinking during the Architect phase. (And once again, note that this does not include any other resources –such as infrastructure, creative, GUI, etc)

4.55.2

5.1351.2

5.13

34

This is clearly not practical…But we can try another way


LESS COMPLEXCOMPLEX

Scaling with Project Mix


Creative Front End SysAdmin Developer Tech lead Architects

2.5%13.5%34%34%13.5%2.5%

Complex projects

Arch.TechLeadDev.

Less complex ones

The technical skills spectrum slides to the left as the type of projects change. Therefore, in order to attain full capacity while still preserving quality we should be cognizant of the different types of projects, the different skills, and staff accordingly.

Note that initially, at least in Argentina, we are seeking the really good people, those that could, in principle, belong to the rightmost area of the curve above. Therefore, when we position our company (EVEN INITIALLY), we need to be able to obtain AT LEAST SOME “interesting” projects in order for these early experienced employees to be properly utilized. Being cognizant of the ratio of difficult to easy projects will help select prospective clients and market appropriately, always putting our money where our mouth is (I.e. “quality”).

Needless to say, this is an oversimplified look, but I would like this type of analysis to be the driver or at least a critical input at the time of “positioning” or marketing our services, and not only blindly go for “what’s easier to sell”.


Industrialization of Design

My position here is simple: I believe that software architecture/design (for “interesting projects”) is substantially more complex than other areas where industrialization has proven successful. In other words, I believe that you need to have a person that is able to do it in her brain. Of course, there are degrees to this statement, but in the end, you need somebody to “create” a design and see it to reality, and this is ultimately not a decomposable activity on account of its inherent complexity.

…therefore, aiming at doing “design by committee”, or “comoditizing design”, is something I would not like iRapid to move towards.


Industrialization of Build

For programming, on the other hand, I do believe that industrialization (componentization of some kind) is not only achievable but desirable (and it’s happening as we speak).

…Therefore, driving towards better ways of doing this is something I believe will be essential to iRapid’s success for two reasons:

(1) Efficiencies of scale

(2) Distributed development enabler


Virtual Teams

Yes. I am for them. No, I do not believe in a fully-virtual, never-seen before, kind of scenario for everything. Certainly not in the architecture & design phase of a complex problem (where you might need multiple people for support). Enabling “distributed design” (a.k.a. DOME) is something I find might not be the best value add. In short, I see a substantial difference in complexity and team dynamics between designing the Ford Escort’s door and a large e-Commerce system.

…Therefore, I would much rather concentrate on more pragmatic tools and processes to streamline team communication, skills databasing, project forecasting, bug tracking, etc. In short, project management for virtual development teams rather than design with virtual teams.

(Which is not to say that distributed collaborative design shouldn’t be investigated, but I firmly believe that we have much bigger fish to fry in terms of methods/practices before we get to such sophistication *AND* these other more pragmatic tools will yield more value in the end, both short and long term –I.e. this is not just an “operations” view of the situation).


Ed’s Questions…Well, I don’t remember all of them, and quite frankly I do not if I would be able to answer them all. I do have a suggestion for our initial targets and why they would make sense holistically –not exclusively because they would be an easy sell-

However, I want to say that I fully understand that selling is a complex endeavor and that we might need to make compromises in the beginning. I do not have a problem with that, AS LONG AS we share a common vision and strategy for our company. For example, if we did share the views presented here we would sell Build services only contingent with having one of our “better builders” present (even if in listening mode) during the Architect phase. Why? Simple, chances are we (iRapid) will have to REDO the architecture/design regardless, and in order to provide a QUALITY result, we need our better builder (i.e. the architect in disguise) present to fully understand all the issues.

In short, I do not believe you can design a Sales/Marketing strategy in isolation from some of the material presented here.


In Summary• Good people interesting projects

• Interesting projects three-phased engagement

• Architecture and Build cannot be separated iRapid should DO both (even if it is selling only one)

• Scaling through project mix is one approach to reach the massive company status while preserving quality

• Architecture/Design is inherently complex design “by committee” doesn’t work distributed design tools are not super important

• However, industrialization of components is good and necessary tools in that regard are critical

• Sales and Marketing cannot be done in a vacuum

• I do NOT want to mold our company so that it is an “easy sell”. I do want to emphasize quality results and quality people.

ALL OF THESE ARE JUST MY PERSONAL OPINIONS, SO TAKE THEM FOR WHATEVER YOU THINK ARE WORTH.

Documents

CONFIDENTIAL © 2000 – iRapid - [email protected] 1 Company Positioning A Position Statement Luis Blando September 10, 2000