This page is powered by Blogger.


 
  corner   



HOME

ARCHIVES

SEARCH

Contacting Us
Recommendations
Mike Tarrani
Linda Zarate
Kate Hartshorn

Who We Are
TEAM Zarate-Tarrani

Our main weblog
Notes from the Field

Our other pages
Mike's home page
Linda's home page
Kate's home page

Forums
Simpatico [we]blogs
Dan Gilmore
Robert X. Cringely
Jakob Nielsen
Julian Bond
Deborah Branscum
Lisa Rein
CamWorld
Ed Yourdon

 

Sunday, March 31, 2002

 

I've been reading Mike Sisco's final book in the IT Manager Development Series titled Acquisition: IT assimilations. This 58-page book is worth its weight in gold to any organization which is acquiring (or being acquired by) another and is faced with the daunting task of merging IT.

The book starts with the problem statement ("We've bought another company; what do we do now?") and then proceeds to lay out a ten-step process for assimilating the acquisition. The steps, each a chapter, are:

  1. Identify Objectives.
  2. Use the Objectives to Develop a Strategy.
  3. Ascertain that Due Diligence was Performed.
  4. Situational Analysis:
    • Key Risks
    • Potential Problem Areas
    • IT Dependencies
    • IT Organizational Impacts
    • Budget Implications
    • Opportunities
  5. List Key Initiatives.
  6. Prioritize.
  7. Obtain Stakeholder Consensus.
  8. Develop the Plan.
  9. Implement.
  10. Measure and Control.
I am not using actual chapter titles above because I wanted to summarize the contents. The final chapter is titled Got More than One Technology to Convert, which provides additional guidance when you're faced with integration challenges that can be best described as a hairball.

While the body of the book is well worth the price, the appendices significantly increase the value of this book. The six appendices are: A - New Acquisition Planning Questionnaire, B - Business Application Conversion Plan Template, C - Sample Employee Severance/Retention Letter, D - Legacy System Status, E - Transition Issues Templates and F - Transition Summary Checklist.

The capstone of value, in my opinion, is the straightforward approach provided, the case studies that reinforce the approach, and the personal notes and side bars that Mr. Sisco has sprinkled throughout. He's distilled his 25+ years of IT management experience into 58 information-packed pages that will give you the foundation for planning an assimilation of an IT department. Embodied in the pages are not only sage advice, but wisdom. It's obvious that Mr. Sisco has done this before, and you'll benefit from his experience.

I will review the companion book in this series titled Acquisition: IT Due Diligence later in the week. I've read through most of this 88 page book and should have reviewed it first because it addresses the software development contracting and outsourcing issues which we've been discussing. However, I had already read Acquisition: IT assimilations and wanted to discuss it because that book complements my ongoing discussion of the Tarrani-Zarate Model.

Have a great Sunday!



Saturday, March 30, 2002

 

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.

 

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:

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

 

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.



Thursday, March 28, 2002

 

RFP Redux, Outsourcing and More on Quality. I have a few additional considerations to add to Mike's software RFP entry. I also want to share two papers on outsourcing and an excellent journal that is devoted to ISO 9000-3 (also known as TickIT).

Software RFP Items to Consider. Mike ended his entry with the statement that acceptance testing is the buyer's responsibility. The entire QA process in an outsourced software development scenario is complex, and I agree that it responsibility rests on the buyer. A document that was previously cited in Notes from the Field, titled Applying Software Quality Assurance to Outsourced Software Development, provides detailed guidelines for managing this type of development and should be read before the RFP is drafted.

If any of the software development includes open source components you need to consider the ramifications of GPL licensing issues. If not you may find that your application is, by law, also open source and what you think is your intellectual property doesn't belong to you. Read the article titled Lineo's GPL Compliance Tool to get up-to-speed in GPL licensing. Related reading that touches upon intellectual property and a number of other issues is the 25 March 2002 article in eWeek titled Internet Insight: Getting Legal.

