Author Archives: Nikody Keating

How to setup Tomcat with AWS Loadbalancer SSL offloading

Category : How To

Recently I ran into an issue with an application which was running in tomcat.  My plans were to run an AWS Application Load Balancer which would offload the HTTPS Certificate from the application servers.  The problem is that my application was writing full path URLs based on the server name tomcat was hosted on.

This post will walk through the process of setting up your Tomcat application to be able to offload SSL certificates to a load balancer event if you have full path urls embedded in your code.

Step 1:

The first step is to setup your domain name, which you will use for your application.  My personal preference is to go with Route 53, as it’s baked into AWS, you can get free certificates to host on your load balancer and you get a lot of other benefits in regards to how routing is handled.  This domain name will be needed for the next step.

Step 2:

Create your EC2 instance, and install tomcat. In your CATALINA_HOME directory open the “conf/server.xml” file.  Scroll down until you find the “<Connector>” lines.

<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443" />

Once you find this segment, copy it and paste the copy right below the line in the server.xml file.  You’re then going to set the port to a different port number (such as 8081) and add in lines which will tell tomcat that it should behave as if it were encrypted and hosting the domain.

<Connector port="8081" protocol="HTTP/1.1"
           connectionTimeout="20000"
           proxyName="YourDomainName.com"
           secure="true" scheme="https" SSLEnabled="true" />

Save the file and restart tomcat

Step 3:

At this point you need to setup your SSL certificate.  To do this you’ll need to navigate to “Certificate Manager” in your AWS console.  Once there you’ll need to request a certificate.

The certificate will need to verify that you own the domain.  If you used Route 53 it will give you an option to add a CName to Route 53 by clicking a button (this is probably the easiest way to verify the domain).  Once you do this, you’ll need to wait for AWS to verify your certificate.

Step 4:

Now that you’ve setup all the pieces, your ready to setup your AWS Application Load Balancer.  To do this navigate in the AWS Console to EC2 and click the Load Balancer option on the left hand navigation menu.

This selection will take you to the list of your existing load balancers.

Click the “Create Load Balancer” button on the top of the screen.  Then select “Application Load Balancer”.   On the next screen type in a name for your load balancer, set the protocol to “HTTPS” and finally set the availability zones for your load balancer in your VPC.  Click the next button.

On the next screen, select the certificate you setup in Step 3, then click next.

The next screen will prompt you to select a security group.  On this step you can either go with the default, but more than likely you’ll want to have a security group strategy to limit access to your server, but in this example we’ll go with default.  Click next.

By default the wizard will want to create a new target group.  Here you’re going to fill in the options simular to the following, but feel free to be creative with the Name property.

Click the next button.

Finally select your server instance you setup. Click next, then click create.

Step 5:

Once your Application Load Balancer has been created, the last step is to setup your Route 53 A record to point to your load balancer as an alias.

 

Once you finish updating route 53 your domain name will now work with HTTPS while your Tomcat server runs without a certificate using HTTP, offloading encryption to your load balancer.


Robust Rest APIs with Serverless Micro Service

Category : Uncategorized

I’ve worked for various companies which both wanted to present a robust set of APIs on a single URL, as well as develop with a Micro Service architecture.  While there are various design patterns which I’ve used, the draw back in terms of complexity or singular bottlenecks for development and release always made that dream difficult.  It wasn’t until I got into serverless architectures where I’ve discovered that there is a simple way to build your robust verb based APIs while keeping the Micro Service architecture and mindset intact.

This blog entry is going to talk about how Lambda and API Gateway can be used in conjunction to allow you to create robust rest interfaces while allowing you to have multiple teams develop and own portions of the API without conflicts in the development or shared resources.

Leveraging API Gateway to decouple your API

API Gateway and Cloudformation nested stacks are probably one of the best combinations I’ve used when it comes to defining restful interfaces.  The first step is to leverage a basic design pattern where you’re going to define your parent API Gateway resource, and then define your sub-resources in nested cloudformation templates by passing in the API Gateway reference as a parameter.

