Believe it or not, Salesforce.com is twenty years old. Salesforce was founded in 1999 under the then revolutionary assumption that business applications could be delivered faster, cheaper and more reliably through the cloud. By any measure Salesforce has been a huge success. It went public in 2004, achieved $1B in revenues in 2009 and surpassed the $10B mark last year. But perhaps its biggest accomplishment was to fundamentally change the application architectures enterprises employ to support their daily business operations. Cloud-based software-as-a-service (SaaS) applications play a major, if not dominant, role in the architectures of most major enterprises.
In 2010 Apple trademarked the marketing slogan ‘there’s an app for that’. This tagline was intended to highlight the wide variety of activities that individuals could perform on their iPhones. Nine years later the tagline is equally applicable to business applications. Although monolithic, multipurpose cloud-based applications still exist, they are complemented and frequently cannibalized by a plethora of one-off SaaS apps that address very specific business problems or satisfy the unique needs of individual business teams.
The proliferation of SaaS apps occurs in every company. Few IT groups would claim to have a complete inventory of the SaaS tools that are being employed throughout their corporations. How can IT groups cope with this ever-expanding collection of cloud-based capabilities? When does IT need to control the introduction of new SaaS applications and when should it simply comply with the preferences of its functional customers?
Systems of Record versus Systems of Engagement
Systems of Record refers to applications that contain business information that’s critical for the execution of core business processes such as employee compensation or supply chain management. They’re also used to demonstrate compliance with externally imposed regulations or standards such as SOX or GAAP.
Systems of Engagement are applications that enhance employee productivity or promote sustained business interactions with suppliers, partners and paying customers. Some applications may serve as systems of record and engagement. For example, a system that consumers use to select and download movies may be designed to stimulate demand by tracking the preferences of individual users (engagement) and also be used for customer billing purposes (record).
Enterprises try to avoid the creation or maintenance of multiple systems of record. Duplicative or inconsistent business information inevitably creates confusion and usually spawns a series of manual processes to resolve discrepancies. Consequently, systems of record are usually selected through a formal evaluation and approval process involving both business and IT stakeholders. Business requirements are explicitly defined; vendor capabilities are explicitly evaluated; and trial implementations are typically performed before a final decision is made. Introducing a new system of record is usually a fairly substantial ‘roll of the dice’ for any corporation. The decision is too disruptive, too costly and too impactful to be taken lightly.
On the other hand, systems of engagement can proliferate within a corporation at the whim of individuals or functional teams. Multiple applications may exist for workflow management, file sharing, document co-authoring, project management, recruiting, meeting planning, texting and even email! Engagement applications are frequently adopted without being subjected to any type of formal evaluation or selection process. If they address a clear need or are simply strongly preferred by key individuals, they can be virally implemented in very short periods of time.
The enterprise architecture challenge
Enterprise architecture (EA) teams have historically tried to rationalize and standardize their companies’ application portfolios. They seek to identify applications with overlapping capabilities with the goal of eliminating duplicative capabilities. They also attempt to standardize the use of specific applications across the corporation to improve business process efficiency and enhance employee productivity.
Cost considerations have been the primary weapon that EA teams employ to justify their recommendations. They appeal to the CIO, CFO, COO and even the CEO to standardize on some apps and eliminate others as a means of reducing current expenses and channeling the savings elsewhere, to more critical business priorities.
The cost weapon is becoming increasingly less effective as a rationale for curbing the proliferation of engagement applications. EA teams need to consciously expand the criteria they employ in evaluating the utility of engagement tools and explicitly consider the following factors:
- Cost considerations are still important and need to be understood. Nobody likes paying twice for something they already have!
- Employee productivity trumps cost. Human capital (i.e. labor costs) typically represents the largest single expense within a company’s operating budget. Modest investments in duplicative engagement tools that improve workforce productivity – even marginally – can have a huge ROI.
- Speed of the business trumps employee productivity. Tools that reduce the latency of internal business processes and reduce wait times for procurement decisions, order entry, order fulfillment, customer notifications, etc. can be a source of competitive advantage. Specialized apps with overlapping task management or workflow orchestration capabilities may actually be required to simply maintain operational parity with an industrial opponent.
- Security trumps speed of the business. Security liabilities are the ultimate deterrent to the use of certain engagement tools. No commercial enterprise wants to experience a crisis in customer confidence, expose itself to regulatory fines or suffer a loss in brand reputation as the result of a security breach. Security considerations are the ultimate weapon in limiting or eliminating the use of individual engagement applications.
The new enterprise architecture playbook
EA groups that have historically tried to generate business value by limiting the choices of employee engagement tools need to develop a radically different mindset. Instead of manically focusing on the best tool for a specific activity they need to sanction an ecosystem of engagement tools that can collectively transform the efficiency and effectiveness of internal business operations. Instead of justifying the procurement of individual tools, they should justify the capabilities of the ecosystem they are establishing and measure improvements in productivity and business velocity relative to the expense of that entire ecosystem. They should avoid trying to attribute significant benefits to individual tools simply because no individual tool or limited set of standardized tools can optimally enable the myriad interactions required for a modern corporation to succeed.
The classic rationalization and standardization principles that EA teams have employed in the past will likely remain applicable to the selection of systems of record in 2020 and beyond. However, EA teams that attempt to apply these same principles to systems of engagement do so at their own peril. Their recommendations will likely be ignored and their roles as leaders of technology innovation within the corporation will be marginalized.