It means "Enterprise Services Platform", its basically the codename we use to identify the "Hornbill Platform", previously used as an internal development codename.
Hornbill is a layered application which at a high level looks like the above image.
The Hornbill Cloud environment is our own version of cloud services, conceptually like Amazon or Azure Cloud Services (database, storage, compute, front end servers, other infrastructure and all that cloudy sort of stuff) but highly optimised just for our own software stack. Unlike most SaaS vendors at our scale, we have always run our own cloud environment on bare metal, in co-located data centres in various regions around the globe, this gives us certain economies of scale, as well as full control over our own security posture, scalability and cloud services selection, without crippling ourselves with what can be very significant recurring costs for cloud services that a lot of SaaS companies will suffer as they scale. We do also use traditional cloud services for some things, primarily backups and resilience type requirements, and today services like AI too. The technical people at Hornbill that build, maintain and support our cloud environment are basically very experienced DevOps engineers with expertise in software systems, networking, internet technologies, all things Windows and Linux operating systems, enterprise storage as well as cloud and enterprise security systems and practices.
The Hornbill Platform is the base of our application layer, its where all the Hornbill core capabilities live, like email, workflow, integrations, automations, administration, and low-level technical stuff like authentication (SAML, OAuth etc), the app store for deploying applications onto the Hornbill Platform, and a myriad of modules and functional capabilities that make it possible to build applications without application developers having to create all this reusable functionality. The platform without an application does not do very much thats useful, until you install one or more applications onto the platform. As an analogy, think about your mobile phone as it comes out of the box, it can make and receive calls and thats about it, it deals with all the technical issues like radio comms, encryption, storage, basic phone and text functions and so on, and it has an app store, you use that to install the apps that you want on your phone and it becomes a personal hand-held computer thats meets your own personal needs. You can think of the Hornbill Platform like the Phone ready for you to install the business apps that will make Hornbill useful for your own specific requirements. The technical people at Hornbill that build, evolve and support our platform are focused on things like platform capabilities, performance, scalability, enabling application developers with tools, systems, processes, build, test, deployment systems, testing tools and systems, test automations, common functions, modules, services, API's, integrations, security and cloud enablement technologies, as well as our CoreUI (the screens you see when you log into Hornbill), there is also some technical overlap between the Hornbill Platform and Cloud teams, often working key services, protocols and other deeply technical issues/implementations.
Hornbill Applications, like Service Manager, Customer Manager, Project Manager, Boards Manager and so on, are business applications, focused on a specific set of capabilities. It is these applications that we actually sell to our customers. The basic idea is, the Hornbill Platform aims to abstract away all of the technical complexities of building complex, scalable SaaS applications, allowing our application development teams to focus on the application domain instead of the low-level complex technical details they would otherwise have to implement themselves. Application developers do not need to worry about the intricacies of how SSO or Email protocols work or integrate, or how our software deployment, test automation, distributed front ends, infrastructure, databases, storage and so on, thats all taken care of in the lower layers of our solution stack. Instead our Application Developers can focus on the application domain, customer needs and business value delivered into that specific domain, for example Service Manager supporting a customers ITSM requirements.
Hornbill has multiple roadmaps, this is because each layer, and each application, generally speaking has a different team behind it, each layer is basically developed independently of any other layer or application, so Hornbill software gets developed and released at different rates depending on requirements, customer base and so on.
Our approach solves many problems for us, enables us to scale, gives us great economies of scale too, but its not perfect, keeping teams focused in specific areas can be a challenge, dealing with interoperability differences, change timings and synchronisations, inter-app dependancies and integrations, shared code, components and other things like that, all present a unique set of problems that we have to deal with that a single monolith application does not have to be concerned about. On balance, what we do works well for us, has enabled us to scale effectively and continuously evolve, innovate and add value for our customers.
