In part two of this series we discussed what technology factors are important, so to close the internal apps series, we’ll discuss the architectural issues and the technology approaches which we think are required to make these efforts successful.
An important part of building your next killer app is to understand what services and resources the app will need to consume, and how that will affect the way the app is architected. Here are some considerations:
- What deployed services will you need to take into consideration for integration?
Understanding the current solutions inventory is very important as it gives visibility to what’s already implemented and available for use. Insights into your inventory will reduce the time to delivery as this is something that does require implementation from scratch. It will also make it easier to understand what’s needed to be implemented.
- Are you connecting to a legacy app/service?
Connecting directly to a legacy service is risky. The preferred approach is to create a proxy service that provides an indirect link to the legacy app and provides an abstraction that UI developers can connect to. This approach also opens the ability to scale the app as needed by spawning multiple proxy services. At this point the question would be how well the legacy app scales. If there are any scaling issues, proxy service mechanisms can be put in place to mitigate some of those issues.
- How many users will the app need to support?
The number of simultaneous users that your app will need to support, will drive how the app is structured and deployed, including the need to consider multiple instances of micro services, and how that ties into the internal systems.
Large monolithic apps are brittle. They do not fare well with change. Deployment becomes a major headache as you can never deploy only the change you need. You must deploy the whole app. Also, they are not easy to test, which is a critical consideration when building your app, particularly as you move towards a CI/CD world.
Think in terms of micro cervices. Small specific services that provide one function. This approach makes it easier to test, easier to deploy, and enables developers to be working on separate services without any interference.
Micro services can also be used to hide the complexity of legacy systems by creating a synthetic services layer. In turn, this approach allows for the implementation of the micro service to change without affecting the consumer of that service. Ultimately, micro services are critical to creating killer apps as they facilitate faster development and continuous deployment and produce overall more robust solutions.
We recommend building small re-usable components that can be tested and made available to other apps via package management – and you should do the same with your micro services. Low cohesion between components is vital as it reduces testing risk, i.e. we want to be able to test software components in isolation, with predictable results. Providing a library of small re-usable components that are easily accessible allows for other teams to take advantage of the work that has been done.
When you start thinking small and components, it sets up the ability to provide architectures that will scale with use and are easy to maintain. Part of building a killer app is to ensure that the architecture will scale and maintain a consistent performance profile.
Technologies and processes
There are several key technologies and/ or processes that should be part of your approach to building killer apps.
A container is a light weight, standalone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries and settings. Containers isolate software from its surroundings, allowing for containers to be run anywhere with the same results. Docker is a prime example of a container, more lightweight than a VM, and scriptable. This is a vital tool in your arsenal as it allows you to build very quickly environments that mirror UAT, production, etc. Also, as a development tool it’s awesome as it allows the developer to isolate themselves from the OS. A good example of this isolation is the ability to run Linux processes on Windows, and the extensive library of images that can be used as a starting point for your own containers.
A package is a collection of code that provides useful functions to the developer. Packages are versioned, so there is control over what version should be used. A package manager is responsible for ensuring a consistent approach to how packages are downloaded and made available to the developer. As apps become more complex, it ‘s necessary to be able to manage the large number of packages that it needs. NPM and PIP are examples of package managers. Both ensure that any dependencies are downloaded and available to the app, which is typically done in a build step so that once deployed, there are no external dependencies that could break. Removing external references is important as it removes the risk of external references becoming unavailable at runtime and as a result causing your app to fail.
Continuous integration / continuous deployment
CI/CD is an approach/process that provides immediate feedback when something in the development process fails, i.e. tests, code quality checks etc., whenever code is changed. Anything that passes becomes a candidate for being released to UAT/production. This process is fundamental for building killer apps. There are many options available to you such as GOCD, Team City, Jenkins and a host of additional ones. Essentially, they all do the same thing, i.e. to orchestrate the retrieval of source, build, test and deployment of your app in an automated manner. By adding additional tools that verify code quality and style, it further adds to the overall quality of the app.
Building killer internal apps is not business as usual. It requires significant ongoing investment from management and requires training for the current staff. Technical proficiency aside, the roles that are being created require support from management. A fundamental shift in corporate culture is necessary to make it possible for these killer apps to be built. Part of that shift is the move away from a culture of blame to a culture of transparency and collaboration. Everyone involved in building the next killer app is responsible for the success of the endeavor. Some considerations:
- Change in roles and skills
As the process of software development changes, developer roles and skills need to reflect these changes to formally tackle these organizational changes. Training is key as is understanding what metrics are needed to allow for the continued monitoring of roles and how the employee is compensated for success.
- Micro services
Where should you manage the micro services that you are building? There are two parts to this question. Clearly, it’s the responsibility of the business unit to drive what functionality is represented by the micro service, while the business is responsible for clearly defining functionality. Once it’s ready to go live, the IT group deploys it, ensures that the service is started if it stops, collects the information log and spins up extra services when necessary. IT should provide a runtime environment, that the business can deploy to, with runtime parameters as dictated by the developer.
- Commonality / cost & control
Building common software that can be used across multiple projects has a price tag. Documentation and samples need to be provided, along with ongoing bug fixes and enhancements. Visibility throughout the organization must be high. There must be a compelling case for developing common components given that there is additional cost associated with them. Evangelists are important to demonstrate to other teams through out the organization what value these common components can bring to their development offers. As part of this process it’s crucial that they take suggestions and provide a fast turnaround time for the feature so that the case for building one’s own solution is drastically reduced.
Front and foremost to any killer app is the user experience. If the experience does not meet user expectations the app has failed - irrespective of how good the backend functionality is. It’s critical that throughout the app software development lifecycle there are as many touch points as possible to allow for UX/UI testing. The use of continuous deployment facilitates this rapid turnaround, so that concerns from the user community can be addressed very quickly. It’s important that there is a continuous process from idea through implementation and iteration to provide as much transparency as possible. This ensures that all involved are working toward the same end goal.
These are key pieces of digital transformation of an existing enterprise: modernizing the interaction to the same level that users experience in their internet world, wring out productivity by organizing interaction to match workflows across the organization not just system silo’s, structuring the architecture to allow for rapid/constant change, and finally moving the development process and its allied organization that is itself more responsive to business needs, and more productive.
Share your thoughts with us.