Enterprise Software Development in 2018

This post was written after a discussion with a co-worker on the most suitable (yet adaptable) model for large-scale enterprise software development from architectural, team & technical perspectives.

My three core values remain consistent throughout the years: build to scale, pivot and team foundations & values are everything.

Starting Out

Firstly, let’s think about what we are trying to achieve when forming a strategic model for a new product or service:

  • Build a relevant & adaptable product that will scale with user growth.
  • Build or extend a team to help you when that growth happens.
  • Keep that team happy, collaborative & productive, after all, collaborative teams are productive teams.

And from a strategic perspective, how to achieve that:

  • Know that architectural decisions & team strategy are directly linked.
  • Empower your team with upfront standards, tooling, mentorship & clear deliverables.
  • Consider containerised, microservices-first approach in order to unbind yourself from specific frameworks & languages.
  • Be ready for next.
  • Deployment first.

Deployment in Strategy

The rise in adoption of continuous integration & delivery over recent years has provided software companies a competitive advantage by being able to build pipelines that allow them to iterate fast and deliver value to customers by releasing live to to production in minutes, not days, so absolutely deployment in strategy. In fact, DevOps everywhere!

2008: You release every two weeks? How agile!

2018: We need that feature live in about 15 minutes. Kthxbye!

Of course, it depends on what you’re building and your target audience, but if you are creating a commercial application and you have competitors and/or customers with high expectations (who doesn’t?), having the ability to adapt, change & innovate is key to the success of your product.  Although this has pretty much always been the case, improved tooling and technologies mean your competitors will gain advantages if you can’t keep pace with change.

So that’s all well and good in theory, and you already know that DevOps is an important part of any software team, but isn’t that going to be quite hard to do at scale, and with the rapidly changing pace of technology?

Yes, that’s where we start to look at the piece between software and DevOps: stack abstraction through containerisation!

But let’s not go straight there…

Development Approaches

When it comes to specific software development techniques, the industry moves so fast, that while a seasoned professional should be able to speak confidently about most technologies, even the most experienced developer or team lead can’t profess to know it all.

This has led to a shift in development approach from single-platform/framework, dictated by the technical lead, through to polyglot architecture (still defined by the technical lead, but slightly less of a dictatorship!)

Here’s an anecdotal timeline of architecture trends in commercial software development:

2007: Proprietary all the way (letting developers in)

2010: A healthy mix of propitiatory & open source with API

2012: API first design

2016: API driven micro-services, improved CI/CD

2018: As above, but containerised & pro-polyglot!

Where to start?

So building a solid team is underpinned by platform & DevOps, even if there are just a few of us?

Yes, and no matter what size you are, go on aspirations. If you have the advantage of having (or having access to) a strong team, it’s team & process first in order to keep everyone on the same page, and to remove the overhead from test, build & deployments.

Processes & Systems

If you have the resources,build our your process with maximum visibility in mind so you can get out of your team’s way and let them do their jobs, setting clear and transparent expectations and deliverables. If you don’t have the resources, do exactly the same! Build out your model as if you do, if you can commit the time upfront.

There are plenty of tools available to help a startup match the tech stack & pipeline of a fortune 500 company. It’s an even playing field.

Team Formation

So, to the team formation part…

As Patrick Lencioni says in “Five Dysfunctions of a Team“:

Not finance, not strategy, not technology, it’s teamwork that remains the ultimate competitive advantage.

A technical leader should understand the various different approaches to building a scaleable & maintainable development model, from both a technical and team perspective, and select the programming model and tenancy model is a crucial part of building a team that gels.

The rest, DevOps, feature planning, etc., can then fall into place. I’m not going to cover that in this article!

So, here are three approaches for structuring your teams at the highest level:

Architectural Strategies

Polyglotism Architecture (Free-for-all)

Letting your team develop the solutions your business needs using the technologies they are best at. This is a scary solution for leaders, both technical and non-technical, due to the fact that that it might not always be easy to maintain the skillsets required to maintain your products.