Other things to consider when outsourcing software development:

  • Clearly define your service level objectives and make them a part of the contract. Mike mentioned this, but they are almost always missing from contracts. Also make sure your change control and release management criteria, and application acceptance policies and procedures are included in the contract terms and conditions. The goal is to align your existing processes with vendor requirements, and this is especially important when it comes to fixes and enhancements that are sure to arise after you've accepted the software for which you've contracted.
  • Don't forget security. Regardless of whether open source software is provided as a part of the application for which you're contracting the Open Source Test Methodology is a solid framework for security testing. Use it as the basis for security testing in the acceptance test process.
  • Make sure that release notes and build analysis documentation are included in the deliverables listed in your SOW.
General Outsourcing. I found three documents on general outsourcing that I thought were particularly well written and detailed:
  1. Outsourcing Impact on Security Issues
  2. Writing an Outsourcing Contract
  3. Outsourcing Information Systems
Although these documents are not specific to software development, each contains information that does apply to development.

Your TickIT to Quality. As a follow-up to my 24 March entry I want to share a cache of information that expands on the ISO 9000 book I recently reviewed and also provides a lot of information about ISO 9000-3, which is the part of the standard that addresses software and services: TickIT International, which is the quarterly journal of the TickIT software sector quality certification scheme. The First Quarter 2002 issue has an excellent article on quality service delivery, and the back issues are treasures. If you're interested in TickIT see Mike's 9 July 2001 review of ISO 9000-3: A Tool for Software Product and Process Improvement.



