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.

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)