Technology has produced many wonderful and useful things and has changed the way we work and play. It has also produced a good many solutions for problems that nobody thinks are important. Or, the technology based solution to the problem has a greater cost than the value that would be realized from the solution.
Business Architecture is a recent development that looks to combine principles of business strategy and operations with the methods of enterprise architecture, particularly architectural modeling. The motivating factors for this endeavor are: (1) to bridge the conceptual gap between business studies and enterprise architecture and (2) to introduce the rigor and repeatability of architecture to the exposition of business principles and practices. Figure 1 shows the components of a Business Architecture and the capabilities of the Business Information Architecture component.
 |
IT architectural modeling is done with node/arc diagrams and formula languages. Business studies are communicated in prose and charts. A business analyst, when asked to create an architecture diagram, will typically respond (correctly) that it would take much less time just to write a report. If both of these representations contain the same information, where is the extra value from the architecture diagram that compensates for the extra work?
The answer to this question is found with the consumers of the information. Natural language is imprecise, ambiguous, and subject to interpretation by the recipient, who may fail to understand or misunderstand. Scientists get around this problem by creating languages that look natural, but use terms in a precise and unambiguous way. Plausibly, this approach could facilitate communication of business knowledge.
Like scientists, business people are assisted by IT, and must communicate their requirements to other people with technology skills. It is much less likely that business people and IT people will have a common set of concepts and terms. If both groups had a shared dictionary of relevant business and IT concepts and terms, this could make communication much more effective.
The World Wide Web in its role as a medium for exchange of information has similar issues, and communities of practice had begun to create shared knowledge bases (e.g. Wikipedia). Observation of this phenomenon led Berners-Lee and others to try to create a standard way to precisely represent knowledge using XML. The resulting W3C standards are called RDFS and OWL – for a more detailed description of these, see [1]. These standards have decades of research and experience in logic, linguistics, artificial intelligence and informatics/information science behind them.
It is not yet completely demonstrated that such knowledge representations provide value in excess of the labor required to create them, but there are very positive indications. ACORD is an association in the insurance industry that has successfully promoted a standard for interchange of claims information that critically depends on a shared dictionary of terms (see [2]). A number of biomedical research groups have adopted OWL as a shared dictionary of terms and concepts (see [3]). SBVR is an alternative knowledge representation standard from the OMG working group focused on business standards (see [4] for more information).
Figure 2 shows a simple example of how an English prose utterance would be represented in a Business Information Model. The visual representation is an aid to understanding; the actual model would be represented in OWL or SBVR.
 |
Do you know what APR and APY are? Are you sure you know how to calculate them? These terms will appear in product requirements documents from banking business analysts to software architects. These are common terms, and it is likely that a banking software architect will know how to interpret them and create the proper software design, but a software architect new to banking might not have this knowledge. How about “escheat”, “midgets” or “notional principal”? How about local terms that are used within a particular line of business in a financial enterprise and may not be understood correctly by business people in a different line of business within the same enterprise?
The term “offset mortgage” refers to a banking product that combines deposit and mortgage products (see [5]). No interest is paid on the deposit accounts, but the mortgage interest is computed on the mortgage principal less the combined balances of the deposit accounts, resulting in a net tax savings in jurisdictions where home mortgage interest is not deductible. The value to the consumer is clear, but creating such a product is complex for a bank. Deposits and loans are separate lines of business in a bank, and since the mortgage LoB loses revenue from the offset mortgage, it has little incentive to participate. When banks in the UK first considered such products, our banking colleagues tell us that many hours of executive and analyst time were spent educating one another and haggling over allocation of revenue on these products. The resulting agreements are not well documented, and occasionally mistakes show up on customer statements that must be manually corrected. Customer goodwill is diminished when this happens.
Business strategists like Michael Porter have observed:
“Exploiting linkages usually requires information or information flows that allow optimization or coordination to take place. Thus, information systems are often vital to obtaining competitive advantages from linkages. Recent developments in information systems technology are creating new linkages and increasing the ability to achieve old ones. “ [6]
However, industry executives and analysts have noted the difficulty of locating information that would inform a business decision, data warehouses notwithstanding. Kaplan and Norton report:
“The first set of opportunities for performance improvement occurs immediately after the design of a Balanced Scorecard. We invariably discover that data are not available for at least 20% of the measures on the scorecard.” [7]
The authors did not mention the difficulty of finding data that is available and insuring that it is valid, consistent, and matches the requirements of the measure, but this is known to be a significant problem. Clearly, there is a substantial business need for a knowledge base that defines the terms of measurement and links them to data where it is available, noting where data needs to be created or recorded and how that data might be obtained.
Business Information Architecture seeks to create knowledge bases about the entities and functions of a business. These knowledge bases are intended for use by people who need specific information, but they are also intended for use by software applications to assist in business and IT analysis tasks, and eventually to help govern and automate the business. It is not necessary to create a complete business information architecture in order to realize value; rather, business information architectures are created to support particular business initiatives, then later extended and merged. Likewise, it is not necessary to capture the complete and unambiguous meaning of a term in a business knowledge base; often just the essential definitions and relationships to other terms will suffice.
We expect that technologies such as OWL and SBVR will be very helpful in creating business knowledge bases as an element of the Business Information Architecture. Currently, these technologies are experimental and should be used alongside proven methodologies on high profile transformation projects, or on lower profile projects. The technologies are fundamentally compatible with other business architecture standards such as BPMN, W3C/RIF and OMG/PRR, but do not expect to find tools or translators to convert from one standard to another.
There is a lively dialog on knowledge bases/ontology and their application to business (see [8,9] for example). I encourage you to get involved and help develop this new discipline.
In future articles, I will show some examples of business knowledge bases and how they be used to transform and govern businesses and link business requirements to IT assets.
[1] Terry Halpin, "Ontological Modeling (Part 1)," Business Rules Journal, Vol. 10, No. 9 (Sep. 2009), URL: http://www.BRCommunity.com/a2009/b496.html [2] http://www.acord.org/Standards/industrychallenges.aspx[3] http://protege.stanford.edu/plugins/owl/ontologies.html[4] Donald Chapin, "SBVR: What is now Possible and Why?" Business Rules Journal, Vol. 9, No. 3 (Mar. 2008), URL: http://www.BRCommunity.com/a2008/b407.html [5] http://investopedia.com/terms/o/offset_mortgage.asp[6] Michael E. Porter, Competitive Advantage, Simon and Schuster, Ebook ID CBUSCESSI026830K, 7/3/2009. Chapter 2; Section: The Value Chain; Subsection: Linkages within the Value Chain.[7] Robert S. Kaplan and David P. Norton, The Balanced Scorecard: Translating strategy into action. Harvard Business School Press, 1996. P. 231.[8] Paul Haley, “Rules are not enough. Knowledge is core to reuse.” Blog posting at http://haleyai.com/wordpress/2008/02/22/rules-are-not-enough-knowledge-is-core-to-reuse/[9] OMG Business Architecture Working Group
There are no products in your shopping cart.
| 0 Items |
Membership at BAInstitute.org includes access to our other communities.
