Platform

Fuuz Platform

What is a Platform:

A software platform, or a rapid development platform, is a technology that enables administrators to do many things that can not be done with monolithic applications. For starters, when you think of a monolithic application, you might think of something you would install on your smart phone or device. These types of applications are generally very focused on their purpose, industry and functionality. They are simple by nature of the fact they are relatively un-changeable. As with most applications of this variety, there maybe a settings or setup option providing you with a hand full of binary choices you can make about how you want your experience with that application to be. Ultimately, your experience with that monolithic application is dictated by the software developer and the way they feel most of their customers will be utilizing it. 

The concept of a platform is not new, applications like SAP, Oracle, NetSuite, MS Dynamics, Salesforce.com are all platforms. The platform concept enables the consumer to have much more control over how they will use or interact with the application. There may still be some specific settings or options to be quickly configured, however, you can go beyond that should you choose to. With a platform, you can go into one or more of its application platform layers. The layers will be discussed here as well. 

Instead of being limited, to just what you see on the surface of the application, or what you can control with a few binary options provided to you by the software developer, you have some greater flexibility. With some platforms this level of flexibility is minor in that you can add or remove fields from the user interface. Other platforms will not only allow that but you might also be able to control the business layer, which is where all of the functional logic is handled. This level of autonomy provides the customer with the ability to manipulate the way in which the end users will interact with the application, as well as what happens under the hood from a data and transactional standpoint. Some platforms will even allow you to have access to the data layer, allowing you to personalize the data that is stored and retrieved from the system. The above statements, do not apply to monolithic applications. By virtue, the software developer of a monolithic application does not want, nor can they afford to have their customers manipulate this level of the system. There are clearly pros and cons to both approaches.

We will discuss a simple 4 layer architecture then draw some comparisons to how this fits within the world of Fuuz. What a platform does is abstract and simplify the process of developing applications for the consumer, these 4 main components are largely abstracted from the myriad of technology that lies benieth each of them, the architecture required to enable them to interact with each other, and the delivery of the technology whether be cloud or on premise.

The Software Life Cycle:

This one is about the life cycle of software as a company progresses from start-up to enterprise level. Often times software consumers at early stages are ill equipped to fully understand and appreciate the value of a platform for them. As they transition from one phase to another phase, just saying it, makes it sound easy. The unfortunate reality is however, that each transition is painfully expensive, fraught with challenge and risk to the business and often times winds up in failure. Just google for failed ERP implementations and you’ll have some fun reading. 

Small mid-size business will generally prefer a monolithic application, think of things like Quickbooks. These are simple to setup and maintain and often times are inexpensive to operate. There are many benefits to this. Ease of implementation, training, cost, etc. These applications are readily available, there are dozens if not hundreds who offer simple per user type pricing, which is attractive to small businesses looking for that option. 

If you consider the trajectory of a small-mid size company as they start off with a system like Quickbooks they will eventually reach a point where the application no longer meets their needs. Perhaps they’re beyond the $5-10 million in revenue that these lower end systems work well in. Maybe they have grown and have too many users, or now they have customers that require them to use EDI. At this point they start to evaluate a new solution which could be NetSuite or Acumatica or something in the mid-market system range. 

A larger mid-size company, has now found themselves starting with a system like Quickbooks and most likely adding on numerous additional applications to address their growing needs over time. Something for labeling, another for shipping, and perhaps excel or a WMS to track inventory. Now they look to consolidate as none of these applications talk to each other so they spend massive amounts of time reconciling and auditing data for accuracy. They will consolidate some as they hit this level but ultimately repeat the same steps as they did before, this time with slightly improved software applications that are more functional than previous but still get them only 80%. 

At this point, they are likely to invest in some on-premise servers and outsource IT, because going to the cloud is perhaps scary or they feel too risky. On one hand, they maybe correct in that assumption but on the other, they’re not placing their business, financials and information, perhaps trade secrets at a much greater risk. There is no way that any on-premise solution can be as robust and secure as a cloud footprint with experts monitoring it every minute of every day. These are education points that we work with mid-size company owners on a regular basis. The perception is that its cost effective to own a server, rather than rent space in the cloud. Perhaps for a while it is, until there is a cyber security attack and you lose everything. 

As the company grows to become an enterprise, they now need to shed the skin of the mid-market decisions they made and look for the appropriate systems to run the business. This often leads them to tools like SAP, Oracle, MS Dynamics. As these ERP’s are platforms they provide scalability and robustness to allow the company to continue to grow and as they do, develop or implement the functionality they need rather than going to more bolt ons. Although, they cannot do everything, these platforms are designed for office level transactions like accounting, purchasing, sales. So these enterprise businesses find themselves augmenting with MES, WMS, TMS, PLM and other packages to address other areas of the business. 

All of this to say that there’s definitely a pathway taken by most companies as they continue to grow out of one set of software into another. Each of these transitions comes with risks and costs and implications. Historically, only enterprises could afford a platform, something scalable, robust and in the cloud. Something that does everything they need it to do today, but provides the flexibility and extensibility they need for the future. These dynamics are changing now with solutions like Fuuz. Fuuz eliminates the need for your company to hire a team of developers, devops engineers and IT experts to get everything working. Fuuz is truly a platform in a box, ready to be used on Day 0. 

Components of a Platform:

