Saturday, March 30, 2002

 
Posted by Anonymous 11:53 AM
Life imitating ... life. Mike's recent entries here and in Notes from the Field have been heavily focused on contract law. I cannot resist using the following quote as a lead-in:

A learned County Court judge in a book of memoirs recently said that the overwhelming amount of his time on the bench was taken up 'with people who are persuaded by persons whom they do not know to enter into contracts that they do not understand to purchase goods that they do not want with money that they have not got.'

Credit goes to Lord Greene, about whom I know nothing except the above is attributed to him. What Lord Green says, however, goes to the essence of contracts in general and aptly sums up software development contracts.

Opportunities Abound. What I most like about writing here and in Notes from the Field is the frequent opportunity to meld my knowledge and skills with what Mike and Linda discuss. Such an opportunity presents itself today. As a competitive intelligence specialist one of the knowledge areas that is important to my profession is law. The practice of law is left to the attorneys; however, understanding the fundamental issues is necessary when one is gathering raw intelligence and transforming it into processed intelligence and knowledge. The scope of understanding includes principles and processes.

A Matter of Principle. Intellectual property is a core area for intelligence gathering and analysis, which makes Basic Principles of Patent Law a key knowledge area. Patent and contract law have radically changed since the web's growth in popularity and the business focus on e-commerce. I've put together a Zip archive of documents and presentations about E-contracts as a basic primer on a wide-ranging subject. The field is ever changing, so do not base any decisions on knowledge or sources other than from an attorney who specializes in this practice of law. You can, however, gain sufficient understanding of the issues through selected reading. One book I recommend is CyberRegs: A Business Guide to Web Property, Privacy, and Patents by Bill Zoellick. I reviewed this book on Amazon on 8 November 2001 and Mike reviewed it on 25 September 2001. It's interesting to read our two completely different perspectives, both of which are valid, of the book.

An interesting paper that integrates contract and knowledge management factors is titled An Incomplete Contracts Theory of Information, Technology and Organization, which discusses information as an asset (which it certainly is) and contested ownership of the information. This paper cuts across a number of disciplines, including law, knowledge management, and human resources.

Processes. Mike has gathered a wealth of documents and links about contracting and/or outsourcing software development. If you want to see what happens when things go wrong (and they often do in our litigious society), read The Anatomy of a Software Lawsuit. Since litigation occurs despite the best efforts and intentions of all parties it will behoove you to gain an understanding of the underlying process.

 
Posted by Mike Tarrani 11:14 AM
New Thread? Not! The material on software development RFPs and contracts was in response to a friend's questions. The topic has taken on a life of its own. On the plus side we've all pitched in and provided information to someone who needed it, and that's what TEAM Zarate-Tarrani is all about, and why we started these weblogs in the first place. An added bonus is this material complements layers in the Tarrani-Zarate model, which I've been writing about. On the minus side, however, is I'm behind on the series about the Tarrani-Zarate Model. I'll err on the side of sharing information every time, so I'm going to wrap up the software development and contract topic and leave it to Kate and Linda to fill in any gaps.

Putting a Fine Point on it All. The final documents and resources I'm going to share are:

• An article titled Fixed Price IS Development Contracts (online), which discusses some of the basic and finer points of this contract model.
• Internal vs. External Software Maintenance: An Empirical Study of Transaction Cost Economics Propositions (online), which supports the decision of whether to outsource maintenance vs. performing this function in-house. As an aside, maintenance is a common goal for development contracts, and even if your goal is to contract out for the development of a new application, the issue of maintenance needs to be addressed.
• A series of online articles that cover the full spectrum of software development contract issues (be aware that these articles are based on UK law):
  1. Software Development Agreements
  2. Maintenance & Support Agreements
  3. Escrow
  4. Outsourcing
  5. Licenses
