Digital Innovation. Bimodal IT. Digital Transformation.
Binding together these core Mendix philosophies is the theme of change. It follows, then, that when an organization adopts Mendix, it signs on for a fundamental change of state in its IT practice.
As a developer, I know better than most that the platform is unique in its ability to catalyze IT transformation.
- Visual modeling is intuitive and powerful
- Functional or stylistic customization is straightforward and in line with modern software methodologies
- Collaboration is easily enabled
These and many other capabilities make Mendix a true centerpiece of Driving Digital Innovation. However, being that centerpiece, important as it may be, does not comprise the entire effort of actualizing digital innovation. Just as a race car will underperform without a trained driver and crew, Mendix’ ability to enable transformation cannot be realized without the right operators.
The client of one of my recent project engagements did not make the transformative leap that our platform is designed to catalyze. With the benefit of hindsight, I am writing to share lessons of this experience with the Mendix community. I must be as broad as possible with any details about the organization, but I hope that in turn the applicable lessons come to the forefront.
Development must be agnostic to hierarchy
In building the app, the exchange of information between and among the organization’s subunits was a well-defined natural blueprint for the application’s architecture. With some of the business units my work adopted a productive cadence of development, testing, and feedback (giving way to again to development), which enabled me to deliver robust design and efficient modeling. With other units, however, productive iteration was impeded by shifting requirements, often punctuated by “scope landmines” – ideas that are initially minor, but explode into disproportionately large tracts of work. In these cases, the underlying architecture (and observed performance) reflected synthesis of a too-large cache of information, waterfall in spirit and containing overlapping or even contradicting ideas.
In the end, those components of the app that were unnecessarily complex tended to belong to the user groups with the most influence in the organization. If we assume, as we should, that an app and its components should only be as complex as needed, then we must resist lending grease to the squeakiest wheels without good reason. App development must be agnostic to an organization’s hierarchy.
Plan for transformation
Side by side with the client’s legacy app, the user interface of the app we delivered is telling of forward strides in technology. As a developer of the app, I can say with certainty that it allows the client to perform their business functions via updated information technologies. I, and the Mendix community, know that with Mendix, this client is better equipped than ever for rapid application development.
Still, I hesitate to say declare this project achieved success. We designed the app based on the user’s business processes and the functionality of the legacy app, but rarely, if ever, did we ask how the processes themselves might be modified with Mendix in play. We brought in a new technology, but did not see greater expectations of technology take root. What we achieved was digital replication, when our aim is digital transformation. Building Mendix apps must start with an openness toward and transformation, and a plan therefor. Only then can success be measured against the correct scale, in terms of movement in the transformative direction.
Innovation is a discipline
From day to day, the project hummed along via mechanics common to almost all IT projects – daily stand up meetings, requirements gathering with the client, task tracking, and stretches of development and testing. Perhaps because things distilled into these familiar patterns, innovation was not accounted for in the mix, and in the absence direct influence, would we make room for something like that? Innovation is difficult and risky because it demands creation of something new, often leaving behind a trail of failed attempts. It is not just a static (albeit aspirational) idea, but a working mindset to that needs to be refreshed daily, if not more frequently than that. Innovation is a discipline, and maintaining that discipline is a critical, essential part of delivering Mendix.
I conclude with an encouragement to my fellow developers. In our projects, and within the community, we trade on our skills – the better we are at building architecture, integrations, and customizations, the more valuable we are in a project team. I learned from this project to regard innovation – a mindset and a discipline – as a skill as well, and to train it in kind. I hope you will find reason to do the same!