The Data Layer - 1

The data layer of the platform consists of the database, where you as the consumer of the software would be storing your data and retrieving it for reporting or analytics purposes. Because business logic is often dictated by data, or vice versa, having access to this is off limits for monolithic applications. They have tried their best over the years to implement things like custom fields, or attributes but those things merely provide additional meta data about an item in the system, they can not be manipulated or evaluated within the business logic of the software. so this means you can tag some things with additional information, but you are not able to alter the way in which your users interact with the software.

The data layer is typically the lowest layer in the software stack, its where things sit or persist until someone using the application requests access to that data or creates new data. Interaction with this data can happen in a number of ways. In modern platforms this is done via an API layer which allows read/write access to data for certain users based on their permissions or policies granted to them. This API layer is extremely important as its the means by which the business logic can interact with the data in your system.

There are several different types of databases available, many companies that attempt to move their operations to the cloud are faced with making challenging decisions like this because once you start down a path, its extremely challenging to revert back if you later learn that you made a design mistake. Before there was no-SQL databases such as Mongo, there were the traditional SQL’ish relational databases. You’ve likely heard of Microsoft SQL, Oracle, Postgres and others. Relational databases had a time and a place, but more modern frameworks have exposed the benefits of no-SQL or non-relational databases. Most modern cloud platforms will take advantage of these document style databases because of the flexibility and ease of use as well as the ability to use more modern tools for building pipelines, aggregation and query languages such as GraphQL. 

Legacy monolithic software packages will generally use the older style relational databases because much of the performance is inherent, there’s less engineering work involved in making them work well. That said, the trade off is they become rigid and complex and much too difficult to be flexible longer term. With modern tools like Mongo and GraphQL, the perceived performance issues of the past are long gone, the ability to create highly relational models is no longer an issue. To capstone this, the ideal database solution for your project should be a document style database, providing you the ultimate flexibility long term so you can adapt, add fields, tables and relationships you need without completely re-writing your application everytime.

 

The API Layer - 2

The term API is often times used in a general sense, referring to an application programming interface. All this really means, is this component of the technology allows either other parts of the software application to access, or some other 3rd party application to access the data via this interface. 

Common terminology like Restful API, webservices, ODBC are all examples of APIs most of the time. Older legacy software applications may refer to something called a stored procedure. This stored procedure, or sproc, is a method in which the application can perform actions to the data, often times referred to as CRUD or create, update and delete mutations to the data. Monolithic applications often times combine two important layers into one, as a way to save time and cost, and since they never plan on being extensible or infinitely flexible, there are some platform architecture componentry that can be easily skipped over. For example, in monolithic applications these stored procedures, often times will be a combination of the api that accesses the data layer, but it will also include the business logic or functional logic that makes decisions on how to deal with data based on the user’s interaction. What this does is make things very fast, and easy to use, as long as you never need to extend or modify the functionality to fit your needs.

With modern platform architecture, especially those leveraging micro services, it is critical to make sure that these architectural layers of the software are kept separate. Not only does this enable scaling to address the needs of users as they grow and transactional volume increases, but also prefers being open so that the program can be easily modified should the end user need to adapt something more closely to their process.

In a software platform, once you’ve defined your data layer, you as the developer are then responsible to create the API layer that sits atop that. By doing this, you can now access the data and its elements within your business logic and presentation layers. 

The Business Layer - 3

The business layer arguably is where the magic happens for most software applications. As mentioned previously, most monolithic applications with one goal in mind will co-mingle the business and API layers since they really have no need or desire to be infinitely flexible. The business layer may consist of orchestrations, flows, stored procedures, scripts or other logic that is created to support the way in which transactions will be handled in the system. 

As you can imagine, with a platform, not many of these things exist, as usually the platform is a blank sheet of paper for you to create something on. In the case of the monolithic applications you will not have access to this layer, except for as mentioned previously perhaps a hand full of binary choices you can make to manipulate some functionality at a very minimal level. 

There are many inherent pros and cons to having access to this layer, for starters, the biggest pro is that you have full control over the way your business will utilize the application. Large scale solutions like SAP and Oracle deliver on this promise to their customers, but as you’ll likely acknowledge implementing that scale of application is very time consuming and costly. One of the first cons you’ll hear from someone offering you a monolithic application, is that this is so complex to manage and requires a great deal of skill and expertise, that watering it down to the point that you’re forced to do things a certain way provides some benefit to the end user. 

The business layer often times is the code or the computer language that provides the functionality. When you hear about no code or low code, what that means is the software company has reduced or sometimes eliminated the ability to have full control over the business layer. This is where many customers have tried and failed to implement such platforms, their technical teams are unable to work with such a tool in the same ways they can work with more traditional methods, such as writing C+, Python, JavaScript, etc. This is typically a big turn off for many technical creators. One thing  that is different about Fuuz is our advanced Pro code capability. While we certainly have the no/low code options for less tech savvy users, those that need full control can certainly have it. This is a differentiator for the Fuuz platform, and one in which we take great pride in introducing to this space that has received a bad wrap over the inability to build truly enterprise grade applications. 

The Presentation Layer - 4

The presentation layer, or the UI (aka User Interface) is really what most of our customers care about. Well, it is the one thing that your business users see, they never see the business layer or data layer, they only see the tactile output of those things within the context of whatever UI they are working in. 