• A collection of MS Word and PowerPoint documents on Software Development Contracts
• A dissertation in MS Word format on Outsourcing Software Development
• Whitepaper in PDF format titled Vendor Screening in IT Contracts
• Whitepaper in PDF format titled Estimating Software Contracts, which addresses a critical aspect of development contracts from both the vendor and buyer perspectives - PDF format
• GSA Guide to Acquiring Software Development Services in PDF format (the US Government's General Services Administration is probably one of the best sources for mature acquisition and contracting practices, as is shown in this document

I'm ending this entry with one final document that is an example of a decision support tool for in-house vs. outsourcing development. It employs standard risk adjustment factors based on PERT (program evaluation and review technique), and uses one standard deviation to the normalized result to increase the safety factor to 84% probability (versus the 50% probability that the PERT formula yields). This is an example from a real life document.

Friday, March 29, 2002

 
Posted by Anonymous 8:02 AM
Saving the Best for Later. I've accumulated a large number of presentations, links and documents about knowledge management and competitive intelligence during the past two days. I'm in the process of sorting and classifying them, and will be posting them here and in Notes from the Field later today.

There are two resources that I do want to share in this entry:

1. CIO Magazine's collection of articles about knowledge measurement.
2. An article titled Is Somebody Dulling Your Competitive Edge?

I'm also reading Working Knowledge: How Organizations Manage What They Know, and will be sharing my thoughts and impressions about this wonderful book later this weekend. Stay tuned.

Wednesday, March 27, 2002

 
Posted by Mike Tarrani 5:22 AM
Software RFPs. A friend recently asked if I had an example RFP for software development. The short answer was I had a few, but like all RFPs they were poor examples. I've been on both sides of the RFP process: I've written them and managed the vendor evaluation and selection process, and I've responded to them with proposals. Rare is the RFP that does the either party justice (rarer still are proposals that completely respond to RFPs, but that issue is for another time).

If you want it done right, do it yourself, so I'm going to take this opportunity to develop an RFP template and share it with all who needs one.

The Goal. The goal of the RFP is to clearly communicate what it is that you're seeking, and to give potential bidders enough information with which to propose a solution that is matched to your needs. An RFP epitomizes capitalism at its finest because you want something someone else has, and they want your money in exchange for it.

An RFP also is an exercise in risk management because you don't want to pay more than necessary to to get what you want. In the seller's case, value is at risk. The sellers who will be responding with proposals will be competing for your money, and risk bidding too high and losing your business or bidding too low and leaving money on the table (or losing money).

There are other, more subtle risks inherent in the process that go to the stability and track record of the seller, the quality of their work, their ability to warrant their work and make good on the warranty, and ownership of the product after it has been developed and delivered. All of these will be addressed in the discussion below.

Elements of the RFP. Here are the minimum elements of a software development RFP and why they are necessary:

1. Statement of Objectives - describe what you are seeking in general terms. Example: Company is seeking the development of a software application to sort widgets.


2. Background - give the background in a paragraph or two that sets the context of your objective(s). Example: A workflow study concluded that our manufacturing facility can reduce cycle time by 30% and improve quality by 50% if newly manufactured widgets are sorted by size and color before they are sent to QA. The software application we are seeking is an initiative sponsored by our VP of Manufacturing to implement a system that results in the improvements cited in the workflow study.
3. Environment - Describe the technical environment that will determine how the respondents to the RFP approach crafting a proposed solution. Example: The system operates on a 24x7 basis, supporting geographically dispersed manufacturing locations across three time zones with two 10-hour shifts in each time zone. We use IBM AS/400 midrange systems that are located in our West Coast data center. The applications to which our widget counting solution must interface are written in RPG/400. We use IBM Client Access/400 and Rumba 5250 terminal emulation from Windows 98 and Windows 2000 PCs. Access to the midrange systems are via point-to-point circuits from each remote facility. Each circuit is sized to allow each remote user 56 kbps of bandwidth, and all terminate into a 100 mpbs switched Ethernet environment in our central data center.
4. Policies, Standards and Methods - List all mandatory policies and standards with which vendors are expected to comply, and methods that you employ to which they will need to align. Example:
   • [Company] has policies in place for change control and release management (copies to be provided under non-disclosure to bidders that make our short list) with which the success bidder must comply.
   • We use Rational ClearCase software configuration management software and will make one licensed seat available to the success bidder to be used during the life of the contract.
   • The system into which the application we are requesting will be integrated has the following service level objectives [list them]. These service level objectives cannot be degraded by any proposed solution.
   • We are in the process of standardizing on Windows 2000 with plans to migrate to Windows XP in 9 months. Any proposed solution must work with our existing and planned standards, and not conflict with the standard software suites and configurations for [Company] desktop PCs that are provided in Attachment A.
5. Statement of Work - Completely describe what you want in unambiguous language. Make sure that the following are covered:
   • Requirements and specifications. Express requirements as business rules for the best results. Example: The application will:
     1. Sort all widgets in two passes: (1) by size and (2) by color.
     2. Group all widgets of the same size and color
     3. Create a routing slip that provides a count of each group and route widgets as follows: Size less than 1" and Color = any to QA station #1, Size greater than or equal to 1" and less than 2" and Color = any to QA Station #2, Size greater than or equal to 3" and Color = any to QA Station #3.
     4. If any Group has only one widget create an exception report that documents the operator (from the WIDGET_OP table), date and time (from the RUN_DATE table) and the size and color (from the widget_size and widget_color columns in the WIDGET_BATCH table). The PK/FK will be the run_number attribute in all of the above tables.
   • Provide all specifications. Example: The application will use Client Access/400 data queues as the means of inputting data into the system. The application will use standard SQL queries to extract any necessary information from the system.

List service level management requirements: Example: Any problems with the application that are not detected in acceptance testing must be resolved in accordance with our standards for problem management. Definitions for severity and priority levels are provided in Attachment B.

Terms and Conditions. Although your organization probably has a standard format, make sure the following are considered:

• who owns the source code - if the vendor, will the source code be placed in escrow so you have access if the vendor goes out of business?
• specify expectations for corrective action for defects discovered after the software has been accepted
• specify in clear language acceptance criteria before payment will be made; if you you're using progress payments, what are the quality gates for each progress stage

Also be aware that acceptance testing is your responsibility and the criteria for acceptance needs to be clearly stated in the RFP.

Monday, March 25, 2002

 
Posted by Anonymous 8:04 PM
Connections. One of the joys is to be able to augment or complement Mike's or Linda's entries. Both have left me an opportunity to connect material from my technical specialties to entries that reflect their specialities. Today is a day of joy.

The whitepaper titled Value-Based Requirements for eCommerce Applications connects Mike's recent entries on both business requirements and service level objectives to competitive intelligence. This document supports Mike's assertions in his recent entries, and it is a blueprint for reverse engineering competitor requirements for CI specialists.

Managing Innovation Risks is clearly a document of interest to the competitive intelligence specialist, and if you stretch your imagination, it also lightly brushes against Linda's recent discussion of business continuity planning (yes - it is a stretch). A more direct correlation between Mike's business requirements and business imperatives discussions and competitive intelligence is found in A Scorecard to Assess Enterprise Innovation Capabilities.

 
Posted by Mike Tarrani 3:15 AM
Tarrani-Zarate Model: Service Level Objectives. In my last entry about the Tarrani-Zarate Model I wrapped up the discussion on business requirements. The next layer in the model is service level objectives (see the illustration). Because we've extensively addressed service level management in previous entries I am going to keep this discussion short and focused.

Short. Instead of wading through the previous entries, download and read the whitepaper titled Successful Deployment of IT Service Management in the Distributed Enterprise. It succinctly and comprehensively discusses all of the key elements of service level management, and places service level objectives in their proper context.

Focused. Service level objectives are goals that are defined as the level of service to be delivered to the business. Examples include:

• When the system will be available (principal period of operations)
• What percentage of the time it will be guaranteed to be available during the principal period of operations (this gives room for unplanned maintenance).
• How long will it take to respond to a reported incident.
• How long it will take to resolve a reported incident.
• How long it will take for a module to load or new screen to appear (key transaction performance)

As you can see these are measurable objectives.

Characteristics of service level objectives:

• Each service level objective must be traceable to a business requirement. If it does not meet this test then the business value of meeting it is questionable.
• They are defined by the business process owners. IT does not define them - a service level objective states a goal that the business defines.
• Service level objectives are used by IT as the specification for service to be delivered. Any gap between what the business requires and what IT can deliver is negotiated when the service level objectives are used as the basis for the service level agreement between the business and IT for the level of service to be delivered.
• Requirements and specifications for applications delivery for systems, applications and services are defined in part by service level objectives.

It's clear from the foregoing that any service level management initiative starts with eliciting business requirements. It's also clear that service level management is directly traceable to business requirements, which are driven by business imperatives, and the smallest unit in service level management is the service level objective.

There you have it: short and focused. That's not to say that it's easy - it's anything but. However, if you attempt to develop, implement and manage service level management processes without taking into account the definition of service level objectives, how they relate to business requirements, and their characteristics I'll predict failure.

In case I was too terse, or you want more information about service level objectives, I'll offer the following:

• Service Level Management Factors, which is a short paper I wrote in 1996. It's embarrassingly out of date and was hurriedly thrown together, but I'll trust you to take those into account as you glean useful information from it.
• Service Support Assessment, which is an assessment checklist in MS Word format. It has some excellent questions and forces you to examine the big picture. Tailor it to suit your own needs and save it because it's a valuable artifact for service level management practitioners.
• Commitment to Service: The Role of Service Level Management - an online paper that touches the key issues.

In the next discussion I'll continue up the vertical path of the model by discussing processes and organization.

Sunday, March 24, 2002

 
Posted by Mike Tarrani 4:57 PM
I just finished reading Doug Kaye's second issue of his IT Strategy Letter and am overwhelmed by the depth of analysis and array of topics covered. Doug is well-connected in the industry and is an insighful observer. Add the fact that he is an articulate writer who addresses topics that are of interest to consultants, IT managers and those in the trenches, and you'll understand why I listen to what he has to say.

Also out is the newest issue of Amy Wohl's Opinions. This newsletter is well worth reading, and for a limited time you can also read a special report on her web site titled Linux Comes of Age?

Saturday, March 23, 2002

 
Posted by Mike Tarrani 9:17 PM
Reading Material. I'm still writing my next entry that addresses the service level objective layer in the Tarrani-Zarate Model. In the interim I want to provide some background material on business imperatives. It's a sad fact that too many IT professionals do not fully understand or appreciate the importance of business imperatives. Sadder still is the fact that many who have the title business systems analyst lack the understanding and appreciation. The books I've listed below will go a long way towards filling the understanding and knowledge gaps that exist:

• Internet Commerce Metrics and Models. This book is an encyclopedia of metrics that business process owners care about, and a compendium of advice for measuring them. Don't let the title fool you - this book is as applicable to bricks and mortar businesses as it is to e-commerce sites. I can assure you that reading this book will give you insights into the minds of the business process owners for whom you exist to serve, and will impart a good appreciation of business imperatives.
• Measuring the Impact of Your Web Site. Not only does this book expose the key metrics, but it also provides a methodology for gathering and analyzing the metrics. The methodology steps you through gathering raw measures, consolidating them, developing assumptions and approximations, then performing impact measurements. This book will not only give you insights into the business and what is important, but will also give you a methodology that can be employed for technical analysis within the IT domain. For example, these business techniques are also the basis for measuring IT effectiveness, service level attainment and other performance areas. Of course the metrics for IT are going to be different than the business metrics given in the book.
• Financial and Process Metrics for the New Economy. More metrics, but from a financial perspective with coupling to process performance. I won't rehash the specifics because you can read my 28 August 2001 review on Amazon.
• Ecosystem: Living the 12 Principles of Networked Business. My 10 September 2001 review covers the reasons why I am recommending this book. Also, in light of recent posts by Kate Hartshorn on complexity and perception I am going to revisit this one myself. The book has a lot of depth and provides deep insights into the business side.
• Web Business Engineering. I saved the best for last. This book is one of the top five I read in 2001, and has everything to do with business imperatives and little to do with technology. Both Linda and I reviewed this book and I cannot improve upon what Linda said in her 16 September 2001 review or what I said in my 14 September review. If you only buy one book this is the one to get.

Friday, March 22, 2002

 
Posted by Anonymous 9:42 PM
Dim Memories of Exciting Times. What do the radical free speech movement of the 1960s Berkeley and a computer-based education system based on B. F. Skinner's behavioral theories have in common? Each has influenced the art and science of knowledge management in unique ways.

I made these connections by serendipity. It started when Mike related some fascinating stories of the early days of personal computing and his parallel experiences on the Internet back in the late 1970s. The reason the experiences were parallel is because his access to the Internet and its network culture was via mainframes and minicomputers on MILNET. His personal computing experience and online experience converged in the early 1980s when he graduated from dialing into single-line bulletin board systems (BBS) to USENET access. The deeper I dug with probing questions the more he revealed (dredged up is a more apt term).

Connections. As his story unfolded he mentioned early work called the Community Memory Project. I took this bit of information and applied my own research. What I discovered was that in the early 1970s a community-minded innovator and visionary named Lee Felsenstein was one of the project's creators. He was also involved with the free speech movement, which influenced his thinking. In any other place but Berkeley an engineering mindset and social consciousness would be mutually exclusive, but the summary of the project and how it came to be shows that Mr. Felsenstein was an engineer with a strong commitment to social change. An account of his role and motivations are provided in a two-article overview of the Community Memory Project's history: Part 1 - How Community Memory Project Came to Be and Part 2 - Second Generation. Mr. Felsenstein (a fellow Philadelphian) made a number of contributions to personal computing, which were recognized when he was inducted into the Computer Hall of Fame in 1998.

The connection to B. F. Skinner and computer-based education also has its roots in the 1960s, when Control Data Corporation initiated the PLATO Project. This early work evolved into collaborative computing, and has significantly influenced, in many overt and subtle ways, the way the world wide web has evolved.

The Point? Both events (the free speech movement that was the impetus for the Community Memory Project and the PLATO project) planted the seeds of knowledge management. Studying these early projects gives insights into what does and does not work when developing a knowledge management solution. Both contribute to the body of knowledge for collaborative systems and knowledge management (PLATO is exceptionally well-documented), and this body of knowledge should not be overlooked if you are involved in knowledge management strategies.

 
Posted by Mike Tarrani 4:28 PM
Tarrani-Zarate Model: Business Requirements. In my 21 March entry I introduced the model, how it evolved and discussed the importance of business imperatives. These are the impetus or driving force behind everything also the flows through the model, with an ultimate purpose of delivering tools to the business that are characterized by reliability, availability and support from IT.

Refer to the illustration and you'll see that before the model's foundation there is one additional layer: business requirements. These requirements are dictated by business imperatives. The requirements flow in two directions:

1. Up, which determines service level objectives, which are performance targets that IT uses to measure how well the business is supported.
2. To application delivery processes, which is either a project to develop a system needed to support business imperatives (or to modify existing systems), or the acquisition of the system/application. Application delivery also encompasses the procurement of third-party services, such as application service providers (ASPs), managed service providers (MSPs) and outsourced services and functions, including IT as a whole.

Doing the right things. Getting requirements right is probably one of the most important activities in IT. This is a two-part process: elicitation and documentation. Within this process is the normal due diligence of peer reviews, review and approval of the documented requirements by not only the source of those requirements (from whom they were elicited), but from the business process owner(s) who are the final authority for whether or not the requirement conforms to business needs, governing policy (see my series on processes in Notes from the Field), and business processes (both "as is" and "to be").

Technical and Business Value. The technical value of requirements is that they are the basis for committing resources (people and money) to develop or acquire the systems and services that support the fulfillment of business imperatives. Poorly defined requirements will at worst result in project cancellation, and at best, tools that do not completely satisfy needs generated by business imperatives.

The business value of requirements is straightforward as well: poorly defined requirements will result in either the delay of the systems and services that comprise tools with which the business employs to satisfy business imperatives, or tools that do not fully address business imperatives.

In both cases there is much at risk, all of which goes back to competitive advantage and shareholder value. These are significant factors that determine whether or not a business will survive (or you have a job). The cost of poor requirements is clearly illustrated in costs of defects, which shows that as the development of a system progresses throughout its life cycle the cost of catching problems in the requirements phase is nominal, yet it increases dramatically in later phases. One of the biggest causes of problems is poor requirements. It's ironic that requirements elicitation and management is too often deemed least important when a project is initiated. To be sure there is much lip service given, but in many organizations the focus is on the development stage. This is why IT often delivers results that are [to put it charitably] less than adequate.

Business Rules. This approach to requirements has been repeatedly mentioned here and in Notes from the Field. The value of using a business rules approach is discussed in detail in my 10 March entry, so I am not going to rehash it in this entry. I do want to recommend two books, both of which I've recently reviewed on Amazon, and encourage you to carefully investigate this proven approach to requirements:

1. Business Rules and Information Systems: Aligning IT with Business Goals
   Best introductory text on the subject

   This book introduces the concept and mechanics of business rules, and is essential reading for anyone involved in eliciting and writing requirements, or developing specifications. I want to disclose that I am a staunch advocate of business rules, so take this into consideration as you read this review.

   This is one of two books on the subject. The other book, Business Rules Applied by Barbara von Halle, is more suitable for an experienced practitioner or someone responsible for implementing business rules as an enterprise methodology. This book, however, focuses on the basics and addresses topics, such as object orientation and development, that are not found in von Halle's book. Both books are valuable, but to different audiences.

   What I like most about this book is that it painstakingly describes how to define business rules, and how to clearly and unambiguously describe them. Moreover, the approach given in this book employs the object constraint language, which is a part of the unified modeling language (UML) version 1.1. As such it shows how to integrate business rules into use cases, and to develop artifacts that align to organizations that are using UML or the Rational Unified Process, as well as object-oriented frameworks in general.

   My favorite chapters were 3, which is about defining business rules (getting them right) and 5, which covers controlling business rule quality. To me these are the keys to understanding and using business rules, and both chapters were clear and filled with examples. I also liked the appendix, which covered logic - another essential knowledge factor for analysts who are involved in requirements and specifications.

   If you're new to business rules or are exploring them, start here. Even though the von Halle book is better suited to experienced practitioners, I would still recommend this book to members of that audience who are working in object-oriented environments or are using UML. If you are also using UML, do consider also reading Alistair Cockburn's excellent book titled Writing Effective Use Cases because that book is completely consistent with the material in this one.

2. Business Rules Applied
   For experienced practitioners and business rules implementors

   This is one of two books currently in print about business rules, and each book addresses the subject from a different perspective. The other book, Business Rules and Information Systems by Tony Morgan, is a better introduction because it assumes less technical knowledge. This book, however, has unique strengths that the other book doesn't, including:

   1. A comprehensive approach to preparing for and implementing business rules as an enterprise-wide discipline. It accomplishes this by providing a life cycle approach to business rules development through ongoing management.
   2. The implementation approach is provided as a work breakdown structure, which significantly reduces your planning for an enterprise-wide initiative (or a pilot initiative based on a single project).
   3. There is an accompanying web site that provides additional papers, case studies and other materials that enhance the value of the book.

   The introduction to business rules and concepts is perhaps too verbose, but is thorough. What this part of the book lacks in sparkling prose it more than compensates in detail. I particularly liked the chapter devoted to business rules methodology, which takes the concepts and applies them in a structured way. Another strong point is that the book provides many examples to reinforce points under discussion, and summarizes key information in easy-to-read tables. The illustrations that are sprinkled throughout the book also add clarity.

   If you're new to business rules the best book, in my opinion, is Morgan's Business Rules and Information Systems. However, after reading that book you'll also want this one if you are serious about implementing business rules because of the way Ms. von Halle has structured the flow and content. Also, the author is one of the pioneers in the business rules community, which adds considerable authority and credibility to her approach.

Next Up. In my next entry I'm going to discuss the impact of business requirements on service level objectives.

 
Posted by Mike Tarrani 3:11 AM
Treasure. We're all required to write, and for some of us it's what we really do for a living despite our titles. I found a handbook recently that is so well written and on the mark that I'm compelled to share it: Plain Language Handbook. I usually provide links and documents knowing that they will interest some readers, but not others. This book is for everyone and I encourage you to download a copy.

 
Posted by Anonymous 12:02 AM
Miscellaneous Musings. Group Decision Support Systems, Inc. has an excellent working paper collection covering topics ranging from knowledge management to organizational improvement.

One of the best papers to illustrate competitive intelligence concepts is the 62 page publication titled U.S. and Worldwide Consulting Services Market Forecast and Analysis, 2001–2005. What makes this paper valuable is the collection and analysis techniques are clearly apparent. While the document itself does not fall into the category of competitive intelligence, it was developed using the same techniques. Since most of us are in the consulting business, the contents are as interesting as the methods with which they were developed.

Strategic Application of e-Intelligence discusses the use of data as a strategic tool. This paper fits nicely into Mike's earlier discussion about business imperatives and how they relate to the Tarrani-Zarate Model.

How Can IT Support the Learning Organization intersects with my discussion of knowledge management and business intelligence, and the direction that Mike is taking with the Tarrani-Zarate Model discussion.

I posted material about cognitive science, complexity and perception in my last Notes from the Field entry. As a follow-up here I am sharing a PowerPoint presentation on requirements engineering that lightly touches on the more subtle challenges of eliciting and documenting requirements.

Monday, March 18, 2002

 
Posted by Anonymous 7:14 PM
Manage Knowledge Before It Manages You. Linda graciously left me an opening to add more material about knowledge management. The theme of this material is making the business case, and a good starting point is Knowledge Management Business Case Exploration. If you are considering whether or not knowledge management is worth the effort and resources, the paper titled Risks of No Knowledge Management may help you decide. The paper starts with an attention-grabbing sentence:

Three recent failures in risk management-at Barings Bank, Kidder Peabody, and Metallgesellschaft Refining & Marketing-point to a similar underlying cause: the failure of the firms to manage their organizational knowledge.

It goes on to give some compelling reasons in favor of knowledge management.

As you go deeper into the analysis and decision process you'll find the paper on knowledge management implementation issues to be useful. You'll also find invaluable information in The Quest for a Model of Knowledge Management Evaluation. This paper's abstract illustrates why the information it contains is an important part of the decision making process:

This paper reviews the features of successful knowledge management systems, trying to reveal the general factors and the characteristics of such systems. The aim is to enable managers to distinguish between traditional IT systems labeled KM systems, and real knowledge management systems, enabling companies to use their specific knowledge in order to gain competitive advantage. The list of general characteristics can be used either for examining existing knowledge management systems at different stages of their lifecycle, or as guidelines for planning and starting the design of such a system.

In other words, approach knowledge management from a business perspective, not from the IT view.

A more advanced look at knowledge management is given in Knowledge Reuse, subtitled, The Missing Focus in Knowledge Management: Results of a Case Analysis at the Jet Propulsion Laboratory. It's a well written case study with information that you can effectively use as you plan your knowledge management strategy.

La Vita Dolce Per Tutti. Rough translation: the sweet life for all. It's a beautiful day in Irvine, California and I am going to take a break and enjoy it. Ciao.

 
Posted by Mike Tarrani 4:34 AM
Book Review. Linda and I finally posted our reviews of : IT Systems Management: Designing, Implementing, and Managing World-Class Infrastructures on Amazon. It will take between three to five days for the reviews to appear on the Amazon product page, so I am going to post both here.

Linda's Review
Amazingly complete and packed with knowledge

Mr. Schiesser has managed to capture all of the essential service delivery processes in a single book, and he covers each of these topics with a thoroughness that will give you a foundation to implement world-class system management.

He starts out with three chapters that cover the history of system management and how it has evolved into an important discipline that is currently challenged by issues that were not foreseeable when I started in the industry 25 years ago. Today systems are interconnected into complex supply chains and extend onto the desktops of home and business users who are not known to the managers of the systems. Although these chapters can be skipped, they do provide context for the details that come in later chapters. In fact, each topic in the book is introduced at a basic level, then built upon in layer upon layer of detail. This makes learning the complex discipline of system management easy to someone new to IT, and exposes details that even seasoned veterans may not have encountered.

The book's best feature is that covers each of the key processes (support and problem management, availability, performance tuning and capacity planning, change control and configuration management), and ties them to related areas (security, disaster recovery, facilities management, and infrastructure management areas for storage and networks).

Although the book is not sequenced in the key process and related areas in the order I've listed, a pattern emerges as each topic is covered. The glue that ties all of these together is the way the author develops a strategy for organizing for systems management, including staffing considerations, and the integration of the processes at the end of the book. I especially like the way tactical and strategic processes are identified and how the relationships are developed.

As an IT operations management specialist with extensive experience I appreciate the way the book has accurately captured the essence of systems management. As a consultant I found the checklists and worksheets provided in the book to be invaluable. This book represents an important contribution to the overlooked body of knowledge of systems management and IT operations, and should be on the bookshelf of every IT manager or service delivery specialist who takes their job seriously. It should be carefully read by those in the dot com and ASP industries because the processes described in this book, if implemented, will differentiate your services and give you a significant competitive advantage.

My Review
Complete coverage of critical processes

This book provides sorely needed guidance for developing and implementing system management processes that will assure reliability, availability and support. The topics that this book addresses that are not found in any other I've read include:

• Production acceptance criteria - this topic covers the critical boundary between development or projects, and operations. The value of employing the book's approach to production acceptance is that applications and systems will be brought into production in a carefully controlled manner that ensures all operations is fully prepared to provide the level of support required by the business.
• Acknowledgement of the importance of facilities management, which is almost always overlooked until problems arise.
• One of the most comprehensive and well thought out collections of checklists I've ever encountered. The checklists provided in the book cover every aspect of systems management, ranging from staffing profiles, key issues in infrastructure support processes, to capacity planning. The checklists alone are worth many times the price of the book.
• Linking change control (a rare topic itself) to configuration management. I specialize in these two areas and can attest that the author's treatment is accurate and reflect best practices.
• Special considerations for web-enabled environments. Finally we have material that updates traditional management and support processes to reflect challenges of web-based computing. The tried and true methods many of us learned from mainframe environments impeded the meeting of business goals in web-based environments. This book gives advice that is useful and provides a foundation for evolving processes to meet these unique challenges.

I also like the way each topic is explored by starting simple and expanding into details that are examined for strengths and weaknesses. The net result is an understanding of all factors and issues, including many subtle ones that would have required iterations of trial and error to get right. Most importantly the author stayed focused on processes and best practices, leaving system management products to authors of books for a much narrower audience. This, in my opinion, greatly increases the value of the book and makes it applicable to anyone who is part of the system management or service delivery process. My only complaint, and it is minor, is the lack of a web site or accompanying CD ROM with the invaluable checklists and tools in electronic format.

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.

Saturday, March 09, 2002

 
Posted by Anonymous 2:23 PM
More Material. I've been reading Lisa Rein's weblog and am amazed by her knowledge of intellectual property law issues and related topics. When I first read about her in one of Mike's entries I assumed that she was an XML expert and a journalist. As it turns out, Ms. Rein closely follows intellectual property, civil liberties and related law, and her assessments are cogent and intelligent.

Mike sent me a copy of Laura Brown's Innovations Newsletter, in which she discusses the DMCA. The newsletter is well written and covers a wide range of topics. If you like the newsletter you may wish to subscribe and automatically receive it in your email when each issue is published. I took the time to explore her web site, and found a wealth of information. Mike cited Ms. Brown's Integration Models: Templates for Business Transformation as one of the top four books he read in 2001 (see the 4 January 2002 entry in Notes from the Field). Take my word, that's high praise. If you want to know more about the book see Mike's and Linda's Amazon reviews that were written in June 2001.

Friday, March 08, 2002

 
Posted by Anonymous 3:32 PM
Introduction. Mike's recent Zachman Framework topic touches upon my core competencies, which has inspired me to emerge from the shadows and contribute to the discussion.

Before proceeding I want to share information about my background and professional interests. I received my BA in Social Ecology from the University of California, Irvine in 1988. I've held a number of positions ranging from marketing support, to project management, to competitive intelligence specialist. I'm also an inactive (at the moment) member of Society of Competitive Intelligence Professionals (SCIP) and Special Libraries Association (SLA).

Mesh of Topics. There is a direct correlation among knowledge management, competitive intelligence and intellectual property law. The relationships are:

• Knowledge management is a superset of competitive intelligence. The infusion of competitive intelligence into an organization's knowledge base is business intelligence.
• Competitive intelligence has its own specialized domains. For example, technical intelligence can be gathered using patent searches, reverse engineering and competitor marketing literature. The connection between competitive intelligence in the technical domain and intellectual property law is clearly shown when patent searches are used as a gathering strategy.
• Intellectual property (IP) law also governs reverse engineering strategies because the Digital Millennium Copyright Act (DMCA) restricts practices that were formerly completely legal. If you've been reading Mike's entries on the Uniform Computer Information and Transactions Act (UCITA), you'll see that IP laws are not the only inhibiting factor in contemporary competitive intelligence. UCITA is related to the Uniform Commercial Code (UCC), which is a set of laws that govern fair business practices. Intellectual property laws govern copyrights, trademarks and patents. Although IP law and UCC are two completely separate areas of law, they both affect competitive intelligence, and the new requirements imposed by the DMCA and proposed by UCITA need to be understood.

What Does This Mean to You? As an IT professional you may be involved in competitive intelligence gathering, either through covert methods (legal and ethical, of course) or through benchmarking. In addition, you have a responsibility to understand legal and ethical ramifications that are inherent in IT. Some examples of the inherent legal and ethical ramifications that apply specifically to IT professionals are:

• The Equity Funding Fraud and Lessons to be learned
• Security and Conflict of Interest
• Be Careful What You Post

The above articles are all from M. E. Kabay's Network World Fusion Newsletters and each provides chilling examples of ramifications of which you need to be aware.

Knowledge management is also a foremost concern for IT professionals because you will either be called upon to develop solutions for your constituents, the business process owners, or will employ it internally to improve IT processes, or both.

Material. I've gathered material (using competitive intelligence techniques, of course) that will get you started in the basics of CI, knowledge management and IP law:

• Competitive Intelligence. Four archives of PowerPoint presentations:
  1. CI Basics (contains six presentations covering the fundamentals)
  2. CI and the Internet (two presentations on basic Internet research techniques)
  3. Research Techniques (five presentations on topics ranging from strategic intelligence to gleaning intelligence from patents)
  4. Other CI topics (contains seven presentations covering CI benchmarking, education, strategic use of intelligence, etc.)
• Intellectual Property. IP Law and DMCA, containing seven presentations on IP law, DCMA, Cyber Liabilities and related topics
• Knowledge Management. Five archives of PowerPoint presentations covering:
  1. Knowledge Management Basics
  2. Knowledge Management in Practice
  3. Knowledge Management in IT
  4. Knowledge Management Processes
  5. Knowledge Management and Business Process Improvement
  Back into the Woodwork. I am going to return to my shadowy underground, providing support to Mike and Linda. I'll emerge into the sunlight again when Mike becomes inundated, which he is now. In the meantime, I hope this short piece and the materials that I've provided fill in any gaps or clarify Mike's discussion of knowledge management as it relates to the Zachman Framework. Some of this material will also be helpful when Mike begins discussing policies, processes and procedures in Notes from the Field. Best wishes from Irvine, California.

Thursday, March 07, 2002

 
Posted by Mike Tarrani 3:56 PM
Zachman Framework - Part 3. This entry is going to introduce business rules, which is a continuation of my last two entries.

What are Business Rules? A business rule, according to Barbara von Halle in Business Rules Applied: Building Better Systems Using the Business Rules Approach is defined as:

[t]he set of conditions that govern a business event so that it occurs in a way that is acceptable to the business (or customer). The business people (or customer) state rules that define all possible and permissible conditions for the business event along with those that are not permissible or are undesirable.

She goes on to state:

A useful way to divide the world of business rules involves three major categories:

1. Terms
2. Facts
3. Rules

The terms and facts will be the foundation for a logical data model and physical database. The third classification ­ rules ­ is where the excitement lies in a business rules approach.

Rules are classified as five different types:

1. Mandatory constraints
2. Guidelines
3. Action-enablers
4. Computations
5. Inferences

If you're familiar with Information Mapping, you'll see parallels between that documentation technique and business rules. You'll also notice familiar concepts if you've worked with the IDEF family of models that provide a structured approach to enterprise modeling and analysis.

Why are they Important? I became a proponent of business rules when I saw how unambiguously they express requirements, and how they easily translate into specifications and test cases. However, the most important aspect of business rules is the fact that they are from the business and reflect a genuine view of what the business needs. By expressing requirements as business rules we in IT are forced to examine enterprise policies, processes and procedures, discover the constraints imposed by policy (corporate and external, such as regulatory and legal requirements with which the business must comply), and the other elements that are provided from Ms. von Halle's definition.

Example. An example of business rules in action is the best way to illustrate their value.

• Situation: A 1996 Congressional act mandated a statutory obligation be put into effect for the FCC and state telecommunications commissions to provide affordable telephone service to rural areas. The act allowed 15 months to establish a method for providing this service.

  To comply with this act, the FCC has begun assessing Universal Service Fund charges on all telecommunications companies. The companies in turn will pass this charge on to their customer base with two percentage based taxes, a low income USF tax on usage charges and a school, library and rural health care USF tax on usage charges.

  The federal government will send assessments to the enterprise periodically based on the prior periods' revenue.

  The percentage charges assessed to the customer base will then be determined by taking into account such factors as the size of the customer base, projected growth etc.

• Rules: The situation obviously imposes mandatory constraints in the form of a law. Since this is an example I am going to bypass the impact analysis and legal research that the situation requires and provide business rules that are based on the findings of those skipped activities:
  1. Incorporate into the system USF percentages for
     • low income
     • school
     • library
     • rural health care
  2. The existing tax calculation routine needs to be modified to use the percentage rates required by USF when applying the USF taxes.
  3. These rates from the previous rule needs to override the statutory rates supplied by the existing taxing interface.
  4. USF taxes applied need to be written to the existing Tax Detail table.
  5. USF taxes applied need to be shown on the Tax Summary report.

To underscore the value of using the business rules approach, consider a typical requirements specification using the same situation:

The business needs the ability to establish a system parameter to be used for storing the Universal Service Fund (USF) percentage rates and the ability to assess USF taxes based on these percentages.

Look familiar? This is, unfortunately, typical of requirements that are passed to the specification developers and designers. If you carefully read the requirement you'll notice that it not only is vague, but it breaks a basic rule in expressing requirements by stating a design approach (... establish a system parameter to be used for storing ...).

Contrasting the business rules approach with the typical example yields the following assessment:

• Efficiency - the requirements stated in the business rules are from governing source documents and business subject matter experts. The design team will not need to meet with the business subject matter experts separately to clarify details about the USF, percentages or other facts. This information was captured in the business rules.
• Testability - the requirements specification containing business rules can be used as the basis for a test strategy because there is sufficient information from which to develop test cases (the business rules show where the USF percentages are to be applied, and they point to other subsystems such as the existing tax tables that need to be regression tested).
• Non-ambiguity - the business logic is captured in the business rules and are expressed in a manner that can be interpreted only one way.
• Focus - requirements are separated from specifications and design because business rules capture the what is important to the business, not how to implement a solution (revisit the statement about establishing a system parameter above to see how easy it is to mix requirements and solutions if requirements are not precisely expressed as business rules).

Resources. I'll be writing more about business rules over the next few days because this topic has a rich body of knowledge. Until my next entry you may want to explore the basics, and the best starting points are: Knowledge Partners, Inc. whitepapers, which contains some of the best business rules material available on the web. One of the principals is Barbara von Halle, who has authored many of the whitepapers on the site, and is the author of Business Rules Applied: Building Better Systems Using the Business Rules Approach.

Business Rules Community is the website for the business rules community. This site is filled with articles, news, case studies and discussions. If you adopt business rules you'll find yourself visiting this site often. Business Rules Community is sponsored by Business Rules Solutions, LLC. Although this is a commercial site the principals, Ronald G. Ross and Gladys S.W. Lam, are internationally acclaimed as the foremost experts and practitioners of business rule techniques and methodology.

End Note. In my last entry I stated that I wanted to discuss the knowledge management aspects of the Zachman Framework with Muthukumar U and Kate Hartshorn. The opportunity to engage either of these two experts has eluded me, so I am going finish the business rules topic before addressing knowledge management. However, I did find an interesting paper titled A Methodology for Knowledge Discovery and Classification. You may also want to visit Technical Communications Resources and Business and Strategic Planning Resources, which are two web pages that Linda and I maintain. Both pages contain material related to business rules, policies and procedures, and knowledge management.

Wednesday, March 06, 2002

 
Posted by Mike Tarrani 6:41 AM
Zachman Framework - Part 2. My last entry introduced the Zachman Framework and background information. This entry is going to be brief because there are two people with whom I want to collaborate before I get too deep into this topic. The first is Muthukumar U, a close friend who works as a risk management specialist at HSBC Bank Middle East in Sharjah, UAE. Muthukumar is much more than a risk management specialist - he's a deep thinker and genuine intellectual who is well versed in a number of subjects. Among his many talents is an abiding passion for knowledge management. Because the Zachman Framework is an ideal structure for developing architectures and solutions that enable knowledge management I want Muthukumar's thoughts before getting too deep into that aspect of the framework.

I also want the benefit of Kate Hartshorn's knowledge and experience. Kate has a keen understanding of knowledge management, in addition to data mining, information transformation and related topics, all of which are enabled or fostered by the Zachman Framework.

Knowledge. Although I am waiting to discuss aspects of knowledge management with Muthukumar and Kate, I do have my own ideas about aspects of the subject. Two areas in which I have professional interests are business case development and value analysis. The 20-page whitepaper (in PDF format) titled, Estimating Benefits of Knowledge Management Initiatives is an important discussion of the methods and tools used to prove the business value of knowledge management. This is especially important if you're examining the potential use of portals as a means of disseminating knowledge throughout the enterprise.

If you need to quickly get up-to-speed in portals as a technology and as a business strategy I recommend Heidi Collins' Corporate Portals: Revolutionizing Information Access to Increase Productivity and Drive the Bottom Line. I reviewed this book on Amazon on 8 April 2001. Linda also wrote an Amazon review on 24 February 2001. Ms. Collins has a new book that will be out in May titled, Enterprise Knowledge Portals: Next Generation Portal Solutions for Dynamic Information Access, Better Decision Making and Maximum Results. Since I was pleased with her first book I pre-ordered a copy of this one.

As you delve into the Zachman Framework you're going to notice that XML is a recurring topic. Discussing the many reasons for this is well beyond the scope of this entry; however, the short version is XML's ability to facilitate data exchange among disparate systems and data sources makes it an ideal technology to employ in any enterprise architecture. Extracting the data is typically done with SQL queries. XML DTDs are the templates into which the results of the SQL queries are stored, which allows you to aggregate data in ways that were not easy before XML came along. Details and techniques are provided in XML and SQL: Developing Web Applications by Daniel Appelquist.

XML and portals are also usually associated with each other. How specifically they are associated can be discerned by reading Building Corporate Portals with XML by Clive Finkelstein, Peter G. Aiken and John A. Zachman (the man himself), or my favorite book titled, Metadata Solutions: Using Metamodels, Repositories, XML, and Enterprise Portals to Generate Information on Demand, which I reviewed on 22 September 2001.

Are you starting to see a pattern? It's all about the data. It always has been.

Yellow Light. We have the standards, techniques and tools to bring to bear on initiatives and strategies that not so long ago would have required us to do a lot of inventing. Here's an example requirement that can be easily met using some of the standards and techniques I've just discussed:

• Requirement: Realtime updating of customer account information and transactions to a central server. Customers should have access to Internet banking functions, including fund transfers, payments, status lookups, etc.
• Situational Analysis: Current account and transaction data resides at the branch level, and is managed by different systems depending on the branch.
• Constraints:
  1. Cost - an enterprise solution is planned with a two-year planning horizon and business goals dictate that no large investment be made in infrastructure that could be obsoleted by the enterprise solution
  2. Competitive pressures - the bank wants to achieve competitive advantage now using an interim solution that will capture and/or retain customers who want Internet banking
  3. Existing infrastructure - 290 branches are interconnected with varying connectivity options, most of which are relatively low speed (VSAT, ISDN, etc.); the solution cannot require a change to the existing infrastructure.

How to proceed? A solution that can meet stated requirements within the constraints can be achieved as follows:

1. Task: Analyze the data structure used in each of the existing systems. Deliverable: E-R diagrams and data dictionary for each system.
2. Task: Develop a master data dictionary using agreed upon data naming conventions. Deliverable: Master data dictionary.
3. Task: Develop a master DTD using data naming conventions. Deliverable: Document Type Definition master template
4. Task: Develop SQL queries for each data source. Deliverable: Tested SQL queries for each data source.
5. Task: Develop and configure central portal to accept customer sessions, assure identity, issue transaction requests and display results. Deliverable: Design specifications, access controls, secure transmission protocol(s), user interface, application and presentation layer coding.
Of course, the solution I just presented is something I quickly pulled out of thin air, and many details have been glossed over. The point is that using the alphabet soup of SQL, XML, LDAP and other standards and technologies a solution can be crafted.

The Rub. Therein lies the rub - the solution shortly becomes an impediment to the planned system, which is two years out. It (or a more fleshed-out version) may address the immediate requirements and stay within the constraints, but it is short-sighted. The missing ingredient is a larger view of the problem, and that view should be based on a framework that serves as a blueprint for the evolving architecture. This is where the Zachman Framework's value becomes apparent. The viewpoints and focus that I discussed in my last entry not only add structure to the solution, but place it in context of the much larger domains of business strategy and enterprise architecture.

Wrap-up. I am out of time on this entry. The foregoing will [I hope] spark ideas, and the following will provide more details about the Zachman Framework and related topics:

• Two articles about enterprise-wide architectures, with a focus on the Zachman Framework
• Eight MS Word documents covering topics ranging from enterprise requirements to enterprise architecture engineering, all of which directly reference the Zachman Framework
• PowerPoint presentation on the Open Architecture Group Framework
• MS Word and PowerPoint documents about architectures and modeling, with an emphasis on the Zachman Framework
• A collection of PowerPoint presentations on miscellaneous topics about or related to the Zachman Framework
• Integration topics, including integrating the Zachman Framework and Rational Unified Process (see my Notes from the Field entry from earlier today)
• Data issues, consisting of two MS Word documents: Data element naming standards and data standards for patient medical records
End Note. I hope to introduce business rules in my next entry, and if I have an opportunity to discuss knowledge management with either Kate Hartshorn or Muthukumar U I'll summarize key findings from the discussions.

Tuesday, March 05, 2002

 
Posted by Mike Tarrani 5:23 AM
New Topic. I've been focusing on project management, security and some aspects of service delivery in recent entries here, with some cross-over in Notes from the Field. It's time to introduce a fresh topic, and the catalyst for doing so is a brief conversation between me and Thinking Minds, Inc. CEO, Unmesh Laddha.

Unmesh's company develops portal, knowledge management, and groupware solutions, among other products and services, and he has become intensely interested in the Zachman Framework. He's on the right track because Thinking Minds, Inc. solutions are a close, natural fit to the Zachman Framework.

What is the Zachman Framework? In a nutshell it's a multidimensional model that displays information systems in accordance with:

• stakeholder viewpoints and perspectives
• focus - What, How, When, Where, Why (the Who is captured in the stakeholder viewpoints)

A picture is worth a thousand words, and a PowerPoint presentation is worth many more, so I'm going to refer you to Overview of the Zachman Enterprise Architecture for a quick introduction (or refresher if you're already familiar with the Zachman Framework). Another document worth reading is the original 1987 article in which Mr. Zachman introduced the framework. More information can be obtained from Zachman Institute for Framework Advancement.

