Watching the recent debates over what constitutes a business architecture has depressed me a bit. In the 90s it was clear to most of us that organizations needed a high-level description of their business processes. Those processes defined the key outputs of the organization and defined how an organization's operations were ultimately to be measured. The processes that created the value for customers, in turn, defined whether specific activities were valuable or not. If an activity contributed to the success of the top level processes (i.e. value chains) it was valuable. If an activity didn't contribute, then its valuable was questionable. This approach to a business archietcture was straight-forward and very useful in understanding how a company should be organized.
In the past decade its become much less straight-forward as Enterprise Architects have “invaded” the business architecture space and have begun promoting a wide variety of different perspectives. Today's business architecture has become such a confusing topic, that I usually step back and focus on what I term a “business process architecture”.
Don't get me wrong, corporations need a lot of information to be well organized, and many of the things now included in the Business Architecture space are valuable and useful. But, in most cases they aren't what EA's referred to when they spoke of a “Business Architecture” in the 90s. In the 90's, when we spoke of a business archiecture, we referred to the business processes and goals that the IT architecture was to be designed to realize.
I won't proceed with this discussion. Suffice to say that lots of people with lots of different perspectives are now engaged in suggesting the creation of artifacts (e.g. capabilities) that are of dubious value and that have made the whole topic very confusing.
The reason I have been meditating on the current disapointing confusion in the business architecture space, however, is because I fear it is about to get much much worse in the near future.
In the past decade a realitiely small group of practitioners have worked on business rules. To develop business rules, in most cases, you need to develop some kind of “knowledge structure” to ground the terms that you use when you create the business rules. This is a variation on the problem we ran into in the Eighties when we explored the development of expert systems. Complex expert systems used lots of rules, and the rules required the creation of knowledge structures to standardize and manage the terms being used in the rules.
With the waining of expert systems development in the Nineties, many of the people who had been engaged in expert systems development shifted their focus and became engaged in what, today, is popularly called “Knowledge Management” (KM). There are several variations sof KM, but it's mostly focused on capturing the terms, definitions, and rules that people use when they seek to accomplish various tasks. As a generalization, KM isn't ranked very high in the hierarchy of importance in most organizations, and the models KM uses are not very powerful or scalable. This is not to say that KM shouldn't get more respect, or that some KM models aren't very interesting and useful in some organizations, but overall KM hasn't had a great deal of impact.
The key point, however, is that we are entering a new “Cognitive Computing” age — AI, version 3, as some have termed it — in which we are going to see a lot of attention paid to new approaches that depend on knowledge structures and their management. You can't create a natural language system to interact with your customers without standardizing your terms. You can't create business rules for case management process tools without a centeral knoweldge base, and you sure won't be able to create large cogntive processes without some standardization of your organization's vocabulary. In fact, its not too much to say that companies are rapidly approaching a time when they will compete based on their knoweldge structures and their ability to manage them. Good organizations, like good thinkers in the past, will be precise and speak clearly. Poor organizations will be vague and get themselves in all kinds of trouble.
Are most organizations ready to invest in developing good knowledge management systems? Probably not. Does anyone have a very clear idea of what such a knowledge management system might look like? A few do. IBM probably has a pretty good idea of exactly what kind of knowledge base it needs to support Watson when its working for a specific industry — say insurance or healthcare. Beyond today's early cognitive applications, however, we havn't really begun to define our knoweldge capture and management needs. Whatever they turn out to be, you can be reasonably sure they will become a key part of any future business architecture. And given how confused our current business architecture efforts are, most organizations are in for a rocky time when they try to extend their current archiectures to incorporate more sophisticated knowledge structures and knowledge management systems. It's not too early, however, to begin thinking about the problems and how we might address them.