To compare with monolithic software, where the UI is there, off the shelf most platforms have limited UI. In that you need to first create that data layer, then the APIs and finally the business layer before putting a UI together would make any sense. 

With no/low code software tools, they usually begin with the UI and work their way backwards. The reason is they want to appeal to the less technical users and lets face it, most of us can only think about what we can see or touch. If you’re not a software engineer by trade, then likely you aren’t going to comprehend how to construct a proper data model, or API. All you really want is a simple screen with some fields you can enter and track some data. That works really well for this purpose, this is where a system like Salesforce.com become very popular. It abstracted the complex stuff, providing for some simple fields to be added to screens and linked together, which works really well for a CRM type solution where data isn’t being tracked numerous levels deep. 

Where Fuuz adds some benefit to this, is firstly starting with the data layer, which provides our platform much greater flexibility in terms of deriving very complex data solutions. Our clients are typically manufacturing companies and the need for complex data exists with almost everything they do. From machine recipes, to production routings and bill of materials. These types of models have never been accomplished before in scalable and repeatable way, by software companies, which is why all MES solutions available to you today off the shelf are monolithic. With these, you’ll be presented with UI and as long as it works for your needs, you’re in luck, because there is no changing it. In fact many of our customers, have signed onto the Fuuz platform just to extend their existing monolithic applications. This is possible as Fuuz has the ability to connect to anything, even if that thing isn’t necessarily the easiest to connect to. We have invented ways to work around the deficiencies of some other software packages in order to provide our customers with that last mile functionality they require to operate their business efficiently and effectively. 

Platform tools will generally go one of two ways with this presentation layer. They’ll be extremely simplistic, and you will only have the ability to generate screens with 1 or 2 columns in them, maybe a simple table, but ultimately very limited in a sense and that is by design. Because designing UI that works, consistently well, is not easy. The more options you unveil, the more difficult it becomes. This is where platforms start to diverge from no code, more to low code. With the lower code options, there’s some more flexibility and control, but now you need someone that has a little more patience working with the toolset. Often times trial and error, learning how ‘flex’ conditions work and so forth. 

Large and complex low code solutions, like Domo, F5, Pega and others give you the no code point of entry, then immediately dump you into the full code side of the system where you’ll find yourself needing to understand HTML, CSS and JavaScript in order to create a fairly simple screen for your users. This is not ideal, as it diminishes the value of the platform by simply encouraging the creator to use the same technologies they could have used without the platform in the first place. Fuuz has bridged this gap, by providing the ability to create fully functional UI, and without the traditional limitations described and no advanced code needed. Having said this, when the time comes for some advanced functionality, the creator can flip into advanced mode to make that happen. 

How Fuuz is Different:

Fuuz is different and unique from other platforms in many ways. The first and most obvious is that Fuuz is a platform as a service. Not many other platforms can claim this, in fact there’s only a couple and Salesforce.com is one of them. Being a platform as a service means that we’re not just selling you a piece of software (the platform) that you have to install somewhere, administer and maintain. The service being provided to you, is our team of expert engineers maintaining the platform, the servers and everything that goes along with that providing you with planned maintenance that is a fraction of even the most stable monolithic solutions on the market. This means you get unprecedented up time, scalability and reliability to run your business without requiring a team of people to manage the application servers. 

Many things within the Fuuz platform have been graciously automated for our customers, this is a game changer and does not exemplify the typical platform. For example, our data modeling tool is a full DIY self service drag and drop visual designer, allowing you to create a highly complex data structure with all the bells and whistles in just minutes. This is a task that might take a developer with traditional tools, days, if not weeks of work. Not only is the time reduced significantly (literally minutes, or hours); but when you’re done with the model, the platform auto generates all of the necessary APIs for the model, as well as policy level controls for all read/write functions. Another thing not mentioned before, is that in most platforms you’re responsible to figure out how to design and develop the security for the things you create, with Fuuz, the hard work is done, all you need to do is give your policy a name and select the items you want to control. Again, saving weeks of work compared to the traditional approach. 

When it comes to the presentation layer, because the APIs are auto generated, you’re building the UI within minutes of completing the data model in Fuuz. Everything is point and click, drag and drop with the screen designer in Fuuz so within minutes you have a fully functional application. The beauty of our business layer, or flow designer, as we call it, is that there are hundreds of pre configured business logic models for you to work with. Even one, that will create the presentation layer for you, with a single click once you’ve made your data model. There is no other system that has this capability, we just keep taking things a step further than any other solution because we want our customers to be successful and not be limited like they have been in the past with other tools they’ve tried.

The Fuuz Stack:

When it comes to modernized software platforms, Fuuz is the shining example of what modern technology can do for companies that want to grow. The Fuuz platform has evolved like many software applications over the past several years, the architecture is nimble and flexible, allowing our engineers to take advantage of the rapidly changing technology world. As new advances in technology become available for general consumption, our team works diligently to incorporate those into the platform, enabling our customers to always be on the leading edge and take advantage of all the benefits available. 

What is a stack:

A software stack describes the different technologies that are used for the software to be able to deliver various functionality to the end users. You will find by doing light research that most commercial software applications do not get into details about their technology stack, often times, because these solutions have been around for a long time and there’s some hesitancy to fully disclose the age of the solution and the tools. You might see software built on Microsoft stacks, that’s going to refer to technology like MS SQL for the database, perhaps C+ or C# code, .net or ASP. It is also common to see many older solutions like Boomi and Tibco to be built on Java, it is a very powerful toolset, but as you well know fraught with challenges and often the target of malicious cyberattacks. As you research the leaders in technology, you’ll see other things discussed like Node.js, GO, Mongo, JavaScript, TypeScript, RabbitMQ and others. It is important to research these technologies so you can fully understand the benefits. You’ll also learn that the concept of mesh architecture and micro services is extremely important to your business, to facilitate future growth and adoption of the tools. 

To reference back to the Software Lifecycle of most companies, when you align your business with technology that is inflexible, your business becomes inflexible. The only way around this, as you probably know, is to start working around or outside your systems and technology, which many of our customers do. Ultimately, to the extent that the technology becomes stale, it becomes difficult to regain adoption. With the labor challenges supply chains are facing currently, our customers are aware they need to present technology that is forward thinking. Younger generations coming up are not comfortable with green screen technology, they are a very forward thinking group and we need businesses to adopt forward thinking technology. 

What is Fuuz Built On:

Of course we wouldn’t have done all this priming, if we were planning to tell you that Fuuz is built on some 30 year old technology, but we’ve made the screens look pretty. Not at all, the Fuuz platform is stably running on today’s technology, every day. 

You read that correctly, Fuuz is designed as a mesh service oriented architecture. Everything in the platform is real time event based processing. This means everything can be used to automate your business from the user interactions to integrations and even your data at rest.

Fuuz is a real cloud based multi-enterprise application. Our customers are all running the same version of Fuuz, all the time. Fuuz is always up to date, with our continuous deployment model, which continuously ensures constant improvement of the software. Unlike other platforms which you install on your own server (or in the cloud), you’ll be forced to perform updates to along the way. Have you ever been to a user group and wondered what version of the application others are using, that’s one of the key benefits to Fuuz being offered as a service. It’s a differentiator for our platform in the market. 

 

The Fuuz Data Layer:

The engineers at Fuuz have painstakingly selected the best tools for every job. For everything we know our customers need to do today, and likely will need to do in the future, they have combined the technologies that best address growing needs. While our tech stack doesn’t fit the most common molds, we have evaluated the best solutions and worst solutions to determine the sweet spot so we can deliver consistently to our customers. 

You’ll find that our data layer is a document style database, in fact, we use Mongo. Because of the flexibility and speed of this database it only made sense to incorporate this in the platform so our customers can quickly and painlessly add custom fields and records to their own apps or to our off the shelf solutions without weeks of development effort. Asynchronous processes are easily supported in this structure allowing for lightning fast user interfaces and data query retrieval for your reporting needs. Many features are supported out of the box with Mongo such as sharding, which keeps things running fast and always presents the most relevant data when needed. With other technology like the traditional SQL style solutions, you’ll find yourself reaching out to your software vendor to help you optimize things over time, which works, but of course comes at a cost of both end user frustration and your CFO may not appreciate the bills received at the end of the month. 

With other databases you need to consider execution plans and optimization of the data structures, re-indexing and ultimately just adding more horsepower to be able to access your data. To mitigate this, often times monolithic applications will throttle your ability to access your own data, with various time out limitations. This means you will struggle pulling data or performing large scale integrations with these applications over time. Also beware of monolithic integrations as we pointed out earlier too many of them have business logic buried in the API layer, which makes integrations extra painful. Without direct access to the data layer via a proper API you will spend much more time than necessary getting things to work the way you need them to. 

 

Database Trends

The Fuuz API Layer:

In the world of platforms, APIs are everything. They provide the backbone to flexibility and extensibility, which is why when developing the only multi-enterprise platform for industrial companies, we took great effort in making sure we selected the best technology.

GraphiQL was selected as our primary interface to the API framework, it is a very popular solution because of how easy it is to use and the robust built in documentation. Within minutes, your team will have the ability to not only query data from Fuuz, but author your own APIs which can be executed within Fuuz or from remote services. 

What is unique about this compared to other solutions in the marketplace, is that you have control. The other software as a service providers are not platforms, and therefor are unable to expose tools like this to you as a consumer. Instead, you go through a process of authoring, or having a 3rd party author an API then you will need to go through various additional steps before you can utilize it. Often times, not having access to real time data even once this is completed. With Fuuz, you can author your own API in minutes and keep your project moving along, saving you valuable time and cost, which goes without saying.

All of this of course is served up by our server-less infrastructure built on Node.js which allows us to create many containers or instances of our software automatically as demand increases. There’s nothing you as a consumer of Fuuz need to think about, this is what our solution provides and what the service you’re offered includes. Traditionally, as your business grew and the usage of your systems increased, you would have a team of people focused on optimizing throughputs, increasing storage size, CPU and memory utilization to address the increasing needs. These types of things go away with a platform like Fuuz. 

