To build or buy, or better yet…

The “build or buy” tradeoff has been described as having “Shakespearean proportions”. It is typically the starting point for solutions to business problems that can be solved with technology.  Due to the increased rate of change and global competition, this question is even more relevant.

To save you research time, we will relay the short and simple answer to this classic question: To buy or rent when you seek the solution to a commodity business process and to build when your solution touches the core differentiators of your organisation.

If only it was that simple. The tradeoffs have become more complex. The proliferation of vendors that saturate the market with general purpose systems makes the choice a complex affair.  Add to this the recent addition of Cloud and SaaS service providers that offer a plethora of modules and a new risk/reward model that removes hardware and hosting issues but adds data ownership, security and an dependance on the Internet to the considerations. Then the decision matrix for a “build or buy” choice becomes an operations research decisioning problem: never mind the normal softer issues like internal politics and ego’s.

The solution is to formally add a third option to the “build or buy” set, namely that of “assemble”.  We then have the following options, namely to buy/rent, to build and to assemble.  SOA provides the technical framework to do this, but does not give us an agile and efficient way to assemble these components into a coherent whole to produce business value. By formally adding the third option, most people will argue that this is not new and has always been there implicitly – the combination of a buy plus a build to extend what is purchased or rented.  However, the introduction of a formal “assemble” option adds a new dimension, rather than just a combination of the two.

Traditionally for COTS systems, a buy-build would be required to extend the functionality for the 30% they do not provide.  The ERP wars of the 90’s showed that this type of hacking resulted in terrible delivery cycles that went over budget, under-delivered and caused huge maintenance nightmares. The lesson: Do not extend off-the-shelf packages where possible, upgrades become a nightmare and the buy value proposition is quickly invalidated. This generally applies to COTS and open source components and systems.

Back to Basics

Before delving into the ”assemble” option as a formal construct, we have to emphasise that it relies on having the “basics” in place, namely:

• Proper business ownership and a formalised product owner team if more than one person has the product owner role (not ideal).
• Have a solid Agile development framework and software development life cycle process management in place.
• Knowledgable people that understand the business and like what they do.
• Have the proper investment focus by investing where you gain incremental revenue or the competitive advantage.
• Analyse your legacy systems and clearly identify what still has business value.
• Business processes have to defined the right way and must focus on the customer rather than inward-focussed business processes.

Infrastructure and tools are normally a simple buy choice, as is using open source components like databases, development, operations and programming languages.

The build-buy-assemble choice still has the same basic decision points, namely cost, time to market, politics, architecture, skill sets, and strategic value, with the old rule of thumb to buy to the maximum extent possible to cut costs and free up resources for what REALLY delivers the unique edge.

Finally, the industry is changing and we believe the following facts give more scope for a formalised Assemble option:

• Vendors are saturating the market with general-purpose systems.
• SaaS will put legacy systems under pressure by offering software with shorter time to market, lower maintenance costs and lower costs as SaaS typically lets customers pick and pay for functionality in modular fashion.
• The major enterprise software vendors like Oracle and SAP are moving toward component-based models.
• Traditional large scale development with .NET and Java is as risky today as it was a few years ago.

The third option

So far we have established the basic criteria and fact sets and can now introduce the third option of system assembly as the better option. Buy components where possible and create a dynamic layer that binds these components into a coherent business delivery model by using model driven technologies. Modern model driven development offers quick time to market and excels at consuming integration points and then adding unique business logic, entities, validators and excellent performance, security, re-usability and maintenance.

SOA provides the technical framework for easily integrating systems. As long as legacy and component based systems provide the correct granularity of services, we can quickly assemble new product delivery systems that leverage and extend them without hacking source systems by using model driven assembly technologies. The important factor here is to choose the correct model driven framework that offers checked and validated logic and can easily consume services and expose its extension points as services.

