Founded in 2011, Philadelphia, PA-based Arcweb is an enterprise software development firm that specializes in mobile and cloud computing. Arcweb’s team is experienced in product management, agile software development, and lean startup methodologies, and helps clients to manage the product lifecycle, including design, architecture, development, deployment, and support.
We recently had a conversation with Chris Cera, the CTO at Arcweb about balancing security and usability, building new products, and the evolution of development practices. Here is our conversation:
DevOps.com: Can you tell us a little bit about Arcweb?
Cera: We specialize in the product design and development of enterprise software. The majority of the work that we do, from a vertical perspective, is in financial technology solutions. We service three micro verticals within financial technology. One is bank operations, which people sometimes call retail bank operations. The second is investment management software, so we do a lot of broker–dealer and broker and financial advisor software. And the third is insurance, such as claims management, sales enablement on the insurance side.
That’s the majority of our business; the other side is general enterprise software. That runs the gamut of the business, including operations, marketing, and sales. From a technology perspective, about a third of our business is mobile application deployment – a lot of iOS enterprise-focused applications. We also do traditional web application software development.
DevOps.com: Well, since you’re there, let’s start there. I mean, what do you see as the key to obtaining that right balance among usability, security, and compliance?
Cera: Naturally, we encounter a lot of security-oriented scenarios, and we’re always dealing with challenges there. I find that design and security are almost diametrically opposite. If you want something that’s really usable, that usually means it’s also kind of insecure. In the banking space, this is a huge challenge for innovators and disruptors; you’re trying to build something that is easy to use but it also needs to have bank-level security. Usability and security are always on opposite paths, so we’re always toeing the line of those two worlds to produce products that meet those needs.
DevOps: When releasing a new app, or product, what separates successful innovation from ideas that fall flat?
Cera: It ultimately depends on the end users. They’re number one, and number two is the customer. We were recently working on a mobile application project that got killed. The risk, security, and compliance people killed it because innovation often scares people.
I think a lot of it comes down to education, because if a big company doesn’t do it, then a small company is going do that innovation. That’s a challenge for any large company: it wants to innovate in its space but it often is not really able to.
DevOps.com: There always seems to be a struggle between innovation and the status quo, so how do you bring security people in early in the design process?
Cera: It usually takes someone who is much more visionary at the customer site to push something like this through. That usually means the executives of the business need to really endorse what’s happening. Ultimately, it’s a very high-level business decision to make innovation work in a large company. The products I see getting killed are those in which product managers have a budget.
They’ll try a test market and the feedback on the product is great. Next, they want to get it through product governance, or whatever that company calls the division that has to approve any new product development. That’s where the product gets killed – that because someone who works in risk and compliance will give 100 reasons why it will cause legal or fraud risk.
DevOps.com: How have these challenges changed as development methodologies changed from those of 10 years ago to today’s agile and continuous integration/deployment organizations?
Cera: I would say people are getting smarter and smarter about how to launch software projects. I think if you looked at how many software projects failed 15 years ago versus how many fail now, I’m positive you’ll see that we’re learning how to increase the success and minimize the risk of projects. Obviously, there are always outliers, and failed projects, but we are getting better.
Also, agile software development has been around for 15-plus years, and a big part of that was focusing on tighter iterations and continuous integrations or continuous deployment. I think that’s largely believed to be a good thing, but a lot of the big enterprises still have not adopted it. If you have a large multinational workforce, trying to get them to do one or two week iterations is nearly impossible. There are just too many challenges with it.
From a security perspective, it also means that the security people who might have been invoked once a quarter to do reviews, penetration testing, etcetera, now need to be involved much more frequently. That means much more focus on automated testing tools. I mean that there has been tons of innovation on automated testing tools in just normal development cycles.
Good security just requires the investment and for the business to understand that this is how you have to invest time and energy into a project. Security tests would just be part of the building process. So, if you talk to agile project managers, everything is focused on iterations. The security test just becomes a part of the deployment process. Then, of course, you’ll always want to do some manual test. I mean that even though we tried to automate as much as possible, some tests are too expensive to automate, so you just need to have a trusted party run a manual test plan. We do that with every product we build.
DevOps.com: How do you like to start a product? Do you like to build a minimum viable product and just try it, see how people kick it around and use it?
Cera: For one of our customers, we literally went into coffee shops and just asked people to test out some apps for us. It wasn’t real data or anything; it was a simulation. We were trying to get a sense of whether the design made sense to the customers. Do they understand it? Would they actually use it? This is something that we specialize in because we’re oftentimes trying to prove that a business is viable rather than just assume that the product is viable and then just go build it. That is a huge assumption, by the way, and I think modern-day entrepreneurs know better than to assume straight off the bat that this product or this vision is going to work.
So, in my opinion, your first level of testing should always be a paper-based prototype thing to see if the business is viable. Then, you should create a vaporware mobile app.
Put it in front of you: you can actually click it; you can swipe; you can move it around; there’s no coding involved. I can have one of our better designers whip that up in like three days, whereas it might take me three months to have an engineering team build it. Then, test its viability. If it makes sense, move on until you’ve validated the business model and you’ve proven demand for the product. Now, you can have more confidence investing in the process.