Leveraging additional technologies like RabbitMQ as a message brokering service, provides the event driven architecture so that your apps and solutions are real time, unlike other stateless solutions you may find on the market. Consider that traditionally, if you’re viewing a form in your current application, lets say its a Customer record for example, what happens if another user were to manipulate that data without you knowing it and then you make an edit. Well, now you have just experience a data collision, unfortunately in every other system on the market the last person to push the update button wins. With the Fuuz architecture because our APIs and event systems are so robust, we can avoid these things and even provide indicators to users alerting them that someone else is viewing the data, or the data you’re viewing has been modified. These features are automatically built in, as someone who maybe constructing a business application in Fuuz, there’s nothing you need to do to incorporate this. Saving days of development effort for every screen you may want to build. 

K8 or Kubernetes is used to orchestrate the creation and removal of all these magical containers that are working for you behind the scenes. Because we’re the only multi-enterprise solution, your system is not operating on an island, or your own server, we’re leveraging real cloud power across hundreds of customers, so you get the advantage of nearly unlimited potential from a computing standpoint. With other platforms you may look at you’ll be responsible for managing this, and ultimately you’ll receive a bill at the end of each month from AWS or Azure or your own IT department to cover upgrades and expansions as the system is used. 

Separating these critical components from an architectural perspective, makes the Fuuz platform extremely easy to maintain and scale. No major upgrades required, in fact the only upgrades happening to the platform regularly are performance enhancements and new features or modules that our customers can choose to take advantage of, or not. Because Fuuz uses this modern lighting fast technology under the hood, that is inherently better for our customers experience. Queries take a fraction of the time and return 100x more data than you can get from antiquated software using SOAP based APIs.

All APIs in Fuuz are REST, everything is streamlined into JSON objects which is most popular now adays. If you’re looking for introducing tech that is relavent to the upcoming work force, you will not find anything more relavent. Why implement something that’s not taught anymore, that’s just going to create challenges. You might be thinking, what happens in 10 years when the technology changes, now Fuuz is out of date, not true. Refer back the fundamental positioning of our engineering and design work, was the maintain a constant state of flexibility, as technology changes, we incorporate those technologies into our stack so you can take advantage of them. For example as scripting languages evolve from JavaScript to Jsonata to Python, they become available for you to take advantage of in the platform. 

It is a very interesting but fundamental design pattern that we have incorporated and it is what makes Fuuz unique, we are never a legacy technology, Fuuz is always and will forever be modern. The caveat here, is that while we maintain modern approaches to everything, the legacy methods never go away, providing for the best of both worlds in your team can learn and grow over time or as needed. If there’s no reason to change, you don’t have to!

 

The Fuuz Business Layer:

The business layer, where the magic happens right? So the data layer is somewhat exciting, the API layer topic maybe a sleeper for most people, but the business layer is what our customers are all about. The business logic layer of any application is the heart and soul, its literally the why to how your company operates. 

The approaches we have discussed so far are the full customization approach, where everything you need to do is handled via some scripting language, the complete opposite of that is the configuration approach. In the configuration approach to software, you are provided your binary choices, you either opt into something or not and that drives how you use the software. This of course has it’s pros and cons, most notably the positive is that you’re going to get a solution up and running relatively fast compared to something like SAP, Oracle or MS Dynamics which takes some design and development effort to do most anything. The downside to a configuration only product, is of course, you have to succomb to the fact that you will need to operate your business like every other company using that software product. Which, maybe just fine for your company, but as we discussed in the software lifecycle section, this doesn’t work for everyone. 

Between the Fuuz engineering and delivery team, we have taken a completely radical approach to this dilemma. Fundamentally the platform itself includes what we call our Flow designer. It is an orchestration tool, where you can go in and build your business logic for anything including integrations, documents, business process, user interaction with drag and drop tools. Do you need to know any coding languages? Yes, typically this is not going to be done by just anyone within the company, that said, there are multiple scripting languages you can leverage including Jsonata, JavaScript, TypeScript and Python, with more on the way as they become popular and widely supported. 

Do you have to write every line of code? No, this is where Fuuz is different, our engineers have abstracted the most common use cases and made them into what we call nodes, these are common practices for manipulating data and processes that you can drag onto your canvas and simply wire into the flow. This saves you hours, days, maybe weeks of effort compared to other tools. Additionally, our team has developed thousands of business flows already for things that are repetitively done, like integrations with other systems for example Plex or SAP. In addition, there are already pre-defined flows for common business logic for our applications which handle things like inventory depletion and genealogy, printing documents, posting production, moving inventory and the list goes on. These become building blocks, for our delivery team as well as our customers so most often nothing is being reinvented and our customers benefit from this because these were developed by our team, with the knowledge and skills that our customers may not have in house. This again is a big differentiator for our platform compared to others which just provide you a blank scripting window.

We discussed the configuration versus customization previously and how Fuuz takes the customization to another level not tackled by other software platforms to date. In terms of configuration, because of the flexibility of the tool set, most of our customers and our delivery team will incorporate configuration functionality into standard apps. If you take an MES for example, there will be binary choices our customer can make such as do they want the ability to log more than one operator into a station. This just describes one of these choices, but there are hundreds in a single app. Configuration is not buried in business logic like it is with monolithic applications, its just part of our data layer, API and ultimately incorporated into the business logic or Flow as a simple variable. Configuration options which are easily managed by an authorized user of Fuuz require no code, just change the option and update. The best part is that a customer of Fuuz, can add any additional configurations they need to the solution quickly and easily. It isn’t necessary often times because of how simple it is to tweak processes and manage changes with our Flow designer, but it is an option.