This approach accomplishes two things.  First you now have a resource which can be deployed independently from other APIs, and secondly, you’ve created the framework for your micro service and their infrastructure definitions.  When deployed you’ll have a single url with a holistic and robust API.

The Lambda Micro Service

Once you’ve defined your parent and child cloudformation templates, which can either live together or be hosted in separate source control repositories, it’s time to build out your lambda micro services.  By leveraging the newly built child Cloudformation templates as container, we can now define our lambda infrastructure, roles, permissions and database resources (such as RDS or NoSql options such as DynamoDB).

Since we’ve built our child templates to only rely on parameters passed in, this enables us to deploy out a single resource to a test environment, or multiple combine multiple to generate our robust API capabilities.

Benefits to Approach

This approach, while simplifying your cloudformation templates and grouping together related infrastructure definition, also changes the way which new APIs can be developed in an organization.  Limitations around centralized resources goes away, multiple teams can work on different parts of the API in parallel, and finally your API components can be released independently, allowing your teams to move at their optimal rate without having to wait for other non-related aspects to get completed, integrated or through a UAT process.  From my perspective though, the ability to get a Robust API to market quickly, leveraging multiple teams, departments and vendors, might be the biggest reason to go in this direction.


AWS and SOA (Service Oriented Architecture)

When I first got introduced to the Spring framework it allowed me to re-envision how to construct objects to work together while enabling more diverse capabilities by constructing variations of object, decoupling architecture and finally increasing test-ability and test driven development.  This is accomplished through a two aspect approach.  The first aspect is Interface & Object definition, the second aspect is orchestration & assembly.  SOA then breaks this model out into the following layers: Consumer, Integration, Business Process, Service, Component and finally the Operational System Layers.  These capabilities allowed me, and other developers, to construct adaptable SaaS (Software as a Service) systems which supported higher customization while limiting the amount of new code and maintenance required on these systems.  The downside to this is that you ended up either having a monolithic service which would then be deployed multiple times or you’d end up with a lot of micro services which would then need an orchestration layer tailored to your needs.

Cloudformation

AWS Cloudformation allows developers to spin up and connect services and infrastructure in a way which is repeatable and reliable.  When I started I was trying to build my entire solutions in a single cloudformation, or separating them into segments then connecting them together through direct reference.  Nesting stacks became a way to organize infrastructure into segments which were functional.  What I missed what that the design pattern which opened up my ability to create highly flexible and adaptable systems was just waiting to be used.

SOA Cloudformation

Cloudformation’s nested stacks concept isn’t new, but it is powerful.  Taking a look at your serverless infrastructure or traditional infrastructure, you can then start breaking out your micro-services into individual definitions.  These definitions could be general purposes or could be custom development for a specific consumer model.  Once you’ve created various definitions for these individual components the nested stack can then be used to wire these components together, or to put it another way orchestrate a specific configuration which will cause services to interact without having to be hard coded to do so.

Lets take a look at an example.  Lets say you have a telecom customer portal your company provides as a SaaS offering.  You have two customers.  Customer A has a specific UI which provides a dashboard back to their customers, which is then connected to a middle tier customer profile service, a billing service and various others.  The billing service is then tied to other services which handle payment processing, bill history, etc.  Customer B is pretty much the same with a few differences around UI and they have different requirements around billing history.  In a more traditional model you’d either end up putting all the configuration into the services via transforms which would have to live with the code, or you’d have to have a centralized configuration system, which I’ve built before and just add another layer of complexity and maintenance.

If leveraged correctly, cloudformation nesting can accomplish this same objective, while allowing for an even high degree of flexibility and diversity of your application.  This is especially true if you leverage decoupling strategies such as SNS and SQS.

The first step is to define your services and components.  In the above example we’re looking at two customer user interfaces,  a business processing service, a profile service, two billing history services, a payment service and an upgrade service.  Our first step is to define these services as unique cloudformations, exposing configurations, such as other services urls or Arns, as parameters.  This does two things.  First it ensures your component’s specific configuration is easy to read and understand as you’ve isolated it from other components, and secondly you’ve just made it possible to deploy that specific component to an environment of mock interfaces for isolated unit testing.