Upsides: Your team is free to use the skills they’re most comfortable with. Your team will probably be happier, programming with the tech they love, and you’ll get a better product.

Downsides: Skill fragmentation, hard to manage, DevOps role is crucial to keep some control over project, so might not suit everyone.

Platform Architecture (controlled free-for-all)

This model involves selecting a core platform which will accommodate most of your needs, but doesn’t restrict your business to a technology per application within your business. With Docker support in Windows Server 2016, this approach is becoming increasingly popular in corporations, as well as small teams.

This way, your team are slightly more free (than using a specific language or stack) to create on their own terms, but having a defined platform at the base provides a little more structure and organisation.

It’s almost the opposite to the free-for-all approach described above and makes things easier to manage under a single platform.

Upsides: Be less fussy about the talent you hire, easier to maintain with common base

Downsides: Might not suit smaller teams

Propitiatory Architecture (closed)

Closed (or vendor specific) software gets a bad name in 2018, but if done correctly and opened up to developers, it can be the right choice in many situations, especially when building a platform.

Upsides: Go deep with industry specific features, entire team on same stack, easier management, better stability if everyone in the team can support it

Downsides: Vendor locking, technology locking, harder to change if entire platform is based on one technology

Note that my thoughts below don’t cover the product side, which is roughly covered here.

DevOps: Remove the space. Make better products.

The route to DevOps is a cultural shift which is integral to the success of any software business.

You might not do it all right now, and that’s fine.
You might do some parts well, and some parts not so well. That’s fine too.

Extending DevOps is a journey, with the end goal being connecting the same principles & practices you do with your development teams to the rest of your business, ultimately creating a scalable workflow, manageable team cadence and by becoming more responsive and agile than before.

Let’s start by looking at what DevOps might look like to a typical developer:

  • Utilising version control & issue tracking
  • Employing software-driven IaaS management
  • Continuous integration
  • Automated deployments

You’re probably asking how we roll the above out to non-technical teams, however, the principles in each of the practices above can be implemented around existing frameworks & systems in use by project teams and can augment support processes and even help boost your sales function.

All too often, development, product, and operations teams work in silos, with too little discussion around the important stuff;

  • Are we focusing our energy on the right things?
  • Is the solution to this problem adding value for other customers?
  • Where is our product going?

DevOps is about inclusion, and we must fight spell check’s urge to put a space in between the two words comprising the portmanteau!

DevOps

REMOVE THE SPACE.

So we know roughly what DevOps looks like from a software team, but how do we implement it throughout the company?

I firmly believe it comes from the top, and by introducing better communication channels between historically disconnected teams.

Ops, Meet Dev

The main benefit of getting your operations team on board with DevOps is cohesion. It’s probably fair to say that your operations team doesn’t want to be looking at JIRA boards all day, just as your development team doesn’t need to know each and every thought. However, agreeing on a common toolset and having buy-in to ensure this is used correctly is a great way to ensure that both teams work together to ensure the delivery of relevant and high-quality software.

The result of doing this is that it breaks down the traditional barriers and ‘God complex’ which sometimes breeds in development teams by bringing everyone, from the product team to the support people into the product design, development and QA process.

At Layer Systems, we use Aha! as the conduit which brings the teams together.

Dev, Meet Ops

So you’ve got your systems (close to) perfect, what next?

Speedy code shipments and quick feedback loops are what most developers working in a team want: their work gets from their workstations to users’ screens much faster and continuous delivery enables faster iteration and product improvement.

If you’re just getting around to implementing DevOps, why not set up a few key metrics to check if it’s working for you as you transition:

  • How quickly does it move from ‘done’ to release
  • How often are you deploying to production
  • How much manual intervention does a deployment need

In Summary

Start small with the cultural shift.

Implement tried and tested processes within your development team, and then look for buy-in from your operations team and repeat.

