trellispark Breakthroughs


Identifying the issues in a solution and being able to accurately describe them is vital in coming up with a workable solution. There are several common problems that will come up every time a new project begins, and understanding these has fundamentally shaped the design of trellispark.

Business Requirements

It is in the nature of projects that requirements are going to change over the project lifecycle. Some issues will only become clear once something has already been built, and therefore cannot be anticipated before a design cycle ends.

Trellispark has solved this problem in a very logical way; rather than attempting to design yet another system to try and predict the unpredictable, we have predicated our technology on being able to make changes easily.

Iron Triangles

Everyone in business will be familiar with the concept of the iron triangles - the fundamental relationships between quality, functionality, and effort; and time, cost, and scope. It is a demonstrable truth that the resources poured into a project will affect what results you receive.

Trellispark accepts the immutable truth of this process, and takes it one step further. With an emphasis on effective minimalism similar to that described by Kevlin Henney, we have been able to maximise functionality and reduce effort by continually pushing to use the least code required.

As Mr Henney says, “Functionality is the asset; code is the liability”. A lot of code takes a long time to write, test, and implement. Trellispark has taken this “less is more” principle deeply to heart; we constantly work to streamline and slim down core code.

Security and Audits

All too often, security is treated as an afterthought to functionality. This has left far too many applications and solutions open to attack, and has in fact inspired a number of laws to protect customer privacy.

Trellispark makes security an early priority with an inbuilt system of firewalls, access controls, and user permissions that are stored within the data itself. Each row in a trellispark table has checks to determine if a user is allowed to call the row. Without those permissions data will not even be retrieved, let alone displayed.

This ensures that all data will only ever be accessed by a legitimate user account, and users will only see the fields that are relevant to them from a row.

Legacy System Integration

The rapidly changing pace of technology has left many companies adding applications and solutions one or two at a time into a self complicating mess of data transfers and distributed functionality. Anyone who has had to update one application within an integration hairball will know all too well the frustration of weeks spent updating and rewriting connections, only to have the whole system crash because one was missed.

Data is often stored in dozens or hundreds of places, connected loosely if at all, and describes different parts of the same idea. Customer information, for example, is often used by several applications, with common and unique fields for each that need to be synchronised to really work.

Trellispark has simplified this system through the use of an entity synchronisation layer (ESL). Instead of communicating directly between themselves, applications each have one path to communicate with this layer in a manner similar to a service bus or hub and spoke model.

This means that whenever an application needs to change or be replaced, those changes are isolated from every other application. The only connection that needs to be updated is with the ESL, saving days of complicated scavenger hunts, and allows us to secure data within this layer to protect confidential information.

Third Party Integration

It is very rare that a business is able to get all of their technology needs filled by a single provider. Far more often, multiple applications from several companies will be meshed together to meet diverse business needs. This not only means that applications will often be written in different coding languages and will need data in different formats, but also that this cannot be easily changed.

Trellispark uses an entity synchronisation layer (ESL) to apply security controls across each application, and eases any translation or transformation difficulties by limiting the number of connections to one - between the application and the ESL. Rather than having applications connect and pass data in a dozen paths or batches, having one synchronizing layer enables all third party applications to be managed cohesively and to translate the data into any format they require.

People and Process

Trellispark helps transform IT organizations to more effectively support and add value to business

Agile Governance

Agile frameworks have shifted the focus in IT from one big push to a series of smaller sprints. This delivers short term objectives and results, and works well with changing requirements that are a problem with the previous waterfall approach. However, the focus on short-term can lead to a lack of a big picture, and the final integration can be difficult.

Trellispark has solved this problem by always beginning from the perspective of a final solution and a data driven model. We have also standardised the language that each module will be built in, ensuring compatibility with a minimum of difficulty. This allows us to take advantage of the shorter build times, safe in the knowledge that our solution architecture will keep time from being wasted in discovering that certain technologies are less compatible than they at first appeared.


In traditional organizations, software development was completely separated from operations teams that would keep the programs up and running. This unfortunately meant that the people who would be tasked with the operations would have no input into how the project went forward, often resulting in conflicts.

Recent developments have seen a shift towards DevOps teams, or a mix of both developers and operations people who will be responsible for one project or service for the entirety of its lifecycle. This has removed some of the more adversarial attitudes, but can be tricky to implement and is a very major shift in company politics. However, it is worth the effort. Feeling more ownership of a project encourages developer teams to seek the most harmonious solution, and the most elegant code.

Trellispark’s small team has automatically lent itself to a DevOps model, and we can facilitate the changes in other organizations with the work of our expert consultants.

Flexible Workforce

As corporations merge and grow, often legacy systems need to be integrated and maintained. Over time this can lead to hundreds of separate applications, with a few key personnel kept from each merger in order to run those systems. These services could be in any language, following any protocol, and having them all work together is very difficult.

An ideal organization of IT departments involves having small teams of people ready to challenge any issue, a flexible workforce. However, to do this around hundreds of apps would require an IT department in the thousands, or assume that every single employee could code in every single language. This is clearly not feasible.

