Every large corporation's business and IT leaders would love to be able to point to a unified master data management and metadata resource, a universal business object model, a library of process maps and an authoritative single source of consistent governing policies. Imagine a global, intelligent repository where all definitions are current and resolved, and all policies are clear and transparent. Envision no policy conflicts or business rules contradictions, and no imaginable circumstance is incapable of being resolved. Imagine an active distillation of a corporate entity's structural intellectual capital that could be used to guide, act and mediate. What if any business event could be described in consistent and unequivocal semantic statements that were immediately reusable?
Maybe such a system exists somewhere in a parallel universe, but where most of us work, this is largely a nostalgic aspiration. Yet it is a goal that drives us. We want control, encyclopedic clarity, certainty and an assurance that we can govern business events directly.
As we all know, the single source of business truth remains as elusive as the fountain of youth. We end up compromising, accepting rough equivalents instead of exactitude, and we govern largely by avoiding catastrophic error and regulatory violations. At the heart of this imperfect world is the dilemma of equivocal business semantics, unresolved terms, unclear language and contradictory objectives that have not been harmonized or reconciled.
What the organization means by key terms such as "high value customer" in one line of business or "suspicious activity" in another may and probably will always mean different things. A business expression such as a "virgin room" means nothing to the data processor at the hotel chain, but means "a room purchased in conjunction with an airplane ticket on Virgin Airlines" to a line of business representative. A "national" sale offer of a home theater kit for a national consumer electronic retailer will vary in its constituent components based on relative proximity to specific distribution centers that have more or less on-hand inventory of specific components. The view of the world within an international bank changes dramatically based on whether you are in wholesale, commercial, investment or retail banking. As one IT spokesperson put it, "They [business units] speak as if they are on different planets."
Three successive movements in IT have attempted to deal with the overwhelming reality of IT silos and the absence of a central intelligence core of unequivocal business truth. They are enterprise resource planning, enterprise application integration and, most recently, business process management. Do any of these bring us closer to the unrealized goal of a unified theory of the business universe? Not quite, but if we put the cart before the horse and allow real-time business events to drive a fact-based, federated view of our business - rather than a predefined platonic ideal of our business - they just might. Let's look at how we have dodged the problem in the past.
The Rise of the Relationalists
The convergence of relational database technology with client/server computing based on nonproprietary operating systems (UNIX) in the early 1980s gave new freedom to organizations. Foreign keys and referential integrity allowed thoughtful designers to detect and articulate intricate and guiding relationships in data that defined what the organization did and how it did it. Sexy new application development and user interface tools proliferated. Finally, prepackaged enterprise application suites emerged and thrived based on massive rounds of trial and error that focused on customer needs and practices.
These enterprise applications, or ERP systems, were built on the dramatic deconstruction of flat-file databases that underpinned the computer mainframe world of top-down hierarchical constructs. To the relationalists, the flat-file world was moribund, static and could not keep up with real business user needs and the reality of business change. The ability to draw relationships between different data columns and to present dynamic views of these relationships to business users on powerful and graphically enhanced computer clients was an extraordinary leap. But the more expansive and informed this functionality grew, the more it also tended to reinforce the lines between one silo and the next. Within the application universe, we experienced univocality. Beyond the limits of the application, however, lay disputation, error and difference.
Human relations, sales force automation, marketing automation, customer management, supply chain, risk and compliance management, asset management, finance and accounting, portfolio project management and product lifecycle management all became towers - some short, some tall - of enterprise capability that functioned much like the towers of the medieval town of San Gimignano. At first glance, the town looks romantic, but its history tells otherwise. These towers represented the internal division among the local warring clans. Lookouts and archers were stationed to rain down terror on the piazza below when invaded by another clan. These were silos gone bad.
The Integration Panacea
As local differences were ironed out and clans united, intracity warfare in San Gimignano was replaced with intercity warfare. In a similar sense, EAI emerged in the 1990s to dig tunnels between towers. In retrospect, how enterprise-wide could an application be that needed to be integrated? But EAI benefited from the emergence of the Internet and a new cross-platform standard of Web services protocols. Just as SQL gave a semblance of abstraction to multiple database technologies, so too did simple object access protocols and Web services offer safe passage between the warring towers. Rather than aspire to build vertically, EAI offered extraction, translation and mapping as well as conversion and consolidation. The silos remained intact. The premise of EAI was always to give the enterprise applications their primacy and to act in their service.
As it happens, the tunnels got bigger, wider - and more popular. In fact, some people starting using these connections for other purposes. Smaller enterprise applets, baby towers, began to be built in these tunnels using the Web services and surfacing in portals and other Web interfaces. The integration tunnels became a service bus, and instead of merely translating and mapping data amongst enterprise applications, they now acquired a life of their own. This service-oriented architecture became a breeding ground for new forms of applications that wrapped and extended enterprise applications and composed componentized Web services into entirely new offerings. But does this fluorescence of activity mean that the underlying needs for authoritative master data, a universal policy library or cross-application process maps had been resolved? Hardly. In fact, the need for governance across applications became increasingly critical. Managing a limited selection of enterprise applications was one thing, but ironically, EAI made the problem it set out to solve even worse by ushering in a plethora of unregulated and viral Web service applications that relied on enterprise applications but also compromised them.
It's the Process, Stupid
A third approach emerged in the current decade: business process management. BPM brought the ideas of continuous process improvement from disciplines such as Six Sigma and embedded them in the new Web services tools. The BPM approach examined the gaps that existed between business goals and the systems that were in place to support them - the gaps that existed between monolithic ERP systems. BPM also aligned itself with business rules technology to help organizations develop a semantic fact model of their governing policies.
As promising as the BPM approach was, it, like ERP and EAI, ran into unintended consequences. BPM projects remained departmental and, ironically, created horizontal silos of improved process that did not achieve enterprise adoption or reuse in any way that would inspire an alternative to the hegemony of towering enterprise applications.
Where there are multiple BPM projects, they tend to be in different areas and do not benefit from shared inheritance or re-use or a common view of the shared policies that govern them. As one BPM pioneer put it to me: "We evangelized the idea of a central repository of process and rules, and everyone loved the idea ... and now everyone has one." So, unintentionally, BPM created horizontal agility silos across the legacy systems.
Is it possible to offer the change agents on the ground the autonomy and agility they need to respond to issues in the trenches and at the same time benefit from reuse, global transparency and governance?
Federation: The Collaboration Dividend
A new approach suggests that there might be an answer to this problem. But first, we must take steps to turn the practice of BPM in on itself and ensure viral collaboration among BPM practitioners, while at the same time introducing governance and intelligent reuse.
The horizontal and cross-functional BPM solutions need to first be able to effectively and dynamically expose their fact models to create a new registry of policies and rules - a semantic understanding of the business. They must then allow their executable process flows to be reused orthogonally, allowing peers to reuse an aspect of functionality that might be applicable. This creates a process repository that promotes and rewards collaboration. Because the repository exists, people will come to use it, refer to it, resolve conflicts and finalize metadata mappings there rather than in an offline system. And finally, these new process systems must dynamically share their process data (metrics and historical analysis). Once these things are in place, a meta-BPM can then federate all of the above to reconcile and distill across all areas.
This approach is different. The assumption has always been that a pure and predefined business object model should drive behavior. Theory rules over practice. The theory needs to defend itself and will reject local differences and conflicts as impurities. A federated model can tolerate and accommodate difference. In fact, collaborative difference and exception drive it. In this model, practice informs theory. The local market experts get the agility they need, but all the while they are building up an active repository of reusable elements that bring the best that each group has to offer to the benefit of the others.
BPM takes a process-centric view of the problem. It is directly used by business stakeholders and therefore tested in real-world scenarios. Because these business policies are being tested under live ammunition, they are reality-checked by the people who most depend on them - and have greater legitimacy than the business concept one finds hardwired in the monolithic enterprise application or the data mapping exercise of an EAI database modeler.
Federation is not perfect, but it offers the best opportunity yet to finally bring down the towers of division. In time, federated process registries and repositories will form the backbone for a new generation of agile enterprise applications. In the meantime, however, it brings a collaborative and reality-driven approach to the problem of a unified theory of the business universe.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access