Hub Manual Template

Document Sample
Hub Manual Template Powered By Docstoc
					                          Bring Order to the
                               Process


Best Management Practices for Lotus Notes




                  By Chris Doig
            IT Management Consultant
                    Outline
•   Start with a little philosophy
•   Where are we going?
•   Why do we want to go there?
•   How do we get there?
•   We start at a high level, and then drill
    down to details.
         A little philosophy...
• Get right down to the bottom. (Axioms)
• Always ask Why?
• If the reason makes no sense, then don't
  do it!
• Be skeptical; demand proof.
     • Read “Flawed Advice & the Management Trap” by
       Chris Argys.
       Where are we going?
• Start with your values.
• From values derive mission(s).
• Goals (and projects, tasks) are guided by
  the mission.
        Missions and Goals
• A mission has direction, but not
  magnitude.
• A mission can never be achieved, except
  in a trivial sense.
• A goal (or project or task) is always
  achievable and measurable.
    The Mission of a well run IT
      Organization is to be...
• Effective - Satisfies customer and business
  needs.
  – Efficient: fast, cost contained & successful.
  – Able to set realistic customer expectations.
• Proactive, not reactive.
  – Builds a sustainable and extendable
    information architecture.
• An enjoyable place to work.
  The Biggest Challenge for IT
Dr Paul Horn, Senior VP of IBM Research:
• “The obstacle is complexity.
• Dealing with [complexity] is the single most
  important challenge facing the IT industry.”

   We are limited by the complexity of our
                  creations.
New / Maintenance Work Ratio
Why do we use Notes, and not
      J2EE, .Net etc?

     Notes contains the complexity.

With Notes you get 80% of the result with
         only 20% of the cost…

       …and only 20% of the risk.
    How do you manage Notes?
•   Implement standards.
•   Documentation.
•   Manage change.
•   Implement Project Management.
•   System Administration.
    – As a whole. Don't split development and admin at
      the manager level.
    – Employ a manager who has a deep understanding
      of and a passion for the technology.
  The Definition of a Standard
Merriman Webster Online defines a standard
  as….
• Something established by authority,
  custom or general consent as a model or
  example.
• In the software world this amounts to an
  agreed upon solution to a recurring
  problem.
                 Standards
• If it isn't written down, its not a standard!
• If it is written down…
  – It can be managed.
  – People can be held accountable.
  – It doesn't “drift” with time.
  – New people get up to speed more rapidly.
  Why do we want Standards?
If we implement standards we expect to see
   the following:
• Efficiency – more output per person
• Time reduced – faster project turn around
• Maintainability – systems that are easier to
   manage.
• Reliability - fewer bugs in the code.
   What makes up a standard?
• Standard - Title
• Purpose - what the standard is supposed to
  achieve, and why it exists.
• Scope – where the standard applies, and any
  exceptions.
• Benefits – what happens when the standard is
  followed.
• Details – How the standard is implemented, e.g.
  code samples, diagrams
• Comments
   Standards Examples: The User
             Interface
Standard: The Default user Interface Framework.

Purpose: To define one standard UI framework for initializing
  new databases.

Scope: Applies to all general purpose “user facing” databases.

Benefits:
   ●   Reduced development time.
   ●   Reduced end user training.

Detail: (Description of standard with examples…)
Standard UI Example
   Standards Examples: Naming
           Conventions
• Variables in code, field names
• Coding practices
• On disk folder structure
• Database names & version numbers
• Template names
With the right naming conventions you can
  save hours of work on any project. I'll show
  you how shortly.
        Standards Examples: Using
               names fields
Standard: In Notes “people” name fields must always be stored in a names
   field, and never in text.

Purpose: To define one consistent way of using people names in Notes
  databases.

Scope: Applies to all names fields that store names. Does not apply to
  “computed for display” fields that only display names.

Benefits:
    ●   When all fields use the same format, names are easy to compare.
    ●   The AdminP process manages names fields.

Comments: Names can be displayed in any format.
   Standard Example: Document
    your server folder structure
• Most “immature” Notes organizations have a
  chaotic folder structure on servers.
• Server folder structure must be tightly controlled
  which makes management much easier.
   –   Same folder structure on every server, e.g.
   –   All production goes in the “Live” folder.
   –   All development into “Dev\Projects\ProjectName”
   –   Etc.
  How do you develop standards?