Modern model driven development specialises in producing reusable components with extension points through what is called a domain specific language (DSL).  We can then augment, extend and aggregate systems to produce business value quickly by using the DSL.  There are currently two categories supported by commercial model driven development vendors that provide the raw material to assemble solutions that are agile, quick and efficient.

The model-driven market is developing quickly and vendors like Mendix, Talend, FICO and Microsoft (to name a few) are delivering new platforms and development tools that makes the ”assemble” option an excellent formal choice.  This is supported with training, certification and support options to offer a sustainable development and delivery model in addition to the traditional development environments like .NET and Java.

The first category of model-driven development platforms focuses on creating new functionality from scratch and offers a compelling alternative to .NET and Java.  In this space Mendix is one of the leading vendors.

The second category is more specialised in verticals. For instance the various BPM vendors like Bonita offer excellent BPM process management tools. Another example of a model driven vertical is FICO’s Blaze that provides model-based decisioning tools, or Talend’s ETL and ESB tool sets.

To conclude, the “build or buy” choice typically included the buy-extend or the build-from-scratch options.  The assemble option replaces the buy-extend with buy-assemble. Here the emphasis is on adding the missing functionality of the purchased systems by using the most efficient technology to add the business value quickly and in a platform designed to handle change.  Model driven platforms are designed with change in mind,  and offers checks to validate dependent systems’ service consistency with the business process, business entities and state.

The build option can also be replaced with assemble as we could use the model driven platform to create the solution from scratch that ONLY implements the function points and business processes required to offer tailor made business value.  We will detail the requirements to look for in a good model driven framework in following articles.

Mendix World – Day 2; Good bye Rotterdam

Its quite easy to assume a fandom prejudice; to praise Mendix “because we are a fan blog”, but our fandom does not stem from the fact that the product we love is called Mendix; thats mere flattery. No, it is worthy of its praise on the basis of its merit, inspiration and the motivation to make the world a better place, not by conventional means, but by the call to convert crisis into opportunity in an innovative fashion. This is how I could summarise day 2.

Mendix World 2012 concluded in excellent form, despite some hiccups from 1 speaker’s anxiety and/or health issues in a session, but reports from all the other talks and tracks were very positive and successful. Johan Den Haan gave a more in depth preview of what to expect from Mendix 5 and proves to be yet another big leap in the Mendix paradigm. The new features aren’t necessarily stuff that I would have thought of for a next release, but the more I think on it, the more I realise that those features will add a lot more than just productivity, but also greatly improve interaction in services, end user experience and interfaces. I cannot wait for the first incremental release of the product and look forward to see its arrival.

Another gem from the keynotes was Ron Tolido’s keynote. He gave a colourful talk on “Enterprise meets Agility” based on research with Capgemini and MIT, for which you can find the whitepaper here. His forward manner and ability to engage with the audience makes him a great speaker and sheds light on a few insightful challenges enterprise organisations face in a rapid changing world.

The tech tracks very interesting. Jouke, Arjan and Arjen all provided very exciting presentations. Not only could one appreciate the forethought and effort that went into making it interesting, relevant, setting the stage and expectation for Mendix 5 in more detail, but you could see that these guys think about what they do in a big way. Their inspiration and enthusiastic approach is visible to the observer. The quotes they use in their talks especially resonated with me. It wasn’t your usual off the shelf buzzword-complient help-me-sell-my-products phraseology; it was focussed, sincere, mature and visionary.

At the end of the day, mostly everybody was exhausted by 2 days’ of networking and delivering inspirational insights into Mendix. Despite that, some of the R&D team sat down with Derek Gardiner and myself and we informally interviewed them on the day to day interaction with each other and gathered some history behind Mendix. This was thoroughly enjoyable and refreshing and left us with something to remember. I wish that we could interview more of the team and hopefully we will still have the opportunity to do so in the future.

The interview and the chats we had was the proverbial icing on the cake of the conference. If we’re able to, we’ll be covering some insight into what we’ve learned there, but we just want to personally thank these guys for their time, their outstanding attitude and willingness for allowing us the chance to get to know them and would like to encourage them to continue building and delivering great software, continue innovating and cultivate the Mendix culture that makes them unique.

