Made in USA: Enterprise Application Services

Ringing PhoneCall Today!817-210-4042

application development Archives - Ayoka - Made in USA Enterprise Application Services

Ayoka brings American know-how

June 12, 2011

Ayoka brings American business acumen to apps development, systems integration

Manufacturing Business Technology
By William Atkinson, contributing editor (w.atkinson@mchsi.com)

The U.S. manufacturing industry has lost its share of jobs to overseas competition, so when these companies seek outsourcing assistance, they may well prefer to work with U.S. partners.

Arlington, Texas-based Ayoka offers an affordable onshore alternative for software outsourcing, targeting underserved industries such as manufacturing. For manufacturing in particular, Ayoka’s factory automation software and remote monitoring allow users to access data whereby the Web browser functions as the human-machine interface, providing much broader access to machine controls and monitoring. In addition to real-time responsive interaction, the data is warehoused in integrated databases for business intelligence and reporting.

“When people use the term ‘application outsourcing,’ they usually are talking about the application in a post-production environment,” notes Rona Shuchat, program director of application outsourcing services for Framingham, Mass.-based IDC. “However, when Ayoka uses the term, it is referring to the application development and/or systems integration of the applications.”

Shuchat says Ayoka is moving companies – especially small to midsize manufacturers – forward to the state of automation where they can control how to tie the front end of the process – i.e., the sales order entry piece – into the production flow, and then into the output side, including control of accounting and shipping.

“In sum, Ayoka can go into a company and identify where lack of automation is hurting the company, and make recommendations on how to create a more automated flow,” says Shuchat.

One company using Ayoka services is HelloLabels, a subsidiary of Safford, Ariz.-based DRG Technologies. HelloLabels makes product identification solutions for electronics and other products. Ayoka developed an open-source e-commerce system for HelloLabels, which features back-end integration with production work orders, inventory management, and shipping systems.

“When I was brought into DRG to launch the HelloLabels division, we didn’t have a Web site and wanted to do our main sales online,” explains Matt Milliorn, general manager for HelloLabels. “We sell through a number of channels, including wholesalers, dealers, and direct consumers.”
HelloLabels deployed an Ayoka system that allows the company to seamlessly address all three channels with a single system.

“We also use it internally to input orders that come to us via mail or other sources,” says Milliorn. “We’ve been able to take the process of quoting and ordering that once took two hours with back-and-forth communication to one where orders can be quoted and entered in about two minutes,” concludes Milliorn.


October 22, 2009

In software development, it is no great secret that things don’t always go according to plan. It’s a stressful job, to say the least, especially when things go wrong. I would not be at all surprised to learn that there exists a positive correlation between software development and rates of trichotillomania.

So what puts a project at risk, and how do we plan to deal with these risks when they occur?
Steve McConnell, the patron saint of practical software development practices, eloquently identifies some of the common problems that bring software projects to ruin.



As McConnell points out, in software development, optimism can be deadly. An optimistic, can-do attitude often leads to the creation of impossible schedules that puts projects at risk of failure. In order to mitigate this risk, it’s imperative that developers and managers alike adopt a healthy, pessimistic attitude. Plan for the worst and aim for the best. Don’t ever rely on luck or good fortunes to see your team through to the end. Optimism and hope is not a replacement for solid planning and risk management.


Software development companies often bow to the pressures of their clients and rush through the requirements analysis and design phases. This is always a mistake. Many studies show that the cost of repairing requirements mistakes outweighs the cost of repairing implementation mistakes by several orders of magnitude. Spend the time to get requirements right before starting even the design phase of the software. In the long run, it will save your company a bundle. And don’t take just my (or McConnell’s) word for it – there is plenty of plenty peer-reviewed research demonstrating the validity of these claims.


Gold plating occurs when developers and managers add features to software to make it “better.” This often occurs past the requirements and design phase, where the implementation of a new feature is far more costly than it would have been had it been planned out in the initial phases of the software’s development. Customers, developers, and managers alike are all responsible for this. Each stakeholder should take different steps to manage this risk:

  • Developers: it is the developer’s job to explain to managers what is possible and what isn’t. As most developers know, what seems like a simple change on the surface (adding a button that performs some nifty function) sometimes requires substantial modifications to a whole subsystem. Accurately estimate the difficulty of any proposed change and make sure that your managers are fully aware of what functionality may be placed at risk by the change.
  • Managers: it is your job to determine how important a change is to the software’s “mission” since they are the ones most in touch with the customer’s point of view. If the change is a convenience change, leave it out. It’s often tempting to add nifty little features toward the end of a project, but the road to hell is paved with good intentions. On the other hand, if the change is absolutely vital to the mission’s success, explain this to the developers so that they don’t take a morale hit from going back and rewriting old code.
  • Customers: customers are an integral part of the development team and the whole reason behind the team’s existence. It is imperative for project success that the developers know precisely what requirements they need to fulfill. Customers should review requirements documents carefully before signing off on them and not hesitate to point out any mistakes. Remember that misunderstood requirements cost tens to hundreds of times more than implementation mistakes.


Project managers sometimes fall into the trap of viewing software development as an assembly line process. It leads to the idea that if a project is behind schedule, adding more developers to the team will automatically bring the company closer to the goal.

This sort of thinking is horribly and fundamentally wrong.

McConnell cites a number of studies demonstrating that not only does adding developers at mid-to-late phase during a project not increase productivity, it actually detracts from it. The reason for this is simple: in any complex project, it takes time to bring a new developer up to speed on both the domain knowledge and the project architecture. Existing developers on the team must then spend some of their time fixing the inevitable mistakes made by the new team member and attempting to train the new developer.

So how do we manage this? The answer is fairly simple. Build your team immediately and then involve them at every phase of the project. A developer who was involved in the requirements analysis and the design phase will be more productive than a developer who is starting out with little to no knowledge of the project’s intricacies. Involvement is the key.


This risk tends to apply more to developers than to project managers. We’re a technology-loving bunch, on the whole, and so when a new framework comes out that promises to make our lives easier, we’re almost instantly ready to jump onto the bandwagon. So optimistic are we that we’ll gain productivity from the new technology that we revise our software cost estimates to reflect the expected productivity gains.

This is dangerous.

Although new technology often does increase productivity, it is not possible to predict the sorts of things that can go wrong with a new technology. It is also important to factor in time for training on the new technology, a facet of a developer’s job which is often underestimated.

While nothing is intrinsically wrong with trying new technology, it is important to be conservative with cost estimates when walking on uncertain ground. This ties in to the risk of optimistic thinking, outlined above.


There are many other common types of risk that fall well beyond the scope of a blog post. The important thing for developers and managers to do is to sit down with one another and draft a risk management plan. The trite aphorism is telling: if you fail to plan, plan to fail. Determine at the beginning of a project what might go wrong and how best to deal with the situation should it occur.

Following this strategy will result in better software for customers, lower costs of development, and fewer grumpy developers.