The second step is to actually connect your services through cloudformation nesting.  Up until this point, your services needed to know the messages which they would send and receive, but wouldn’t know specifically who they were sending them to.  Nesting the templates allows you to now connect the services you’ve created by referencing each other, allowing you to easily create customization, standalone deployments or even side by side systems without increasing the complexity of any single component,

While I personally see the benefit of this design pattern really applicable to the serverless world, it can be used in a more traditional infrastructure environment as well.

 


Making big decisions small decisions

Category : Insight

“BIG” decisions stop progress.  They are the decisions which must be thought about, must fall in line with strategy, finances and alliances.  These decisions can limit who you target, how you operate or even how innovative you decide to be.

Some of the big technology trends lately have made a huge impact on the size and scope of what used to be the “BIG” decisions.  This trend has impacted apps, infrastructure and even skill set requirements.  This post is going to dive into a couple of examples of these technologies to show actual examples and how they impact decision making for businesses.

App Development

A “BIG” decision around apps has always been which platform are you going to build your app for.  Are you going to go after the iPhone crowd, the Android crowd?  Do you have the time to build a Windows phone or desktop app?  What devices are your users more likely to use, and will it effect them if only a portion of their social networks have access to your app?  Believe me, hitting only a section of someone’s social circle can spell doom.  The problem here though isn’t just a technology problem, but a people problem as well.  iPhone developers aren’t typically Android developers.  If you’re going to hire in house for this position then you suddenly need to hire, maintain and develop the various skill sets needed to build your apps.  If you hire a consulting firm, then you’re looking to oversee duplicated effort across the various devices your app is being built for.

The good news is that there’s technologies which can help.  Cordova is an example of a technology where your website developer can use their skills to develop an app on Android, iPhone, Kindle, Windows Phone, Windows Desktop, etc.  The tools used are html, css and javascript, which are skill sets typically needed to build and maintain modern websites.  While there is a bit of a learning curve around navigating operating systems to build the app, the benefits of a single set of code for all apps greatly outweigh the learning curve.

Two notes building on this technology.  While you can write a single app for all devices, it is important that you build your apps to be responsive to the type of device its being viewed on.  The expected experience for an Android user is different than the experience the iPhone user will expect.  While these variations are minor, a mature app will take these into account.  The second note is that if you’re web developer is on a windows system, it is pretty cheap to get a cloud based Mac to build your iPhone app on.  I personally use MacInCloud.

AWS Cloudformation

Building out your data center has always been a BIG investment, then the cloud came along and the immediate material investment decreased.  You still end up requiring people who understand how to configure the cloud environment. As part of that your decision as to where you host your infrastructure and if you’re going to setup a site for production and for development purposes.  This meant lots of manual work which could lead to slight variations which could have big impacts.  On top of all of this you have to maintain a staff of network administrators to maintain your cloud which is a separate skill sets as those of your developers.

Now enters a set of cloud tools which turn these big decisions into small decisions.  AWS Cloudformation turns your infrastructure into a template which can be deployed at will, with very little knowledge as to how to configure the details needed after the Cloudformation has been built.  Suddenly, if you decide to start hosting your data on the West Coast of the US, then learn that the majority of your users are on the east coast, with a click of a button you can deploy what you have on the west coast to the east coast.  If you decide that you want three different instances of your site, such as a partner site to test out changes with your partner companies before you go live, your developers should be able to click a few buttons and get one setup which mirrors your production configuration.  If a disaster happens, getting your business up and running becomes clicking a few buttons, if its not just automatic.

What this means to your business is that you are going to spend some time and money up front, but you gain flexibility in decision making from this investment. Cloudformation is just one example, but other cloud providers have comparable options (such as Azure Resource Manager).  In all cases you position what use to take manual effort and weeks (if not months) of work into a push button solution.