Geeking out on a Dark Knight, Artificial Intelligence and Mendix

Mendix is a fantastic business tool catered to provide business with rapid high quality applications. Some time ago someone made a joke about writing an artificial intelligence application, specifically  a genetic algorithm (GA), in Mendix and for some reason I couldn’t let the idea go so I gave myself a time boxed period to model one. I learned a few interesting things about Mendix which I summarize in the last section and have defined more of how I built the GA in the inbetween section.

In order to understand more we need to define some GA terms:

1. An Organism as: A solution contains the blue print to the answer to the problem trying to be solved.

2. A Chromosome as: A building block of the solution contained within the organism.

3. A Population as: A group of organisms, each containing their own specific answer to the problem. Some solutions are better than others and therefore the organisms with the better solutions are deemed to be fitter  (more valuable) than others. When the GA is initialized the first populated of organisms gets generated and each chromosome randomly selected, there after each generation is bread by crossing the chromosomes from parent populations to create the next generation. Since organisms are created from parents (2 organisms being joined to create a child organism and in doing so mixing the parents chromosomes into the single child organism) the population is refreshed each generation with a set of organisms.

The Rules Of Game

The purpose of the game is to, by using an endless supply of knight chess pieces, try to find a way to fill each block of a chess board. Practically, and in genetic algorithm language, that meant that each organism gets a random starting point as part of the initial population generation. From that point they can decide which block the knight must move to next (moving in the special way that only knights can). The program allows the knights to move until there are no further free blocks to move to as per their chromosome move choices they’ve made.

Example of one of the organisms chess boards

The Organism, Fitness and Generations

Organisms that can place more knights on the board are seen to have within themselves a more optimized answer to the problem and are defined as fitter than others. Once the fitness for each organism is calculated then the fittest organisms breed and produce the next generation. The organisms breed by randomly mixing their chromosomes together.

In this game the chromosome is a set of decision choices about where to move next. For example a chromosome will be a decision choice to firstly move 2 places up and one place to the right after the last taken block.

I represented each potential move as a enumeration and saved that in an organism entity.

Genetic Algorithm Entity Model

After all moves had been played out the fitness was calculated by a simple retrieve on open board blocks linked to the organism. After the organisms are scored then their enumeration chromosomes mixed together to form the next generation organism.

The breeding microflow on a Mendix GA

The Output

The outputs show that after running the algorithm for 6 generations or more than the best solution flattens out at about 76% optimization. To progress to a further optimized solution would probably require the addition of mutated organisms, something I might leave for a time box another day.

The Lessons

I learned a lot in doing a GA with Mendix. Some of the lessons are business related, some of the lessons were things I just picked up during the development of the GA:

1. Mendix promotes a configuration approach

Mendix makes it really easy to add your settings and configuration for running the application in an entity format. Things like setting the number of generations you’d like the program to run for, number of blocks on the chess board and number of organisms per generation are really easy to set. A configuration approach immediately puts a Product Owner/Business in the driving seat allowing them to be responsible for the application solution. When running GA’s you need to tweet with these types of settings to figure out how to optimize things. I found that Mendix naturally lends itself to a configurable approach without having to compile and run each time I wanted to tweak something in the algorithm.

2. The Visual Nature of Microflows

The visual nature of Microflows is an added benefit to creating GA’s with Mendix. The Microflow which calculates where the next knight would move to was visually created as such.

The Microflow to calculate where to move next

For example the Microflow to move the next knight left 2 blocks and up 1 block was called “West Up” and could be found exactly there: on the left hand side and up.

3. Traditional looping is difficult, but visually easy to interpret

Creating loops in Microflows are interesting to get your mind around. It doesn’t feel natural but it is visually really easy to visually interpret. In a code like fashion looping within a Microflow feels heavy but achievable.

4. Getting my hands on the Data was Cha Ching