• Write them down. Anything reasonable is a
  starting point.
• Encourage (Demand!) participation from the
  team. Anybody can propose improvements,
  exceptions etc.
• Develop a process for improving standards, .e.g.
  “Standard Change Proposal” doc, a response
  doc to a standard.
• All developers & admins are held accountable to
  standards.
• A continuous process, never complete.
          Documentation
• Standards & procedures
• User manuals
• Developer notes
      Project Documentation
What do you use to document standards?
  Choices range from...
• Paper based systems at the low end
• High end systems like Domino.Doc and
  Documentum.
       Filing System Analogy
• High end systems like libraries.
• Notes database level systems like filing
  cabinets.
• Both are important, but there are many
  more filing cabinets than libraries.
      Documenting with Notes
• A high end system is not required - Notes is an
  excellent documentation tool.
• Even if there is a “high end” system, there are
  always document repositories “on the edge”.
• Very important to realize most IT documentation
  doesn’t fit the “word processor file” model.
• Rich text fields are very powerful: easy to work
  with images, tables etc.
• Sametime enabled documentation reaches new
  heights of collaboration.
      Documenting Applications
• For corporate software development, documentation is a
  collaborative effort.
• Capture development documentation while development
  is being done. Also capture tester & user input.
• Use Notes database for documentation, and include
  collaboration with it. e.g. Like a wiki. Anybody can add
  comments to a page.
• Each page has an owner. When comments are added,
  owner is emailed.
• Rough, not finished: a few notes up front save hours later.
       Change Management
The Software Management Paradox:
• Because software is so easy to change, it
  is so hard to manage.
• This is why a Notes environment is so hard
  to manage – because it is so easy to
  change.
• Change management applies to
  EVERYTHING, not just code.
 How do you manage change?
You make change harder!
To control change you must...
• Restrict access – control who can do what.
• Implement standards – so people make
  consistent changes.
• Implement audit trails – so you can see
  who did what, when and why.
 Corporate Software Development
Not the same as commercial software
  development…
• Usually a few large & many small projects.
• Small budgets, few frills.
• Little in the way of support staff.
• Much closer to the customer.
• Requires a collaborative approach to
  development.
 Software Project Management
• Notes development is usually many small
  projects.
• Manage these projects in a database.
• Consider IT reps as an interface between
  IT and business units.
• Use frameworks or roadmaps
  – CMM (Capability Maturity Model)
  – ITIL (IT Infrastructure Library)
    The Factors in Software Project
            Management
•   Scope
•   Resources
•   Time
•   Quality

You can never manage all four.
  Actively Manage Project Risk
• Explicitly consider project risk.
• Add only one risk factor at a time, e.g. On any project
  only one of:
   –   New technology
   –   New developer
   –   New customer
   –   Untested architectural approach
   –   Critical new project (vs maintenance)
   –   New platform (SW, OS or hardware)
   –   Budget, Requirements, Regulatory
• Consider worse case scenarios. Are they acceptable? If
  not, put in contingency plans.
   Actively Reduce Complexity
• When deciding between options, strive for
  the simplest.
• Use loosely coupled systems.
• Write easily maintainable code, not highly
  optimized code.
• Use script libraries, not copy & paste.
• Use design inheritance.
    Project Management Database
• All project info in one place
     – Requirement specs
     – Bugs
     – Design specs
• Worth using Notes because it integrates so well.
• Integrate with Sametime for extra value.
• Track developers assigned to projects, and project status.
• Track owners and other interested people. Automatically
  email them when new version is released.
• Slice & dice project management DB.
• Prioritize your projects. Get realistic estimates of your
  workload.
The Development Work Flow
   Requirements Management
• Every application must have a sponsor.
  – ONE person from the customer is the final owner
    of every application.
  – Customer MUST commit significant resources to
    project, e.g. “good” person several hours/week.
• Manage requirements: one requirements spec,
  complete with audit trail.
  – Keep requirement specs, discussions, email etc in
    Project Manager DB.
  – Scope creep is the killer. Put it in the next version.
  – Avoid requirements by mail – a sure path to hell.
                           Design
• Capture design requirements in project manager.
   – All design requirements traceable back to request, bug or IT
     standard.
   – Capture the reasons why design decisions were made.
   – Design must be approved before coding starts.
• Use the built in Notes features: don’t reinvent the wheel.
• Re-use designs & code
   – Templates: e.g. for user help
   – Multiple inheritance from pre built components, e.g. audit trail
