Unlocking Value: The Need for Speed in OutSystems Development
Building apps with OutSystems is great, but building a Business Platform really drives innovation within the organization.
This article discusses the limitations of traditional software development and highlights how OutSystems, as a comprehensive platform rather than just a tool for rapid application development, can significantly enhance the software development process. It emphasizes the importance of aligning closely with stakeholders, building a modular system with reusable components, and adopting a strategic approach to application development to avoid common pitfalls like project delays and budget overruns. It advocates for starting with foundational elements on the OutSystems platform to facilitate faster and more efficient development, ensuring projects are better aligned with business needs and more adaptable to changes.
With OutSystems, software developers can create applications a gazillion times faster than with traditional code.
We read this constantly, and to some extent, it's true, but I still don't like it. It doesn't really express the value of OutSystems as a platform.
Software development involves much more than just writing code. It begins with developing an idea, and then you need to interact with various stakeholders before, during, and after the project. This includes actual users, indirect users, and the Security Office, among others. You also have to consider various technical and organizational conditions, and sometimes, you might even need to involve the works council. Budget and timeline are, of course, crucial. You need to define an architecture that fits within an overarching architecture and more. And if that's not enough, the application also needs to be deployed, monitored, operated, and maintained.
Projects fail more often than they succeed
Nearly 70% of all digital transformation projects fail. "Failure" is a strong word, and it doesn't mean that these projects never see the light of day. 30% of them are canceled before they're finished. The other failures are projects that go way over their original timeline or budget, or the end result doesn't bring the benefits it was supposed to. Usually, the costs are higher than the benefits in these cases.
This happens for many reasons, like a project suddenly becoming urgent and needing priority, goals not being met, outdated software architecture blocking the solution, or new requirements leading to a total reassessment, among other issues.
Why projects fail
However, when you take a closer look, you can pinpoint two main reasons.
First, software development is generally too slow. Naturally, if a project takes too long, there's a high chance that new needs or realities will emerge.
Second, software development isn't closely aligned with stakeholders. Usually, a business stakeholder talks to a business analyst, who then communicates with the solution architect and others; the project manager also becomes involved. Eventually, all these messages get to the development team. In complex projects, this can result in huge loops of communication.
This might not be the exact process but it helps to make the point. At some stage, the development team might go off for about 8 weeks to develop the framework and the first feature as specified. Initially, everyone is satisfied, a test deployment is done, and a meeting is set up to show the developed feature to the business stakeholder. The first feedback often begins with "Yes, but...". This "but" alone can instantly add about €30,000 to the costs and delay the project by two weeks. It's no surprise that projects often go over their time and budget limits (or need to be canceled and reassessed).
Build up Speed! Build a Platform!
Even rapid development with OutSystems is only partially effective. It truly shines when used as intended: as a platform, not merely as a tool for developing applications.
Unfortunately, many potential OutSystems prospects approach it with just one use case in mind, often a single application, and inquire about the overall costs. While some of these applications are complex enough to justify using OutSystems as a platform, a simple approval process does not. Starting with OutSystems only to build a basic application is like adopting Salesforce just to store addresses.
OutSystems should be adopted as a comprehensive business platform, and applications should be developed once the foundational elements are established on the platform.
Every company has an enterprise architecture, even if it's not formally documented, where data flows between systems through business processes. For this data, also known as business objects, and their associated systems, it's important to create reusable core services and integrations on the OutSystems platform. This includes considering development, testing, and production environments. Building upon this foundation, we should develop reusable UI components (like a display element for a product record) and complete UI and application templates. Additionally, central libraries for utility functions related to business data objects should be established. All these steps should be taken with the foresight that future individual applications will generate more data.
Achieving this is easier said than done, as it involves extensive planning and potential changes to existing services.
The effort is definitely worth it, especially since you can coordinate these modules with other stakeholders ahead of time. It also speeds up application development because getting access to existing business data objects through integrations usually takes a lot of time in projects.
The main idea behind these core services is to build a modular system and design the individual parts in such a way that the application developer doesn't have to worry about the details, or only to a limited extent. The developer should focus solely on the application's benefits and functions.
This approach can somewhat speed up the development process, but it also requires a lot of upfront work. However, you don't have to model the entire company as a modular system right away. Ideally, you can start with one area and expand gradually. It's completely feasible to begin with one application and, within this application, create the reusable core services and modules. Just remember that this method will require more time for the actual development of the application.
Speeding up application development has its advantages. The quicker an application is finished, the less likely the project will be canceled due to changes in priorities, reevaluations, or shifts in budget.
Keep your Friends close your Business Stakeholders closer
However, this approach doesn't always ensure we're aligned with business stakeholders. They are the ones who define the basic functional requirements, which often change during the project or may introduce new requirements. In a low-code power-house, developers work more closely with business stakeholders and communicate with them directly. Visual development speeds up this process, making it easier for stakeholders to understand. Forms for input and output can be adjusted in real time, and even minor changes to the business logic can be discussed, modified, and reviewed on the spot.
The aim is to hold feedback sessions with business stakeholders in short cycles. This approach allows for quicker feedback collection and greatly lowers the risk of needing to implement major changes.
Summary
With OutSystems, you can develop applications quickly, but there's an even faster way to achieve comprehensive digital transformation. Rather than using OutSystems just for creating individual apps, aim to build a Business platform. This can be done by leveraging one of OutSystems' key features: Modularization. Additionally, by utilizing the visual development tools, you can bring your development teams closer to the business side.
Combining both approaches significantly speeds up end-to-end development of solutions. While it may not be a gazillion times faster, it's quick enough to transform ideas into valuable solutions rather than failures. After all, no software developer enjoys working on projects that fail, right?