Jim Shepherd at Gartner’s AMR practice has been producing some really good First Thing Monday blogs lately. If you don’t subscribe I recommend that you do. It’s free. Both Jim and Dennis Gaughan have been writing about the segmentation of enterprise applications into ‘systems of record’, ‘systems of differentiation’, and ‘systems of innovation’. The piece published on March 07, 2011 is about the perennial debate around the relative importance of process, people, and technology. In other words do you make the software replicate the processes or do you make the processes fit the technology, and the choice will have a big impact on the amount of change management required. Of course this fits in nicely with the concepts of ‘systems of record’, ‘systems of differentiation’, and ‘systems of innovation’. But most people find it difficult to segment their applications in this manner and tend to apply the same requirements across all enterprise application. For example, some years ago I was leading a team selling into one of the big German auto manufacturers and had a meeting with the CIO in which he told us that he wanted a totally unique solution that had been implemented many times before. Huh? If that isn’t enough of a conundrum, remember that there are only truly about eight auto OEM’s in the world once you look at cross ownership and independent buying decisions, so how many times can a certain technology or process capability be deployed? I was so stunned by the remark that it took me about a minute to respond. But I have never heard the conflict between the requirements of a ‘system of record’ (reliability, scalability, compliance, …) and a ‘system of innovation’ (flexibility, configurability, speed, …) expressed as succinctly before or since. Of course this is the usual tradeoff ratio between benefits and risks. But we were selling a ‘system of innovation’ and the CIO, was evaluating us based on characteristics best suited for a ‘system of record’. It was a tough sales cycle. Luckily the buyer was the business and ‘system of innovation’ requirements prevailed over ‘system of record’ requirements. The point that Dennis Gaughan made in the original blog on June 28, 2010 is that categorizing applications in this manner forces a reevaluation of how system should be assessed, and I would argue vendors too. Key issues that Dennis brings out (with my interpretations interspersed) are that:
- Vendor selection criteria vary significantly and should be consistent with the objectives of the type of system purchased.
- Integration, data, and security strategy must reflect different goals with ‘systems of innovation’ being most ‘loosely coupled’ to the ‘systems of record’.
- Business cases are different because the goals and criteria are different for each category.
- Ownership and funding models differ at each level.
- Overall governance strategy changes to support a more distributed model.
- Application life cycle management differs by category.
I would argue that for ‘systems of record’, where the emphasis is on what Tim Payne of Gartner calls ‘process automation’, largely because most of the processes are standardized or commoditized, the focus should be on fitting the process to the technology, assuming of course that the technology encapsulates ‘best practice’. Customization should be kept to a minimum because, as we have all learned, upgrading highly customized ‘systems of record’ is a nightmare few would wish to live through more than once. The required efficiency of the process should be reflected in the efficiency of operation of the application. As you move into ‘systems of differentiation’ and even more so into ‘systems of innovation’ the emphasis should be much more around fitting the software to the process. But I want to emphasize that often it is the manner in which the application allows you to perform a process in a different manner that is in fact the innovation. This is where the real rub between people, process, and technology comes into play. Would you really think of sending a supplier a piece of paper through regular mail that contains your forecast for the next week? Of course this is a fairly simplistic example, but it illustrates the point. Today. As little as 20 years ago this decision would not have been so obvious. Because a lot of differentiation and innovation is about being more effective, ‘systems of record’, which are focused on efficiency rather that effectiveness, are not suitable for either differentiation or innovation. But even then, the ‘systems of differentiation’ should be configurable rather than customizable. I distinguish between the two loosely as configurations can be migrated easily to new versions whereas customizations require a reimplementation during an upgrade to a new version. In fact this should be a key criterion for the selection of ‘systems of differentiation’, while, largely because of their shorter life cycles, ‘systems of innovation’ can allow greater levels of customization. So what do you think? Is this just more analysts gumph, or is there something to be learned from the segmentation into ‘systems of record’, ‘systems of differentiation’, and ‘systems of innovation’ proposed by Gartner?
You might want to check out.
Do you think anything has changed in the systems landscape since Meta Group used these terms? I mean with the advent of 'cloud', SaaS, PaaS, and social networking technology since the early 2000's has our understanding of enterprise systems architecture changed at all?
My view is that the likes of salesforce's force.com and Microsoft Azure are changing the debate. I also think that the 'Millenials' entering the workforce will put a lot of pressure on 'command & control' IT policies and technologies. The 'Millenials' will just bypass these.
That doesn't mean that the concepts of 'run the business', 'grow the business' and 'transform the business' are outdated. In fact I prefer these terms because they focus on the business rather than the systems, as do the terms used by Gartner. But as I have written many times, systems architectures can be transformative, so I am interested in the point of intersection between the processes and the supporting technology, and hence my questions about how more recent systems architecture concepts may have changed your ideas since the early 2000's.
Leave a Reply