One note on this technology.  I would personally recommend spending some money up front to get a Solutions Architect to put together your initial Cloudformation, or comparable template.  This individual will make sure you’re setup for success and placed in a position where you have more options to do what will make you successful.  With current trends towards developers having more responsibilities around designing and supporting their application infrastructure, your developers will more than likely pick up extending and maintaining your Cloudformation templates.

Conclusion

Some of the latest technologies are making those “BIG” decisions into small decisions, which can at a blink of an eye be altered.  This changes the game when it comes to taking risks and innovating, making the former easier to tolerate failure of a single assumption and allows more effective adaptation.


whitepaper.guru – What is it

Category : Uncategorized

History

What you know is directly tied to what you can do.  I know this all too well, as I grew up with a reading disability which made school difficult and my professional life that much harder.  I really started taking off when I discovered audio books, which opened up the doors to information which I never would have without this medium.

What is it

whitepaper.guru is an app designed to turn the process of reading technical whitepapers into a convenient listening experience.  You can choose between a variety of narrators, and have access to your whitepapers no matter the device you’re on.  Whether its a web browser, an iphone, an android or a kindle fire, the whitepaper.guru app will give you access to the information you want to know.

Technology wise, whitepaper.guru runs as a mostly serverless aws application.  This allows the overall costs near zero, while opening up the capabilities to a broad set of technologies which typically would have to have custom solutions.

Current Status

Currently whitepaper.guru is in beta.  If you’re interested in getting it during this time period please email you itunes email address to nikody.keating@gmail.com and ask for access to the whitepaper.guru beta.


Should you build it, reference it or buy it? Making software decisions

Category : Uncategorized

When starting a business, you often start with a vision of a product which you believe in.  But in order to make it work, you need to take your concept from the idea phase to the prototype/MVP phase as quickly as possible. For many, the reason for this is obvious, but for those hopeful newbies this is because once you get your Prototype/MVP you’ll be well positioned to get funded and make this your full time job.  Until then, you’re working multiple jobs and your business is in the highest risk position it could be in.

So how do you build your prototype as quickly as possible? You typically end up with three options:

  1. Build everything yourself (this is the instinctual draw to the new entrepreneur)
  2. Find aspects of your prototype which are either free or open source
  3. Buy aspects of your prototype from third parties

With these three options in mind, what should you do? How do you make the best decision for your startup?

Through my experience I’ve come up with the following approach to making these decisions.  My principled approach is to: Find open source options.  If that’s not available or doesn’t work, find something you can buy that will work.  If you can’t find it or buy it, then you’ll need to build it.  While these three simple sentences make sense generally speaking, I’m going to walk through a little more detail as to how you figure out which option is best for you.

Free or Open Source Options

Finding a free or open source solution isn’t always free or inexpensive.  Typically, you need to keep several things in mind.  The main contributors to this is that you will have to potentially build, configure, deploy and problem solve the issues with your free or open source system.  These systems often have a community approach to support and documentation, meaning that there’s a lot of other people out there who are using it, and you can ask them questions, but there’s no true authority on the software.  This can be a  blessing and a curse. While most of your support aspects are free, it really depends on how active the open source community is that determines how responsive people are to answering your questions.

After you find a potential open source or free solution, identify what you plan to do with it.  Is it a server component, a client component or an app?  Are you planning to sell it to consumers or third parties? The reason to ask these questions is to check what the limitations of the usage license associated with the component.  If its a server side only component, you’re typically safe using it (as no one is really going to dig through your back end looking to see if you’re compliant with licenses at this point in your business).  If anything is being used in the client, make sure you follow the license strictly.  Generally speaking I look for MIT or LGPL licensing.  If I’m planning to make my client or project open source, I’ll look at other licenses.

