A Sleek App Architecture for Life, the Universe, and Everything
Beautiful application architecture can have considerable benefits for an organization, despite being very often overlooked. Throughout this blog, I will provide insights into how OutSystems approaches application design, provides rules to ensure a sleek (dare I say sexy?) architecture, and makes available tools that simplify the overall architecture management.
Much like OutSystems approach to development, OutSystems has looked to simplify and disrupt architecture design by reducing a complex idea into 3 simple layers.
These layers consist of the following:
End User Modules - How/Who are going to be interacting with an application.
- User Stories, UI and associated processes
Core Modules - What business logic/concepts are core to the application.
- Reusable business concepts/logic usable by end user modules or other core modules
Foundation Modules - Think of them as highly reusable business agnostic components.
- Such as an integration layer
This sounds great in theory but let's take these principles and apply them to a practical use case I commonly hear in the field:
A customer has an operationally-focused application that is needed for a set of business users.
Their current system is inflexible and the amount of time they are spending each day is not optimized; they need to cross reference data in multiple systems (Oracle, Snowflake, for this example). Ideally, they would prefer a solution that helps them reduce the daily wasted time, consolidates their data into a single report, and proactively provides recommendations to improve user efficiency.
Breaking this application into its essential parts while following the three-layer canvas approach, I come up with the following elements:
- End Users Module: Business User
- Core Module: Decisioning Engine
- Foundation Module: Oracle, Snowflake
But this approach can’t address complicated use cases… can it?
Taken to the next level, these fundamental principles can distill large-scale complex applications into much more manageable (not to mention understandable) applications. This allows them to be delivered faster and more to the needs of the business, all while substantially reducing the amount of technical debt within an organization.
I’ve always been of the mindset, the best way to solve a problem is to break it into smaller pieces and continuously improve them over time. The powerful strength of the OutSystems application architecture allows you to do just that. It breaks down a complex problem into smaller pieces, making the components highly reusable and segmented for different delivery cycles and changes. This is especially prevalent and impactful on large scale applications. I’ve seen large 20 year old systems replatformed in a more fit to purpose manner onto OutSystems in months. In turn, it is being more manageable and adaptable to changing business dynamics. Considering how hard it is to predict where a business will head in the next few months, much less multiple decades out, this is powerful.
To drive this home, let me come back to my previous use case. Commonly, after users have been in an application for a couple of weeks, they discover more functionality that they may want to incorporate. In the example mentioned above, possibly wanting a centralized dashboard that cross-references data pulled from Snowflake and Oracle would help to save time and improve end user efficiency. Now given I already have my data properly segmented, I don’t need to update my Snowflake or Oracle Integrations, thus allowing me to make my change and deploy it quickly. In fact, I should expect that my Business User layer would require quicker changes as the users are in and out of the application daily, possibly needing updates weekly. Whereas my integration layer, I may only want to update monthly, given the criticality of the component and the impact throughout my organization. Thus my application architecture can be further refined as follows:
Need to make a quick change to your dashboard? No problem! You can quickly and easily make changes in a manner that doesn’t impact corresponding business functions. Such flexibility improves speed, reduces time to market, and provides an optimal end user experience.
But how can we stay true to this design? How can I scale this to a platform of applications or wrap my head around the current state of my applications?
These are great questions I hear all the time. Fortunately, OutSystems has augmented this architecture with three simple rules to ensure the applications are properly designed.
- No sideways references (in End Users Modules)
- No upward references (in the three layers)
- No cycles (within the modules)
No sideways references (in the end user layer)
Let's say I wanted to add a role to my application, such as an application administrator. Having the delivery of this separated from my business user allows a tailored experience to quickly deliver changes without relying on a completely separate and potentially unrelated Business User Module. Fundamentally, this rule helps to improve segmentation while reducing cross
No upward references
Now, what if my business users decided to consolidate data from Snowflake and SAP into a singular dashboard screen? Often, situations arise from inflexible systems and can lead to dozens of hours per week per site/person trying to resolve. I want to deliver this change as fast as possible; however, if I need to wait for updates to my Integration layer, this may take weeks to accomplish. Fortunately, having no upward dependencies, I can quickly deploy my changes without impacting my integration layer. This modularity substantially helps the flexibility of my architecture, and allows my release cycles to be driven by need and criticality.
No Cycles
Removing cycles from an application helps to remove one of the biggest challenges that can face application architecture. Imagine if my decision engine connects to my oracle module, which connects to my snowflake module, which integrates to my decision engine (decision->oracle->snowflake->decision). Complicated connections such as this can lead to difficulties in understanding the logical structure of the application and make it extremely difficult to update the application. If you update one of these, would you need to update them all?
Keeping these rules in mind makes it easier to manage the structure of an application while taking the most significant advantage of the OutSystem platform capabilities.
But my environment has dozens of applications in it!
I can’t possibly understand all the nuances of the applications in it. It's too big, too all-encompassing and getting more complicated with each passing day.
Wouldn’t it be great if there was a tool that helped me ensure that I was following platform best practices while helping me understand if there are any critical issues with my applications?
Enter OutSystem’s Architecture Dashboard.
The OutSystem’s Architecture Dashboard helps to visualize platform best practices, security recommendations and performance issues. What's more, with each passing day, the dashboard gets more intelligent by learning from the hundreds of thousands of applications built on the platform.
Understanding the nuances of 100+ applications is incredibly hard; however, having an intelligent solution that proactively provides feedback to you can help to focus time better and improve the safety and security of an application portfolio.
At the same time, the Architecture Dashboard helps to understand the aggregate change in an environment over time.
So simple design, harnessing easy-to-leverage rules, coupled with an intelligent platform, makes creating and managing application architecture easier than ever.
Want to learn a little more? Join us for an interactive discussion on September 28th with Professor Rick Kazman, author of “Technical Debt in Practice: How to Find It and Fix It.” All attendees will receive a free copy of the book!
Thanks so much for taking the time to read this post!!!
So long, and thanks for (helping to get rid of) all the technical debt.
