What do you think?
Ken Schwarz is Product Marketing Director for Pega Business Process Management and Dynamic Case Management solutions. He is an expert in enterprise middleware and its application to business transformation and competitive strategy. Ken’s career spans marketing, competitive intelligence, international sales, technical service delivery and product development.
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".
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!
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.
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.
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.
Oracle North America Technology & Government Consulting
IT Strategy & Architecture Services
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”.
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.
+44 (0) 1491 874368
+44 (0) 7590 677232
Scott's opinions only. Logo provided for identification purposes only.
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.
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 "
[i]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[/i]", then I would have agreed.
I guess Peter Whibley already said this, but in fewer words. : )
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.
As for not being able to afford to write software, well yes and no. Software now is much easier to write, with frameworks, and underlying data models much better understood. So writing one's own GL is probably not too difficult -- except there's zero business case for it. Your real value is in the business semantics that really concern your business - in this case your chart of accounts and accounting practices, e.g. around DPO and DSO.
I agree there is a huge payoff for investments in BPM. But I don't see BPM as "writing custom software"; I see BPM as a platform for managing business semantics, especially the business semantics of business process (and business rules).
Working with BP and BR as "first class citizens" of your technology platform is a thousand miles from anything to do with code. It's interesting to see the growth of a new "low-code" movement, I call it the "return of RAD". As you say, a big pay-off. But proportional to the ratio of semantics to code.
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.
Software are not designed specially for particular business needs. Some, small alterations on customers needs can be changed easily. When there is a change in workflow the task becomes difficult. Every company needs immediate services than making things complicated.Then, timely delivery also comes into place.
Customize Apps is very much essential for an software company. Modifying the apps as per customers needs. It must be simple creation of business logic's and also focusing on business plans.
- Page :
However, you are not allowed to reply to this post.