The second part you’ll want to look at is what type of support it will take to deploy it.  Typically this is a question you’ll be asking if you’re making server side components.

  1. Does the license make it impossible to do your business?
  2. Does it require a specific operating system?  (Windows operating systems are more expensive and can require more hands on efforts)
  3. Will you be able to deploy it to your servers or to the cloud you plan to use?
  4. What type of knowledge do you need to have to get it setup? Do you have it?
  5. Will the answers to these question be sustainable for the immediate future?

If you answer these questions, and the result are good then you have a solution.  If the answers indicate it won’t work, start looking at other options or purchasing.

Purchasing Options

When purchasing, you need to consider what solves the problem at hand, ensure that you have the budget to purchase it if it does work, and finally understand when to buy.  The strength of purchasing software is that you get a fully tested and qualified product which you should be able to rely on.  In essence you are purchasing the time and effort those others put in, so don’t expect it to be cheap.  At the same time, approach all purchases with skepticism.  Businesses which sell software tend to oversell what they can do.

When purchasing non-SaaS (Software as a Service) software, first look at their documentation, support and community presence.  If they’re missing the community presence, it’s not a huge deal as long as they have the other two.  Understand what the costs would be based on having a significant number of issues which you wouldn’t be able to handle by just reading documentation.  Next see if you can use a free trial period or a low cost option to prove your concept, rather than the full version.  You can always upgrade later once you’re funded.  If you’re on a free trial, make sure to purchase it only at the point you absolutely need it, and make sure you implement the most important features you’re going to depend on before the trial expires.

The preferred approach to purchasing software is to purchase a service rather than a licensed product you have to deploy, scale and maintain.  When approaching any SaaS  purchase the first step is to ask for their software road map.  This should be a technical road map of what they’ve done and what they’re planning on doing in the future.  Assume anything being done in the future won’t be done in time for you unless it’s in the contract that you put together with significant penalties.  Review the road map, and ask questions to their technical staff, rather than just the sales person.  I’ve gone through negotiations with CDNs where the sales person affirmed that I would be able to do http puts to their service, to later find out that they couldn’t technically support that functionality by their technical staff.  Avoid this headache and do a feasibility discussion with their technical staff around where they are now.  All promises need to be in writing and must have penalties associated with missed deadlines.  Make sure to get a free trial period for evaluation and integration.  Expect any time put in here could be wasted if the deal falls through.

Build It Yourself Option

This needs to be the last option you look at.  The reason for this is that is that this is the slowest, most costly option at your disposal.  The cost you’re looking at is that every second you’re delayed from getting your product live and funded, the more likely your competition will move beyond you and capture the funding which would have been available.  You also will spend more time testing and supporting a variety of functionality which will take on a life of its own.

In an ideal world your product would connect existing pieces from a variety of other previously developed software products, either open source or purchased.  This isn’t to say that your product isn’t unique, but rather that your concept’s various aspects tend not to be new problems to software in general.  You’ll know that you will need to build something when you are not able to find any other way to get it built.  In these cases, make sure you understand what functionality in your system this component will affect and verify that it’s absolutely necessary to prove your concept’s minimal viable product.  If you can delay it, you should.

Epilogue

More and more investors expect a product to exist and be functional before they invest in the seed round of your company.  Since more and more startups are able to get apps, services and solutions developed, the investors see their role as accelerating a viable concept.  The approach I’ve outlined is intended to focus your efforts on building your user experience and solution, rather than low level system development.  If there’s something that long term you want to build yourself, great, but first purchase something that you intend to replace to get your initial product built.  Your goal should always be to prove your concept, and iterate on building your MVP and then features on top of that, rather than building the ideal product.


The business of connecting people

Category : Uncategorized

A new market opportunity is emerging related to how businesses can connect people to moments they might typically miss. This new market has been triggered by the consumer’s lack of desire to push aside competing interests that may or may not be more important, in order to engage. Technologies that utilize real-time engagement are seeking ways to excuse the user from having to take a break from what they were doing in order to engage.

The Live / Stored Streaming Hybrid

