Friday, March 15, 2002

 
Posted by Anonymous 12:05 PM
Knowledge is Empowering. I've been discussing competitive intelligence and its relationship to business intelligence in recent entries here and in Notes from the Field. When you strip away the motives, processes and activities it all comes down to knowledge. It makes little sense to engage in competitive intelligence operations, or to use business intelligence as the basis for solutions to give competitive advantage if knowledge isn't effectively managed.

Information and Knowledge. Information by itself is of marginal value. It must be turned into intelligence (see Mike's 28 February 2002 entry for details), and intelligence provides decision makers with the basis for decisions and action.

Managing information is the easy part - it's stored as data in databases and extracted, aggregated and transformed into information using queries, tools such as spreadsheets and more specialized tools. At some point the information that is derived from the data becomes intelligence. Decision support systems and multidimensional databases and other technology are routinely employed to either enable this, or to actually provide raw intelligence.

The hard part, however, is capturing and managing the knowledge that is a byproduct of the data-information-intelligence flow. In too many organizations knowledge, unlike information and intelligence, resides inside heads. The disadvantage is that when the executive or key employee leaves the knowledge locked in their brains leaves too.

One reason for this is implementing effective knowledge management systems is difficult and expensive. This is slowly changing, due in no small part to portal technology.

Realistic Concerns. Technology alone is not the solution. There has to be a strategy for capturing, organizing, disseminating and maintaining the knowledge.

There are hurdles to overcome, one of which is the politics of information sharing. Yes, sharing information empowers and strengthens. Making it happen often requires a sweeping change in corporate culture. Even then, there will be pockets of resistance.

There also has to be a strategy for securing knowledge. For all of the talk about learning organizations, how knowledge empowers and knowledge capital, a lack of controls would result in a disaster.

Need to know, is a time tested rule for managing sensitive information that could cause damage if it falls into the wrong hands. Therefore, in addition to capturing, organizing, disseminating and maintaining knowledge, you need to include compartmentalizing knowledge.

Full Circle. Knowledge has value. The critical issue is how to quantify that value as it relates to your organization, and how can it be leveraged. The driver is simple: business imperatives. The approach is straightforward: investigate, develop a business case, evaluate options and alternatives, decide on a solution that best supports business imperatives with the most attractive ROI.

Make no mistake, the approach to leveraging organizational knowledge may be straightforward, but it is not easy. It also requires commitment at the highest level, both for vision and for funding.

Read Intellectual Capital ROI to gain an understanding of how to determine the value of knowledge, and this article about data waste for additional supporting information for your business case. Outer issues and factors can be derived from Principles of Knowledge Management, which will give you the big picture.

Thursday, March 14, 2002

 
Posted by Mike Tarrani 9:49 PM
TEAM Zarate-Tarrani. You read what we write, but probably don't know much about our backgrounds and professional capabilities. I've just placed TEAM Zarate-Tarrani Capabilities page online that fills in the gaps.

Software Process Improvement. I've added process-related documents and presentations to my latest entry in Notes from the Field, and want to focus on software process improvement in my entry here. To that end I have a collection of documents and presentations that succinctly cover the key issues, as well as tie software engineering processes to the topic (general process design and implementation) that I am addressing in Notes from the Field.

Implementing Software Process Improvement discusses the issues and challenges of an initiative that many organizations have started only to later abandon because it isn't easy. Critical Success Factors for Software Improvement is a document that points out what must be done in order to successfully implement software process improvement, and Software Quality Organization brief gives a brief summary of the organizational considerations that need to be taken into account.

Related. When you're addressing software process improvement you'll have a model or framework in mind. If you're considering the CMMI as the framework, then the presentation titled Unintended Consequences of the CMMI is a document you're certainly want to read. If you're either an ISO 9000 organization considering the CMM, or are weighing the options of whether to go with ISO 9000 or the CMM, you'll find the 75 page CMM-ISO 9000 cross-reference invaluable.

Tuesday, March 12, 2002

 
Posted by Anonymous 10:07 PM
News. My web page is completed and available for viewing. There is still much content to add, but none of the pages are under construction. They are in a state of evolution, and more content will be added in the coming week.

Interests and Documents. Although my background and technical specialties encompass research, competitive intelligence and knowledge management, I also have a professional interest in information warfare. There is a grey line between competitive intelligence and information warfare, and a direct relationship between competitive intelligence and security. In you were to create a Venn diagram using competitive intelligence, knowledge management, information warfare and security domains you would see the relationships among each of these areas.

I have three collections of documents that introduce information warfare, provide related issues and cover basic security, all of which show the connections that you would spot if you drew the Venn diagram:

1. Overview of Information Warfare (what is it, who does it and why).
2. Info War Issues (insights into political and legal issues).
3. Security Issues (various topics, including assessment appraisals, privacy, typical threats and security in a connected world).
My Role. If you've been reading this weblog or its sister, Notes from the Field, you've probably noticed that I'm taking a more active role in developing and publishing content. Mike and I are in the process of developing a new web site that focuses on business and competitive intelligence, which will tie together my entries in the weblogs and broader material about those topics. Until then, you can read up on security and information warfare by going to the Information Technology Security Page that Mike and Linda maintain (this page has a sub page devoted to information warfare), and Robert D. Steele's collection of security and information warfare whitepapers. In addition, you will find well-written and topical entries in Lisa Rein's weblog. Enjoy.

 
Posted by Mike Tarrani 10:51 AM
Briefly Speaking. My time lately has been thinly sliced and shared among a number of competing projects, so this entry is going to be brief. My goal is to share, with little commentary, documents that I've recently come across. Each document is related to, or supports, in some way topics that I've recently discussed here and in Notes from the Field. Without further ado (or much in the way of explanation), here they are:

• Business/IT alignment presentations and documents.
• Business/IT alignment case studies from the building and oil industries, plus an ERP case study.
• Business case development presentations and documents.
• CRM Business Case and Implementation issues.
• Measuring the Value of IT (presentations and documents covering various aspects).
One final document that does not fit within any of the above topics is Project Management Diagnostics, which is an MS Word document containing checklists to help determine project health.

Sunday, March 10, 2002

 
Posted by Mike Tarrani 6:34 PM
Zachman Framework - Part 4. Since my last entry Kate Hartshorn and Linda Zarate have been busy adding background material here and in Notes from the Field. It's now my turn to produce. I'm going to pick up where I left off in my 7 March entry by finishing the topic about business rules, and wrapping up the Zachman Framework.

Business Rules. In my previous entry I gave an overview of business rules, an example and resources for further reading. Among the resources was Barbara von Halle's book, Business Rules Applied: Building Better Systems Using the Business Rules Approach. While I think Ms. von Halle's approach is sound, the business rules body of knowledge is still relatively young. There are many differing, albeit complementary, points of view and approaches, and if you intend to become an advocate you need exposure to these points of view and approaches. One of my favorites is a five-page document titled Business Rules Primer. It's consistent with Ms. von Halle's approach and you can get a working overview without wading through Business Rules Applied: Building Better Systems Using the Business Rules Approach's 546 pages. To be sure, you'll still want to read the book, but exposure to the concepts and basic mechanics before delving into a 546-page tome is an efficient way to get up-to-speed.

The six-page whitepaper titled The Importance of Business Rules in the Organizational Transformation Process touches upon topics related to business processes and, to a degree if you extrapolate, knowledge management. Both of these topics are integral elements of the Zachman Framework, making this paper particularly valuable.

Modeling Processes and Workflows by Business Rules goes even deeper into the importance of business rules as a technique for organizational transformation, and also augments a topic that I'll soon be addressing in Notes from the Field: processes. (Kate Hartshorn and Linda Zarate have already laid the foundation for this topic in their recent entries.)

There is a strong and natural affinity between business rules and data, which is illustrated in the following documents:

• Business Rules and Data
• Entity-Relationships and Business Rules (this presentation is from Chapter 4 in Modern Database Management, 6th edition by Hoffer, Prescott and McFadden)
• Business Rules and Constraints

If you work with PeopleSoft you'll also want to read Enforcing Business Rules with PeopleSoft.

I'm obviously a business rules advocate, and hope that I've piqued your interest as well as provided a good starting point from which to gain a more in-depth understanding of business rules and their value to an enterprise architecture. While I've linked business rules to the Zachman Framework in my series of entries, the two are complementary. Business rules as a technique and approach stand alone as a tool and are effective independent of any framework, methodology or approach you are working with or considering.

Zachman Framework Wrap-up. Between my entries covering the Zachman Framework and Kate Hartshorn's excellent and insightful entries here and in Notes from the Field that cover business intelligence and knowledge management, there is sufficient information with which to evaluate the Zachman Framework as a viable approach to an enterprise architecture. I'm an advocate of the Zachman Framework in the same manner that I am of business rules.

I do want to point out a drawback to the Zachman Framework that you should keep in mind if you do share my opinions about its value: there is a tight coupling among the dependencies in the framework. If you change one cell, it will trigger a cascade effect that ripples across all of the cells. If an enterprise architecture based on the framework is developed be aware that it can spin out of control if the evolution is not carefully managed. Do read Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology by Steven H. Spewak and Steven C. Hill if you are seriously considering the Zachman Framework as the basis for your enterprise architecture.

There are three final documents that I want to share, all of which were written by John Zachman:

1. A Framework for Enterprise Architecture
2. A Framework for Enterprise Architecture: Background, Description and Utility
3. Challenge is Change

These documents, all in MS Word format, succinctly summarize the Zachman Framework, and provide enough information to make a further investigate/not of interest decision with respect to Mr. Zachman's approach to enterprise architecture.

End Note. I am pleased to see Kate Hartshorn's increasingly active contributions here and in Notes from the Field. She has a wealth of knowledge and experience from which we can all benefit. What makes her entries especially valuable is the fact that Kate is not an IT professional. Her insights give those of us who are IT professionals a unique glimpse into the thought processes of a sophisticated business user.

Linda's recent entries have also added value to both of the weblogs and I appreciate how she has augmented my topics, in some cases anticipating me, with background information. She and I enjoy a close working relationship and deep friendship that are symbiotic and enriching.