Fabian Schonholz’s Blog

Recently there was a post in TechCrunch regarding Facebook’s hype. One comment to the post was that Facebook was already passe and “the new hype was being already developed by three guys in somebody’s garage”.

I recently wrote an post regarding Innovation In Technology and the process of creating new technologies; from the need to solve a problem, through making existing technology better, and creating new markets by “discovering” new ideas. I also wrote about companies generating fresh ideas and implementing them, and how these new ideas improve the bottom line. The problem of innovation affects us all, at all levels. From technology through education, stopping along the way in government and politics, healthcare and medicine, and economics.

“Three guys” in a garage can do some very powerful and life changing things. Think Steve Jobs and Steven Wozniak, Bill Gates and Paul Allen. Yahoo!, Google, Hewlett Packard and countless other companies started in an actual or figurate garages. These people took everything they had, had the charisma to raise funds and attempted to execute on their dream and would not relent, are to be applauded. Even the ones that did not succeed; because on the shoulders and ashes of every failed company, a new idea is born with the potential to change our lives.

But is hype life changing? I mean, does a company like Facebook have the potential to change the way we live? Yahoo! and then Google did change our lives. So did Microsoft, Apple, Amazon, Dell, etc. Even Friendster and MySpace have had an effect on how we communicate with the ones close to us. Linkedin and Facebook made this communication innovation their own and improved on it. But are they themselves life changing or disrupting enough? Both companies have the potential to be life changing or provides a change in a commerce paradigm the way eBay or Amazon have, for example. And there is no need to go into how Yahoo!, Google, Apple, Microsoft, etc., have indeed change our lives. But potential is not enough. There has to be value for ALL users for that change to happen.

I am going to come clean: I like LinkedIn and extract some value from it, and I do not like Facebook because I do not extract “any” value from it. But strategically speaking, I think that Facebook has had some brilliant ideas and has executed well on them. So, I tip my hat to them. Their technology AND business innovation, as far as I know, has been converting their product into a platform where people can develop application for it; thus, extending the feature base at little cost and by that, perpetuating their freshness. However, and again, in my opinion, unless there are some true productivity applications developed for it, to me there is no value to Facebook.

Let’s be clear. What does it mean “to me there is no value to Facebook”? As a user, there is not much in the product and additional deployed applications that entice me to go back with any regularity. The only draw that the site has on me is when somebody posts a note on my wall or sends me a message or IM and the sites lets me know. I am curious to read it so I go back to the site. Otherwise, there is nothing yet that I have found of any interest to me.

On the other hand, If I was analyzing the company as an investor, there is ton of value (but $15B worth?):

First of all, because I may not find value as a user, it does not mean that others will not as well. The fact remains that hype or not, Facebook is drawing a lot of traffic and keeps on increasing. Then why would Google buy YouTube when they had Google Video? The answer is traffic and with it, the ability to experiment in different ways to monetize that traffic, within the context of the property. Facebook faces the same ability to experiment on different models of traffic monetization; especially with the Microsoft investment and the rumored additional funding.

Second, the Facebook platform is another traffic draw, perpetuating the point above, but beyond that, it provides the potential of added value; the potential to draw me back as a user; the potential to leverage not only the data in the so called social graph, but the social graph and the connections. Whether it is apparent to people or not, it is clear to me that we are in the midst of a paradigm change in computing and computing services, services in general and how all these are combined. Apple with the iPhone and iPod Touch is good evidence of this. As stated above, Facebook has the potential to be a contributing party to this change. I will go more into this last point in another post already named “Social Networks and Cloud Computing”.

In the end, as fun as it is to think of three guys working on their parents garage on producing the next hype, I would rather think of three guys creating the tools and means to usher the new way to interact with technology and once again, change the world.

Over the years I have either participated and/or was the main person in architecting large scalable web based solutions. In many cases I also built them, but in the last few years, I have directed the implementation and execution. There has always been a common thread to all of these build-outs:

”If you are talking about technology, you are missing the point of building a scalable system”

So, what should you be talking about? Three items:

•  Real Estate - Room to rack the servers
•  Power - Enough power and outlets to power the servers
•  Temperature - Right operating conditions to operate the servers

Truly, these should be the focus of the conversations and soon enough, these conversations would be only of any importance to just Cloud service providers. There is , however, an assumption in the above statement: The architecture accounts for lateral scalability. Indeed, this assumption is of a tall order. But not hard to obtained.