The Live / Stored Streaming hybrid presents a compelling opportunity to work with the current cultural nature rather than against it. The goal is to provide a safe environment, notify the observers that an event is going on, then allow them to decide to engage in the moment in real time or some time later. This provides a freer level of engagement the end user can log into in a way that flows much more cohesively with his or her current behavior. While this concept is not completely new, and has been going strong in social media for a while, the use of video in this context is in fact new. Using this approach, Weple is finding that engagement across social groups increases, with the types of content shared increasing as well. With an average session duration of 12 minutes or more, this medium can easily be seen as an effective new form of communication.

Extending businesses

Social Streaming is poised to become the new way in which businesses illustrate why you should engage with their products and services. However, that just breaks the surface of how Social Streaming will actually evolve businesses, both big and small. Social Streaming will allow businesses to offer access subscriptions, such as a fitness studio giving classes or a sports feed like ESPN offering curated content. It will drive sales of products and services through linking from the Social Streaming platform to product and service sites, or directly to a point of sale. It also has the ability to allow customers to recommend products and services in a “living and breathing” way that will engage other consumers on a more emotional level. For example, imagine restaurant reviews with Social Streaming of the actual meal that’s being reviewed. All of these ideas open new doors for business, and will become more and more common in the modern industry.

The Value of the Data

Other fascinating aspects being seen through the use of public/private Social Streaming are new categories of analytics. This medium has the power to identify emerging patterns about the strength of a relationship more than any other social media type. The primary reason for this is that video is more personal. What you share and with whom you share it reveals laser-focused metadata versus a traditional social media post that is sent out to the masses. How people engage after that builds upon that base, creating a profile of connections and involvement. All of this can be observed through analyzing the metadata only, without watching a single video.

Getting Involved

While we’re in the early stages of social streaming there is tremendous opportunity to get involved with defining how businesses can leverage it. Companies like Weple are starting to engage in these aspects and are always looking for early adopters who have a passion for reaching consumers in new and innovative ways.

Go to http://www.weple.com to find out more, and download the app.

photo by: ViaggioRoutard

Information Convenience Technology, the current disruptive innovators

Category : Uncategorized

Over the past 5 years there’s been a steady change in how technology is used to simplify our lives.  While the trend of convenience is not new (most technology stays due to its convenience in practical lives), the modern trend is to use better and more real time information to generate a new level of convenience for existing systems or concepts. The first time we really started seeing this was the introduction of the iPhone, which started a slow change from desktop and stationary computers to mobile ones.  Since then we’ve seen a large reduction of mp3 players, personal organizers, cameras, even wallets. This simple concept of having a phone be a mobile information delivery system has been well documented and its impact is continually being increased.

The current trend among disruptive companies is based around the next level of information/communication convenience, in the same way that the iPhone disrupted its market.  From employment to transportation to relationships to the music industry, the current trend is information convenience.

Transportation Disruption

Companies like Uber and Lyft are innovating in the area of transportation convenience.  The first front is the convenience of transportation on demand.  This is an area where the current systems of public transit and taxis have struggled.  My personal experience with taxis was has been trying to find the right local taxi service late at night, with no taxis on the road.  After calling the service I had to wait for 30 minutes to an hour after, with no idea when the taxi would show up, and any taxi I saw couldn’t pick me up since I called.

Uber and Lyft came up with an interesting solution where you have a single app that can get you transportation in many cities (and they’re continually expanding). When you specify where you want to go, the app shows you where your transportation is while on its way to pick you up and give you an accurate estimate as to when it will be there. When comparing the regular taxi service it is easy to understand how companies like Uber and Lyft are winning hands down.

Other innovators in transportation, such as \”One Bus Away\”, are showing that by increasing the information to consumers, things such as transportation can become more highly convenient without changing the structure of the current systems.

Employment Disruption