Lets quickly recap here, there are pros and cons to configuration only and customization only; our team has evaluated all of these and we kept all the pros alive in Fuuz. This means you have the simplicity of configuration, but ultimately the flexibility of full customization if you need it. You might now, take pause thinking you’ve heard that customizing software leaves you on an island, or creates trouble for upgrades and updates. That’s true! However, not true with Fuuz, here’s why, as we’ve described Fuuz is a platform that is being continuously deployed and updated without you being impacted, unless you opt into the new features. Fuuz is a multi-enterprise platform, so all customers are running the same version or release everyday. The real magic of Fuuz is how we have isolated the actual software or platform from your apps, your MES, WMS, TMS, or your custom one-off solutions you’ve used the platform to build. Whatever customization you need to do to your own apps to be successful are never impacted by the Platforms continuous enhancements, think of these as nothing more than you’re own configuration. Even if you were to build your own solutions directly in Azure or AWS, they too continuously deploy changes, but the difference is they could and most likely would impact your applications as they change authentication methods, network strategies or anything you will need to migrate. Fuuz being a service to you manages that back end completely, allowing you full and complete flexibility and control of how you use your apps, while never positioning your company on an island.

The Fuuz Presentation Layer:

Last but certainly not least, the Fuuz presentation layer. This is what most software shoppers focus on in their evaluations. What you see, in a software demo, usually is what you get when you purchase it. That’s not entirely true with Fuuz. While a lot of what you might see in our demos, is what you’ll get with our out of the box applications, the Fuuz platform provides those layers of personalization or customization that you need to be truly successful everytime. 

Depending on your subscription package you may have access to our Screen Designer tools, this set of tools is a drag and drop design application that allows you to build amazing UI’s for your business, in minutes, tie them up with flows that you’ve created or pull from libraries and you’re off to the races. Let’s say you need to add some more data to a product record, easy enough. Go to the Schema Designer, add the columns, save it. Then goto the Screen Designer, pull up the screen those fields get added to, drop them in place where you want them, set your defaults if needed, save it, deploy the latest version and let your team know they can start using those fields. All of that likely took place in under 5 minutes. Can you do that with a monolithic application, well, unfortunately no. If the software vendor, and that’s a big if, agrees to add some fields for you, then you’ll likely wait months or years and be asked to participate in some co-innovation project where you’ll be paying them mightily for adding the fields. That may not bother everyone, but now that you have the fields, what are you going to use them for? Hopefully you mentioned to the vendor that you’d like to use them in an API, otherwise that’s a new project. Maybe you needed them to trigger some activity on an operator dashboard, likely another project as well. Maybe 2 years later, you have those 3 additional fields that were so important to your operation. With Fuuz, you added the fields in 5 minute, you adjusted business logic in 15 minutes and you had them on your operators dashboard before lunch that same day. 

This story line really is about the underlying tech, the Fuuz front end as our engineers call it, uses React and Redux technology. You maybe familiar with this as you’ve likely heard Facebook, LinkedIn and several other high visibility cloud apps use React. React is a highly flexible, scalable and fast. One reason we like it is that it allows for lightening fast user experiences. React installs a very small file into the web browser when a user initially visits a site using React. This file contains a lot of cool stuff, basically, its a lot of framework type things that now can run locally on the client, instead of having to go back and forth over the internet. This significantly reduces latency, and bandwidth on your network. If you’ve ever wondered how Facebook is able to automatically start and play videos as you’re scrolling through without the typical jerkiness, there you go. The experience most of our customers have with so called business applications, like ERPs, WMS, etc. is quite a bit less than lightening fast. You may be waiting minutes for screens or reports to render, there’s a lot of activity going on between where you’re sitting and where your data is, using modern technology, we can change that. 

Many of our customers, don’t end up doing a lot of activity in Fuuz screens, because we also extend to your existing applications. This is literally a Fuuz only capability, any application you have that is accessible via a web browser can be augmented by Fuuz using our browser extension. This means, your users don’t have to login to multiple applications, have different apps open, or toggle tabs. The browser extension can also leverage data that’s available on screen from these existing applications, essentially turning some stateless monolithic solutions, into real time, powerhouses enabling your team to work much faster and have much more data available at their fingertips. Oh, and if you haven’t already figured this part out, while you can’t add fields or manipulate data models in most monolithic apps, using Fuuz, you can augment those apps and add whatever fields you need; but you can also use the Fuuz Flow Designer, Document Designer and Screen Designer to take that as far as you need to take that. So even if you find yourself in love with your current application, but you’re not in love with its inflexibility, Fuuz can fix that. 

The Fuuz Architecture:

Basic Concepts:

Let’s start here by saying, that there is nothing unique about being a ‘cloud based’ application anymore. Any software company that realizes the benefit of cloud is moving in this direction if they have not already. While Fuuz is ‘cloud based’ this is not something we feel is noteworthy anymore. Just like talking about how long the application has been running in the cloud, pretty irrelevant at this point and just becomes a dated concept.

There are of course various degrees of cloud based applications, many are simply hosted in the cloud, running on AWS or Azure and while this provides some flexibility you may not have when on premise, ultimately you’re just running your application on another piece of hardware that you don’t own. In this scenario you still have updates and hardware upgrades to consider, as well as point of use costs. In a hosted environment, you’re not getting a service, you’re just renting the hardware from a service provider, so you only get what you’re willing to pay for.