The trick to building laterally scalable systems is to architect around the concept of independent components that can be clustered. In other words, each functional block of a system should be a component operating independently from a different functional block (or component.) And given multiple instances of a component in a cluster, it should not matter which instance answers requests at any given time. Moreover, the instances should be load balanced; Furthermore, given multiple geographically distributed clusters, there should be load balancing and fault-tolerance between these clusters as well. In this case, if a server in the cluster goes down, another will take the requests. Similarly, if an entire cluster disappears, a different cluster should take over.

The implication is that components that need to cooperate can find each other regardless of their location. Obviously, the components know about the clusters through DNS, thus, the name space needs to be tightly configured. The other part of being able to mix, match and integrate geographically distributed functionality is to be able to deal with network latencies. This is easily masqueraded - performance drop will be hardly noticeable - by always connecting to the nearest neighboring cluster providing the needed functionality. In automating the switch over algorithm, we see that by thinking of the local cluster as the nearest neighbor, it follows that the entire switch over strategy becomes very dynamic but easy to manage as new clusters are incorporated.

More often that not, data bases (DBs) are needed as part of the web application. I consider DBs as just another component, thus, the DB architecture and implementation must support clusterization and geographical distribution just like any  other component in the system. I favor federated database systems, where only partial data sets are housed on each DB cluster, with the caveat that the set must be optimal. I will explain:

If you have multiple geographical instances running on multiple data centers, then you will route traffic based on network closeness to a data center. So, if the application is running on Los Angeles and Colorado based data centers, and I am in NYC, then most likely Colorado is closest to me from a network topology point of view and that is where I should be routed. Thus, and optimal data set in Colorado would be such that most or all of the data for users from NYC would be housed in Colorado. An optimal set does not imply that the data only lives in one place. Using this same example, if somebody in Los Angeles wants to access the same data as somebody in NYC, then the user in Los Angeles should not be routed to Colorado, but a copy of that data should be copied to the DB instance in the Los Angeles data center.

Another tool that I have found useful in building scalable web system is AFS (Andrew File System). If you are not familiar with AFS, a good way to understand it is “NFS on cacheing steroids”.  I have used AFS for many parts of the implementation, but in the end, AFS, as an infrastructure component, has helped me with helping, not only synchronize builds across data centers, by releasing to a volume and then “pushing” the volume to all data centers, including configurations; but also, in the management of all the releases.

Component Architecture

We all agree that separation of concerns is a good way to architect systems. By extension, it is a good way to architect components. The concerns in this case are the protocol, presentation, API, logic and data layers:

The data layer is the data bindings to the database. We already described above the DB as a separate component; this concern is the connection and abstraction to the DB.

The logic layer implements the business logic, and ultimately the functionality that users experience.

The API layer serves two purposes:

1 - It converts all HTTP requests to elements that the logic layer can easily interpret and on the way back, converts what comes back from the logic layer to XML.

2 - It isolates the layers below by creating APIs for the components they belong to. In this way, the entire components becomes part of a whole and by calling specific action, certain functionality is exposed.

The presentation layer renders the information (not data) coming back from the API layer - already expressed in XML - based on given and specific XSL style sheets. Effectively, this layer is an XSLT that provides, by choosing a discreet XSL, rendering flexibility.

The protocol layer makes the entire system device agnostic. In other words, it should not matter what device the application is being accessed from; whether it is accessed from a web browser or a cell phone or some new device, the protocol layer brokers access and selects the rendering methodology based on the device.

Conclusion

What I exposed above is a way to architect systems that scale horizontally based on three principles:

•  Real Estate
•  Power
•  Temperature

These principles reduce the problem of scalability to a simple budgeting exercise. And again, if you are talking about anything else, then you missed the point of scalability.

My wife, for her birthday, wanted a video camera and since I am such a good husband I bought her one. I am into photography and never really thought about getting a video camera; moreover, most of the digital cameras we own have video capabilities that we never use. The rational for buying yet another camera was: (1) the wife wanted it and (2) I figured it would be fun to play with another media medium. So … I bought her a camera for her birthday.