Wednesday, March 27, 2002

 

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.


  • Tuesday, March 26, 2002

     

    Linda's 24 March post in Notes from the Field triggered something in my memory about an article I recently read about quality and its relationship to project failure. The article is titled Failed Software Projects? Not Anymore and is a chronicle of how an international service company, CTG, adopted ISO 9001 to eliminate costly errors.

    I also want to add one more resource to augment my last entry on the Tarrani-Zarate Model and the discussion of service level objectives. The April 2000 Gartner Advisory titled An Introduction to IT Service Management packs information and insight into a short and well written brief.

    Mike Sisco's latest issue of Practical Technology Tips & Techniques Newsletter is out. This newsletter covers a wide array of issues that are of interest to IT managers. Signing up for a free subscription is painless and well worth your effort.



    Monday, March 25, 2002

     

    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.

     

    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

     

    My recent research has been directed towards business continuity planning and service level management from the service provider perspective. I've collected two archives of the better documents and PowerPoint presentations on these two subjects to share:
    1. Service Provider SLAs
    2. Business Continuity Planning Resources
    Since I am also in Oracle training for Oracle Certified Professional I couldn't resist the MS Word whitepaper titled Data Warehouse Availability, which fills the gap between service level management and business continuity planning.

    I'm going to be busy most of the week, so Mike and Kate will be the main contributors for the rest of the week. I also want to welcome Marcia Hopkins, who has joined us as a contributor. I'm looking forward to reading Marcia's entries here and in Notes from the Field. Welcome aboard Marcia!

     

    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

     

    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

     

    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.

     

    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.

     

    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.

     

    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.



    Thursday, March 21, 2002

     

    Tarrani-Zarate Model - Part 1. I'm finally caught up and have the time to pick up where I left off nearly two weeks ago. First things first: I greatly appreciate the way Linda Zarate and Kate Hartshorn stepped in and kept this and Notes from the Field going while I was engaged elsewhere. Not only did they cover for me, but they both shared an incredible amount of information about a wide array of topics. With such wonderful colleagues and friends I am doubly blessed. Thank you both!

    Genesis. Linda and I developed this model nearly two years ago. The impetus behind it was our dissatisfaction with a model, called the Inteliant Operations Maturity Model (iOMM), that was developed by a company where she and I were working. Although we participated in the development of the model, we clearly saw that it model had many gaps, not the least of which was the fact that it just didn't make sense when you drilled down into it. The reason why the problems existed had little to do with the team that developed it. Indeed, the people with whom we worked were the best and brightest IT operations management professionals in the business. The problem came about because we attempted to cast the model in a neat geometric shape. The first iteration was a pyramid, which did capture the essence of what it takes to effectively decompose the complexities of IT operations management into domains.

    The second iteration of the model as it unfolded was depicted in a cube to add another dimension to capture elements that were impossible to depict in a pyramid. This was a major leap forward, but the root cause of the problem was we were looking at a geometric form with which to visualize IT operations management instead of looking at the important aspect: answering the simple question, "What is operations management supposed to accomplish?"

    We decided to answer the question and let the shape of the model, regardless of how unseemly it turned out, be determined by that answer.

    What is the Tarrani-Zarate Model? In a nutshell, the model is a way of capturing the purpose of IT operations management, looking at the necessary drivers, required processes and casting them into an end-to-end flow that delivers service and support to the business. That, after all, is why IT exists.

    What we came up with was a model (see illustration) that had business imperatives as a driving force, and the following major layers:

    • Foundation, consisting of business requirements, service level objectives, processes and organization
    • Key processes, which encompass change and configuration, problem, recovery, workload, security and service level management
    • Technology - the layers of infrastructure and systems that are necessary to provide tools to the business
    • Service Delivery (the end goal of IT operations
    • Applications Delivery - which is how new systems and services are brought into the enterprise
    One problem with this model is that we have not shown the full scope of security. While there are IT security processes, they should be under the aegis of an enterprise-wide security program. This is something we'll correct in the model as we develop it.

    Business Imperatives. This is the driving force behind the model, which determines how all other layers (both vertical and horizontal) will be managed. Business imperatives can be broken down into five basic forces, all designed to create customers at the most basic level, and business viability at the macro level. The forces are:

    1. Strategic and tactical objectives - the reactive and proactive responses to competition, market shifts, regulatory factors, etc.
    2. Mission and values, which define the business entity and are a function of leadership.
    3. Competition, which determines strategy and tactics to a large degree, and the barrier to creating customers in an open and free market.
    4. Shareholder value, which is an imperative for all publicly held companies. This imperative has legal ramifications that are closely connected to regulatory and legal imperatives.
    5. Legal and regulatory compliance requirements are constraints and govern how all other imperatives affect the business.
    One way to see the cause and effect of business imperatives on meeting the model's objective of providing service and support to the business is to closely examine the flow, factors and considerations depicted in the recovery management process. This particular process is at the key processes level in our model, and as shown in the illustration it touches all other aspects of the model (with the exception of applications delivery). Each of the key processes in the model can be traced to business imperatives, so this example is apt.

    Closing Notes. Tomorrow I'll discuss the foundation level of the model, which has been partially addressed by Linda's recent entries here and in Notes from the Field. At some point in the coming entries I will also begin introducing books from Mike Sisco's IT Manager Development Series. Until then you may find useful information that addresses business imperatives on our Business and Strategic Planning Resources page.



    Wednesday, March 20, 2002

     

    Capacity Management. I've just posted a review on Amazon of Resource Management. The review is:
    Approach and concepts that apply to all environments

    This book provides in-depth coverage of resource management that can be applied to not only Solaris (or other UNIX systems), but to any system. It accomplishes this by tying resource management to service level management, and does so with one of the best discussions of service level management in print.

    Service level management, covered in chapter 2, clearly shows the service delivery cycle by exposing interactions among and between vendors, system managers and the systems being managed, and business users. I especially like the resource management control loop discussion, which places the rest of the book into the context of support and service. Another innovation that is introduced in this book is the concept of viewpoints as they relate to performance and capacity: These viewpoints can be system-, cluster-, network-, application- storage- or database-centric. The viewpoints are not mutually exclusive. The authors show how to integrate any and all of them into a coherent and consolidated approach.

    The approach is based on policies and controls,and workload management and measurement. The discussion remains focused on service level management throughout the book. The examples for achieving the approach's objectives are, of course, based on Solaris for the most part. If you're using a different variant of UNIX you should be able to easily re-map the facilities and utilities cited in the book to those that are available in your own environment. This also applies to non-UNIX environments. The concepts and approach apply to NT/W2K/XP, IBM midrange systems and mainframes. I was surprised to find that IBM's Workload Manager for OS/390 was included in the book. I came from this environment, so the discussion provided me with familiar territory that caused me to clearly see just how applicable this book is to any environment.

    If you work with Solaris this book is essential. If you work with other operating systems still buy this outstanding book for the concepts and approach.

    One of the foundations of service level management (which I discussed in my entry in Notes from the Field earlier today) is resource management. This activity not only affects how well service level objectives for transaction times are met, but also has much to do with availability. Poorly planned and managed resources (capacity and performance) can affect maintenance window length and/or frequency. Maintenance windows should be minimized as much as possible. Every maintenance action that requires a system to be off-line reduces overall availability of the tools that the business uses to meet business imperatives.

    I want to share related documents about capacity and performance management that will get you thinking about these two primary elements of resource management:

    Since this material is directly related to what I posted today in Notes from the Field, I'm going to end this entry with two additional documents that tie together both entries:
    1. Application Service Provider Models
    2. Balanced Scorecards and IT Management
    I hope these will also help Mike when he begins his discussion of the Tarrani-Zarate Model for Information Technology Management, which is due to commence any day now.

    Best regards from Azusa, California.



    Tuesday, March 19, 2002

     

    Knowledge Management Wrap-Up. Kate's wonderful contributions and endless sources of documents and presentations on knowledge management have given me a priceless education and has inspired me to do deeper research on the topic. I have two contributions to the topic that relate to support and service delivery:
    1. Diagnostic Knowledge Representation, which discusses how to best display knowledge to tier 1 and 2 resources who troubleshoot and resolve problems.
    2. Managing Customer Support Knowledge, which squarely addresses issues and challenges in using knowledge management effectively at the call center and help desk level.



    Monday, March 18, 2002

     

    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.

     

    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.

     

    Knowledge Captured. I'm going to wait for Kate to pick up the knowledge management thread to which she and I are contributing before going deeper into that topic. Knowledge management is Kate's domain and I am going to defer to her expertise, while learning everything I can from her. In this entry I want to address a topic that's important, but one that we tend to overlook: data center management. There is a large body of knowledge about this discipline, but it is difficult to find.

    Data Center Knowledge Base. When was the last time you saw a book about data center management in your local bookstore? Even a search on Amazon, which boasts over two million books, yields two titles, one of which is out-of-print. However, you can find excellent material with persistence and the help of Google. Here are the gems that I uncovered:

    Closely related in a PowerPoint presentation titled System Administration Efficiency, which covers many issues related to data center management.

    Fairness. To be fair to Amazon my title search was limited to books with the words "data center" in the title. There are some excellent books, if you're familiar with the top ones in print, and most of them are published as books in the Harris Kern Enterprise Computing Series. Mike and I have reviewed all but two of the books in this series on Amazon. Of the remaining two, we are each ready to post a review of IT Systems Management: Designing, Implementing, and Managing World-Class Infrastructures, which is probably the best book in the series. As soon as we post our reviews on Amazon we'll post them here as well, so you can read why we both think so highly of this book.



    Saturday, March 16, 2002

     

    Knowledge in Production Support. Kate's discussion of knowledge management ties into IT production support, particularly at the contact center or help desk level. In fact, all of the major help desk applications either have knowledge management modules built into the core product or are available as options and/or third-party add-ons.

    Gaps. While these tools have been available for years, they are often not implemented, or if they are implemented, they are not used to their fullest potential by any but a few help desk organizations.

    Help desk professionals who understand knowledge management are rare. Moreover, many help desk managers are experts in problem management and service level management, few have the background and knowledge needed to appreciate the true value of knowledge management. In theory they all seem to agree that it's a good thing, but in practice many give it lip service. This does not diminish their professionalism; instead it validates everything Kate had to say about the daunting (and expensive) endeavor of implementing knowledge management. As a service delivery practitioner I fully appreciate the difficulties, and also believe that knowledge management is a discipline, and implementing it correctly requires experienced professionals who fully understand how to capture, organize and disseminate knowledge. I also appreciate having Kate on our team and look forward to her future entries about knowledge management.

    I want to share some basic documents about knowledge management that are specific to help desk operations:

    These documents only scratch the surface of what help desk and service delivery professionals need to know about knowledge management, but they are a starting point.

    Wrap-up. Lessons Learned from Help Desk Consolidations doesn't address knowledge management, but does represent valuable knowledge that we should be capturing and managing. I found this gem when I was researching a completely different topic and immediately saw its value to anyone who is faced with consolidating help desks or contact centers. I also enjoyed reading a whitepaper published by Hewlett-Packard titled A Fool With a Tool is Still a Fool because it supports my position that tools without processes are useless.

    Mike is not missing in action - he's swamped with a heavy workload. He should be resurfacing later in the week.



    Friday, March 15, 2002

     

    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

     

    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.



    Wednesday, March 13, 2002

     

    Service is the Game. In today's Notes from the Field entry I discussed IT services and the emerging models that have been designed to standardize and/or add structure to service level management. My focus in that entry was service level management as it related to outsourcing and contracts. Here I'm going to concentrate on more general aspects of service level management, and also discuss the IT Infrastructure Library (ITIL), which is the UK standard that encompasses it.

    Service Foundations. First I want to add to Mike's earlier entries that provided balanced scorecard material. The document titled Balanced Scorecard for IT contains advice and strategy for measuring services provided by IT. Another document that gives a solid foundation to any service level management initiative is Production Environment Engineering, which is a topic near and dear because I spent most of my professional life in production services.

    Chicken or Egg? Do you begin with Service Management Essentials or with SLA Specifications? Neither - it's a trick question. You start with an understanding of the basics, and with a framework, then build out from there.

    Building Blocks. A starting place is Introduction to Service Management, and is reinforced by an example using real service management processes that were implemented by Bangalore Labs.

    Quality and service management go together. Quality Framework for ITIL does an excellent job of explaining the basics of the ITIL, and also uncovers the essential quality ingredients that need to be present in any service management process, regardless of the model used. The flexibility of the ITIL approach is shown in Hewlett-Packard's Service Management Reference Model, which is based on the ITIL approach. You can learn much about how to apply ITIL processes and practices by reading this document.

    As you dig deeper into the ITIL (and you should if you're serious about service management), then you'll find the ITIL glossary to be a handy reference to terminology you'll encounter. If you're involved in business continuity planning, which was raised to a highly visible activity after 11 September, the whitepaper titled Interfacing ITIL Change Management and Contingency Planning shows the close interrelationship between business continuity planning and service level management at a high level, and how specifically the ITIL approach supports BCP.

    A mature look at service level management for advanced practitioners is discussed in Policy-Based IT Service Management.

    Parting Note. I've only just discovered the IT Comfort Reference Model. It's poorly named, in my opinion, because it has nothing to do with ergonomics (which is implied) and everything to do with service management. I only briefly browsed through the site, but it does look interesting and is certainly slanted towards the ITIL.



    Tuesday, March 12, 2002

     

    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).
    4. 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.

     

    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:



    Monday, March 11, 2002

     

    Plan of the Week. I just finished posting my first entry in a series about processes in Notes from the Field. In the next day or so I'll be starting a series about the Tarrani-Zarate Information Technology Management Model, starting with the foundation layer of business imperatives and requirements. That layer and the entries on processes in Notes from the Field complement each other, so if you're interested in one topic, you'll probably be interested in the other.

    Because Mike Sisco's IT Manager Development Series covers many elements of our model I will be reviewing each of his books as I write about the model. The IT Manager Development Series is a 10-book collection of professional guidance that addresses every facet of IT management.

    Full Plates. Linda is starting her Oracle Certified Professional training tomorrow, so I don't expect her to be actively writing here of in Notes from the Field until she settles into the training regimen. My workload has also increased. I've encouraged Kate to take a more active role, and hope she continues to grace these weblogs with her clear writing and extensive knowledge.

    Resource. Until I start posting the entry about business imperatives you may want to explore the documents and links that we have on our Business Strategy and Planning page.



    Sunday, March 10, 2002

     

    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:

    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.

     

    Killing Two Birds. I posted an extensive amount of material earlier today in Notes from the Field about processes. The following documents are about security, but two of them discuss security processes in great detail. In you're interested in developing and implementing security processes you'll find the general material on processes and capability maturity useful.

    The documents:

    • Enterprise Security Policy is a PowerPoint presentation that steps you through the development and implementation of an enterprise-wide security policy. This document is directly related to the process material I posted in Notes from the Field because policies govern processes.
    • Another document that is about process and security is the PowerPoint presentation about how to set up a Security Incident Response Team. This document contains a lot of material about security, as well as policy, process and procedures.
    • Cyber Threats to Critical Infrastructures is for the hard core security practitioner. This document is short on process and rich with technical insights.



    Saturday, March 09, 2002

     

    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.