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.

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.

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.

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.

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.

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.

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.

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.

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..

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.