We recently rolled out the Outsource Lite campaign to provide a middle-ground software outsourcing option to small and medium size businesses. Our goal is to provide a lightweight, enjoyable and Factory Direct delivery process for customers wanting more structure than freelance / staffing options, without the 300K+ USD entry cost of a large development firm. If that sounds like you, then I hope you get in touch. We're not sales people. Let us earn your business and your trust, by delivering something small and valuable.
In this post, I will go over 3 of the projects that helped us formulate the Outsource Lite concept:
These projects were completed for different customers, each in a different technical domain. All the projects were small, self contained and delivered immediate ROI for the customer - perfect projects for testing the waters with Outsource Lite.
If your business is Software-as-a-Service (SaaS), your enterprise customers are probably asking for this. The question usually takes the form "Do you support Single Sign On (SSO)?" or "Do you have Active Directory support?" What they are really asking is: Do you support Federated Identity?
From your customer's standpoint, this feature is mundane when it's already available, but it can result in a lost sale when it's not. From an internal point of view, however, it's not mundane at all, because it involves modifying your existing security to interface with 3rd party external systems. Matters are complicated by the fact that the configuration is done by your customers, through a Web UI provided by you. Your team doesn't get an opportunity to test every unique configuration before deployment, they just catch the support issues if things don't work. For these reasons, it's very easy for features like this to end up on the back burner, especially if your Dev Team doesn't have the domain expertise to implement SSO.
RJB has implemented Federated Identity and SSO in many different applications. We know the available options, including when and how to use them.
Some time ago, I was involved on a micro-project where we implemented Federated Identity for a multitenant SaaS operation. This customer had their own DevOps, but resources were spread thin with day-to-day operations. RJB recommended and implemented Security Assertion Markup Language (SAML) in their cloud application, allowing it to interface with just about every Identity Provider (e.g. Active Directory) on the market. The integration worked seamlessly with their existing app security. We developed a wizard-based UI for end users (our customer's customer) to configure their Identity Provider(s). We even wrote the branded end user documentation, with instructions on how to connect with various Identity Provider implementations, and a troubleshooting FAQ for common errors.
This was an Outsource Lite project to the core. The entire thing was delivered, from requirements to production, by a small offshore team in a single Sprint. The project delivered instant ROI to the customer, by satisfying several of their larger enterprise subscribers. A small group of RJB developers were exposed to the customer's system, and these devs seeded teams on subsequent projects. We went on to do a lot of work for that customer. What a great project.
System modernization is typically a technology upgrade, rather than a feature/function upgrade, although it often has the benefit of making new feature development possible that could not be implemented on the old technology. System modernization is often neglected, because you don't notice these parts of the system until they're causing problems. Some folks like to refer to this as Technical Debt. I like the term, but I don't think it drives home the possibility of hidden profit opportunities.
I was recently the customer contact on a small engagement to modernize an existing SaaS system. The system was running on a very old app server and the hosting cost was outrageous. Moving off the app server required a major Java upgrade, which broke some framework code, which broke some application code, and so on. The database and tooling versions were ancient, making matters worse. The customer's Web Developers - all very experienced with supporting the system - weren't comfortable with tackling the upgrade.
Projects like this can be a thorn in the side. You're losing money hosting old technology, but you face risk and uncertainty with an upgrade. There's a real possibility you will spend months fixing bugs. Without the in-house expertise, it's a non-starter.
At RJB, this in right in our wheelhouse. We have lots of domain specific experience, but platforms and frameworks (particularly Open Source) are something we are extra passionate about. We invest tons of time and effort to stay ahead of the curve, and we have a great track record with difficult upgrades.
This particular upgrade was actually very straightforward. One of our Senior Architects proposed an upgrade plan, and the whole project lasted a couple weeks. It was a problem that just looked tough from the outside, but an expert was able to make sense of things with relative ease. I have to hand it to the original developers of this app - they were way ahead of their time from an architecture standpoint.
Anyway, the punch line here is the quick ROI for the customer. This upgrade allowed the customer to move the app to a new hosting provider and reduce cost by a factor of 10x. It was done in a way that introduced virtually zero application code changes, and by extension, zero application bugs. For a contractor, it doesn't get much better than this - we performed work for our customer that repaid itself in a month. What a satisfying engagement. We've had ongoing business with that customer ever since.
Big Data - Proof of Concept (POC)
It might seem strange to see a Big Data project mentioned in a blog about really small projects. I think it's safe to say that Big Data projects are rarely small. Disregarding specific requirements, they usually involve significant cluster design, major hardware acquisition, and integration with legacy systems.
There is, in fact, still some room to test the waters here. When you have zero Big Data infrastructure and little idea how to get started, you need to take baby steps. I would venture that organizations in this category typically don't have the in-house expertise to get started.
At RJB, we have experience implementing Big Data solutions in multiple business domains, using best-of-breed Open Source technology. We also have a history of integrating "traditional" systems with highly scalable Big Data architectures. This is harder than it sounds - Big Data systems are typically based on very different programming paradigms.
I was recently involved in a Project Scoping to implement a Big Data solution for an organization with exclusively "traditional" data management experience. We delivered our findings, however, the customer still had some concerns about integrating existing software packages, re-training analysts and developers, etc. The concern wasn't with the proposal and the new functionality, but rather with the possibility of impacting the existing operation. This was one of those situations where recommendations weren't going to cut it.
We decided to implement a small Proof of Concept, and specifically demonstrate a set of SQL based solutions for Big Data (Apache Hive and Apache Phoenix + HBase for the techies out there). The SQL interface was the key here, since the customer had significant Business Intelligence (BI) and Extract-Transform-Load (ETL) assets, as well as a mid-sized development staff familiar with traditional Relational Database (RDBMS) systems.
Our approach was to deploy a small virtual cluster (no hardware purchases required), and integrate some of the key existing assets. We also got their analysts connected to the new platform through a popular SQL client (SQuirreL). A few of the customer's in-house developers were involved in deploying the solution.
Here are the key takeaways: The POC was delivered in a single Sprint, with a small hybrid team (RJB resources + customer resources). Almost all the delivered functionality was reusable, meaning the customer moved on to Application Delivery with a partial Manufactured Prototype. The customer's in-house team, through their involvement in the POC, went from being uncertain about the new platform (possibly even their job security) to being advocates. They also laid the groundwork for a good working relationship with the offshore team. This was a win-win for everyone involved.
A Pattern Emerges
Big Data, System Modernization, Federated Identity - these are all interesting domains. However, the pattern among these 3 disparate projects is the real point of this blog post. There's more to Outsource Lite than small projects and quick ROI. Over the past few years, it's become a new business model for us.
Factory Direct Pricing - There's no "middle man" in any of the projects described above. Outsource Lite projects begin with a Free Project Scoping Lite and follow with a Streamlined Application Delivery. You deal directly with Managers and Engineers every step of the way.
Streamlined Application Delivery Process - The goal of Outsource Lite is to start small and deliver ROI quickly and efficiently. We've delivered many projects like the ones described above. Through this experience, we've pared our standard Application Delivery process down to brass tacks. One more example of removing unnecessary overhead to help your bottom line.
Consistent Results, Easy to Use - Our goal with Outsource Lite is to be the most approachable Vendor Managed Software Outsourcing option on the market. Don't trust your project to a staffing company with no development culture, and no established tools and processes. Our cohesive factory teams beat staffing any day of the week.