Another area of innovation is employment.  For many the 40 hour work week is just something that needs to happen to pay the bills.  For others we’re seeing a shift towards independent contractors who can decide their own hours, decide how they want to work, and have less cost to the companies by doing so.  Technologies like CroudFlower and Mechanical Turk have companies paying for completed tasks rather than the number of hours performed completing them.  Businesses are leveraging this available man power to accomplish anything from reviewing consumer feedback, such as GlimpzIt, to generating a distributed workforce of drivers, such as Uber.  The assumed employment wisdom of the past, where benefits and a steady income matter most, are out weighted by the convenience of working the hours which make the most sense and a compensation model based on how well you perform as an individual without management.

Relationship Disruption

Another company is innovating in an area which lately has been hotly debated, relationships.  Weple is making it convenient to stay involved with those you know. Through the use of what Weple calls Social Streaming, a live/stored stream hybrid model, users can stream an event, have a push notification sent out to either all their friends or a specific group, and allow those friends either to view and interact with the event as its happening live, or come back later and view and interact after the fact.  This technology, when looking at a small test sample, has caused the type and frequency of social interaction to increase substantially.  When members of this test group were asked how the technology affected their view of their relationships, they indicated that there was an increase in familiarity and understanding of the others in the group.  When looking at the modern workforce, being pulled many directions all at once with limited time, this type of technology has the potential to disrupt our definition of community and strengthen our connections to those around us.

The music industry

Another area of innovation is around the convenience of handling non-centralized payments.  Areas such as payroll have been innovated on for years, but companies such as MediaNet are innovating in fields which isn’t so visible to the general population.  MediaNet is known as the backend for a lot of music services, from radio streaming services such as Songza.com, to paid streaming services such as Beats Music.  The area where they are creating a disruptive technology isn’t the content delivery, but rather the ability to pay everyone involved with the songs that play.  Most people have heard of labels, which represent the artist.  The other piece to a song is the composer which is represented by the publisher.  While the label is rigorously involed with providing songs and approving services, the publisher is often a forgotten entity.  Governments are working to ensure there’s repercussions for ignoring the publishers.  The problem is that unlike the labels, the publishers can own parts of songs, ownership can change, and tracking who owns what and how to get their money to them can be difficult.  Companies like MediaNet are working to address the problems of tracking and distributing royalties correctly in a way which minimizes the efforts of consumer facing services.  In doing so, they increase the accuracy of payments which in turn helps the music industry.  As this effort is seen as more achievable by those in the industry, the expectation for this type of accuracy and capabilities will become expected.

Conclusions

While this is a fraction of some of the disruptive companies out there, it is apparent that the current trend of technology is shifting to a convenience in how we can receive and utilize information for markets which aren’t really new.  While everyone might not embrace or fully understand these changes, the market is defining a new equilibrium around them.  Sometimes the most disruptive companies don’t find something new to do, but take something already there and do it differently.

photo by: weeklydig

The 5 steps to planning a software startup

Category : Uncategorized

There are a lot of people out there with “BIG” ideas.  These ideas range from the practical to the absurd, with some of the practical and some of the absurd turning into successful businesses.  A problem I had early on in my plans to build a business was that I would approach is as great idea leads to a product and a great product will automatically get customers and success.  This assumption was all wrong.

I’ve been a part of several startup companies, a lot of which I started on the ground floor and helped build the concepts.  Through these experiences I’ve come to a couple of conclusions as to what we did correctly and what we could have done better.  The biggest realization for me though came when I realized that my tendencies lead me to a result which limited their ability to succeed and increased the amount of effort I was putting in.

Below I list the 5 steps I currently use for planning a software startup.

Step 1: Construct a thought of a product and put together a team

This step is designed for you to come up with a concept.  This level of idea is typically high level, visionary and might have a wide range of interpretations. With this vague notion you have enough information to start finding your founding team, with a variety of relevant expertise.  You and this team will be responsible for flushing out the concept into a fully formed idea, so make sure its creative and business savvy people.

I personally recommend that you have at least one technical expert and at least one sales/marketing expert.  Consider what other roles will be needed if your product was already created today and make sure to get a representative with those skill sets.

Step 2: Come up with your idea

