To start I want to give an example of a dedicated team scenario and that same scenario with a dynamic team.

Let’s say a company has a one person dedicated team, and let’s say it take a developer two months to get up to speed on the company’s application. Once the developer is up to speed, all is well, and they can work very fast. But then suddenly after one year, they leave. In a best case scenario two weeks are needed to get a new developer in (if one was waiting in the wings to give notice at their current job and start with the company right away – always happens right?), and then two months for them to get up to speed on the company’s application. So the cost to the company in lost productivity could be approximately two months of fully loaded salary while the new developer is getting up to speed plus two weeks with no one available.

Let’s look at that same scenario and how it may differ if the company was working with a dynamic team. One year ago the further development and maintenance of the company’s application was assigned to a 5 person dynamic team. During the first two months all 5 persons touched and got to know the company’s application as a result of working on adding new features and fixing bugs. Knowledge was shared during pair programming, daily status meetings and code reviews. After one year, one of the five persons leaves the team. A new developer is brought in to work on the five person dynamic team and begins to learn the company’s application. There is no loss of productivity while the new person is getting up to speed, as there are 4 other person’s with knowledge of the system.

If you compare the two scenarios then the dynamic team scenario sounds ideal as there is no lost productivity. But is that always the case? What are the challenges or risks in working with a dynamic team?

The biggest challenge that always comes up in discussions about dynamic teams, and the one I want to focus on here, is that in a dynamic team, no one developer gets to know the system inside and out, because they are also working on other systems at the same time. Looking at the scenario above, we can assume approximately 2000 hours of new functionality were added to the system in one year. For a dedicated team of 5 persons, each would have worked on the system approximately 400 hours (it is also assumed of course that they heard about the system via code reviews or status meetings or common discussion of issue meetings, etc., as well), versus 2000 hours for one person, in the case of the dedicated team.

Who is going to know the system better? There can be nothing to make up for the experience gained by working with the same system daily. Therefore we can agree that the dedicated team is always going to gain better individual knowledge of an application, especially in the short term, there is no way around that. But in looking at this challenge we have to look also at the risks or challenges with dedicated teams. One was referred to before in the scenario, the risk of losing that one or two persons who have all of the knowledge. But there is also another possible risk; the downside to daily work on the same system day in and day out. Here I enlisted Anatoliy Okhotnikov, Softjourn’s Head of Software Development, again for our discussion on the challenges with dynamic teams. According to Anatoliy, “Consistency is better for a person who works in some fields of technology, but projects must be rotated to bring in new talent and continually improve developer’s skills. People who work for a long time with a single project become stagnant and their efficiency and effectiveness drops as they start to lose interest and get used to a routine.”

I would have to agree that this could be an issue with some projects and certainly with some developers. Some developers like and need change more often, they like to continually be working with different projects it helps them develop different skills. But there are certainly some who like to work with the same system and really get to know it and be an expert in it. If you are able to find that one or two developers who want to stick around for a long time, that may be the way to go, but is that reality and always possible? As well what do you do when they want to leave, which they will want to do at some point? Whether you choose that a dynamic team is right for you, or if you prefer a dedicated team, will depend on which risk is more acceptable to you; the risk of losing all knowledge at one time, or the risk of maybe not having that go to person or persons who immediately know every single detail about your system.

There is another question I would like to explore some time, regarding dynamic teams. Is there an optimum dynamic team size that correlates to the size of the system that is being supported? Or perhaps correlates to some other aspect of the number of new functions to be developed over x time period? But that is a question for another post!

I picked this methodology to talk about because many companies would like to have a dedicated software development team; i.e. have a specific group of developers who only work on their products and who can get to know the company and its people well. Many start-ups and small and medium sized businesses like to work this way, and for many it can work out great. The Dynamic Systems Methodology is an alternative to a dedicated team, which may be more effective for some companies, especially when the dedicated team size would be small.

To help explain the dynamic systems development methodology, I enlisted the aid of Softjourn’s Head of Software Development, Anatoliy Okhotnikov, asking him several questions about this methodology. The discussion of this methodology will be done over a couple of blog posts, starting out with more details on what it is, some of the benefits for a company if they decide to work with this model, and moving in to the challenges.

1. Explain to us your role and duties and responsibilities within Softjourn?