The concept of multi-tenancy is something that was made up decades ago, by software companies that were some of the first to move to the cloud concept. The idea behind multi-tenancy, to over simplify, is basically one giant server, that supports many customers or users. The advantages here are in favor of the software vendor, as the costs become shared across many customer accounts. As with anything you have some heavy and some light users, so you average this out and it becomes a win-win, the heavy users aren’t necessarily paying for what they’re using, the lighter users get the benefit of paying less than they would if the application were hosted on a standalone server. 

To further complicate this situation, some software vendors started to come up with creative ways to reduce costs further. For example, multi-tenancy databases, means that your data, sensitive information is stored alongside all of the other customer’s sensitive data. This creates limitations to how flexible the application can be, as one customer is unable to have different data structures than the others. This is one example of things that become shared but is the highest risk factor as you rely on the software vendor to ensure your data remains secure and that other customers cannot inadvertently access it. This has happened several times. It’s a wonderful scenario for hackers wishing to engage in cyberattacks, all they need to do is crack the code once and they have access to everything. 

Let’s keep moving along here, next up is the issue of security. Not just the cyberattack kind of security, but browser security. Companies like Google continue to make their Chrome project more and more secure. This is why companies like Microsoft gave up and are using the Chromium project as the core for their browser now. That said, one of the most significant risks is malicious access to your PC, network, or other infrastructure from a browser application. Your users have a lot of freedom typically to access various websites throughout the work day, at lunch time perhaps they jump on YouTube, or Facebook to look at things. All of these activities are not malicious on behalf of the employee, but someone else out there is trying to gain access to everything that the employees PC has access to. The browsers continue to enhance and make this harder and harder to penetrate. This presents issues for cloud based solutions when it comes time to things like printing paperwork or barcode labels in manufacturing environments. They simply cannot do it, which creates additional work and potential issues on the shop floor. Some have worked around this by requiring that you use certain operating systems that support their plugins, which can become a significant hidden cost when you deploy these applications. Others will suggest the use of some 3rd party application to bridge the gap and then it becomes a science project of an integration to get things working. Hope that your firewall or the software vendors firewall settings don’t change and break everything some day.

To recap, what is the difference between an on-premise application, and one that’s hosted? Nothing. Its the same thing only you’re renting the equipment. All the concerns and issues remain the same. There are risks in traditional approaches to multi-tenancy from a data security perspective. We ultimately suggest you do your homework on what you’re buying. It may look wonderful on the surface, but what lurks under the surface may cause your business significant trouble eventually. 

Multi-Enterprise:

The Fuuz Platform is what we call, multi-enterprise. This means that each of our customers are safe and secure on their own isolated data farm. Each of our customer enterprises is completely isolated from a data standpoint ensuring the utmost in safety and security for your data. This also provides an unparalleled ability to create and maintain unique data fields and the separation between customers ensures that noisy neighbors do not become problems for you. 

What do we mean by ‘noisy neighbors’? Well, consider what we said earlier, you’re on a multi-tenant solution, there are large companies, small ones and everything in between. There are some doing a low volume of transactions and others doing extremely high volumes. When you sign up, you don’t get a say in how your system gets provisioned. So you may end up being put next door to someone with ultra high transactional volumes and it very well may impact your user experience from a performance standpoint. This is not fair, but its one of the downsides to this old school multi-tenant approach. Unfortunately, you don’t know this is an issue until you’re live on the solution, and at that point there’s nothing the vendor can do to change it. We hear this all the time from some of our customers switching from other vendors. 

Having your own island of data, is a blessing. We’ve said Fuuz is everything a cloud solution should be, and nothing it shouldn’t be. With your own island of data, everything becomes blazing fast and your experience is never compromised by other customer’s usage of the system. The thought of someone else on the system, potentially gaining access to your data, is also never a concern. 

Tenants:

The concept of our multi-enterprise solution, is that each customer is in control of their destiny with the platform. Your subscription allows for as much consumption of resources as necessary to run your operations. Within an enterprise, we have what we call tenants. Think of this like a giant apartment building, you, own the building, tenants reside in the building and share certain things like the parking garage. Another unique thing that we’ve architected is each tenant has isolation, within the building. So think of this like sound deadening insulation in the walls between each of the apartments in your building. You may have a rock band practicing next door but you’ll never hear them, you can continue binge watching your favorite Netflix show without interruption. 

In the same we we protect our customers from other customers on the platform, we also protect our customers from themselves. You may have a need for different configurations or customizations for different facilities (aka tenants). What if you have mixed mode manufacturing going on in the same facility? For example, perhaps you’re doing discrete and continuous manufacturing under one roof, how do other applications handle that? Well, this depends, if its a monolithic application, you only get one configuration for a location. This means the solution is to purchase, implement and configure multiple environments of that application based on your different processes. This is really unfortunately, time consuming, and frustrating as now you have disparate systems in the same facility. With Fuuz however, because the platform is built around the concept of flexibility, you can keep everyone on the same page (one source of truth) all within the same tenant. 

 

Environments:

If you’ve ever done development or have worked on a project requiring development you have likely run into the situation of multiple environments. Fuuz is no exception to this, in fact, most of our customers have at least 2 environments, some have 3. This just depends on the subscription package. 

