Your company is making the switch from selling products to offering customer-centric services. While facing many challenges due to legacy systems, you are slowly but deliberately updating and simplifying your application landscape. The question is, are you also making the switch from an application-centric approach to a data-centric one?
An application-centric architecture is characterized by a portfolio of application systems with clear ownership and effective governance to drive ongoing innovation. Can you say the same things about data? For example, are there clear owners for customer data or product data? Are you routinely measuring and improving the quality of enterprise-shared data? Are you investing in innovative, cross-functional uses of customer information to enable cross-selling of products, conduct predictive maintenance, or increase customer self-service? Are you prepared to handle the exponential growth of data, including sensor data, images, and video?
Historically, applications were the primary structural element behind the system-of-systems to serve the enterprise. The approach served us well in the 80s when silo business operations had little need for integration. We made it work through the 90s with the advent of middleware to glue all the system together. But, as applications swelled to gargantuan size and the complexity of business operations grew exponentially, major cracks have appeared in this approach. The problem is we focused on the wrong structural element. In the end, it is the data in the application that delivers the business value – not the application itself. Anyone can buy SAP – but no-one else has data showing what your customers purchased from you, the results of your internal product quality tests, or financial data about your performance. It’s the data, and not the applications, that provides competitive advantage.
You need to switch to a data-centric architecture. The first tip: start with an Information Model for the enterprise. Note that I didn’t call it a “data model,” which describes data entities, cardinality, and other characteristics necessary for effective computer processing. The Information Model instead reflects not how data is processed, but how business functions create and use data in the context of day-to-day operations. This is key to Connecting Architecture to Business Strategy.
To develop an Information Model, start by decomposing the enterprise into functions that describe what the organization does. Next, model the interaction of the functions (including external interactions with customers and suppliers) to show service flows or “who is serving whom.” Add to that the information that is created by each function and which functions use the information (many functions may use the same information).
The collection of information subjects, grouped into functional domains, is your enterprise Information Model. It describes how information is created, for what purpose, and who uses it. With this model, you can now assign organizational responsibility for the subject areas and drive requirements for the supporting systems and technology. As I’ve said before, If You Want Business to “Own” the Data, You Need to Build an Architecture for the Business.
Building a data competency is not easy. But adopting an architectural approach to organize the changes into manageable pieces can make the digital transformation of your business a manageable task.