My position is the Head of Softjourn’s Software Development Department. My responsibilities range from establishing team work processes and providing continued education on such topics as secure web development, to analyzing new projects, and researching and architecting technical solutions.

2. You advocate a dynamic team model for certain types of companies. Can you explain how it works?

The Dynamic team model works in the following way: a vendor does not provide just bodies to companies (the dedicated team model), but rather delivers functionality. For example, instead of having a dedicated team of two persons, a company may have a pool of 5 or 10 programmers available to them, who have some familiarity with their product and deliver by functionality. Functionality development, for a particular client, is not assigned to the same two person team all of the time, but rather it is assigned to a pool of developers and then to individuals in that pool based on skill-set needed to develop particular functionality and based on availability.

Companies looking for software development services, may pick up on a key here which is that more developers in the pool have “some” familiarity with the product and project, rather than just the two persons who may be on a dedicated team. The pool of developers share the knowledge about the project during code reviews and demos, by doing pair programming, by rotating team members, etc.
The plus for a company who agrees to work with a dynamic team is two-fold:

- Less interruption if one developer leaves the team. There will be several other programmers available who are familiar with the system and who can work on the functionality of their products; they won’t be losing all of the knowledge.

- The ongoing development and maintenance of any system can take different technical skills. Within a pool of programmers, there will be varying skill-sets, and it will be easier to put the best skill-set on to the right project to complete specific functionality than could be found in a dedicated team of two persons. Odds are that two persons are more likely to have less experience with different computer languages, frameworks and tools, than a pool of 5 to 10 programmers.

Another implication with this model is a smoother team load. If there is a situation where the team needs to speed up and deliver faster, additional resources can be more easily added than with a static team (he reason being of course that “some” familiarity.) With the dynamic model it is also harder to overload a team member which in theory leads to more job satisfaction. The more satisfaction the developers get from their work, the higher the quality of work they are able to produce. With a fixed team, sometimes people may be overloaded and stressed, they start to make mistakes and the quality drops. On the other hand if they are under loaded, they may get bored, lose interest in the project and the quality will drop as well.

Based on the discussion thus far, it seems there are some benefits for working with a dynamic team versus a dedicated team. However, this model is not without its challenges for companies who agree to work with a dynamic team, nor for the vendors who provide this model. These challenges will be discussed in the next post.

I think that’s great! But then I find out from many of them that they have never architected a product before, or they have never worked first hand with the technology they have chosen. Now that does not necessarily mean they have done a bad job with the architecture, or that they have chosen the wrong technology. But I do wonder why they spent time on this activity when it clearly is not their area of expertise, and there are so many other things to do when starting up a company. Maybe they were just interested and wanted to do it and wanted to learn more. That’s ok too. But when I ask them why they did it, some of the top reasons I hear are:

1. I need to know what is being used when talking with potential investors.
2. I will never get a good answer from a vendor, as to what to use.
3. I want to use the latest technology and no one will know how to do it.

Clearly Founders are not very trusting people and that is probably not a bad thing given the fact that they are trying to start a new business. But I think there has to be a better way.

I can understand why a founder would have trust issues around technology or what to do. Ask 10 different vendors (or individual technologists for that matter) to respond to your RFP or which technology to use to build your app, and you will probably get 10 different suggestions of which technology to use. Why is that? Well one of the reasons is because there are so many choices. The same business problem can be solved using many different combinations of technologies. Another reason is because each vendor (or individual) usually has their own technology area/s that they concentrate on. So naturally what are they going to recommend? They are going to recommend that, low and behold…..the right technology to use is the one they have the most experience with.

How to ask for and what to look for when you get a response to your RFP?

So what do you do if you are a founder and you need suggestions as to which technologies to use to build your new service? You need to concentrate not only on the timeline of development and the price, but also on the technology recommendations and more importantly the reason for the choice. The reason for concentrating on this is obvious; a founder needs to understand the pros and cons of a particular technology so they can determine what is best for their company initially and what will be the best for the long run.

Unfortunately there is often less concentration on the reason for the choice than there is on the overall price of the project. The question usually comes down to money, however, in order to get the best recommendations, often some money will need to be spent.

