Found this statement from Matt Calkins, CEO of Appian, interesting: "Instead of packaged software, the future of the market lies in custom applications, with organisations developing their own solutions to solve their own very specific problems."
What do you think?
Yes, I very much agree. You need custom apps, or at least highly customizable packaged apps, to automate work in ways that differentiate you in the market. The trend towards digitalization--where traditionally non-digital businesses discover ways to grow through digital channels and automated processes to support them--is making custom apps hot once again.
I agree. Currently BPM systems are flexible enough to be able to deliver business applications adjusted to customer's specific needs.
Though I'm not sure if "custom application" is the right name for it. In my mind custom apps are something that you have to hardcode, while the idea of BPMS is to be able to use as little code as possible and at the same time maintain flexibility and ability to make quick changes into already developed applications.
I know a real life example, where company uses BPMS (among other things) to open new chain stores. The functionality of this business application includes each and every step of such process, which begins with decision to open, finding a proper place, gathering documentation, hiring staff, etc. It's a quite complex process as you may imagine, but perfectly doable with proper tools.
So I guess, "the future is now".
Count me in! Nothing especially new in that statement, though, except maybe that it was uttered by a senior exec in one of the affected companies.
Per Ken's comment, there are degrees of "custom apps" -- programmatic, configurable via checkbox, etc. Critical for orgs to know what they really need and what they're actually buying lest they set themselves up for a whole lot more work than they expected!
I think it depends on the type of work (let's call it a process) you want to support with it.
If it's a back office thing like 'Paying invoices' (why is this always called accounts payable?) I think there is not much strategic value in that process, so standard software might work well.
But when it comes to your core processes, I think it's always smart to be different than competitors (assuming that customers see value in being different). In that case the software that supports the execution and managing of your core processes might be customized. And if you can build it yourself, why not?
But be aware that using customized software is a means, never a goal. If you can make your customers happy and earn a buck only by using Excel and Google drive, that's fine to me.
At the extremes there's COTS and there's bespoke - but there's many flavours in-between.
While of course large and mid companies will be able to go relatively deep with custom apps, I tend to believe the big growth will come from process development platforms - there's so much white space in SMEs and they will never have enough resources or focus to address their process automation / work organization needs. But the small need is there, for small money. And the way to address that is to pre-package mass-validated process flows, with a tiny bit of customization allowed - this is good enough for SMEs and they will come a dime a dozen.
Why is there so much space? Because large corporations are effectively ignoring this lazy money - their overhead structure does not allow them to chase small deals with a clear sales and deployment model - they are either looking at massive high-touch enterprise and government accounts or at massive consumer markets.
I see things differently from Mr. Calkins. Simply put, unless the company's key value propositions are to deliver software to their customer segments, they should not be developing custom solutions. At least they should start with a "buy" approach and then move to "custom".
The idea, conveyed by one of my prior managers, is to "buy for parity, build for differentiation". Companies like Oracle*, IBM, SFDC, SAP deliver typically deliver *applications" rather than suites of business. I could see these vendors evolving to decompose their applications into these suites over time to aide companies in the composition of a "mostly COTS" solution. There is always a need for some tailoring. But for non-differentiated capabilities, leave well enough alone and focus on your core business.
*This has been my position long before I worked at Oracle, BTW.
Companies are evolving or iterating their business models at such a pace now.... as I discussed in my recent blog Digital transformation is the new, new, thing. True competitive advantage is through agility (ability to transform) delivering superior customer experience (best practice delivered consistently). With all of this change, building custom apps is just too hard and is not quick enough to keep up. There are applications on the market that are comprehensive enough to support businesses, are social and mobile, and are simple to tweak at the edges.
Customers need to focus on staying relevant in changing markets, not distracted by developing custom apps.
Yes for those important applications that are core to the business such as ACM, SCM, CRM, ECM even HRM etc; basically where people are creating information and interacting with others internal and external.
Not only are custom builds direct from users’ business language but readily supporting change even by users! I call these Salient Processes that must have “Adaptive” capability. Buying inflexible COTS even with tailoring is not a future proof investment it is just another potential legacy. The speed and thus cost of build these new Adaptive custom solutions make it a no brainer…! But of course you need to understand how the software actually delivers (without need for coders) and works not just accepting an easy vendor marketing driven outcome sell where “how” is often a mystery belonging to the vendor =new legacy?
But Emiel is right there are what might be called Non Salient activities such as paying invoices, bookkeeping, running the payroll etc that are best off the shelf indeed might even be “outsourced”.
I agree with Eric, the digital revolution is all about creating apps for organisations to innovate or differentiate themselves from the competition, to build uniqueness and build it at pace. Pega Systems has rebranded itself an application company for years, new players like Mendix go one step further and represents itself as the "App platform for the enterprise" The challenge for BPM is to keep pace with the demand for change, it's still too hard to build, test and deploy these "apps", especially when they are custom built to fit "unique" requirements.
First we must ask what’s the future of Enterprise. Monolithic, autocratic manufacturing companies where employees had no say in the technology they use are not part of our future.
Many companies will get larger in reach and in sales volume. But the actual organisation behind them will shrink massively. 80% of corporate head-office employees today are paper-shufflers – just the sort of people BPM was designed to get rid of. It is only our failure to sell this stuff which keeps them in their jobs.
The barriers to entry have been brought down, software being one of them. So we may see an explosion of small and mid size companies competing in high end territory, making niches their own and forming networks to compete where scale is required. Or we may see consolidation as country boundaries break down and the world is carved up into a few global companies in every market. Or both depending on product and market.
So who’s left to use the software? And what do they need - it certainly won’t be ordinary applications like accounting programmes, spreadsheets and CRM.
Secondly where is this software deployed? Once the Internet of Things gets underway, products will track themselves – a mobile phone or chip scanner is likely to be the only interface device needed throughout the supply chain. A product will effectively load itself into inventory at one end and out at the other, with all stages trackable in between. Services will be similarly fluid with sale or use (item sales will become a thing of the past in many industries) automatically triggering all sorts of subroutines to pay freelancers, remove items from inventories and update customer records.
Thirdly whose device is it anyway? The borders of companies are breaking down. Many companies will use a cloud infrastructure shared by their business partners, suppliers and delivery agents. Many will only be collections of freelancers, using their own devices. Half a dozen people working from home in different countries can run a whole enterprise corporation in a distributed manner. And we have yet to see how the retail v manufacture v supplier hierarchy battles pan out – many retailers can now order and organise their own goods and even sell services. So who owns the cloud everyone is plugged into?
Custom applications are a response to two things.
1: The cost of making software stuff has plummeted. A hackathon can create a whole company infrastructure.
2: Requirements have changed so what you need isn’t readily available.
So at the moment it is cheaper to build your own. But the basic principle of write once, sell many still applies. Only more so.
Imagine when you don’t need ERP software because ApplePay comes with everything you need.
When your foreign supplier isn’t prepared to be part of your infrastructure, but suggests you become part of theirs.
Or when your customer collective simply designs their product themselves, integrating your component if it is on their system, using their software and working their way.
Custom applications are a blip, because we haven’t yet embraced the connection economy.
The secret is out. BPM isn't about automating process as much as it's about revolutionizing the way custom applications are built in organizations. Custom applications will be more flexible, maintainable, and cheaper to deploy than they are today, overturning the economics of custom development. As a result of this change, even applications that today are considered commodity, such as invoice processing, will be reexamined to determine if a customized app could provide previously unrealized benefits in efficiency, compliance, or ease of integration.
Sure, enterprises need some kind of “3D printer for software” to deliver innovations via automation of their unique digital challenges.
I think, it should be a platform for quick delivery of process-centric solutions. The speed of adding/modifying automation within the process is the major factor. Various DSLs, interpretive languages, federation of cloud and in-house deployment, explicit security, microservices and process patterns (not workflow patterns) are parts of such a platform.
Welcome to the party Appian. Of course packaged and customisable apps are the the future of enterprise software and bpm. Small businesses don't have the time or deep pockets to deploy heavily customised SW solutions and when you consider SMEs accounted for 99.9 per cent of all private sector businesses in the UK, 59.3 per cent of private sector employment the business opportunity is obvious.
For too long the bpm industry has had a "big project" mindset. The cloud, multi tenant bpm paas and the app market point towards an alternative future for BPM.
E. Scott Menter has mentioned the economics of software development, which can be seen as the axle around which everything else spins.
I have experience in RAD tool and middlware software sales sales, the focus of which is various kinds of custom development. My observation is that the proportion of organizations that can afford to do custom development -- and do it well -- is only a fraction of the total. Even billion dollar companies can often barely afford to maintain any kind of development staff.
Thus the obvious rise of shared-costs COTS packaged software. Packaged ERP -- even if as someone suggested ERP is disaggregated -- is not going away.
And especially if we expect a larger proportion of employment to be in smaller more agile firms, the problem is even worse. Very few organizations can afford or need custom application development. And on top of that, a good application requires serious computer science skills in data modelling, as well as process modeling paired with decision modeling. And try and fund good UX. The quality of much private app dev is poor, and achieves the opposite of what was intended. Instead of "agile", one is "buried in cement-made-out-of-hacked-code-without-a-proper-data-model".
The point is well made about the rise of agile and digitized organizations. Fair enough; but they will not be writing their own GL system, even if they will have their own chart of accounts. They won't be writing core HR systems or ecosystem-networked field service systems -- even if their deployment and management of contingent and mobile workforces will be unique.
If Appian's CEO had said "BPM, along with decision modeling and event engines, is the business customization engine of the future, and the whole kit complements massively shared packaged ecosystem software", then I would have agreed.
I guess Peter Whibley already said this, but in fewer words. : )
It helps to put Matt's statement in context. He's pitching to the press and investors that his company isn't in the BPM space, that it is in the "custom application space" - which is $100B or so (I forget what number he threw out). This is an age-old tactic to say, "see, even if we get this very small percentage of the market, the market is so big, we'll be huge"... but the problem is that it rarely works that way. Better to focus first on a market you CAN win and win it, then raise your sights in a way that is consistent with previous vision/culture.
I disagree that companies can't *afford* to write custom applications - GL, HR, or otherwise. They choose not to fund these applications and the maintenance thereof, they choose not to invest in a software practice within their four walls. But IT personnel spend as a percentage of company spend is pretty small for most firms. And the leverage on successful software implementations is quite large (as seen by BPM initiatives that report ROI #'s). I think we'll see the most successful firms bucking this trend of devaluing IT, and instead see them double down on software to enable their business.
There appear to be questions over the ease and speed of build of custom enterprise level applications. A 6GL that delivers on no code to build custom applications is long over due. Our R&D and working with early adopters of over 20 years discovered the key and it is surprisingly simple because the creation of information using business logic only needs less than 13 work task types plus flexible linking. This includes the custom UI for each specific use which is designed as required with a simple focus on ease of use in presentation and collection of new data.
All tasks are stored in a relational databases (early work was Paradox but now Oracle and future will be any) completely data centric in one environment handling all business requirements. All coding done just configure in graphical interface click and ready to run using declarative. Yes you need a sound data structure (only one in a process) and manipulation of data in the calculation task but all well within skill set of the business analyst. Have clever coders ready to do algorithms etc but the driver is now the business not IT!
It really is that simple yet can handle quite complex processes applications big and small. It has to be the future so now I work on quite how this goes global…quickly?
Wow! I actually choked on my coffee when I read this statement. After deleting the first draft of my response, going for a walk, and having a quick lie down, here’s my best effort at a temperate response to this assertion. Please forgive me if I sound a little snippy, this really is the best I can do…
There is no way that I can explain how someone with Matt’s experience can have said something as utterly nonsensical as this. I can only assume that the statement has somehow been taken wildly out of context, because if someone were to simply make this statement to me, without adding some dramatic qualification, I would question their sobriety, sanity or basic wit.
Let’s start with the term “custom”. This has a meaning that is widely used and understood; custom apps are apps you write yourself. To suggest that people will begin writing custom applications for anything but a very, very, narrow subset of their application requirements is utter, utter, nonsense. This attitude belongs in the 1980’s when, partly through ignorance of the complexity of writing software and partly as a result of the lack of off the shelf software products organizations wrote their own back-office software.
In the 1990’s and early 2000’s packaged software emerged, and towards the end of this period we began to appreciate the absurdity of buying a solution then customizing it beyond recognition (I had an entertaining conversation with a client earlier this year who described how his organization had bought a leading ERP solution and then spent millions customizing it so that it looked and performed exactly like the rotten custom app it had been brought in to replace – while costing considerably more).
We are now, thank goodness, in an era where good packaged software is built in a way that allows customisation to be externalized – And yes, BPM technology is an awesome basis for implementing those external customizations. The future, though, takes that notion of “externalized” customization a step further – in the future we will build applications by orchestrating multiple services that fulfil a particular function or set of functions. Some (ideally a very small number) of those services will be “custom” (ie built in-house) and BPM tech may, or may not, be a solid basis for those services. These services will be orchestrated by BPM technology (although very likely not by the “mainstream” BPM platforms that appear to dominate the market today). This future may even take us as far as the point where we “bring our own apps” to work – Apps that key into the existing services we need, via an interface that suits us.
I certainly do take the point that there will be some things, some processes that really should be “custom” – or at least ”highly customized” but in my experience the proportion of the total set of things that a business has to do that are actually differentiating is extraordinarily low. Typically, as a couple of the other respondents have noted, the most differentiating processes will be those that touch the customer; I’d add “partners” and “employees” to the list, mind you. I classify these processes as “delivery processes” – they’re the processes through which you interact with external entities. These are the processes that tend to be the most differentiating, and consequently they’re the ones that are the most volatile. If I stick a wet finger in the air, I’d hazard that these processes typically account for less than 5% of what any given organization does (of course there are some very notable exceptions, but in part I am exaggerating for effect here). These processes are very good candidates for BPM tech.
There are two more classes of process or business activity – These are “Assembly” processes, the processes that need to happen in order to manufacture the good or service that your organization sells, and “Utility Processes” – these are core processes that are essential for your business to function but which do not differentiate either your product or service or your relationship with your customers/partners/employees.
Assembly processes are often simply a combination of utility services, with a degree of customization – In the future the vast majority of these processes will be fulfilled through the combination and process-based orchestration of a number of prebuilt components or services. Utility processes are things that should simply be outsourced – either via BPO or via some “as-a-service” mechanism.
So, yes, in a very very limited class of process there will always be an argument for either “custom” or (preferably) customized – especially where it comes to delivery processes.
But when a BPM expert asserts that “the future of the market lies in custom applications” my immediate reaction is to urge that person to take their beverage dispenser, pack it back into the box it came in and send it back to, Starbucks, Koolaid Corp or whichever “craft brewery” it came from, because they are plainly drinking too much of something.