I’ve created GA’s in Object Orientated languages before. Typically it takes too much time to persist the data generated by the algorithm so debugging and problem solving is normally done via drudging through app created log files or if you do output data to a database you then have to peruse the data via SQL. The Mendix entities persist with no effort at all so I had no problem getting my hands into the data to source problems because it was so easy to do so especially since it was effortless to create custom screens from which point I could both see and change data while tweaking the algorithm during run time. The result was shorter problem solving time periods and in a time boxed scenario saving time is gold!

5. Good fun

It’s great to do a project like this in Mendix. It’s also good to experience practices like working from the entity model hold true even when dealing with traditionally “Computer Science” type lab problems. As always its great to experience how easy it is in Mendix so create a good quality solution in such a short space of time.

The Knight without shining armour or a nice Italian Suite?

Foreword: Mendix isn’t just software. Its a different approach and a different way of thinking. Mendix consultants dress differently, use different tools and think more abstract about problems. This article was originally written for another tech site but was inspired by the “Mendix Philosophy” and deserves a spot here. HG

IT was created to extend human abilities to where we could not reach and to automate boring and repetitive tasks. IT frees humans to do the things they are good at. Like thinking, and adaptation. Humans are built to like change and dislike the repetitive. For this reason, companies spend lots of money to figure out how to keep the masses’ attention and how to sell better, recruit better and capture more. Yet the systems they build are inherently static, cast in IT concrete of data schemas, work flow, form and data validation and the last bright developer’s wonderful framework that promised flexibility. Promised to deliver a configure-once and “get your new change quickly” framework. The knight without shining armour.

Those that have been through this and hurt by this go out and buy the new knight in shining heavy armour that suits 70-90% and hope to teach the new gentleman their dialect and court manners. He just might end up stealing the court’s ladies hearts for a time. However, it soon becomes apparent that he was trained in older tactics which do not deliver the punch his sponsors intended and his adoption of the house’s colours and insignia is shallow to say the least. He needs diplomacy and agility that his rigid strictures do not cater for. Still useful for the heavy hitting punch he can deliver (if his heavy maintenance is paid), he needs the services of the guys in their tailored italian suits to form new alliances and capture the attention of the up-and-coming masses who might join the ranks. Lets meet the new knights who like change and can switch diplomatic ties that win the war without a battle and bring prosperity with a handshake. Before we do however, lets first describe the knight without shining armour.

Current development methodologies are mostly centred around Object Oriented development, which itself builds on Object Oriented Analysis and Design where problems are decomposed into Nouns with related Verbs. The decompositions will then be strung together in different layers to provide a solution to the problem. The knights that wield the OO armour tend to be optimised for delivering the core punch required in the ranks. Their manoeuvrability is low, because the Nouns and Verbs are tightly coupled into layers and have to offer heavy protection to maintain the ranks and flank. Use them as components in the battle to deliver a focussed punch. They are not agile and do not change their method of warfare easily as new tactics are required. They often promise to deliver re-usable weapons that will work beyond the current Fort that needs to be conquered. Sadly, the lead Knight gets bored when the Fort is scaled and the other knights are not interested in maintaining his siege weapons with its flaws. Besides, the next Castle will require a different tool set to win, and the last knights’ light armor does not even shine anymore. The cost of maintenance has become to high and the King and Lords are at odds with the lost flexibility they were promised.

The King needs the new knights that operate at a higher level. They do not need to wear armor and wield heavy weaponry to define themselves but they can don the shining light armor should the need arise. Yet, that is not their first line of defense nor offense. They know how to move on higher planes of abstraction, to listen to the deal makers of the day, and they are trained to seek to understand before they swing the sword. They like to win the war without a battle. And to deliver business value to the Lords and King. They have the ability to steer the armies and listen to the feedback of the intelligence officers and logistics. In short, they have a different mind set that helps the kingdom to prosper and use the current assets to a maximum and to change tactics quickly. Meet the knights in italian suits. Meet the new approach that still leverages the older established weapons and their doctrines but builds on that with a focus to listen, understand and deliver value rather than a crushing blow.