Anytime you research the Zachman Framework you're going to also see the term Enterprise Architecture Planning. The connection is shown in the PowerPoint presentation titled, Zachman Framework for Enterprise Architecture. The best book on the subject, in my opinion, is Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology by Steven H. Spewak and Steven C. Hill. My personal copy of this book dates back to 1993, and I've referred to it many times over the years. My first exposure to the Zachman Framework as a foundation for enterprise architecture planning came from this book. Linda also read the book and came away with a completely different perspective, which she documented in her 21 January 2001 review on Amazon. Where I saw a coherent approach to planning and implementing enterprise architectures, Linda saw a direct connection to service delivery. Her perspective is validated in a PowerPoint presentation that I discovered on the web titled, Service Delivery for Virtual Communities. This document ties together Linda's perspective, how one of Thinking Minds, Inc. products called ThinkingWare aligns to the Zachman Framework, and how the Zachman Framework defines an enterprise-wide architecture.

Examples. I made an earlier statement about how the Zachman Framework was a natural fit for portal, knowledge management,and groupware solutions. The following examples, most of which are PowerPoint presentations, support my statement:

• Information Exchange: Integrating Knowledge in the 21st Century
• Knowledge Management and the Zachman Framework
• Data Warehousing and the Zachman Framework
• Mapping the Zachman Framework to the C4ISR Architecture Framework