Yesterday I videoed Jared’s soccer match and using iMovie HD put together a little movie. I had already done a short and quick clip of one of my fishing trips, but this time I was undertaking a much bigger task. I shot a bunch of short clips during the match and last night I imported them and put together the short video enclosed at the end of this post. I am now a filmmaker, albeit not a good one, but for my first time around, really, I would think not a bad effort. Ed Wood would be proud.

Movie making aside, technology has always caught me off guard and surprised me. Mind you that I make my living with technology and on a regular basis I am exposed to really advanced and new technologies. One of my trademarks is being an innovator, always staying as current as possible with bleeding edge technology and using those technologies to solve business problems. But iMovie HD is an application that comes bundled with every Mac; in other words, it is consumer grade software that works superbly on a stock computer. Anybody can now be a filmmaker and produce videos with some level of quality. Technology to some extent is being demystified.

What keeps on surprising me is the contrast that I have experienced in my career. For the last 25 years, actually a little more, I have seen a tremendous change. When I first started with computers I had an HP 41C programmable calculator. To this day I think that it was the greatest. I also had a Commodore 64 and access to an Apple II and then an Apple IIc. I also had access to ORT’s data center, which, the first year I had access to it, still used punch cards. The second year punch cards had gotten replaced. Nonetheless, the machinery used at that data center occupied half a floor and did not have that much computational power.

Fast forward 25+ years and I am writing this Blog entry on a MacBook Pro that has a gizillion more times computational power that the first data center I set foot in. Not only that, my kids, both have MacBooks and individually they have more computational power than those first data centers as well. Computing machines have evolved so much in the last 50 years. From computers that would occupy entire buildings used to perform ballistic calculations, to laptops solving problems way more complex problems than ballistic equations. You can always quote Moore’s law to me, but Moore’s law does not take into consideration the direction of the innovation.

On TechCrunch, last night, there was an article about the future of commerce. On the post it was reported that ICANN CEO Paul Twomey stated at a conference that virtual worlds are the future of global commerce. Virtual Worlds?? Amazing. I agree. Not only I agree, I am certain. But the problem is the interface semantics. The current interface semantics is wrong. Going back to Apple for a moment, what they are doing with the iPhone and iPod Touch is remarkable. They are not only introducing a new interface to the market, but I can guaranty you that they are coming up with a way to write this blog without a keyboard. Call it dictation or some other form. With their current devices they are experimenting with a change if semantics and paradigms. Eventually, somebody will fully figure it out and not only devices like the iPhone, but also Virtual Worlds will be more life changing than imagined before.

From computers taking entire buildings to house them, to iPhones, to Virtual Worlds. What an extraordinary trip. I wonder what the next 25 to 50 years will bring us.

Software Development Methodologies have been at the core for solving problems with computer software. There are many reasons why a methodology is important, but mostly, because it gives projects a beginning, a middle and an end. Projects are like stories and as such, they can have good or bad endings.

Let’s define what a Software Development Methodology is (I will be broad to serve the purpose of this post):

“A Development Methodology is a repeatable series of steps followed in order to complete a project involving the development of computer programs.”

Development methodologies are particularly important when there is a team working on a project. If just one person is working on the project, then the methodology is simple: just crank the code out. But when more than one person are working together then the level of complexity also increases proportional to the number of individuals involved in the project. Additionally, after the number reaches critical mass (defined as the absolute number of people with the right skill sets assigned to the project), one more person increases the complexity in an exponential manner. This WILL derail the project and the more people are added, the worse the project will fair. The proverbial “Mythical Man Month”.

The way I like to organize teams is as follows:

• Developers: Lead by a development manager, this group is responsible for coding. There can be more than one development team working on different components, products, releases, etc.
• Integration and Release: Lead also by a manager, this team is responsible for engineering the release during its different stages and for completing the release altogether.
• QA: lead by a QA team leader, this group is responsible for the engineering of tools used for automating regression and basic use cases.
• User Acceptance Testers (UAT): Also led by a team leader, they are responsible for functional testing. In other words, they look at the functional spec and press buttons to verify the application works as expected.

I left out two very important roles, project management and architecture.

I am normally heavily involved in architecture. I have some very definite ideas on how to architect massive distributed systems and I am not yet willing to relinquish that responsibility, but when I do, architecture and design are more general management areas than production. They do ensure that the product is built right, but that is true across all products being built. Also, the responsibilities of an architect extent pass the boundaries of projects into integration with outside products and services.

