Agile is about delivering. Every business application development team today wants to break out of cyclic and move towards continuous value delivery. That’s what Sclable is made for. From day one of your project.
The time-to-market Challenge
Imagine a business application such as a supply chain management for some highly specialized industry with a lot of company specific functionality. In days like these, requirements are changing on a daily basis, and business applications should be just as flexible. So why can’t those application monsters update regularly just like any of your smartphone’s instant messaging apps? Well, that’s because these monsters are real beasts.
The nature of business applications is complex
We speak of multi and concurrent User Systems. Even for a small company’s order-to-cash process, a number of inter-related business entities within the hundreds is not unusual. Process workflows tend to change a lot. In 1974 Lehman formulated in his famous “laws of software evolution”:
“Observing that most software is subject to change in the course of its existence, the authors set out to determine laws that these changes will typically obey, or must obey in order for the software to survive.”
Taming the Beast
Now that is what Sclable is aimed at. The Sclable Platform is designed to have a fully functioning product from day one. Toolchain, organizational structure, agile method are very important, but honestly, the flavour depends on the nature of the software project you are doing. SCRUM, XP, Waterfall: No matter what flavour you go for, the Sclable Platform let’s you tame the beast itself.
Let’s do some sclabling!
At Sclable we are experimenting a lot with software project formats and agile methods. Let’s roughly sketch out one of our favourite agile software development format, we call “sclabling”. Sending ahead that you should choose your agile method according to the project you want to do, sclabling is just perfect if you know little to nothing about the business application that should be built.
Project kickoff and prototype release day
The good thing with business applications is that product owners seldomly start with just an idea. It is more likely that there is a legacy product or a bunch of such to be replaced. Often POs show up with a lot of additional material. Excel sheets along with calculation macros or other home grown stuff. In short: All that scattered knowledge needs to be structured.
That’s where Sclable’s business domain modelling comes into play: Sclable’s Domain Designer allows you to quickly develop the domain model that’s going to drive your business application. Whatever you do within the domain designer, Sclable’s Generic Application will reflect those changes immediately. That way, the project’s PO not only can verify the application at any time, also additional functionality that is not delivered by the generic application can be identified.
Prototype ready under one hour
In fact, from the PO’s first execution of an action within the domain model of your application out of Sclable’s Generic Application, your application’s prototype is born. From our experience, that’s after about an hour from the first time you throw up the domain designer. Most of the time it is some standing data being entered since it is hard to develop a business application without the data in mind.
First release under one day
No matter how far you will go on that project-kickoff workshop day, at the end of that session you can release and deploy. Your software project now consists of the following assets: Your business application is up and running. Of course there are a lot of features missing, but your project’s backlog is filled. At least to some extent and surely enough to plan the next sprint. And to add to your Definition of Done: your domain model represents a full documentation of your business application, which is (automatically) testable, and, because you haven’t touched any code until yet, there are no bugs.
Agile Methods and Sclable
Building upon the Sclable Platform means that you can do feature- test- or behaviour-driven development. You can develop your own breed of all three combined from here. You could go for a SCRUM setup or XP or both. At Sclable we have seen all sorts and have observed teams adopting quite unique flows.
A FinTech table prototyping project built upon Sclable. In addition to the tablet prototype, the solution included a full Sclable backend which was build upon Sclable’s Generic Application. A lot of the features and concepts developed in those 3 days wouldn’t be visible for the tablet-front-end user. Amongst these were two different adaptive suggestion engines along with configurable weighting algorithms which would guide through the application. Image: Sclable.com
A Fintech Showcase
Another format has been exemplified in a recent FinTech project initiated by FinTech Specialists at sopra steria and Scrum specialist bor!sgloger. A tablet-PC prototype for a banking advice application has been successfully accomplished together with 25th-floor, 9dots within 3 sessions each lasting 3 days. The SCRUM team included software architects, developers and UX specialists. About 35 additional persons from about 10 companies were involved, which is not unusual for projects within corporate structures.
With our Platform version 2.0, which is centered around developers, their teams, project setups and development methods, we’ll be definitely seeing more agile project formats in the future. And we’ll be showcasing them a lot. So watch out for more blog post about #Sclable and #Agile!
It started as usual…
The idea behind Sclable was to make our lives as software developers easier. We probably have that in common with most startups that offer products and services around software development. However, our area of expertise is hardly ever found in startups: We are focusing on solving complex topics in the the area of enterprise application development.
What is Sclable?
Sclable supports the development of complex business applications through a high degree of automatisation. Simply put you could say that Sclable is a machine that knows to program.
But Sclable is much more. With Sclable it is possible to build completely individual application architectures. Sclable is infinitely extendable. And Sclable is an ecosystem of services, that connects Sclable developers and makes them even more efficienct.
… what again is Sclable?
Our biggest challenge at the moment is to communicate a highly complex product in a simple way. We are dreaming of the “one sentence” that gets to the heart of Sclable. It seems like that does not exist. Therefore we have to develop a seperate communication strategy for each target group.
Paradoxically it is Sclable’s versatility, that is getting in our way: As it is possible to develop any kind of business data management system with Sclable, there always remains one question:
What is it, that Sclable is especially suited for?
On one side, we can identify a tendency towards certain industries: First of all there is FinTech where Sclable can be seen in risk management, process automation and private banking applications. This is mostly due to the fact that FinTech is our background and Sclable results from our experience in developing risk management solutions for major banks. Besides, our recent customer success stories have shown particular use of Sclable for applications in the food and publishing industry (manufacturing processes, supply chain management, ERP, CRM and more).
On the other side, we can look at the deployment scenario. Sclable is perfectly suited for implementing prototypes very fast. That allows for evaluation of solutions at all technical levels. The result is not a throw-away prototype, but the basis of a final solution, no matter what parts of the Sclable stack are finally being used in the production system.
One of the reasons, why Sclable is not easy to explain, is for certain due to the fact, that Sclable was originally not created as a standalone product. During our first times as a company, we ourselves were using Sclable to develop business applications for our customers. The advantage of this “service phase” is of course that we could finance ourselves.
Starting to focus at the Sclable Platform only as a product, was not only linked to investments, but changed the company more than we initially imagined.
Continuing to grow
The last two months in our company history were a major step forward towards this direction. As by now, our ecosystem of services, knowledge transfer and winning of partners is equally important to Sclable as the product, the Sclable Platform, itself.
With the Sclable Developer Hub and the Sclable Academy, we are building up a training program. And there is the Sclable Partner Program. Probably the most important element (coming in Q1 2016) is the Sclable Marketplace: our app store for business application functionality!
The most important aspect of Sclable’s growth is our team. We are constantly searching for talented people. At Sclable, basically everybody is responsible for his/her area. We are always interested in meeting people, no matter if there is a job opening at the moment or not. Contact us, if you are searching for new challenges!
This article was first published in German on startupbrett.de on 14th December 2015.
Supporting businesses with data visualizations is undoubted one of the most crucial factors for detecting and understanding the challenges every business has to master to be successful. But data visualization involves a number of heterogenous skills within the scientific fields of economics, mathematics, geography, data analysis, programming and design. And it isn’t a one-off operation.
Most companies struggle when it comes to create simple graphical dashboards or visualizations for a standard executive report.
CHALLENGE 1: ASSURING DATA QUALITY
Business data quality often is quite poor. Data sources are missing constraints, or even correct data types. Interestingly enough, legacy systems are better than younger ones, because in the early days, precise data models were crucial for disk usage and performance.
For many data visualization professionals it is still shocking how much effort companies put into operations called “normalization”, “weighting”, “data cleansing”, “sanitization” instead of guarding the accumulation of quality data in the first place. Usually you can see more creativity in finding euphemisms for data manipulation and truncation than in dealing with the root of the problem.
CHALLENGE 2: UNDERSTANDING & SHAPING DATA
The second challenge is tightly intertwined with the data quality issue. Bad data quality often goes hand in hand with insufficient structurization of the underlying data architecture. Poorly structured business domains are extremely difficult to understand and shape. Without thorough domain expertise, data wranglers won’t be able to provide correctly aggregated information for a visualization.
To be able to create graphical representations from your data, you need to take it to a higher level: The simplest form is to aggregate columns of tabular data, a task you can do with any spreadsheet application. Add more dimensions and you’ll quickly end up with concepts like online analytical processing (OLAP). Adding niftier aggregation functions than counts and averages will increase complexity.
Challenge 3: Displaying Meaningful Results
Getting valuable and meaningful insights from business data visualizations depends foremost on a deep understanding of the origins of the data, the aggregation procedures and the audience that will interpret the visualization. A common mistake is that visualizations are used without much of a context. Poor or absent context is exactly what renders data visualizations meaningless.
A data visualization example with poor context, from: “The Visual Display of Quantitative Information”, Edward Tufte 1983
In general, most visualizations do not provide enough context. It is essential that a data graph is linked to the aggregation matrix. It would be ideal if the aggregation is linked to the aggregation function as well as the underlying data set. How many dashboards or reports provide such a deep linked context?
HOW WE ADDRESS THESE ISSUES AT SCLABLE
At Sclable we aim to combine the latest scientific findings, data wrangling methods, programming techniques and design approaches to get all the major obstacles out of the way of data visualization creators.
Data Quality & Integrity
The Sclable Platform’s application architecture guarantees the highest possible data quality and integrity on every architectural level. You can define your own data types to meet your exact needs, exploit uniqueness and requiredness concepts and create your own regular expression rules for data validation.
Data Consolidation and Aggregation
In Sclable you don’t just select and aggregate data. Instead you are modelling calculations, aggregations, selections and data filters. The way your business data is managed and how it can be analyzed is both part of your business domain model.
Never lose context
Since data accumulation as well as data aggregation and analysis is based on your domain model, you’ll never be off context with your data visualizations. Sclable allows you to create “Data Driven Documents” directly from your business domain. Your data visualizations are more than just a way to visualize information: Your graphs allow you to explore your business domain’s data interactively: you can feel your data behind the graph.
Feel the data behind the graph: A data visualization upon D3.js providing an aggregation matrix showing interactive small multiples along with a geo map, made with using dc.js, Crossfilter, and Leaflet.
THE POWER OF THE DOMAIN MODEL
As with any other complex task in business application development, our goal at Sclable is to provide platform capabilities, tools and best practises that are making it easy for you to achieve your data visualization goals. You can develop and implement advanced algorithms if you want. But you don’t have to:
Having your model at hand, the possibilities of what eventually could be visualized meaningfully shrink drastically, since a lot of decisions and rules for your data are already described within the model. The approach we are taking is to pre-analyze the domain model your application is running on. This gives a lot of useful input for pre-selecting the right “recipe” for application developers. These recipes resamble the latest and greatest research in the fields of mathematics, data science, UX and UI engineering. Applying them should be a matter of minutes for developers.
Learn more about Data Visualization at Sclable
Research Project: Data Visualization upon evolutionary developed Domain Models
Blogpost: Domain Driven Data Visualization
In agile business application development projects today we see two drivers for the transformation of teams: One is the demand for a diversified set of skills, the other is the demand for stronger integration of users. How will agile teams for enterprise application projects look like? How can the demand of more diverse skills be satisfied with ever shrinking budgets? The following blog post explores recent discussions we are involved in at Sclable and outlines how we envision the future of agile teams.
The diversification of skills
Business application users are also users of online platforms such as Google Drive or social networks like LinkedIn. They have become accustomed to a level of user experience that is not common for business applications today, therefore we see an increasing dissatisfaction with the overall appearance and usability of applications that were meant to be designed for a lifecycle of many years. Users are expecting any application to be appealing, highly user friendly, intelligent and supporting multiple devices. To provide such an experience, agile teams need a skillset ranging from user experience design to higher mathematics, from enterprise application architecture to process and data analysis.
The magic unicorn
All-around talents are rare to find. About ten years ago it was not unusual for highly skilled individual entrepreneurs to develop a specific enterprise solution all by themselves. Taking front-end design for example: We would have been going for the screen resolution most common within the company adding a “best viewed at 1024×768” note to the logon screen. Today, responsive front-ends are obligatory due to the transformation of people’s working places. Quite similar examples can be found on the server-side: Customers rarely realize that services such as databases have evolved as much as end-user’s devices.
IT budgets are growing?
According to Forrester Research and other institutions, IT budgets of 2016 will more than double those of 2012. So why are many IT departments complaining about shrinking budgets? The answer is simple: When mapping the IT project scopes to the increasing budgets it is quite clear that IT departments will have to get more things done with the same amount of resources compared to 2012. In addition to that, many companies are aiming for a transformation of their IT department from a cost to a profit center, a trend and at the same time a controversy over the last years.
Software is to be the biggest area of spending increase in 2015 at $620 billion (expected by Forrester)
A big part of that goes towards analytics, as-a-service, and enterprise process apps such as ERP and CRM.
Image: Forrester Research, Inc.
Business Applications of the future will not be “made”. There won’t be “application launch days” anymore. Business Applications of the future will gradually evolve. And they will be evolved to a higher degree by the users of the system than by developers or architects. Non IT staff has been developing business functionality of great value all the time. Usually they rely on spreadsheets which are used as a workaround until IT departments come up with a solution. Unfortunately most of those workarounds never make it onto the roadmap of long term enterprise application strategies.
The Sclable Vision
At Sclable we envision a future where appealing, highly user friendly, intelligent and multiple-devices-ready business applications are built and evolved by the users of a system rather than by developers. The resources of skilled programmers, system architects, user experience designers, mathematicians and analysts are too valuable to be wasted with repeating tasks.
At Sclable we aim to provide a Business Application Development Platform which puts everyone in the right spot. Magic unicorns are rare. But highly skilled developers are found all over the world. Most of them have a very specialized skill set. Or can provide a very distinct business domain know-how.
The Sclable Ecosystem brings all that together. Technically we provide packages submitted and maintained by experts from different fields containing functionality, logic, know-how and more. Above that we are organizing the exchange of packaged knowledge and focus on the productivity of business application development teams.
The Sclable Ecosystem includes services, tools and environment configurations you will need to
use the Sclable Business Application Development Platform (SBADP) at it’s fullest potential.
So we don’t need developers anymore?
To the contrary, at Sclable we foresee a rising demand for programmers, designers and coders. What will change is the amount of work agile teams will be able to do together.
And this means that the way these teams will accomplish their goals will change a lot. Since any project’s team can’t have all the skills needed within the skillsets of its team members, knowledge and expertise must come from somewhere else.
In fact it always did. “Highly skilled” often applies to people, who know where and how to gain knowledge rather than knowing something in the first place. The only problem is that everyone needs time to get into new things.
Sclable’s Platform provides an environment for an understand-and-apply way of doing things. What if your IT staff would only have to focus on what they are really good at?
The Sclable Business Application Development Platform continues to grow and gain functionality. Besides developing stunning new features for our Platform, it is one of our biggest challenges to share and spread our knowledge on developing Business Applications with Sclable.
Knowledge only has value when it is available, and even the best tool isn’t worth much if you don’t know how to use it. This is why we have reinvented the Sclable Documentation and the way we transfer our knowledge.
With the launch of the Sclable Documentation as part of sclable.io (our key knowledge hub for Sclable developers), we made a big step towards our goal to make Sclable knowledge available and understandable for every developer out there.
Sclable.io – totally build with our own Sclable Platform technology – will also cover some other features and topics in the near future. You will read about these upcoming exciting news in another blog post. For now it is our biggest challenge to capture and structure the Sclable internal knowledge and transfer it to our developers.
“INFORMATION IS NOT KNOWLEDGE”
Albert Einstein said that. And yeah, probably he is right about that too. It is one thing to inform our developers and users about the power and new features of Sclable.
It’s another to build a structured system to impart knowledge in a sustainable way, and make it available at any time for every developer worldwide.
KNOWLEDGE MANAGEMENT THEORY AND CLASSIFIED KNOWLEDGE
Before launching a new documentation system, we started to classify what kind of knowledge there is and what we want to share with other people.
According to Michael Polanyi, a hungarian-british polymath, knowledge can be classified into explicit and tacit knowledge.
Polanyi made his thoughts about knowledge, knowledge transfer and what kinds of knowledge there are, back in the 1960s. That was long before the term “knowledge management” came up in the early ’90s by people like Ikujiro Nonaka and Hirotaka Takeuchi. And even longer before it got hyped at management boards and chairmen’s speeches in companies all around the globe.
Nonetheless. What Polanyi pointed out and Nonaka, Takeuchi and many others made clear with their researches, were some basic ideas on how to capture, develop, share, and effectively use organizational knowledge.
EXPLICIT AND TACIT KNOWLEDGE
As Michael Polanyi pointed out, there are two different kinds of knowledge. Explicit and tacit knowledge.
Explicit knowledge is that kind of knowledge that can be articulated, written down and is relatively easy to store. It can be understood as a kind of “people-to-document knowledge”. It makes sense to write explicit knowledge down, as it marks a fact. For example, “That’s an entity. It has attributes, states and actions.”
With tacit knowledge it is a little more tricky. Tacit knowledge cannot so easily be written down. It is more complex to transfer tacit knowledge to another person. In fact it is sometimes not even easy to realize that it is (very important) knowledge.
Tacit knowledge can be things people just do in their daily life, without imagining, that it could be really important knowledge for other people. Like the engineer, who knows that on a particular hydraulic press he has to unlock the protection safeguard twice in order for the machine to work properly.
These knowledge “between the lines” (also called people-to-people knowledge) is very hard to document, but all the more important for a successful knowledge transfer.
THE SCLABLE DOCUMENTATION – KNOWLEDGE TRANSFER IN THREE PARTS
When we were planning how to share our knowledge best and how to structure it, we knew that the Sclable Documentation had to cover both, explicit and tacit knowledge.
Our explicit knowledge on the one hand, is easy to transfer. It includes fundamental concepts, descriptions of layers within the Sclable Platform and so on.
Our tacit knowledge on the other hand, is more complex to add to the Sclable Documentation. Yet, it was the kind of knowledge we were interested in even more:
It’s one thing to know (and read) everything about Sclable Entities, but it’s even more productive to understand why in a certain domain model some references were implemented the way they were by our business analyst and domain modeller.
It’s even more helpful to grasp the benefit of selections and action triggers through a hands on example of one of our domain specialists than just read about how these things work out.
We came up with a solution that consists of three parts, which we believe is the most effective way to transfer our entire knowledge:
1. Explicit knowledge:
Captured within the Documentation menu. The place for plain concepts and descriptions. The theoretical foundation for developing with the Sclable Platform
2. Tacit knowledge:
Captured within the Tutorials section, this is where you find solely specific solutions for your specific problems. We tried to bind as much tacit knowledge as possible to here. All the little hints and tricks an experienced Sclable developer makes use of are shown and explained.
3. Hands-on and knowledge mix up:
Captured within the Get Started section. The idea was to give an easy jumpstart into Sclable. Set up your Sclable environment, start building a first application and check out our Phonotronic Sample Application. Away from theoretical jabbering just start developing with Sclable and gain knowledge through experience.
SCLABLE DOCUMENTATION FURTHER DEVELOPED
Basically, these are the main ideas behind the new Sclable Documentation. Our aim was to transfer knowledge with a straightforward approach. Explicit knowledge and tacit knowledge had to be included as well as guided walk-throughs to just “sclable around” and gain knowledge passing by.
Nonetheless, we are just standing at the beginning when it comes to transferring our knowledge. As this is an ongoing iterative process, new content for our Sclable Documentation will be added and updated continuously.
Sclable aligns with experienced IT Investor and Business Developer
Sclable meets the challenge of our ever-changing world with an intuitive platform for agile business application development. Companies need to adapt faster to internal and external changes. Applications supporting the company’s processes need to be just as fast and flexible.
The Sclable Platform allows to develop, test and use business applications simultaneously – during ongoing operations. Sclable offers an armada of productivity tools to help get a prototype ready under one hour and a first release out in a day. Changes can be applied in hours, not months. Compared with conventional technologies, Sclable provides a saving potential of up to 70% in financial and time resources.
To know more about us, have a look at our videos: https://sclable.com/get-started-with-agile-development-tool/videos/
Speed and flexibility are the major success factors in today’s business world. Just like the Sclable Platform facilitates agile developing, Sclable as a company subscribes to the principles of agility. With Thomas Streimelweger, Sclable found a partner whose personal approach and job history is based on the same maxim.
In this current phase of business expansion, many decisions and investments need to be made. This calls not only for financial resources, but also for the experience and the network of a business expert like Thomas Streimelweger. He built up the S&T AG from an idea to a 3000-employee company with which he went public.
Not only will this top manager with excellent connections in the American and Eastern-European market contribute his business expertise, but he will also fully support Sclable’s global expansion.
Peter Kerschhofer (CEO Sclable) is happy. “In Thomas, we found somebody that will not only contribute his investment and expertise, but also fits our team perfectly on a personal level.”
For his part, Thomas Streimelweger says, “Sclable is on top of all these proprietary, slow and inflexible systems and enables companies to break open old structures without large investments. It is a typical development platform and will very soon create a big community and spread. I believe in the disruptive power of the Sclable Platform. It reflects my philosophy of ’getting things done’ to the maximum extent.”
Let’s talk success to date
Sclable has what it takes to be internationally successful. The innovative and high-quality technology meets the needs of modern companies. Founders Peter Kerschhofer, Markus Nenning, Roland Rust, Martin Sirlinger have combined 37 years of entrepreneurship and hands-on experience in founding and operating businesses. Backed by a culturally diverse and growing team of 9 passionate experts, they are building upon the success of the last two-and-a-half years.
Number of employees
- Projects in the entire DACH region (Austria, Germany, Switzerland)
- Recent customer success stories have shown particular use of Sclable for FinTech Applications (Risk Management, Process Automation, Private Banking) as well as Applications in the Food and Publishing Industries (Manufacturing Processes, Supply Chain Management, ERP, CRM and more). (Read more: http://sclable.com/success-stories/)
- Current clients include Bank Austria, LexisNexis, Nestlé, Wiberg, Kochabo, Heinzel, Leica Shop
- After a research project in evolutionary domain models in 2014, a second research project on data visualization is supported by the FFG, the Austrian Research Promotion Agency in 2015.
- In December 2014, Forbes.com mentions Sclable as a “Start-Up to Watch”.
- Currently participating in the PricewaterhouseCoopers (PwC) Accelerator Program
- Chosen by the Austrian Federal Economic Chamber (“Go International Initiative”) as one of 16 Austrian startup companies that will participate in the accelerator program “Go Silicon Valley” and spend 3 months in the USA at one of the partner business accelerators of the Austrian Trade Commission.
Where is the journey heading?
Sclable is providing a fully functional platform for agile development of business applications.
- The focus is in the evolution of the product and in constantly extending the scope of functions and productivity tools. The hotlist of upcoming features is in http://sclable.com/roadmap/. The launch of an app store for specific business functionality and even entire business applications is scheduled for the end of 2015.
- The Sclable Academy is the place where the most experienced Sclable developers share their knowledge. A fully featured development environment is the knowledge hub for developers and includes documentation, white papers, videos, etc.
- The partner network of experts and integrators that use Sclable to build individual business applications for their customers will be extended.
The red-stars.com data AG invests a sum in the high-six-digit range in Sclable. With this investment, the path that Sclable started can be continued and growth on international markets can be guaranteed.
Effect on company management
In terms of operations, the company will be managed as before. It stays in the hands of the founders Peter Kerschhofer (CEO), Markus Nenning (CBDO), Roland Rust (CVO) und Martin Sirlinger (COO). Thomas Streimelweger will participate as an active advisor and will contribute his extensive knowledge.
Let’s do this!
The investment of the red-stars.com data AG in Sclable is a great feedback and testament of the work carried out so far and shows its trust in the future of the company. We could not have done this alone. This is why now is the time to thank the Sclable team for all the excellent work!
Thomas’ business experience and access to the investor network assures that the path that Sclable started will continue and international growth will be guaranteed. We are happy to be accompanied in it by an experienced expert, that sees Sclable not only as an investment, but believes in our vision and the people behind it.
Prior to the 2.0 release of Sclable’s Business Application Development Platform, the Domain Designer was part of the generic application and vice versa. As of Platform 2.0 the Domain Designer is not only a standalone application, but also a good showcase of what can be achieved upon Sclable besides extending the generic application.
Extensibility through packages
Sclable’s Domain Designer is a complete re-write and re-design. It is available as a package from the Sclable Factory, our centralized package hub, and can be installed via BOB, our build tool. The Domain Designer allows you to access any of your local or remote Sclable installations via a web service, which is a package of its own. Both packages serve as a good example of how functionality can be packetized when extending Sclable.
Model, visualize and explain complexity
Sclable’s Domain Designer is developed with large and complex business domains in mind. On the one hand we want the tool to let you be quicker than copy and paste. On the other hand it should be as useful for you as a developer when you need to visualize and explain the complexity of a business domain to others.
Since ERD and Workflow graphs are used a lot when modelling business domains, we decided to drop server side rendering with GraphViz in favour of client side rendering with dagre/dagreD3, so you can watch the graphs morph while modifying the domain model. This helps a lot to stay focused, especially when you are editing large graphs, giving the tool a generally more responsive feeling.
Sclable workflow graph. This image shows a workflow from our sample package featuring a ticketing process. The example shows a highlighted action named “set to solved” which is a workflow action of the type “edit”. It lets you set tickets to the state “solved” regardless of their pre-state. This is especially useful for interactive data cleaning after deleting a state when instances of the entity referencing the state get decoupled.
Workflow Edit Action
Actions of type “edit” can have a post-state while not having a pre-state. This allows instances to be set into a specific state from any state. An example use case for this feature is a “cancelled” state within a order workflow for example, when you want an order to be able to be cancelled anytime.
Editing Action Attributes. This image shows how action attributes can be defined as of Sclable 2.0. From ‘invisible’ over ‘read only’, ‘editable’ and ‘required’ different levels of user access to an attribute’s value can be set. What’s happening behind that is quite a complex combination of modelling actions: setting ‘invisible’ in fact deletes an action attribute from the sclable core domain, ‘visible’ adds the action attribute with a boolean flag for ‘readonly’ set to true, ‘editable’ sets the ‘readonly’ boolen to false and ‘required’ creates a corresponding restriction along with the action attribute.
Workflow Action Attributes
Attributes can be assigned to an action within a workflow with an additional “read only” attribute. This allows you to specify accessibility levels: invisible (attribute is not an action attribute) to visible (attribute is an action attribute but set to “read only”), editable and required.
These can be edited via the all new relation editor from within the entity view. Reference types become important for the definition of migration paths, where the domain designing developer defines how relational migration issues should be resolved upon deletion of an instance.
Sclable Domain Designer: entity editor tabs.
This image shows the workflow-, attribute-, relation- and agenda editor tabs of the entity editor. The ? key will show a context sensitive hot keys cheat sheet, alt+h displays inline hot keys as seen in the screenshot. Our goal with hot key support is to allow for domain modelling without using a mouse.
The ? key will bring up a hot key cheat sheet, alt+h will display contextual hotkeys inline. Domain modelling now can be done from the keyboard without using a mouse. We will subsequently extend the set available hotkeys to in-graph editing and navigation as well.
Upcoming Features for 2.1
Subsequently we will add every Sclable Core Engine Feature to the Domain Designer. Depending on the complexity of the functionality itself it might take one minor release’s time for a core feature to be fully implemented by the Domain Designer. For the 2.1 release we plan to implement the Agenda/Action Binding Editor and the Selection Editor.
The Sclable Core Engine as of platform version 2.0 has been re-written from scratch. For two main reasons: first, to have a less monolithic architecture and second, to allow developers to extend the Sclable core.
At the same time we added some new features we’d like to introduce. Read on to learn how Sclable 2.0 adds more performance and security to your applications and lets you utilize events and triggers.
Postgres Performance Comparison from versions 7.4 to 9.4. One of the reasons why Sclable uses PostgreSQL is because of its continuous performance improvement. With the new Sclable Core 2.0 we are getting more out of the PostgreSQL community’s endeavours.
Image: PostgreSQL Addict
This one must go to the beginning of this post: The main challenge before the rewrite was the varying performance for agenda filtered views of an entity. Even though we aimed one step further to filter on an attribute level, we wanted to increase performance. We solved that issue by tying the Sclable user management to the PostgreSQL user management. Instead of primarily operating with filter functions, Sclable uses real views, thus allowing PostgreSQL to plan the execution of the query more efficiently and increase the performance.
With tying the user management to the PostgreSQL roles, the Sclable Core Engine is secured down to the data level. The users are not only logged into the application, but into the database as well with the very same privileges. Hence the users have the same level of access on every architectural level of the Sclable Business Application Development Platform.
Event and Trigger System
The event and trigger system introduced with version 2.0 allows you to extend the Sclable SQL core with additional functionality by simply hooking SQL functions into events and triggers. This reveals a world of great possibilities from process automation to arbitrary business rules.
Sclables Core Engine architecture has been redesigned to collect features in modules. Every module is stacked on top of the modules it depends on, just like layers of an onion. From the domain modelling point of view, the Sclable Core Engine modules belong to the domain «Sclable» and can be read and understood just like any business domain modelled with Sclable, thus being a good example of how to structure a domain.
Sclable Core Entities. This Graph shows the dependencies of the entities of the Sclable core domain grouped by modules. Image: Sclable
System, Event and Builder
The minimal core consists of the system module containing domain, module, entity and attribute information and logic. Followed by the event module, needed to execute the appropriate actions upon changes to the instances of entities in the system module. Those actions reside within the builder module.
Data Integrity Modules
‘rule’, ‘restriction’ and ‘path’ are the next Sclable core modules in the hierarchy. It’s all about data integrity. ‘rules’ are regular expressions and operators applied to attributes. The ‘restriction’ module describes uniqueness and requiredness of attributes and handles references between entities. The module ‘paths’ chains references to more complex relations such as ‘customer’ → ‘city’ → ‘country’.
To give a better description and control to the behaviour of references, we introduce reference types. In a relation of ‘order line’ → ‘order’, the type would be ‘cascade’ (which is the default), allowing to remove all order lines of an order when the order is deleted. While this is a good thing to keep the order lines entity clean, it would be catastrophic removing all customers for a city when it gets deleted. By describing such a relation as ‘restricted’, a city can’t be deleted as long as there are customers pointing to that city. ‘decouple’ will leave instances with the former reference set to NULL and ‘delegate’ will force users to point to an instance to be referenced, replacing the former reference.
Workflows with Action Triggers
Workflows became a system module of it’s own to describe the lifecycle of an instance of an entity. One of the most important new features with workflows are action triggers. action triggers allow you to execute functions on the database before and after a specific action has been executed on an entity. They present the ability of a more fine grained hooking than a trigger on the entity itself which is executed on every change.
Delegation with data filters on attribute level
One of the top onion layers of the Sclable Core Engine is the delegation module, responsible for authentication and authorization. Sclable 2.0 implements an authorization down to the attribute level: Users have access only to the attributes of an entity they are allowed to read by the actions they are allowed to perform.
A new Action Binding Concept
In Addition to this, Sclable has a new action binding concept as of 2.0. Take a Sclable based CRM for example: A user is responsible for customers in Germany and Austria. The entity customer has a relation to the entity city, which is related to the country. The agenda ‘key-account-manager’ allows to execute the edit action on customers bound via the city to a country. When assigning the user to this agenda, we select the countries Germany and Austria to grant access to all customers in these countries.
Sclable Selection use case example.
This image shows a simple use case for Sclables concept of “Selections”: For the display of chosen manufacturers from a business domain only the name of the company along with the latitude and the longitude of that company’s city is needed. It is a simple task of click-selecting attributes along a chosen relational path. The Sclable Core Engine automatically writes the appropriate SQL join statements for the auto-generated database view which ultimately is filtered by the user’s scope. Image: Sclable
Selections were introduced in version 1.0 as an extension to the core. Selections represent a set of values from attributes or calculated/aggregated attributes throughout a defined relational path. In version 2.0 we decided to give them more importance by adding them as a core module. They now integrate well with the authorization concepts of the delegation module.
Last but not least, we refactored (and simplified) Sclable’s built in data dictionaries. Translations can be activated for attributes since 2.0. Translations then are stored by entity, language and instance, thus reducing the amount of queries to translate an entire instance dramatically.
Recap and upcoming features
With its rewrite, the Sclable core is ready for our proposed roadmap. The onion architecture allows developing and releasing of feature packs every quarter as well as the maintenance of legacy versions. Amongst things we already queued for the upcoming version 2.1 are re-written calculated attributes along with a concept for aggregated attributes, both available within your selections. Keep an eye on our roadmap to stay up to date!
Martin Fowler has written an article titled “Domain Logic and SQL” on the topic in February 2003, the same year Eric Evans published “Domain Driven Design – Tackling Complexity in the Heart of Software”. Recently we were asked (again) where we would see our position. Obviously, we favour an architecture where the relational database holds as much logic as possible, but why? And how does Sclable come around the common pitfalls?
OOP (Object Oriented Programming) versus SQL
The debate is largely run by technicians divided into two camps: OOP and SQL developers. Unfortunately they’re often divided by organisational and cultural splits. The OOP party isn’t allowed to apply changes to a database as they require, while SQL architects refuse to write helpful views for maintainability and performance reasons.
Though living on both sides, Fowler himself admits to be biased towards OOP (or at least, was in 2003), but he states in his article: “By hiding SQL, application developers are excluding a powerful tool”. To give an impression on how intense discussions already became back then, Fowler mentions that he has been run out of a company by a former client’s OO expert group because he was a “data modeler”.
In this post I roughly follow the route Fowler takes in his article. While written in 2003 and a lot of people still referring to it, many things have changed. I’ll show how Sclable takes advantage of the new world of RDBMS.
Many application developers would still shy away from even minimal complex SQL queries. This is absolutely understandable, as SQL differs in many ways from programming languages. And when it comes to JOINs over ten or more tables along with calculations, aggregations and windows, nobody would say, it’s maintainable. How would you be able to react on domain model changes?
Sclable’s concept is called “Selections” and puts an end to this dilemma. Selections can be built extremely fast with a visual query builder generating user permission aware (!) views. Change your domain model and your Selections morph with your requirements.
Transaction Script, Domain Model and Logic in SQL
Fowler compares three approaches to query data and apply domain logic: A procedural pattern called “Transaction Script” described in his book P of EAA with the advantage of having business logic and loading separated in your code, the object oriented domain model with the advantage of a reusable data loading and a more separated yet encapsulated business logic. Both have the downside of requiring multiple queries to lift more data into the memory as required for the logic. The third approach is written in pure SQL. It is quite obvious that the latter is the most powerful, performant and efficient way to go for.
Looking at Performance
Fowler sees more priority in writing maintainable, reusable code than in thinking of performance first. This sounds reasonable, but he also admits that his SQL query example performs 20 times faster in the test setup of his “little laptop” than the two other approaches. His suggestion is to enhance OO code later on, where necessary with more complex SQL queries. Obviously you’ll end up having both: maintainable but unperformant code at large and a growing base of SQL painfully hard to maintain.
Sclable models the domain directly in SQL and adds APIs giving you the benefits of all three approaches: You can extend your business logic in an OO manner in the language of your domain, you get an automatically generated metadata mapping to achieve that and all will be built on top of the full power of SQL.
Fowler sees modifiability as the main reason why developers put business logic in memory rather than into the database. He sees two limits in the capabilities of SQL: You can’t use non-standard extensions if you want portability and you might need some business logic for your session data before persisting it in the database. The next five sections will go into detail about this.
This is a topic we have been dealing a lot with at Sclable. Modelling relational database structures and writing business logic are often two different disciplines, since databases are seen as a persistence layer while business logic is made to work on data. Database architects refuse to tackle domain logic, and on top of that, programmers have a hard time to understand SQL to an extent required for writing business applications.
At Sclable we aim to visualize structural as well as logical concepts so anybody, even the end user will be able to understand. Furthermore, we provide APIs on every level of the platform. Our Low-Level SQL-API translates domain logic to our PHP-API which translates it to your application front end. The generator component of the Sclable Core Engine keeps your domain logic moving and morphs all dependant layers with it. Think of it as WYSIWYG on application scale.
Fowler states that duplication easily can be avoided in an OO domain model approach. To avoid duplication of SQL code, you would have to create views in the database. In some environments, this would move it out of the scope of the application developers. Well, we use views in Sclable extensively. A fairly large Sclable Business Domain with more than a hundred entities can easily have about the same amount of calculation and aggregation functions and four times as many views to produce domain logic specific results. And all of it only in the database in SQL.
Instead of avoiding a powerful tool to prevent duplication, we are generating all required views and the Sclable Core Engine with its builder component modifies them upon domain model changes, so they are free of maintenance while your domain model always stays DRY.
A common approach in OOP design is to encapsulate logic. The application layer is having modules interacting via interfaces to simplify their complexity on the outside. Yet the database is seen as one big module a layer underneath. Fowler argues that changes in the data structure otherwise would cause a large ripple effect across a system.
At Sclable, instead of separating the application from its data, we move the domain logic into the database. We still encapsulate logic in modules, but give them a place of its own beside their data. The system overcomes the painful round of editing across the application by listening to the model changes and executing necessary changes automatically.
A big point to not utilize the database all too much is portability. Using the strengths and powers of SQL makes your business application depending on a specific database vendor.
This is true. But as with every business application it depends on the project if this issue has to be taken into account all too much. How likely will it be that you will need to change your database vendor at all? Sclable ships with PostgreSQL on board. And that’s for more than one reason.
Although it is common practice in SQL not to test, at Sclable we have written our own SQL testing framework we named “Sclunit”. Using the advantages of transactions, we finally are able to run tests directly in the database, with the business data and its logic in a completely non destructive way.
Fowler suggests to go for the development team’s personal comfort. And he is still true, when he states that a lot of people find SQL terribly cryptic. For any critical performance issues you might have to write queries nevertheless. Our experience is that it will be very likely that you’ll end up with an incomplete domain model having parts of your domain logic in SQL as soon as your model gains complexity.
At Sclable we made it our goal to put an end to the debate whether to go for in memory only or use the power of SQL (structured query love). We’ve been set out to deliver a Business Application Development Platform that gives you the best of all. For the majority of business logic you’ll actually never need to write SQL at all, Sclable’s Core Engine does that for you.
Sclable’s development stack also allows to seperate modelling from coding. Coders do not need to bother the system’s architects when it comes to write boring, repetitive SQL and the system architects can focus on the domain model.
One of the most frequently asked questions regarding the Sclable architecture is: what does Sclable use as database? The answer is PostgreSQL, which according to the PostgreSQL Global Development Group is “The world’s most advanced open source database”. Read on to learn why Sclable just loves PostgreSQL.
PostgreSQL is open source
Why is this important to us? Well, at Sclable we do a lot of quite amazing stuff. Therefore we need to fiddle with the source code of our underlying technology. PostgreSQL allows us to do just that. We need the opportunity to extend, patch and tweak the relational database behind Sclable in every way to give you the best possible Business Application Development Platform available today.
PostgreSQL is enterprise-grade
PostgreSQL is the premier choice for mission critical applications when an Open Source RDBMS is needed. The PostgreSQL website currently lists companies specialized in enterprise support for PostgreSQL on every continent, while Europe is leading with the highest number of PostgreSQL enterprise integrators. For the size of the country, Austria is leading in Europe.
OSRDBMS like PostgreSQL have a low TCO
According to Gartner’s 2015 Report on The State of Open-Source RDBMSs the total cost of ownership of OSRDBMSs (Open Source Relational Database Management Systems) is significantly lower, even when enterprise support is taken into account. The report states, that by 2018 more than 70% of new in-house applications will be developed on an OSDBMS and 50% of existing commercial RDBMS instances will have been converted or will be in process.
PostgreSQL is fast as hell
It is out of question that PostgreSQL is a performance beast. An example: The Skytools library, used for replication and failover in Microsoft’s Skype, the popular VOIP application, is built upon PostgreSQL. Doesn’t that tell you more than a bunch of statistical graphs?
Some younger developers ask why Sclable doesn’t go for some hipper NoSQL approach like MongoDB. So if you long for some stats, read how PostgrSQL outperforms MongoDB in a blog post from Marc Linster, Senior Vice President at EnterpriseDB.
An image from this year’s FOSDEM, a PostgreSQL developer conference we’ve been attending at Brussels, Belgium. The history of PostgreSQL goes back until 1996, when PostgreSQL became open Source. Today the project hosted on Github, where you can fork the source code and commit to the project as a developer. Image: Weborama Blog
Postgres is for developers
Sclable is a platform for developers designed by developers. So is PostgreSQL. Among the features we like and use with Sclable – which are missing in alternatives, including commercial RDMSs – are:
- Platform independence
PostgreSQL runs on any OS. Many proprietary RDBMS products just don’t.
- A proper shell
At Sclable we use the PostgreSQL shell extensively. In fact you can develop a complete Sclable Business Application just on the command line of the psql shell.
- The contrib
PostgreSQL has tons of features on board. But there are 45 optional features (as of 9.4) coming with the PostgreSQL contrib modules. At Sclable we like pgcrypto a lot.
But will Sclable run on other RDBMSs some day?
At the moment the answer must be: maybe. A port of the Sclable Core Engine over to another real good relational database is theoretically possible. From the conceptual point of view. Lastly it will depend on the Sclable developer community. There needs to be at least someone who really wants this for a technically valid reason.
This blog post is just what comes to my mind as the main important matters explainable with only a few words. At our daily work we are facing challenges that possibly could fill a book (and maybe one day will do so). Overcoming them reassures our choice for PostgreSQL, which makes us really, really happy.