Then you’ll be one.

Layer Case Study – Voice2Voice

My name is Warren Stroud and I am the Managing Director at Voice2Voice Ltd. We are a international business that have been in business since 2003. We concentrate on multi-site organisations, supplying them with their telecommunication infrastructure and services.

The reason why we selected The Layer was to move away from various other programmes like Microsoft Dynamics, which was running our CRM, various spreadsheets, which were running the back office side of things, and various subscription models that handled all of our quoting processes.

From an order management perspective we never really had something in place that could take the equipment quoted within a proposal and follow that right through to invoicing. The Layer addresses that perfectly with barcodes, scan readers and a simple process of taking an order and processing through from a customer services perspective.
The Layer captures every bit of information that is needed here at Voice2Voice. The dashboards give us a good idea of what’s happening within the organisation. Our sales dashboard can tell us prospects, to quotes that have gone out, and even margins that can be made on the various deals that are out there. Help desk dashboard gives management information on cases that need addressing urgently [inaudible 00:01:33] being breached and general customer service.

My recommendation for someone who’s looking to change their CRM package, especially in the telecommunications industry, is to be quite wary. There are a lot of products out there, we’re a prime example of a company who used many of the products that are out there. When we found The Layer, we now know that it encompasses everything that an IT support or telecoms company requires in order to run their business.

I would definitely recommend The Layer to anyone who’s interested in it. It has brought this business to a new level with regards to profitability, efficiency and customer service.

Layer Case Study – Tru Solutions

I’m Mat Whyman, head of marketing, and key account manager for Tru Solutions. Tru Solutions are a complete business communications provider. We offer mobile, fixed line data, and managed services. We originally started looking for a quoting tool, and looked at two or three different processes. We also were interested in the CRM. When we saw what The Layer did, it was a no-brainer. The Layer took us through every process in the business we were looking to improve.

So our key business issues were finding an easy to use quoting tool for our sales guys, as opposed to producing a commercial report or template separate to that, and having no control. I think we wanted a system where the quoting was easy. So The Layer helps us solve our issues by condensing multi-supplier price books, products, and offerings into one platform.

The sales order process has also given us the ability to be able to track where we’re at in the process of completing the sales order. We’re not having to duplicate anything for capturing, for data capture. That converts through from the sales order process, which converts through from the quote. So there’s no room for error.

So from a management perspective, The Layer has given us a higher view of everything, from telesales operation, to booking appointments, where we’re winning, and where we’re not winning. Where we need to change, through to what sales activity we’ve got going on. Who is busy? Who is not?

The main benefits that we’ve seen since using The Layer are move effective on renewals, and at the point where we renew it ahead of time, as opposed to after events. That daily interaction with our customer base is invaluable. Also, profitability, we’ve actually increase profitability since using The Layer. 2015, we have 95% feedback from our customer base on the cases that we manage, which we thought was excellent. 2016, it was up to 97% positive feedback, and 2017 to date, is currently at 98% feedback. So it is helping us progress and to learn from our mistakes.

From a support and training perspective, The Layer came down and spent quite a bit of time with our staff, and took them through the modules that they needed training on, introduced them to the system fully, and then have since supported us impeccably since we went live. So I’d definitely recommend The Layer to any commerce business. It’s given us a streamlined process. It’s given us a condensed view of multi-suppliers, multi-clients, all in one place, and it’s given us control. It’s empowered Tru Solutions.

Removing bottlenecks in smaller software teams

Juggling innovation with day-to-day maintenance in a small software team can be challenging. Staying innovative & creative is key to ensuring your product or service stays ahead of the competition.