Project management, even though it is an incredibly important function, I see it as external to development as well. Indeed, it does set the mood, pace and organization of development, but still, I feel very strongly that it is more a part of management and administration than development.

Incidentally, I have the best Project Manager working for me: Sue Christensen. She rocks. She is the best and to boot, she complements me very well, specially when we do not see eye to eye.

Similarly to the way I like to set teams up, I like to set up operating environments in the following manner:

• Development: This represents each one of the developers’ workstations. Each developer should have a scaled down version of the application. The code is kept locally for the purpose of development, but it MUST be checked into a code repository like CVS or SVN on a regular basis, provided the code compiles.
• QA: This is a separate environment where the code is deployed for load testing, regression testing and other automated tests. There are multiples of these environments so different releases or components can be tested simultaneously. These multiple environments are key to the pipeline.
• Staging: This environment is a facsimile of production but scaled down. It needs to accurately represent production configuration so similar problems are manifested and they can be addressed before the release goes live.
• Production or Live: This environment is SACRED. It is the environment that is used to operate the company.

The Pipeline

I see software development as a manufacturing process. Do not be mistaken though, I am very much into innovation and I see it core to my functions and what, as a CTO, I bring to the party; but innovation should happen outside of production and brought into production as part of a product rollout. In a sense, it is similar to architecture, design and project management. They are all external to the actual production and manufacturing of a technology product.

But what is the pipeline?

The concept of a pipeline is to carry out no less than a release per week. Ideally releases would happen every day, except for Fridays, but definitely not less than one. Each of these releases can be a bug fix, enhancements or even new products. But for each release to be put into the release pipeline a process needs to be followed.

This process is simple. Let’s take a new product for example. The product development group is responsible for writing the business, which should explore and document the business logic for the given product. In a perfect world the business requirements will be closed and complete, which is a pretty way to say there should be no holes in the document. This document is given to the project management group for review.

The project management group develops the functional specifications, which are sent to the development group for review. Of course there are consultations between the product and the project managers as the functional specs are written. Once development has a chance to review, a Joint Application Development (JAD) session is conducted. All concerns are brought up at the JAD session and documents modified. After a quick get together and making sure all is good, development starts. In some organizations before development starts there is a very formal process where the documents are approved and signed-off. I think it is too formal a step and should be avoided.

Development should work towards quickly building a functional prototype. The prototype should be bare bones of what the final product will be, but it should start showcasing the beginnings of that product. As development proceeds new versions of the prototype are deployed into a QA environment for everybody to start playing with each new version. Each one of the prototypes cycles should take no more than a week. Sure, there will be some features that will take longer to develop, thus they should either get developed as part of the initial prototype; or in a different branch and merged into the release branch once ready.

There are some very tangible benefits to having these prototypes rolled out early:

1) Transparency. Everybody can see how the project is shaping up.
2) Expectation Management. If there is slippage, it will become apparent immediately. Also if a feature is less than expected, it will become apparent as well.
3) Market Deviations. If a product takes too long to develop the market it was going to serve might have changed. Early prototypes allow product managers and management in general to measure the developing product against the market and make the necessary changes without derailing the timelines too much.
4) Mood. Developers see their work materialize faster. They get happier and work faster.
5) QA. The QA team can start building and running automated test cases against the prototypes and provide early feedback to developers, minimizing the QA and bug fix time at the end of the project.
6) UAT. The UAT team can also start setting up the right cases and start exercising them so as to get readier when the time to execute comes. Also, UAT can double up as a documentation team during the early stages.

As the process moves forward more and more of the product is showcased through the prototype cycles, until one day it is ready for the final push and QA, UAT and development get the product into the pipeline and finally out the door.

In what I outlined above there is nothing new. Except, if you have noticed, there is an active role for everybody. Nobody is waiting. Release cycles happen quickly from the conception of the product through the final release. The philosophy is: “Do not chew more than you can swallow and if the piece is too big break it in smaller parts. And it you can not, then in parallel, pick at it one bit at a time.”

Develop small pieces, fast, integrate all the time and continuously test. The prototypes are key to this. Get QA in early, generating feedback along the way. Fix bugs early, do not wait until the end where there is a greater chance to have regression problems.

The same process can be applied to enhancements, except that if it takes longer than 2 weeks to develop an enhancement, then it should be considered a product release. Furthermore, there should be a team dedicated to bug fixes and patches where they crank a few bugs every day. The process remains the same, except in shorter increments of time and business requirements are replaced by bug reports.