Note: the last presentation is a Department of Defense initiative. C4ISR stands for Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance. The reason I chose this example is the alignment to the complex C4ISR architecture is a much more difficult undertaking than merely applying the Zachman Framework to a commercial enterprise.

End Note. I am by no means finished with this topic. Tomorrow I'll share more presentations and documents, as well as introduce business rules. While business rules are not a part of the Zachman Framework, they do align very closely with the framework.

Monday, March 04, 2002

 
Posted by Mike Tarrani 4:54 PM
Late Note. In my haste to get the last entry published I overlooked PIKT, which is an embedded scripting language and accompanying script interpreter.

What does a scripting language have to do with security? It was designed to be an embedded tool for developing monitoring and problem resolution solutions. The Introduction to PIKT fully describes the design philosophy and how to use PIKT to achieve these goals.

Other resources for PIKT include:

• a tutorial
• reference manual
• example code and developed solutions
• user contributons, including alarm scripts, object/data lists, and macros

You can download PIKT if you feel that it may be useful to your purposes. It is compatible with AIX, Digital UNIX, FreeBSD, GNU/Linux, HP-UX, IRIX, OpenBSD, SCO OpenServer, Solaris and SunOS.

Also see related applications that work with or like PIKT.

Sunday, March 03, 2002

 
Posted by Mike Tarrani 11:07 PM
Security Tools. As promised in my last entry I am sharing sources of free security tools that will aid in security assurance initiatives:

• Egressor, which is designed to check the configuration of their Internet point-of-presence router. The tool will help companies determine whether their routers are configured to the Help Defeat Denial of Service Attacks guidelines. This configuration of egress filtering reduces the chance that their computers can unwittingly contribute to a distributed denial of service attack.
• Spitfire, developed as a prototype operator workstation for Network Intrusion Detection System Operators.

A complete list of UNIX host and network security tools is provided by NIST. Another list, with overlap, is published by Mitre. This list covers the wider scope of Security Information Resources, that includes tools and documents.

NIST also provides free Common Criteria tools that include the Common Criteria Toolbox and Common Criteria Profiling Knowledge Base.

End Note. Realtime Forensics and Tracking is a PowerPoint presentation on forensics that covers this aspect of security in detail. The more generic PowerPoint presentation titled Security Management Practices is useful as a memory jogger and as a training resource.