If the older knights represent the established development environments like Java and .NET, and the hard hitting siege weapons represent the ERP systems, the knights in italian suits represent those that wield new technologies AND methods to deliver value. Notably, model driven development technologies are designed to leverage the existing tool chains but to quickly assemble solutions based on their business user’s and client’s requirements. Model Driven Development will continue to deliver new frameworks that allow a new breed of expert to assemble their solutions by focussing more on the solution than the scaffolding. They are trained to listen to business and understand the business value they must deliver.

Model Driven Development frameworks will be sold as a platform as a service, it will be marketed under various names to appeal to the non-technical Lords to deliver them from older inflexible systems while retaining the best elements of the old. Otherwise, the older knights will feel threatened and never allow them to enter. Set a watch on the wall, and look out for them. They might be impostors, or just may deliver the city without a war. It is worth a try.

Try model driven development before the other cities flourish and attract all the trade.

Adapted from a true story of an old knight that donned a new italian suite (or even better: a Dutch suite called Mendix)

Mendix Spring 2012 Release

Today was a lot like when the Apple Online Store is down and the famous yellow “We’ll be Back Soon” sticky gets some web-time. It was a morning of click refresh until at last the site was back up.

After snapping out of the hypnotic effect that the new Mendix website had on us, we managed to log in and notice a huge overhaul of pretty much everything. The Public Facing website’s change is welcome. It looks inspiring and takes the game up a notch. Its not just a pretty face though; there are a lot of substantial changes inside too.

It boasts a unified platform, integrating Sprintr™ and the cloud portal into 1 unified experience. The forum still seems to be a separate entity though, but all the other portal bits and pieces are being fused together. The first thing that caught my eye after I logged in was an IM chat widget in the right bottom corner of the portal and an improvement to the layout. It feels more like an app now and looking for “the old stuff” is feels a bit like finding easter eggs.

Most importantly is the new platform. Mendix 4 has a lot of new offerings which we’ll introduce a bit later today.

Here are some of the highlights in the new release:

• Mobile for the Enterprise
• One Platform for All
• Social Productivity
• Enterprise Integration
• App Mash-up
• Improved Performance
• Non-persisting entities
• Overall enhancements, tweaks and improvements

Click here to view the official release notes.

Spring is in the air (if you live in the northern hemisphere anyway)

This morning I tried to acquire a Mendix license for a project we are working on, when curiously enough the website had this message displayed. I wonder whats in store?

I know I’ll be refreshing my page the whole day, or I’ll just use that monitoring tool I wrote in Mendix to email me when they go live, or see if Mendix emails an announcement before that.

Project Management and the development environment

There is exactly one universal rule about all development environments, that they are all different.

In my previous incarnations I worked in a medium sized development group split into smaller teams per project, often consisiting of one developer and one analyst/tester. Working as the development management team, we investigated what methodologies we could use within the environment. After examinations of project management, agile methodologies, various other literature and the preferred management, team personalities and development styles, we ended on a project orientated, agile method. This was obviously not a formal style and will start many hearts palpatating with the risks and inconsistencies this fr-agile approach takes, but lets not go into the details of this now.

This approach worked with its own hiccups, projects were delivered and of course there was always debate on improving delivery, issues. But what this did lead me to was the world of PMI project management.

From that starting point I then got to experience some more tantalizing environments ranging from very formal waterfall to very formal scrum environments to single man teams and throw numbers at the problem development environments. And slowly my framework, as everyones does, grew.

Now where is this all going? Well, debate within an environment is always good particularly when people are open to it. One thing I have always found when discussing development methodologies though is much fear and loathing of project plans, the dreaded GANTT chart and in turn project management. Furthermore for development teams it brings back often scarring memories of waterfall.