The pipeline is the form that development takes once you have a high degree of parallelism in your technical organization. And if you can achieve a pipeline, then development will happen faster, with better quality, meeting your market on better footing and at the end, it should help you get ahead of your market. It does take a great deal of effort to set up the pipeline, but once in action, technology as a whole becomes easier to manage.

OpenSource and the Free Software Foundation have been around for a long time and starting in the early 90’s more options have become available. Linux became a somewhat common word and the use of free software became, step by step, widespread not only for home use, but in universities and corporations. This post is not about the history of OpenSource but the concepts I subscribe in my decision to use OpenSource projects.

There is no free lunch.

Indeed there is not. If you think that using free to download software, including operating system or applications then I have a bridge in Brooklyn that I want to sell to you. But the cost is indeed less. There is no cost for the software itself. In most cases you pay for the distribution, which is the media, the packaging and the shipping. But if you do not even want to pay for that you can always downloaded it from the Internet. The cost there is bandwidth.

So, what other more important cost is there? People. And the cost of these people is higher than FTEs focusing on Windows – We can talk about Sun Solaris, or AIX, or HPUX, which are not free and are also versions of Unix, which enter in the people cost discussing, but since those tools are not OpenSource we will ignore them. A good and/or decent Unix sysadmin with deep knowledge of Linux or FreeBSD runs, depending on experience, at no less than $65K/y. And that would be for an entry level guy. A similar sysadmin for Windows will cost $45K/y. So yes … it is more expensive, but for every 10 Windows servers you need 1 FTE to administer them. For Unix based system, you need 2 every 40 or 50. The math works out that to fully support a cluster of 50 Windows servers you need to spend $225K/y in people, not including license fees. For the same Unix cluster $130K/y. And there are no license fees.

Transparency.

To me transparency is a primary element of security. And transparency is in regards to being able to audit the code. As a CTO one of my roles is to be mindful of the company’s assets, both, digital and physical. So, having access to the code to verify its security is important. Do I look at the code each time I install a server? No, but once upon the time I did. And I try to follow up on security patches. And even if I do not, one of my two guys – not 5 – will.

But that would be at the OS level. At the application level works the same way. Any OpenSource application that you install, it’s code is available for you to scrutinize. Moreover, you are encouraged to do so and to report any finds … specially in a public way. Transparency in this case is about the lack of secrecy. It is secure because it is build secure and security exploits are widely communicated for the community’s benefit. It is also good to provide a security patch with the communication, but not obligatory. You are encouraged to contribute.

Reusability.

I am big in reusability. Reusability to me means several things but most importantly from a business point of view – not to be confused with pure technical meanings of reusability – is expediency. If I can start a project from 50% done by basing it on an OpenSource project then why not? I have the code and I can modify it. It means getting to market faster. It means less development cost. It means starting from a more-less stable code base and if done right, retaining that stability.

On one of my previous posts I discussed buy vs. build and the gist was that if it is core then you build. How is starting from 50% relate to that? By the nature of OpenSource you OWN the modifications, but you need to disclose that the base is OpenSource.

But reusability does not need to be on entire projects. Maybe parts of a given project are the necessary components you are looking for. Reusability is core to OpenSource, in all sorts of ways.

Quality.

Quality is a hard concept in OpenSource and can be argue in both ways, against and in favor.

Against: A software producing company has a dedicated QA team to assuring the quality of the product. They know the product in and out.

In Favor: Thousands of users are proxies for QA teams. And thousands of users can find more issues than a few dedicated QA guys.

It is not about the quality of the dedicated team. I have worked with dedicated QA teams throughout my career and some of the folks on those teams were the best; but you cannot argue with share numbers and probability. The more people looking at the code or using it, the better the chances to find obscure issues.

Moreover, many of the found bugs are reported with the solution in it – even the code that fixes the bug – which accelerates the rollout of the fix. Quality in OpenSource is pride the community takes very seriously.

Community.

Community is an important aspect of OpenSource. Without the community there would not be OpenSource. Without the community there would not be quality on OpenSource projects. The community helps with problems by providing the solutions to the specific problem or similar problems.