Here are six key points to ensure your software team can support & maintain your product and continue to innovate:

  • Split development work into streams to achieve faster development speed. Team A works on new features & Team B gets bugs, fixes & improvements.
  • Ensure your software delivery lifecycle is open and transparent using tools such as JIRA, Confluence, Bitbucket (formerly Stash) and of course Crucible for peer review. Take it all the way to the product team by introducing roadmapping software like Aha! into the mix to guarantee consistent flow from concept to delivery.
  • Promote good team practices such as version control, build & release automation, testing & good documentation, both in your comments, APIs and manuals.
  • Ensure you (or your DevOps manager) communicates the constant changes in workload & customer priorities carefully with as little impact on the team as possible.
  • Create an automated user-testing workflow that works with your build process to reduce the “end of sprint” impact on your team.  This creates a third testing stream which runs alongside your development streams.
  • Talk to sales & operations teams and ensure your systems talk to each other too!  Avoid duplication of work and get your specifications into one place.

Web Application Security Testing Tools

Port Scanners

  • Nmap – general port scanner

 Vulnerability Scanners

  • Nikto and Wikto – web server vulnerability checkers
  • Nessus – general purpose vulnerability checker
  • WebInspect – web application vulnerability scanner
  • Absinthe – SQL injection testing tool

Information Gathering Tools

  • SpiderFoot – footprinting tool
  • wget – site duplication tool
  • Offline Explorer – site duplication tool
  • WinHTTrack – site mirroring tool

Web Proxy Tools

  • Paros – local proxy and data manipulation tool
  • Spike proxy – proxy and data manipulation tool
  • Fiddler – proxy and data manipulation tool
  • Web View / Syntax View / Timeline – Fiddler extension
  • Burp Suite – proxy and data manipulation tool
  • POSTHook – IE plugin to manipulate POST data
  • TamperIE – IE plugin to manipulate GET and POST data
  • Webproxy – proxy and data manipulation tool
  • Webscarab – proxy and data manipulation tool

Browser Tools

  • IE, Chrome, Firefox, Opera – browsers
  • Mozilla Web Developer Toolbar – browser tool
  • IE Developer Toolbar – browser tool
  • Mozilla IE Tab Plugin – browser tool
  • Firefox Tools
  • HackBar – encoders/decoders
  • Web Developer Toolbar – modify objects in web pages
  • Tamper Data – manipulate HTTP data and headers
  • Firebug – modify HTML, Java, and CSS in the browser
  • Grease Monkey – add user defined JavaScript to a web page
  • Switch Proxy – allows easy switching of web proxies
  • FoxyProxy – regex based smart proxy selector
  • Edit Cookies – cookie editor
  • XSS-Me – cross site scripting tool
  • SQL Inject Me – SQL injection testing tool
  • CookieSwap – cookie editor
  • RoboForm – caching form data for testing

Cookies / Session Manipulation Tools

  • Cookie Pal – Cookie capture and viewing tool
  • CookieSpy – Cookie manipulation plugin for IE
  • IESpy – Cookie manipulation plugin for IE

HTTP Request Generation Tools

  • netcat – raw packet generation tool
  • wfetch – raw HTTP request generation tool

SSL Proxy Tools

  • openssl – SSL programming toolkit
  • stunnel – SSL proxy tool

Password Guessing Tools

  • Brutus – multi-purpose password brute forcer
  • Webcracker – HTTP authentication brute forcer
  • Hydra – Brute force password guessing tool for HTTP, FTP, etc

Decompiles

  • JAD/Jode – Java decompiler
  • Reflector – .NET decompiler
  • Reflexil – Add-in for Reflector used to modify decompiled .NET code
  • FileDisassembler – Add-in for Reflector to export .NET code to Visual Studio

Miscellaneous

  • fpipe – traffic redirector
  • lynx – text browser
  • curl – web client tool
  • Dave Proxy – proxy tool used for thick client applications
  • Dave – WebDAV tool
  • Cadaver – WebDAV tool
  • SSLDigger – SSL cipher strength checker
  • THCSSLCheck – SSL cipher strength checker
  • Perl, Python – coding tools for custom scripts
  • Twill – scripting language for web browsing