Personally I believe the first plan of any project should be burnt just after it has been saved and only looked at when reminiscing about the past. Although not important to the actual workers involved in a project, it is a valuable tool in visualising the work which is to be performed across a company not just a single development team and in communication with the management and greater business unit.

Now this is where the biggest dangers come in, in many cases an initial single project plan is presented to management and presented as a series of static milestones, often as a static pdf. Which is ofcourse how the management interprets it and this then gets filtered through the entire company and down to the development and other teams to implement with disregard to changes. Now this is where real project management is meant to step in. A project plan, schedule or GANTT chart should be an evolving document as scope, time, cost and risks change, and should never be provided without the details of the variance which can be expected. But importantly it is the project managers responsibility to ensure the management team understands the pan and variances.

Now in the scrum environment it is very important to know where the responsiblities of the project manager fit in with the product owner, scrum master and development team. In many environments the project manager often becomes the scrum master, however, this causes a major conflict of interest as the project manager is on the line to deliver the project and can start manipulating the team based on pressure of the project to deliver rather than faciliate delivery. The project manager as a product owner doesn’t work  as the project manager cares only for the product in the terms of the project. As such any other projects or company requirements will be removed for the sake of the project. This is often no problem in a new product or single project product, but where the product services a larger company audience this will cause conflicts of interest.

This then leads many down the lines of saying a project manager doesn’t belong at all. However, these projects are not oten limited to a single product development but include multiple team coordination, budgetting, preparing a physical operations environment (call centres, marketting, retailing) as well as other legal and reporting requirements. These responsiblities are very different to the product owner as they are of limited time and scope.

With the above concerns I would say that a project manager still belongs in the environment, working very closely with the product manager and only interacting with the development team with the product managers involvement. This allows the product manager to maintain their product and team while the project manager can do their job on the project. Of course this all relies on the close relationship of these two people.

And with that here are some interesting articles for food for thought:

http://www.goodproductmanager.com/2007/09/24/product-management-vs-project-management/

The Value of Hiding Text Copy During your Demo

Mendix is very practical in the way it enables engineers gather requirements, then build and quickly retrieve feedback from stakeholders. Feedback is best performed through two practices:

1.Through an accelerated “build and demo” process.

2. The use of the feedback module available for free from market which enables actual users of the application to create stories directly within the application that get automatically placed on the backlog.

Use Latin in the Build and Demo Process

Normally within enterprise organizations the marketing/legal department is responsible for the copy on the application but this copy isn’t necessary available or signed off for the quick build and demo sessions (especially early on in the project). Often, if the correct copy hasn’t been delivered to the engineering team then, the stakeholder audience can become fixated on the copy instead of the valuable functionality being demonstrated – not so much when it comes to labels but more so when it comes to actual information or application instructions or messages. In these cases it’s often better to simply use Latin or more specifically Lorem ipsum. It will allow stakeholders to focus more on functionality than getting hooked on text within the application.

Are there any practical ways that you get around the incomplete copy during your demonstrations? We’d love to hear more of your thoughts on the topic.

Feeling creative?

So who says engineers can’t be creative? Firstly, its a fallacy that only artists are creative, as the basis of the word creative implies creating things. And we create stuff daily, and we need to be creative at modeling effective and elegant solutions.

But lets stop splitting the proverbial brush-hairs and do something arty. The guys over in Rotterdam are asking for beautifully crafted microflows. Submit yours now!

What if you are too fast?

Picture this. You are in a 120 km/h zone, you’re driving a car more capable than the speed limit and you need to be somewhere, but you are stuck in a traffic jam. This is familiar to most people: A traffic jam. What should be a speedy highway, is now the world’s largest parking-lot. The same thing happens when one has a more capable tool that demands a faster development pace for efficiency, but the current environment is in a dead-lock of inefficiencies and status quo’s.

Mendix Business Engineers have the opportunity of churning out functionality really fast. So fast, some regard it as disruptively fast. The environment cannot adapt quickly enough to change, especially if the organisation has processes built for traditional development teams. People with job-insecurity might perceive this as invasive, they typically do not like change and might even consider the current state of affairs as optimal