As I mentioned above there are usually many different combinations of technology that could work for every application or new service. In that case it often pays for a founder, if they are not a technologist themselves, or even if they are but their knowledge is in a limited area, to pay for a vendor or two to do actual research on different tools or different open source solutions that could be used for their new product or service. The choices and options should include the pros and cons of each choice based on the founder’s objectives for the new service;, based on its direction, based on estimates for number of users initially and in the future, etc. If for example the founder’s new service needs a video solution, this type of research project can uncover which open source solution best fits the objectives of the product, or if a paid solution is better. Another example may be a new product/service which needs a handwriting recognition solution; well there are many of them out there. To find the right one for your service could take a lot of trial and error, as well as it would need to take in to account the acceptable “minimum” of recognition that would need to be done by the new product, etc. A vendor or technologist should be easily able to create a long list of possible solutions for your new service, narrow it down to a short list of potential solutions and then run an actual test of the most likely solutions, and then present to you their recommendation. By doing these types of research projects, a founder will often be exposed to many more options than they could uncover on their own, in a shorter time period, and get more information than just the price and timeline for creating their new application. These type of projects often do not cost that much money. They can be limited in scope so that the founder feels like it will not get out of hand and end up costing them a ton of money.

But should that founder decide what technology should be used for an application, or should they want?

On the other hand, there are cases when it makes sense for the founder to make a suggestion as to which technologies to use for an application. I say suggestion because the final decision of what to use should always be the founders. It is the level of input that he/she may receive from others that is the question. Those reasons may be.

1. The founder is going to develop the initial application themselves and they are familiar with a particular language or tools.
2. The industry that is going to be served requires very specific technology to be used. In other words the potential client base maybe only uses Microsoft tools, or the target market’s main mobile phone OS is Blackberry, etc. This is something the founder as the main product manager would know best.
3. The exit strategy of the company. We have run in to companies which have come to us, after they had their initial product built out, and said they had to have the whole thing redone. Why? Because they did not own everything that had been built for them previously. There was some part of it that was a proprietary system from the vendor that built it. This was going to be a problem when it came to selling their company. In this case it is clear that the founder needs to define that proprietary solutions will or not work for their company.

If you are a new founder of a technology enabled service business, and you are facing that inevitable question, what technology to use to build your new service, how you go about making the choice is certainly up to you. If you feel comfortable making the choice yourself, or if you want to involve technologists or vendors, it is up to you. Either way, if there is not clear cut choice based on your target industry, make sure you have some information on the pros and cons of the different choices, and a good way to get that information is have a service provider conduct a research project for you and point out the pros and cons of different solutions.

Developing the next generation of bright programmers is such an important part of what we do that we’re partnered with the National Technical University in Ivano-Frankivsk, Ukraine, where our software development center is located. Many students are in a five-year master’s degree program in computer science or other software engineering related disciplines. One of our Project Managers is an instructor at the university as well. Many interns come in as third or fourth year students. They work for us as junior programmers while finishing their degree, and then become a part of our regular development team. This preparation process gives them the opportunity to develop their skills under the guidance of experienced software professionals, and gives us the benefit of their enthusiasm, and gives them time to get up to speed on Softjourn’s methodologies.

Our training program is equal parts trainees and trainers. Developing future managers and project leads is another benefit of integrating training into the work environment. Team members who volunteer or are “volunteered” to take on the role of mentor get the type of hands-on experience that’s essential to management training. By training others, mentors learn how to lead a software development project before they’re officially in the position. They’re managing another person and taking responsibility for someone else’s work. They learn to communicate on their feet, so their non-technical skills evolve naturally. Employees interested in management know they can best demonstrate their potential to lead and work with clients by doing a knockout job at training our newest software developers. A senior developer in Softjourn also has taken on the responsibility to liaison with the National Technical University. He continually presents to the students’ different topics which aid in their development, as well as talks with them and mentors them on their technical interests whether it may be java, or .NET or mobile development.

Communication is a primary concern of many prospective clients. Therefore, non-technical skills are among the most important qualities for the emerging generation of software developers to cultivate. To be successful in this industry, we’ve pushed the communication skills of every person at our company. That means not just English language skills but skills in working with clients. It’s our priority to grow team members who are capable of putting themselves in the clients’ position. It’s not enough to ask a client what they need. Our people ask the questions that help pull out essential information for a project, and they realize the concerns a company may have in working with remote software developers. As a company, we’re able to relate, and that’s what keeps our clients coming back.

