I was amused this week to be contacted by Researchgate, a syndication platform that have somehow republished my paper Enterprise resource planning: Componentizing the enterprise application packages that was originally published in April 2000 by the ACM. [ref 1] It was entertaining reading something I authored over 15 years ago, but quite refreshing that much of the thinking makes sense today. The gist of the paper was to discuss how some of the package vendors had responded to the impending Y2K event by componentizing and service enabling their packages, many of which at that time were exemplars of the worst monolithic application architecture (sic). At that time I observed that the componentization was a key factor in the huge growth of the EAI (enterprise application integration) market, and provided a genuine alternative to the conventional “buy or build” choice by enabling “buy, build or reuse”.
And this is really where my thinking has evolved considerably. Fifteen years ago we were very focused on transactional systems with a much lower requirement for flexibility. Today, and indeed for the past decade, I advise a radically different approach which is much more strongly business focused.
All too often the big question that bubbles to the surface is “should we buy or build?” And not surprisingly the buy option is often seen as an easier option because current systems are viewed as problematic and the organization has little or no competence in large scale systems development. In fact, for many organizations that have outsourced IT, development is not seen as a core business capability. So the question of buy or build becomes focused on whether a suitable package exists at an affordable price, where suitable means “supports our processes and information needs as we understand them today”. And package vendors are well equipped to demonstrate how they have readymade and low risk capabilities that have high levels of configurability.
These days I advise a focus on just two important questions:
1. What are the systems requirements of our future business?
Many enterprises recognize their business models are changing rapidly and that there are numerous triggers, including technology, regulation, demographics, climate change, economics and more, that only indicate much more volatility. Most enterprises operate established sector specific models that have many conceptual elements that are shared with competitors, with clear areas of differentiation. Geoffrey Moore [ref 2] gave us excellent vocabulary to describe the Core and Context areas of our business, in which Core business capabilities should be highly differentiating and Context capabilities are managed to be equivalent to the competition, but no better. So the primary question to attempt to answer is, how might the balance between Core and Context shift over the coming years? If the shift is likely to be towards the Context, where competitive equality is a high probability outcome, then a buy solution “may” be appropriate if there is a package that really fits with the business model. This could well be true of highly regulated industries, semi-state organizations etc. However all the signs are that in the general commercial market there is likely to be a frenzy of innovation of core capabilities. That a high level of unpredictability inherent in some of the major triggers would indicate the most appropriate strategy will prioritize maximum flexibility and response to change. And that leads on to the second important question.
2. What are the cultural requirements of the future business?
Everyone will recognize the extraordinary innovation culture demonstrated by organizations such as Amazon, Google and the vast numbers of start-ups leveraging technology opportunities. And this cultural paradigm shift is not restricted to so called Internet companies. Many large, conventional businesses recognize the existential threat and have responded, integrating bricks and mortar operations and processes with Internet portals, apps, IoT and B2B architectures. Crucially evolving their products and services in which information is an integral component. And most of these innovating companies are exploring Agile development practices demonstrating the extraordinary innovation, productivity and quality that can be achieved by a convergence of business and IT skills and expertise. Some of these organizations have reinvented their business models because they have been brave enough to change from command and control to delegated responsibility development models. They are demonstrating tomorrow’s enterprise is an information enterprise where conventional demarcation lines between IT and business need to be challenged and reengineered. Do packaged solutions have a place in such a high innovation culture? Of course – for the obviously Context areas of the business such as general ledger and receivables they make sense. But for Core business capabilities, a packaged solution must look like the dead hand of a commodity.
You may ask, “but back in April 2000 you expected a flourishing integration market, based on buy, build and reuse, why is that not applicable today?” And my answer is, “That actually happened in the noughties. But today we have a different challenge. Burdening creative people with huge integration and semantic transformation complexity is not a great way to reinvent the future business, as the past will be an anchor holding you back. Integration will be necessary and essential, but your core business architecture should be optimized as much as possible”
In a
recent blog post I said, “modernization is not about achieving a new plateau of capability and functionality. Rather it is about enabling continuous, short cycle time response to change”. It’s about creating an Agile Enterprise.
CODA: Geoffrey Moore’s concept of Core relates to the centrality and mission critical nature of a capability. This should not be confused with the CBDI-SAE concept of Core Business Service, which is the service layer managing the state of the business.
References:
1. Componentizing the enterprise application packages , David Sprott. ACM April 2000
ACM (subscription or pay as you go)