Trellispark offers a simpler solution - an entity synchronisation layer which every service and system will communicate to and through. This eliminates many of the problems of updating or changing any particular system; rather than needing to hunt for every reference point throughout every app, users can simply update the link between the service and the synchronisation layer in complete confidence that no other services will be affected.

Having an entity sync layer can also help to impose language standards across your applications, freeing up employees to work on multiple apps with a reasonable degree of confidence. Old applications that do not meet the new standards can be neatly phased out, as their only contact with other systems is through the synchronisation layer. Clear documentation also increases workforce flexibility, as it provides a starting point for someone unfamiliar with the application to work through a problem.


It is clear to anyone in business that there are some problems which will crop up regularly, and others that occur infrequently. While it makes sense to maintain a staff of permanent employees who can deal with common issues, it makes less sense to retain the kind of experts whose unique skills are rarely needed. These experts are always expensive, and most of the time companies have no real use for such developed skills.

Outsourcing these more complex projects to trained industry experts is the most logical way to extend the abilities of your existing IT teams, providing just the push to guide your own developers along the path to a solution.

Trellispark has a team of experienced consultants who are able to help with high level issues such as enterprise architecture, data center migration, and business transformation. We work with established teams from the strategy and design stages of a project right through to implementation, ready to tackle any issues that may crop up in the course of the project.


Evolutionary and Sustainable Architecture

Sustainability is a common problem for modern architecture solutions; often, pieces of a solution are cobbled together to solve a problem, leading to many lines of code with no clear organization. This prevents code from being reused, and makes changing any functionality or code line more difficult. If dependencies are being created on an as-needed basis, solutions will quickly become a tangled mess.

Trellispark has solved this problem by creating our entire scope of operations within an architecture designed to evolve and change. Services are partitioned based on their intended use with a single, simple interface each. This minimizes the dependencies between services, allowing them to be updated, changed, or replaced without affecting any other part of the solution.

Our Data Agnostic Services (DAS) framework ensures that our architecture is designed to be changeable. By assuming that every single service will need to be modified and replaced, trellispark has ensured that the architecture is flexible and able to handle updates and acquisitions of new technology seamlessly. This means that trellispark is always using the newest technologies and cutting edge techniques to gain the full advantages of the ever-changing IT landscape.

Code Generation

Traditionally, code generation is useful, but limited. It works well for creating high volume, simple pages without any kind of customization. It can be used to create first drafts of a page, but because re-generating the code will destroy any customization done to improve the page, code generation has not been terribly useful for modern businesses.

Trellispark has found a use for code generation that emphasizes its strengths, without falling into the trap of customization; CQRS optimization. The generation of lookup tables and stored procedures, and triggers to fill and populate them, is exactly the kind of high volume, basic software that code generation excels at. The type of table or procedure being generated will follow the same essential process every time, with changes only as far as the data fields being populated, which can be easily imported by a generator.

Since look up tables and stored procedures will rarely be seen by human eyes (as long as they’re working!) they are perfect candidates for some very simplistic coding solutions. And because the code generator is used every time any search functionality is used, the code has been tested millions of time by default. It is a reliable piece of the background, saving hours of work.

Separation of Concerns

Code built on the “this is the problem, make it work” basis used by most software companies is often messy, long, and heavily context dependent. A page may have a dozen different functions built into its back end, including independent save functionality, workflow, and state transitions. This makes the code inefficient, because it is almost impossible to reuse from one page to another, let alone between applications.

Trellispark has created a full separation of concerns, ensuring that all services are kept small and isolated. Services are assigned to one of four zones by their functionality, between Data at Rest, Data in Action, Data in Motion, and Data Presentation. They can be loosely coupled to services in the other zones in order to complete their functionality, but using a single interface per service can prevent them from building up unnecessary dependencies.

This means that services can be replaced or changed without having to track down every reference to the service throughout the entire application. It also increases reusability in ways which are fully explained below.

Automated Workflow

Automating workflow can be impossible when dealing with half a dozen different applications written in different languages. So much time is spent manually swivelling data from one app to another that being able to link actions to changes in the data is considered a heady dream. Data is often kept in silos with the goal of “eventual synchronization”, rather than actually synchronised to a single data source.

Trellispark stores all data from a business within a single data silo, making it automatically synchronised. Every application calls the data it needs from the central concept, displaying what is relevant to it but not changing information which another application may need. This makes it easy to automate workflow, because there is no need to call half a dozen different data silos to check that the right data is being used. It’s all there, and can all be acted on at once.

Having automated workflow makes life easier for employees and customers alike, as they can use your applications to perform a wide variety of actions and information without needing to re-enter their data. States can be switched with the click of a button, with confidence that any notifications or requests for permission will be sent, and workflow can proceed once the proper authorization is given.

Dynamic Page Generation