If only you’d been asked a few questions to clarify what you wanted; if only they’d listened to your vision…you wouldn’t be condemned to grabbing a pizza later because you’re still starved.

The point is — and I’ll expound on this later — communication is huge.

Everyone can agree that outsourcing and globalization are powerful game-changers in today’s business world. Although Thomas Friedman made his case for this with 2005’s “The World Is Flat,” I actually got my first inkling of the possibilities of outsourcing over a decade earlier after reading “Decline and Fall of the American Programmer” by Edward Yourdon. Around that time, I was living in Russia and working with developers in Arkansas, a fifteen hour time difference, so I was already getting a taste of distributed development and how it could work. Later, after working in Ukraine for five years at another company, I started Softjourn in 2001 with a partner in the U.S, who had also worked for years already with software development teams in Israel and in California.

One thing I’ve learned along the way is that communication is both the challenge and solution when it comes to distributed development. Our business model is very much focused on communication and working directly with customers so that they’re heavily involved in the step-by-step process, continually seeing the results of the work. Certainly, we follow an Agile development methodology, which a lot of companies do, but we’re more involved. We don’t do only one month iterations, making it four weeks before showing customers what we’re doing, only to have them say, “This is totally not what we were expecting.” We want them to be heavily involved from day one and seeing results very quickly.

This emphasis on communication extends to our developers as well. A common concern among customers is language. Since most clients speak English (and that’s the business language we mostly use with customers), English language skills are something our multistep screening process takes into account. That said, we also want good people who are technically skilled. To balance these needs, when we bring people into our company, in addition to training them in our processes, we also test their English proficiency. They’re then put into an English level group with classes specific to their needs.

Communication doesn’t just stop at language proficiency. We place a heavy emphasis on how we work with clients, what kinds of questions to ask. That’s because they’re really working more as consultants — when we’re talking with customers, we are not just saying, “OK, tell me what you need to have done.” We’re asking the right questions to make sure that we can help our clients in the best way. That kind of consultative style is something we stress and also try to train and instill in our team.

Ultimately, our approach toward communication is definitely a strong point and something that differentiates us from other companies. And that’s not just me talking — it’s what our customers tell us.

One reason I have heard for why outsourcing has failed is “bad code”.  Now I can see that you do not want, and should never settle for “bad code”. As a customer, you should never settle for code that cannot later be easily maintained, that is not architected correctly, etc.  Also, of course you have a right to look at the code while it is being developed; it is your code that you are paying for. Certainly that should never be an issue. Often, however, when I ask exactly what was so bad about the code, “Why was it bad?”, the answers sometimes become a bit vague… I would expect to get answers which were more concrete, something like, “They wrote the app so that the entire survey was loaded in to memory, therefore the app could not easily be run on different telephones which had less memory.”, or something similar depending on the platform or the type of application in question. Or to hear a reason such as, “The developer did not document the code correctly, or at all.”

However, a more typical answer I hear is that it was just bad code (not from everyone of course, but often enough). Here in lies the problem I believe and I think you can see it too.  If you can’t define exactly what you didn’t like about it or what was not done correctly, then how would the developer know exactly what you wanted.  You may argue that you should not have to tell the developer to use common acceptable standards for the language they are developing in, or to comment their code, etc., with that I would definitely agree with you.  But if that were really the problem, then that is what I would hear from VP’s engineering or CEO’s of companies as the reason why outsourcing did not work for them in the past.  But I do not hear that, I just hear, “the code was bad”, which leads me to believe there is something else behind why it was bad.

So how do you get around this the next time you want to work with remote developers? There should definitely be a discussion of what you expect in the code, with the developers.  Telling them you are going to be looking at the code is one thing, well they should expect that you will look at it since it is your code and it will be delivered to you. But being more concrete as to what you expect as far as:  official coding standards to be followed, if your company has its own standards that you want followed, your expectations for code documentation, etc. Another suggestion would be to include as part of your weekly deliverables, or once every couple of weeks (at least at the beginning of the project), code reviews. Have the developer explain why they wrote something in a certain way. Also, if you expect architecture to be done as part of the project, or if you are not providing it, have the developer document the architecture and send it to you for your review, then have a discussion on it before the developer goes forward and starts writing code. Following a few simple methods of getting to the goal of having good code, can eliminate the “bad code”, and the frustration that goes along with it.