I used to be a Red Hat beta tester for JVMs. Since I was a Java developer and used Red Hat, I always installed the Blackdown JDK and tested it as part of my regular development duties. I encountered problems and posted them and if somebody had a solution they would share it with me. I did the same. Once every other day, as I posted issues, I would scan the posts and provided answers if I had them. To a less extent I did the same with FreeBSD – which I also used.

On closed source software, it takes a longer wait to get an answer, even in the cases where you paid for ongoing support.

Robustness

And this is where things get a little dicey. Is OpenSource more stable than close source? Part of the answer does reside with similar arguments as in the QA portion above, and part of it with the community argument as well. I would agree that early days of OpenSource maybe a small percentage of the projects had a high factor of robustness, but that is in the past.

Machines running Linux or FreeBSD, at least in my experience, have stayed up error free, even in the face of configuration changes, longer than machines running Windows, or Solaris, HPUX, etc. Part of the robustness comes from being able to use commodity-computing devices. There is something to say about using the lowest common denominator in terms of hardware.

Another element that brings robustness is, as stated above, transparency. Thousand of people looking at the code and contributing does make a dent – in the positive sense – towards stability and robustness. But robustness also comes from choices; as a CTO I have to choose what is best for my company and in some cases it does imply using bleeding edge components.

Robustness is a choice, and OpenSource allows you that choice.

There are other arguments, including philosophical ones with which I totally agree, but these are the most important to me as a CTO:

• Cost
• Ownership
• Quality
• Help
• Robustness

As a technology executive I am always faced with the decision to build vs. buy. For each feature and for each project, for each component that is implemented, the decision has to be made. And it is seldom easy. There are many factors that play into making a decision and it is not always clear what the long-term effects are. One of the bigger factors is time-to-market, and not less important is integrability. So, how do I make the build vs. buy calls?

Company type is important. Different companies have different needs. And those needs should be fulfilled in different ways. A technology company is different from a service company or financial institution or factory. But because they are different does not mean the way they look at technology differently from each other. The question of technology usage has to do with the purpose of it.

It seems obvious that a technology company will tend to build most of what it uses. But that may not be the case. Similarly, a service company, we would think, would buy and integrate what they use to conduct business every day. And again, that may not be the case. It is all in what is core to the company and what can be best leveraged on a financial event – M&A or IPO.

The way I look at it is that if technology is core to the value of the company and intrinsic to the company itself, then you build it. It is an investment that will pay big dividends. And all ancillary technology should be bought. For a non-financial company it makes no sense to build a general ledger. There are some good accessible products that will do just fine. For a financial company may be worth reinventing the proverbial wheel if they have some new paradigm they want to implement, but if they do not, then most likely it would be fine with a tool like Oracle Financials – I will let the CIO/CTO for such a company decide.

But a company’s technology does not need to be build from the very beginning. Proof of concepts can be constructed on top of canned software. There are a myriad of sites that implement different business all built on top of Drupal, a content management system. The only concept these sites have in common is the fact that they are content rich and that content needs to be managed. But how the content is displayed or monetized, that is different. Drupal is a great tool that can get you going fast, meet your market on a short amount of time, with as little as possible development investment. And then what? Then, again, if owning 100% of the core of your technology is important from a valuation point of view, you start re-implementing and replacing little by little the bought components.

At the end you build if your technology adds to the valuation. Else, you buy. Nobody wants to buy or invest in a company that does not own its most precious asset, technology. Nobody wants to buy or invest in a company that is at the mercy of some third party technology producer.

For large established companies I propose a very similar argument, but with a more macroscopic approach. Larger established companies should be on the lookout for small or large companies that complement them and help expand and cement their position on the market. These acquired products may remain on the periphery or become core.

But, what about their internal technology folks? These established companies have core products that they own, that got them to where they are. These folks work on that and keep on building new version of the core products. Also, they build more core products that the company would own and would positively affect the value of the company as a whole. The companies that they buy in combination with the core products create a more powerful market offering.

In the end, it turns to be a balancing act between core values to the company, existence of quality products, time to market, budget and what strategy the company follows.

As I look at my job and what I do, I am continuously confronted with the task of developing and completing projects to meet the ever-growing company’s market. We continue to expand our needs and as the company grows and we meet our market opportunities, so do the risks and execution complexities. Expediency becomes central to execution. In other words: how do we do more with less and faster?