Build Environments:
Build environments are exactly what they sound like. This is where you can install pre-built apps, extend those apps, or even start your own apps from scratch. You connect to other software applications using our Flow Designer and iPaaS connections, design your data models in the Schema Designer and then of course edit your user interface in the Screen Designer. This provides a safe (disconnected from Production) environment where you can experiment until you think you have things the way you want them. All the while, not interfering with your users or production system. Our Build environments persist for as long as you want them to. Some systems can only refresh a build environment very infrequently, you can update it as often as you like. You can also use our build environments to do prolonged projects. Some systems offer these type of environments, but they refresh every 24 hours, so you have very little time to do what you need to do, before all of your effort is lost. 

Another interesting note about Build Environments is they are the first to receive platform updates! On a fairly regular basis, they receive all enhancements including performance and new features. So this becomes a perfect playground for you to go in and evaluate new features before you make them available to your business users. 

QA Environments:
These are not included with every subscription package, but for those that have them, they provide a seamless UAT environment. With this you can maintain a constant environment between your build and production. You can deploy changes here so your business users can test, validate or even train new employees on things without impacting production, and without having to constantly roll back your changes on build. This is extremely beneficial for organizations and something that most software platforms do not make available. 

Production Environments:
Last but not least, Production. This is where everything really happens. Day to day activity, including all user transactions, live integrations and so on. The majority, by far, of your transactional volume will happen here. You can replicate your production environment to your QA or Build upon request, it doesn’t take nearly as long as what you maybe used to, this can be done within a day, you wont be waiting 3 months for a refresh. 

Gateway:

The Fuuz Gateway is another piece of the architecture puzzle. There were some mentions elsewhere of browser security and some applications requiring you stick with specific operating systems and hardware in order to support the most basic of usability. Fuuz has taken a modern, reliable and very scalable approach to some of these concerns by developing our own Gateway application. If you’re familiar with AWS greengrass, this is not that, but its our flavor of it. 

The Gateway has a couple of deployment options:
1. At the Edge
You may have heard this term before. It simply means, something that is deployed as close to the point of collection as possible. Generally, in the world of manufacturing, the “edge” is the piece of equipment, or workstation where data is being collected. By deploying at the edge, you can collect more data, more reliably than you can with a centralized deployment which is most common with other applications you’ve likely evaluated. This is commonly used for high volume, machine data collection activity. One advantage of this method is you’re not dependent upon a single point of failure like you are in a centralized deployment model. This also reduces the overall cost of ownership, as the hardware required at the edge is generally very inexpensive compared to servers and virtual machines which require complex hardware, software and expertise to maintain.

2. Centralized
This is the most common approach of deployment by far to date for solutions that interact with your equipment. If you have used Kepware, Wonderware, Ignition, FactoryTalk, ThingWorx, etc. you have had a centralized deployment model. This piece of software runs on a physical or virtual server somewhere in your building that is connected to 2 networks, one being your industrial network and the other your business network which typically has internet access. This model is often used for low volume machine data collection, printing applications, or disk level integrations.

There are pros and cons to each deployment model as you can imagine, and each needs to be evaluated to ensure that all requirements you have are being met. One advantage of the Fuuz license model, is if you choose to do edge deployments, there’s no additional costs involved. Our gateway can be installed on just about any type of device as well, so your costs to deploy the hardware are drastically reduced. 

The gateway provides a secure tunnel between assets behind your firewall and the Fuuz cloud platform. Using pub/sub technology things are kept in sync, in real time. Additionally, if your project involves any type of data collection or aggregation, the gateway has built in Store and Forward features to circumvent latency and network issues at your site. Robust logging is available as well so you can analyze any inconsistencies in your integrations. 

One of the best features of the Fuuz Gateway is the fact that once it is installed locally, you never have to touch it again. Well, except if you need to update it. Unlike other OPCUA, printing solutions, or disk monitoring applications the Fuuz Gateway is always in sync with your Fuuz cloud environments. Configuration of devices, adding devices, or viewing logs and connectivity data is all done via the cloud interface. This eliminates the need for VPN and RDP access making projects much easier to deploy, as well as better enabling support if something needs troubleshooting. For example, if you need to add more PLC tags to the scope of the store and forward system, you do that from the cloud, by checking a box and clicking update – the Gateway is instantly updated and starts to store those values should you suffer network issues. All other solutions that offer edge capable software will require much more work to make changes like this. 

Extension:

A first ever for any software platform, is our Fuuz Browser Extension feature. This little application is available to be installed in your browser of choice, and bridges the functionality of the Fuuz cloud platform, into any browser based application you have. 

Unlike other solutions, that would depend solely upon batch processing, you can use any feature of the Fuuz platform and extend it into your existing solutions. Eliminate complex training, users logging into multiple apps or fumbling with multiple tabs. 

The extension provides you the ability to augment and extend existing applications with screens and processes you build in Fuuz, but also provides the ability to perform integrations between outdated software applications in a more real time fashion. The extension can read anything on the application in the browser and use that information to pass back to Fuuz to trigger events. 

Another solution many customers use is to leverage the extension to augment information in monolithic apps. You can have creative ways of adding custom fields or records to existing non-flexible solutions that allows you to get more value from what you’re already using.