What do they all have in common? Credit cards.

More specifically, these merchants use what are known as automated recurring billing (ARB) platforms for merchants who use card not present (CNB) billing for their clients.

Parallel to this is a crisis in credit card payment declines.  Card not present merchants using ARB platforms suffer from payment decline rates of 10-20% of their subscription base due to a variety of factors, such as cards hitting their limits, cards that have expired, or cards that have closed.

This can take a huge bite out of profits when a merchant as to continually resubmit payments.

Card not present profitability solutions

CentreBack payments, a payment profitability solutions service for card not present recurring billing merchants, was founded by entrepreneur Michael Bradley, to solve this problem.

Traditionally merchants have used their own internal “re-try” logic when an attempted authorization fails. However, CentreBack realized merchants needed a more repeatable, quantifiable and strategic approach to managing payment recovery – a key component in managing the entire lifecycle of a customer.

CentreBack created a recovery platform that:
•    Increases the ability of firms to automatically recover failed payments
•    Seamlessly integrates into automated customer contact solutions, and
•    Identifies sales channels and/or campaigns which lead to higher decline rates

So how did CentreBack get to where they are today?

Force.com considered, then rejected

CentreBack needed to create an automated payment recovery platform to address this market problem, and turned to Softjourn, a software engineering firm, specialized in building sophisticated and secure payment processing solutions for demanding U.S. and European clients.

We helped them build a state-of-the-art product called Revenue Patrol which was designed to increase merchant’s authorization success rates by 25%. Initially we looked at Force.com, Salesforce.com’s cloud computing platform, on which to build CentreBack’s solution. However, we rejected it due to its lack of portability across platforms at the time.

Java based solution for portability and flexibility

Eventually we suggested to CentreBack that a Java-based solution, which is more portable across platforms, would give CentreBack more flexibility with the application.

As part of this project, Softjourn provided an end-to-end service that included design, development, testing and deployment of the Revenue Patrol application.

One of the key requirements of the platform was to develop the application in accordance with PCI Data Security Standards for payment applications. This includes security features such as:

•    Encryption configuration for credit card fields
•    Gateway configurations
•    Removing private data from completed or hard failed transactions.

We worked with CentreBack’s PCI compliance auditor to assure that all PCI requirements were met.

The delivery also included an easy to use business-user interface, an integrated analytics package, and a sophisticated rules engine to support complex business processes associated with exception management for payment. We ensured that Revenue Patrol was able to call out to third party contact systems, such as text messaging, emails, or IVR solutions.

The project development process and governance included mandatory weekly meetings for project status reviews, answering questions and solving any issues that may have arisen.

“I felt like there was a much more professional approach, distance did not become an issue, really the team understood the goals of the project.  A lot more collaboration rather than a one way push of here is what you need to do,” said Mike Bradley, CentreBack’s Founder and CEO.

The solution was built using Linux, PostgreSQL, Apache Tomcat, Sun Java SDK, as well as the Spring Framework, Spring WebMVC, Spring Security, Hibernate ORM, Jasypt + Bouncy Castle security frameworks.  Libraries included jFreeChart +ceWolf, Java Mail, Jasper Reports, Quartz scheduler and Apache commons.

Revenue Patrol was deployed in a PCI compliant private cloud using Rackspace as the host.

Conclusion

Revenue Patrol has successfully been launched and is now in Beta testing. The next step is to roll this out to a larger group of sizable card not present automated recurring billing merchants.

Solutions for sending money abroad have varied from Western Union and MoneyGram to smaller startup companies.

Viamericas (www.viamericas.com), a Bethesda, Maryland-based company, is one of the more innovative companies that have emerged to provide services for international remittances in Latin America and the Caribbean.

International money transfers using Check21

Viamericas had been using a Check21 system provided by a nationwide bank to fund remittances. The Check Clearing for the 21^st Century Act (Check21) of 2003 provides guidelines and standards in check truncation. Check truncation is the practice of using an electronic image of a check to substitute for a physical check when presenting to the receiving bank for settlement.