In my opinion there are three ways to approach technology development and company growth, whether for a start-up or an established company. These approaches are about the business of technology and not the technology of the business. They are about technology as a business tool and technology as a business process.

Just like everything, each one of them has pros and cons:

1 – Purist. The purist approach is based on having all the answers before hand. No opportunity is pursued unless all is known about that opportunity and an existing product is 100% ready to answer the opportunity.

Development cycles are long and tedious and innovation is not the order of the day or the charter of the technology group. On the other hand, all processes are highly repeatable and steady. Also, priorities are SET IN STONE.

I do not think this model works at all. It is too rigid and stifling. For a start-up it spells dead and for progressive companies, it means “getting stuck in the mud”. It is important to note, however, that there are companies that follow this approach very closely and are VERY successful. These are companies not only with deep pockets, but with really long term visions and strategies and are largely unaffected by market changes. Also, their competition behaves in similar ways and innovation is “acquired”.

2 – Opportunity. The opportunistic approach is based on letting the company flow as opportunities develop. Business development seeks out opportunities on areas that are related to the company’s market, but they may or may not be close to it. As opportunities present themselves new products are developed to fulfill the opportunity. And if the company has an interesting idea that solves a good problem, these opportunities come faster than they can be handled. And if the company is a dud, then being driven by opportunities that do not exist generates a quick exit, however, not a successful one.

Development cycles are all over the place. Priorities change on a regular basis and many projects get started and never fully finished. And there are more products/projects to do that can be done. Thus, the continuous change in priorities and lack of 100% completion on projects.

For start-ups this is not such a bad approach. It is very eroding and risky, but ultimately success comes from being able to reign in the opportunities, priorities and products together at more less the right time. The problem is that this creates many one-offs that are hard to integrated with each other and sometimes the quality of the code is not the best – no matter how good the developers are – and documentation is lacking.

For established companies, this is probably one of the worse methods to follow. As a company goes from start-up to the growth face, the issues of priorities must be resolved and productivity needs to be managed and understood. Product road maps must be respected and business development needs to focus. This focus is not about not looking for opportunities outside of the core, but it is about looking for opportunities that do not represent too much of a change to the products and priorities and that are inline with the growth strategy the company is following.

3 – Growth. The growth approach is based on looking at a company in a continuous strategic manner. Products and projects are selected based on a crafted road-map and business development targets opportunities very close to the company’s core products and/or services. Additionally, all development is done in a fashion where high reusability is ALLWAYS achieved.

The key for growth is reusability. In other words: leverage what you have so to reduce cost of new product development reusing existing frameworks. New product development does not just mean cost of technology development, but full product development cycles, which include technology. Also, reusing does not mean lack of innovation, if anything it all about innovation, but on the shoulders of existing products and services.

Another key to growth is full understanding of the market the company plays in and other markets into which the company can expand. But these markets should have similarities as to be able to reuse not only technology, but also the business models, and by extending the company’s business model as well. This understanding produces successful and flexible strategies that propel companies forward.

So … what is the right model to develop and keep a company growing? My inclination is to choose a combination of Opportunity and Growth, although, I would still err on the Growth side. But that is for startups. It is hard to ignore opportunities, especially early stage when the company is still looking for an identity and trying out the idea that created the company against the market. Flexibility for an early stage company is paramount. But sometimes flexibility gets us in trouble and produces lack of focus. In the end, lack of focus is the biggest killer of any startup.

For companies that are past early stage, Growth is the best way, again in my opinion. The growth stage is where companies make it long term. Growth is about understanding the market forces and incorporating them into the strategy. And that strategy turn into a long-term plan that include “what-ifs” scenarios. It is also during this stage where technology is re-factored, possibly rewritten and new products are built to update existing ones using the same and expanded API set.

For companies that are well established I think that a middle ground between Purist and Growth should be the model. Innovation MUST be a focus of an established company. It is the only way to keep an edge and to stay competitive, but existing products need to be maintained and updated. So, long existing products should have a steady release schedule and roadmap, while other areas should, again, focus on innovation and leapfrogging the competition.

One more point I would like to make: The stage of growth and development of each company should dictate what is the most optimal method or approach is best for each company. Each company has different cultures and obstacles to overcome to keep on growing, so, to think that one method will apply to ALL companies is silly. Best practices or writings like this, whether you agree or not, are just guidelines and at the end, each company has to find its own way.