Traditional software is often hard coded into the pages, and as applications grow and problems are discovered, the software becomes a tangle of interconnecting references and patches. This makes it very hard to make simple changes such as adding new fields or states, or changing workflow slightly. Creating a change log can become so costly in these systems that yet more elaborate patches will be required for a basic save function.

Trellispark pages are not hard coded. The Data Presentation layer reads XML data from our data agnostic system and organizes it into pages and forms. Formatting is imposed only when the data is being displayed to the user as pages are dynamically generated, and a single service is used to display any number of ideas. The same service will display a Person, Car, or Action in exactly the same way, based on how that type of concept should be read.

This, and our data agnostic storage, means that adding fields or functionality is almost effortless. There is no need to change the presentation services; they automatically take the appropriate fields to display. Versioning is automatically maintained as well, so data can be updated without hours of time rewriting pages, stored procedures, and data tables. And because the same presentation service is called every time any page is loaded, it is thoroughly tested by day-to-day use.

Changing the Way We Test

Every new piece of code written within a solution will need to be tested extensively before it is ready to go live. Data errors and security issues mean that every written piece of code must be backed up by hundreds of lines of test code. This takes a great deal of time and money.

Yet trellispark is not storing data in code. The code generators and dynamic page generation have severely limited the amount of code to a single service each to save, store, and read code from the database. The code to test these services already exists, freeing up almost all of the budget and time for testing that would be required from a traditional IT project. This allows us to focus on an entirely different type of testing; testing the functionality and model, rather than the software.

Because we know that fields and forms will be displayed in secure ways, protected from data errors, we no longer need to worry about whether a page will display. Instead the flexibility of the system allows us to ensure that users are seeing the fields they desire, and that the workflow works for them at every stage. And if they decide they need a dozen new fields, the page rearranged, and a new state? Implementation is as easy as changing the XML.

Omni-Channel User Experience

Without a single, consolidated data view, it is hard for any software application to be truly omni-channel. When a phone application is written with entirely different coding languages, siloing data in a dozen different places, the idea of synchronising perfectly with the same data in the web application is a nightmare. There are too many dependencies, conflicts of language, and places where the code was simply written differently that are difficult to reconcile.

Trellispark has a distinct advantage here as our data is already arranged into a single data silo. Our architecture was built around a single view in the first place, eliminating the need to make data from several applications mesh. Using dynamic page generation and the Data at Rest silo allows us to use the same data between new channels or applications.

Genuine Reusability

Most code has been written to do a specific job, in a specific application, from a specific trigger. This makes reusability very difficult, as the context of the call is so heavily woven into the functionality. Coders are often of the mindset that it is quicker and easier for them to slam out a functionality in their own code rather than going to another, generic area and finding something else to weave in. And for talented coders, this may be true. But it leads to very inefficient solutions, repeating the same code over and over and creating more potential points of failure.

Trellispark has been built on a premise of minimalism and reusability, with small, simple services which are used over and over. By giving each only a single interface, these services can be switched out and changed without impacting any other service. And using an agnostic data storage (link) system means that trellispark uses only one Save service to save any kind of data. This drastically decreases the amount of code involved and the potential for errors.

Reusable components also make it easier for our users. Most companies need some kind of Human Resources software; we have built a Human Resources application that would need minimal modification to work for any company in any industry. Reusable components saves time and money, which is passed on to our clients..


The features that make a product unique in the marketplace are often treated as optional extras, but can make a massive difference when customers are making their decision. Simple features like a more friendly user experience, saving your place in a form, or bookmarking a page are not usually a required part of the application, and therefore not usually budgeted for. However, trellispark already has these features and more to improve the user experience. This means you can have the optional extras, often without spending more that would originally be used for the bare bones functionality.

Data Migration

The most difficult and daunting part of implementing a new software application is migrating the data over from the legacy systems being replaced. It is always very expensive, very time consuming, and extremely risky. Data can be lost in the transfer, or changing data models could require months or years of tweaking to allow old data and new to coexist. Putting off the change only makes matters worse, however, as new and emerging technology is changing so rapidly that the gap is always growing.

Trellispark has been involved in many large enterprise data migrations. Perhaps the starkest advantage of our data agnostic approach is the ease with which old data can be moved into the trellispark system. Because we use XML instead of the more traditional data model, transferring data is as simple as copying it into XML. Metadata fields can be added with a little extra automation, allowing full data sets to be transferred seamlessly. There will always need to be some deep diving and personal tweaks to make sure the data is still connected and functions the way it used to, but given how much less will now be required, the costs are minimal.

Great Ideaz Solutions

Strategic Consulting

Generate ideas and identify opportunities to grow the business and improve the effectiveness and efficiencies of operations

Sustainable Architecture

Create sustainable frameworks for implementing hybrid cloud business solutions

Transformation Roadmap

Evaluate options, build business cases, and estimate effort, cost, and time to perform risk analysis

TRELLIS Components

Supply pre-built components that can jumpstart projects and reduce development effort, cost and risk


Provide experienced consultants and teams that can fully leverage our Architecture and Components to deliver successful transformation


Maintain availability of production systems through monitoring, alerting and incident response