With its fast rate of growth Viamericas knew it would grow out of its bank-provided solution, and had to develop their own solution. But their network of nationwide independent agents had grown accustomed to their current system, presenting a challenge: how to create an alternative solution that was acceptable to their agents.

Developing a secure system to rival large banks

Viamericas needed to develop a system that satisfied their agents’ usability requirements, provided the functionality of larger bank solutions, as well as additional functionality that allowed them to become more competitive.

They turned to Softjourn, a development firm specializing in designing and developing secure financial applications, with headquarters in the United States and development facilities in the Ukraine.

Softjourn designed, developed and tested a centralized server application and a client check truncation application. They also worked with Viamerica’s current Check21 solution provider to design, develop and test the sending of electronic cash letters and the receiving of electronic returns files between the bank and Viamericas.

The new solution also included functionality which was not available with the current solution, such as the ability to put checks on hold automatically, based on system-wide restrictions established at the central Viamericas location.

An integral part of the new solution was to research, test, and recommend the appropriate recognition software to be used for the final solution.  Initially Softjourn created a long list of potential OCR (Optical Character Recognition) vendors; including open source vendors and large-scale commercial products. The Check21 application being developed was to replace the one that Viamerica’s was paying for on a subscription basis, from their bank.  That solution included high-end OCR recognition including recognizing CAR – Courtesy Amount Recognition (the amount in characters) and LAR – Legal Amount Recognition (the hand written amount). The solution Softjourn chose also had to take in to account that almost 50% of the checks processed by the new system were going to be hand written, so the OCR software would have to be able to recognize the amounts on a lot of different checks. Having a .NET version was also a requirement as the new Check21 system was being written in .NET.

Some of the vendors evaluated included:
http://www.altova.com/download/authentic/xml_db_form_editor_desktop.html
http://www.dart.com/products.aspx
http://www.infragistics.com/dotnet.aspx
http://www.leadtools.com/SDK/Raster/Raster-Products-n.htm
http://www.visionshape.com/Evalrequest.aspx

As well as several higher-end solutions:

http://www.miteksystems.com/products_quickstrokes.asp
www.a2ia.com
www.orbograph.com
www.byteway.it

Evaluation included installing all of the different products, creating test image files based on real check images, supplied by our client, and comparing the results.

After initial results and creating a short list of possible vendors, Softjourn recommended the QuickStrokes Banking Edition, from Mitek. The product included ICR (Intelligent Character Recognition), OCR, MICR (Magnetic Ink Character Recognition), CAR and Business LAR. It did not include hand-printed LAR and was therefore less expensive. Mitek did have a QuickStrokes Premier Banking Edition which could read the LAR field, but in most cases it was not necessary. Recognition results averaged 92% with the Premier edition and 78% with the regular Banking edition.

Using bank functionality to compete with banks

Check truncation systems are usually the realm of banks, but smaller firms, such as Viamericas, can also use this functionality.

Softjourn helped Viamericas develop their own system, allowing them to compete more effectively against their competitors and larger banks.

Luis Gonzalez, CFO of Viamericas, said: “This project puts our company in a competitive advantage with regards to our competitors because we were able to emulate what large banks are doing quickly and effectively even before some of them launch their own product, providing unbanked customers with the means to use financial services.”

Their agents also liked the solution.

Esteban Bernal, Viamericas’ VP of Engineering, said: “Our agents like working with the new Viacheck system over our old solution. Their work is consolidated on a couple of screens making it much easier for them to use.”

Conclusion

The United Nations estimates that 191 million immigrants send money to relatives back home.  The World Bank estimates that $550 billion was remitted globally in 2008.

This is a huge market with a huge opportunity for financial services providers, and advances in technological solutions making it easier to securely transfer and process money abroad, has enabled more firms to take part in this lucrative market.

But financial processing applications are complex. If you want your share of the billions traveling back and forth across borders, you need the right partner to help you.

Back then I wrote, “Most information on outsourcing, books written lately, magazine articles and blogs have been geared towards larger companies. On one hand this is great, it is great to learn from the big guys who have been doing this a while. On the other hand, it leads to a lot of discussion on areas that may not be applicable for a smaller firm who needs 2, 3 or 15 persons offshore, not hundreds.”   The idea behind the blog was to provide information to entrepreneurs with new company ideas, or smaller firms who would have smaller teams of software engineers.  I emphasized the objective with the tag line, “Outsourcing is not just for the big guys!”