The cause of some dead-locks in IT, is dead culture. Tradition determines culture; it is distilled from experience and gathered over time and determines the way we work and the way we predict outcomes.

Here are some telltale symptoms of a bad cultural legacy:

• slowness to react or adapt
• taking little ownership over the domain
• lacking creativity and craftsmanship
• failure to understand business and a dependency on spoon feeding
• too many impediments caused by technological constraints
• an incompatible vocabulary with business
• a “not-invented-here” syndrome
• leaders threatened by new technology not their flavour and that use straw man arguments to keep the status quo
• an attitude that limits Business and often dictates what can and can not be done
• an environment where failure is punished and innovation can not happen.
• an environment with a gang culture where the choice morsels of knowledge of systems are only shared freely with those that comply with the gang’s culture and is liked by the alpha members of the pack

If these indicators match we can expect an environment where we need safety checks and processes that protects team members and dictates to the development team and business, in short and environment with lots of red-tape and ego’s. Processes and formalizations are always necessary, but the tail should not wag the dog. These should be support processes, not impediments. And often we find that in such environments the current “best practices” are not even blogged, documented or publicised and provides and insecure environment for any innovation to happen safely.

Most entrenched coders want job security, and want to be spoon-fed what business requires. They are low-risk – but not in a progressive way. Completer-finishers are crucial to teams but often fall into the low risk, pro status quo group that like security, getting things done – but generally happy to introduce technical debt at business level just to “get the job done”.

Everywhere we go, we see a general pattern emerging: Business is not happy with the pace of development that current IT shops can deliver. We see a similarity emerging with the construction industry where roles are clearly segmented in verticals and specialisation forces people to silo and only look down at their part. For instance, a brick layer only lays bricks and does not have the ability to read and interpret the architect’s plans. They rely on supervisors to take ownership and just do their thing. Plans can never detail everything and clients often feel cheated at the results they get. They feel they pay too much, get too little and that it it delivered late. The answer is typically to get new builders, new plans and better plumbers. And better processes. What we need is more than that. But a better process is a start.

Like Scrum. Implementing a better process is an excellent start. However, few seem to understand that it is a framework that requires customization to fit and optimally serve the environment. It can change the environment as its provides a division of roles with the minimum one should have to be successful in systems development. But we see environments where “the way we do things” are branded Scrum and is not allowed to change when required. The Scrum term gets branded against any disruptive force and Scrum’s rhythm and velocity arguments are used to structure teams in ways that do not make sense – when the goal is to develop great systems that satisfy the business requirements and where rhythm, velocity, measurability etc. should be supportive of this rather than the goal! The tail wags the dog. IT is there to write great systems that allow business to double their business.

Mendix engineering is fundamentally not traditional development. Mendix teams will find that they will have to challenge these processes to gain maximum efficiency and freedom to create business value. One needs to reform what IT means in the eyes of everyone else. This is a gigantic task and may take some time to break the deadlock depending on how agile your company is. It will be a change that will require time and effort and will probably upset people who are comfortable and in cozy jobs. An Oil Tanker takes a long time to change direction, and it is to be expected from other large organizations. Hang in there and work with lots of compassion, openness and communication, however do not comply with bad/non-optimal practices just to keep the peace. We have to put business first.

Mendix, as quick as it is, is not a silver bullet. The processes and approach around Model and Domain driven development needs reformation. Pick your engineers carefully, since they will be your first line of change agents and culture trend-setters, the ones who will share the vision of your business. If you want a comfort delivery zone and do not like change – look somewhere else for a solution as this is not a get-popular-quick scheme but a new and fresh business driven approach to churn out value with lots of changes to support that. It offers a new set of experts and building techniques that allows us to focus on what our clients wants and works best in an environment where ownership and initiative is encouraged rather than playing the blame game that results in dead culture and causes people to hide behind red-tape.