• Simplest design is usually the best.
• Extreme Programming (XP) model works well for most
  Notes projects.
   – Light, upfront design.
   – Frequent, small releases
                         Coding
• Have design signed off by manager before coding starts.
• All code traceable back to requirements.
• Avoid fancy / optimized code.
   – Simplest code is usually the best.
   – Avoid premature code optimization.
   – Code for reduced maintenance.
• Developers MUST use CIAO (people make mistakes!)
• Capture documentation as code is developed.
• Another Standards example: Comment headers in all
  script explain each procedure.
Example: Script Header
            Reusing Code
• Templates are a very powerful way of
  reusing code.
• Use multiple template inheritance for even
  more return.
• Use tool like Teamstudio Design Manager
  to initialize every new database with the
  standard UI.
• Minimize rewrites: Refactor often to reduce
  future maintenance costs (XP)
      Refactoring Code:
Why it makes Economic Sense
   Configuration Management
• Essential. Use CIAO – it works.
• Modify CIAO log to show design history.
• Use CIAO log to capture reasons for
  changes – prefix field names with $CIAO.
• Every design element change must be
  linked to one or more design requirement.
• Do not put code into configuration docs,
  because it is then outside CIAO.
Example: Custom CIAO Log
    The Importance of Testing
Corporate development is NOT the same as
  commercial development.
• You will never have the resources of
  commercial development.
• You are a lot closer to your customers than
  commercial development.
Testing validates the customer & design
  requirements have been met.
                  Testing
• Developer writes test plan.
  – Ensure a test for every design requirement.
  – Consider developing test library.
• Another developer tests.
• Automated testing against corporate
  standards.
• Database owner approves production
  release.
            Phased Testing
• Used for corporate wide roll outs, e.g.
  Changes to the mail template
• Create 2 test groups
  – The Notes team – the first to test a new
    template
  – The IT team – the 2nd to test a new template
  – If you have over 10k users I would create a
    3rd test group of real users.
        Moving to production
• Only the Notes manager has the authority
  to release to production.
  – A manual step is required
  – Move a template (not database) after the first
    release.
• Documented procedure to be followed.
• Security: Sign database with corporate ID.
• Can be automated.
Example: Moving to Production
1. Development DB, e.g. title is: Docmaster R4
   DEV.
2. Use CIAO to create DB version in \Test folder.
3. Set Master Template property to DB name
   (e.g. “DocMaster R4 DEV”)
4. Refresh test DB and test.
5. After successful test, refresh master template
   on hub server (manual step)
6. All production inherits design from master
   template.
    Your Customers - Your User
           Community
• Collaborate with your customers…
  – Capture their comments in your app
    documentation.
• Training is more important than you
  realize.
• Sell your services.
• Identify and work with opinion leaders.
       Managing Developers
• Disciplined programmers who enjoy their
  job produce more.
• Get people to enjoy their job. Start with
  “Peopleware” by Tom De Marco and Tim
  Lister.
  – Windows and daylight
  – Quiet environment
  – Consider part time work from home
  – Get them the tools they need.
  – Minimize interruptions.
             Managing Production:
             Notes Administration
• To manage development, you must also manage admin.
• Audit trails of changes to environment.
    – Especially the NAB.
•   Documented procedures for making changes.
•   Developers have only “normal” access to production.
•   User hub & spoke replication.
•   Consider splitting mail from apps.
•   Up your reliability: cluster production servers.
•   You must have a separate development server.
    – All development in ONE place.
    – A server crash does not take production down.
    – You don’t need a separate dev domain.
               Summary
• Notes management is a rich, deep subject
  with many opportunities for results.
• These ideas are a framework for creating
  an effective, proactive approach to Notes
  Management.
          The End
For more information see my blog:

          chrisdoig.net

      You can reach me at:

  Email: chrisdoig@yahoo.com
      Cell: (760) 470-2011
                   References
•Flawed Advice & the Management Trap by Chris Argys.

•Dr Paul Horn, senior VP, IBM Research on Autonomic
Computing: Page2: The obstacle is complexity. Dealing
with it is the single most important challenge facing the I/T
industry.
   http://www-03.ibm.com/autonomic/pdfs/autonomic_computing.pdf

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:11
posted:6/22/2011
language:English
pages:53
Description: Hub Manual Template document sample