In order to determine if this topic was still relevant, one of the things I looked at was what Softjourn’s clients have told us over the years.  Six years ago the quote from one of our start-up clients was, “My fears and concerns (with offshoring) where alleviated by having a local contact who was not just relaying information back and forth but who seemed to understand that he needed to have a firm grasp of my goals before assigning the work overseas. Every attempt has been made to provide an excellent product. Issues were addressed promptly and through the entire process I felt that I had a partner not a contractor.” So clearly there is concern over the location and the distance.

A more recent quote from a client looks like this, “It was great to find someone to work with us as a collaborative partner. We have never done this before so sometimes we didn’t know what we were asking for and we were figuring things out as we went along. When you’re creating something totally new it is absolutely necessary to have a partner offer suggestions, be proactive, and think 3 steps ahead instead of merely executing what we said. I can’t thank you enough!” Obviously more recently, there is less emphasis on where the people are, and more on how they can be an effective partner and assist in getting a company, or a new service, up and running.

When I first started this blog, it was less common for smaller companies to want to work with remote teams of software engineers. Start-ups especially though, we are working too fast, how can we work remotely? Now, however, it is expected that start-ups will work with remote teams; it is considered basically obligatory. It is also more and more common for smaller companies to have team members all over the world. But with the move to more global teams, there still comes the challenges such as: managing time differences, collaborating with individuals in multiple locations, making sure everyone is on the same page, managing different sets of goals, and so on. This blog has always been about helping start-ups get their businesses launched and helping small and medium sized businesses add new services and improve on their current ones.  Going forward I will be placing increasing emphasis on helping these same companies overcome the challenges they are facing while trying to grow their businesses with global teams, after all, “Global teams are not just for the big guys”!

Point number one in the counter presentation: open source software is safe – safer than proprietary solutions, such as Microsoft, which are often rife with security loopholes (noting of course that it does depend a lot on how the application is built).

Hundreds of security and financial transaction applications have been built using open source development tools and frameworks, and supported by open source operating systems, application servers and web servers.

Modern, cost-effective online payment processing solutions for merchants

Case-in-point: startup company Noca, a California-based firm, has developed an innovative online payment processing solution that enables merchants to start accepting payments online right away and avoid the high fees of credit and debit card processing systems by offering a new type of electronic checking solution.

Offering near instantaneous approvals of merchant accounts, the Noca system avoids the pitfalls of traditional e-check systems by offering identify and account verification services as an online, in stream process.

This is ideal for merchants who were previously skittish about using an electronic checking system due to the inability to automatically and instantaneously verify a payer’s identity.

Help developing a testing environment

To get their new service off the ground, Noca needed to develop a comprehensive testing environment to allow potential merchant customers to test out the system before committing to the service.

The project required deep knowledge of several open source development tools and frameworks, and detailed coordination of several intricate pieces that comprised the complete system.

For example, Noca needed to:

• Develop and integrate credit card processing
• Develop a plug-in for Ubercart ecommerce shopping cart
• Set up complex email processes, with specific event handlers using an upgraded email system
• Improve their notification system
• Modify their marketplace functionality
• Develop security features such as the use of PIN numbers

Noca decided to turn to Softjourn, which specializes in developing financial transaction applications, front-end development, and open-source software.

Complete secure open source solution

Using tools such as an open source application server, Dojo and Eclipse development frameworks, Drools business rules management system, and other open source web service frameworks, Softjourn developed a complete testing environment for Noca.

Noca’s CEO PJ Gupta was so pleased with the work our partner did they decided to extend their assignment to work on core payment processing applications.

“I have been very pleased with the work that Softjourn has done to assist us in getting our testing environment in place for our clients, and I look forward to continue to work with the team!” Said Gupta.

So is open source secure?

Though it sounds counter-intuitive, having hundreds if not thousands of developers worldwide helping to make open source development tools and platforms secure makes open source a more viable solution than proprietary technologies.

cutting-edge online payment processing company Noca is betting its whole business model on open source software.

But if you want to build your financial application with open source software, and get it right the first time, contact Accelerance, and we can arrange for an interview with Softjourn who specializes in developing open source financial applications for some of the most demanding financial services firms today.