Now that you have your high level concept, and a team with some of the pieces needed, it’s time to flush out your idea.  Your newly formed team will start identifying areas they think will or will not work from the perspectives of their skill sets.  The goal here isn’t to come up with what your product will look like, or its detailed functionality, but rather build a story to tell which either hasn’t been told before or is a problem that can be solved more efficiently.  Try role playing your product idea with your team.

The typical story should include answers to the following questions as well.

“How does my business change my consumer’s worlds?”

and

“What new behaviors am I asking my consumers to make, and does it make sense?”

Step 3: How much capital can I realistically afford

The next step to starting your own business needs to be a realistic assessment of how much you and family members are willing to put into your idea.  Starting off this is going to be your budget, and expect this to last until you’ve built a proof of concept or even launched your product.  In the case of iPhone apps the current trends are that your app will launch before you get seed round funding, so make sure you take this phase very seriously.

When approaching getting the actual dollar amount it is important not to treat this step as a hypothetical problem where you assume people will invest.  This step should be money you have access to immediately and money you’ve had people pledge to you after discussing your idea with others.  Get a piece of paper, or have people email you amounts which they are willing to put in.  The reason for this is that it’s easy to say “Sure I’ll invest”, but not really think through what they can afford.  By making a document, or an email, with the specific amount of money they could be willing to invest they also have to go through the process of thinking out what they’d be willing to put in.

Step 4: Plan out how you’re going to sell your product

This step is critical to think through, and to figure out how to prove your approach.  The sooner you can prove that your ideas resonate the way you expect the better.  This is where a concept called “Lean Startup” comes into play.  To sum this method up, your user acquisition strategy isn’t fact, but rather a theory which can be either proved or disproved with the scientific method.

Use your full team to discuss the sales strategy, and pare down your product to what’s minimally needed to be functional, be useful and something that can be sold to customers.  While it might be nice to have every feature, the sooner you can get your core concept out the more you’ll learn, but what’s initially shipped must also be able to be sold.  This is why this step comes before building the product.

Be very cautious of sales ideas that you think will work or false positives of success. Likes on a Facebook pages and followers on Twitter should all be disregarded.  These are all activities which require little investment by others, and cannot be relied on as indicators of a functional strategy.  Alternatively, pre-registration, crowd funding and pre-orders are better indicators of a successful strategy.

After doing an initial draft of your sales strategy make sure that the costs of what would need with the capital you have access to.  If your sales plan exceeds 25% of that budget to get your first round of results, then you need to rethink your sales approach.

Once you’re finished with this step, don’t expect the plan to be written in stone.  The sales strategy will evolve as the product evolves, but what you’ve created in this step will help define what needs to be done when building the product.

Step 5: Make your product

Now that you have a sales strategy, or user acquisition strategy, it’s time to start making your product.  The product road map needs to be designed to fulfill onlyStep 4, without adding extra “nice to have” features.  This criteria will lead you to what will be called your MVP or Minimum Viable Product.  Expect that your project will run longer than you expect, and cost anywhere between 150% – 300% what you expect it to cost initially. The reason for this is that it’s near impossible to think through all the details and low level decisions of your product.  A lot of ideas might sound good on paper, but you’ll really find out if you’re on track when you use the product. You also won’t really know if the product is simple enough to use and understand until you have some time using it.  Complex products tend to lead to less interest from consumers.

Ideally your product team would be funded with equity or be on a fixed bid for the work.  The value of a fixed bid is that the cost doesn’t go up for bug fixes and missed deadlines.  The negative of a fixed bid is that the team doing the work will build to the letter of what was specified, and if you forget a necessary feature or scenario it will cost more money.  Fixed bid also tends to limit iterative product development, where feedback is taken, prioritized and build continually.

Epilogue

Making a business is hard, and every ounce of effort not leading towards your initial sales, or which doesn’t contribute to getting your initial rounds of funding, is wasted.  I put these steps together in order to best focus my own efforts for startups which I am a part of.  These steps are not intended to cover some of the finer aspects of building your specific business as all businesses vary case by case.


Bitnami