Archive for the ‘Documentation’ Category

Reverse Engineering

Tuesday, July 10th, 2012

I support several units outside of the Enterprise Data Warehouse to retrieve, process, and export information. Most of this work is done using straight PL/SQL (Oracle’s transactional SQL language). However there are quite a few processes on a platform that we no longer want to support. These processes have a minimum (and I do mean minimum) amount of architectural documentation. This leaves me with the unenviable position of having to reverse engineer these processes and draw up a plan to convert them to a new platform.

Reverse Engineering – The process of discovering the technological principles of a device, object, or system through analysis of its structure, function, and operation.

Just to be clear: The only reason this is necessary is that the original architectural documentation was a) lost, or b) never completed. If the person who originally created the process or someone who understands the process was available to write the architectural documentation, reverse engineering would not be necessary. This, however, is not the case I found myself in.

So…How do you reverse engineer something? Here are the steps I’m using:

  • Get access to the current system.
  • Use current system to create a sandbox area.
    • If a sandbox already exists, ensure that the sandbox has the most up-to-date source code from the production environment.
  • Familiarize yourself with the existing platform: You need just enough knowledge to navigate the environment and read the processes. You don’t need to program it.
  • Start at a very high level and work your way down to the details. Each level that is delved into gives insight and clarity to the next. During this iterative process create the following documents:
    • Diagram of the major items. (These items will get smaller and more detailed the further down the iterative path you get.)
    • Description of the major items.
    • Listing of item’s code elements and locations.
    • Listing of major business rules.
    • Any other information that clarifies the system.
  • Analyze documentation and look for areas for efficiency gains and process streamlining. Modify documentation where appropriate.

Yeah…This is boring and tedious and VERY TIME CONSUMING. Example: My current documentation for the DMExpress jobs I’ve targeted for conversion is just north of 140 pages! Think of it…how much is it costing the company when this type of thing happens?

What it is not is a waste of time. Once completed I can sit down with a group of developers and break down this documentation into Agile stories ready for development. And this is exactly what I plan on doing.

I will return to my regular subjects shortly.

“Technical skill is mastery of complexity, while creativity is mastery of simplicity” – Erik Christopher Zeeman

Tuesday, July 3rd, 2012

In the past I’ve been called technical…Usually in the phrase, “Look, I don’t want you to get to technical in this meeting.” Heck, if I didn’t know any better I would think that was an insult.

But I don’t think I’m that technical. There are many more people a lot more technical than I. I think of myself as procedural….as in, “A standard procedure could remove the complexity of what we are trying to do and make it simpler…and more efficient!”

To wit the situation I’ve seen with turns in the Enterprise Data Warehouse: They are complex…very complex with many rules and exceptions. At least that is how it appears. And, in general, appearance (perception) is reality. This is further complicated by having each developer do their own turn requests, which in turn is complicated by the turnover, especially with the contracted/offshored resources.

So what is the cost of all this complexity?

  • Miscommunications
  • Delays
  • Defects
  • Rework/Resubmissions

It’s like throwing sand in a transfer case! So what is the answer? My proposed solution would be twofold:

  1. Create a living document that consolidates all the turn request processes/knowledge/lessons learned into a single, cohesive standard operating procedure.
    1. Create a logic-branched procedure so that someone could literally ‘walk through’ the process…step by step.
    2. Cover all aspects of a turn: Sign-offs, security requests, document transfers, code file staging, job templates, etc.
    3. Create examples for the most common cases.
  2. Have a turn Subject Matter Expert (and a backup) who is responsible for all turns within a unit.
    1. They would serve as the liaison between the DBA group and the unit doing the work.
    2. They would advise/facilitate all turns.
    3. They would provide quality control and feedback for the procedure outlined above.
    4. They would automate what pieces of the process that can be automated.

And the best part? This is not theory. This is how my old unit operates day in and day out; regular turn or emergency turn. It works, it works well, and has allowed the unit to split out some of their resources to work on other projects (like Mobile Computing!). Gotta love simplicity!

Maturity Models

Thursday, June 28th, 2012

I really appreciate, in general, maturity models. They provide a frame work from which organizations can contemplative and improve, and in doing so provide a healthier environment to work in while becoming more efficient and profitable. Probably the most well-known is the Capability Maturity Model which evolved directly out of the software development process. There are some concerns with models like CMM in certain circles. But if you disregard the ideological hype and consultant-generating/copyrighted/patented materials, you can create a very cohesive structure that can effectively meet the necessary business objectives for a lower cost in a shorter timeframe.

Maturity models outline a framework that provides:

  • A starting point for process improvement.
  • A shared lexicon from which information can be exchanged.
  • A way to define and document processes.
  • A structure for prioritizing actions.
  • A way to measure improvement.

I’m not married to a particular maturity model and the belief that goes with it. Rather I prefer to follow a common sense approach that can fit the organization’s idiosyncrasies. Additionally, following an unofficial model allows an individual to institute changes from the bottom-up rather than the top-down.

When it comes right down to it, process improvement is having a process that can be documented, executed, measured, and then evaluated for improvement. The best way to accomplish this is to automate all the repeatable steps in the process.

When I look toward process improvement, I take the following path:

  1. I take an inventory of all known processes and assess the complexity of possible automation (the Risk) and the resources I could save (the Reward).
  2. I prioritize the inventory list based on the Risk/Reward factor and available/desired tools and resources.
  3. Using the prioritize list as a backlog of projects:
    1. Document and verify the process steps.
    2. Investigate and evaluate possible forms of automation, identifying which parts can be and can’t be automated.
    3. Generate the appropriate design documentation (blueprint) required to automate the process
    4. Develop the automation and supporting process measurements
    5. Test and validate the automation
    6. Integrate the automation into the existing process, updating the process documentation.
  4. Once the process(es) are automated, reports can be generated to evaluate the process, find trouble areas and provide feedback back into the backlog.

We’ll look at more details as we progress…The next entry will discuss the Process Inventory.

“I stand relieved.”

Thursday, June 28th, 2012

In a previous life, I spent countless hours watching gauges, taking logs and answering the bells on an engine order telegraph a couple hundred feet underwater: Life on a submarine can be quite boring. Six hours of every 18 were spent standing watch on the throttles (big chrome wheels on the left). It was boring…very boring…mind-numbing, like watching paint dry boring. And it was one of the most important jobs on the boat, because if you did not pay attention, if you didn’t follow the proper procedure and documentation, if you did not give the proper turnover to your relief then a catastrophic accident could occur. So it was vitally important to give a proper turnover.

I can hear it already, “What’s a turnover?” A turnover in the Navy, what we would call a transition in in Corporate America, is a process by where you provide information to your relief (replacement) for the watch station (position) that you currently hold. Kind of sounds mysterious, but is conceptually quite simple:

  • You outline the current state of the system(s) that you are transitioning.
  • You detail any anomalies that has occurred since you took over (or a sufficient period such that any relevant events can be considered).
  • You review any existing documentation.
  • You review most important standard operating procedures.

Once you have covered this information, you ask, “Is there anything else you wish to cover?” If there are additional questions you answer them. If not, “I stand relieved of the watch.” Sounds easy, but the details can get quite messy. For example, before I moved to the Data Warehouse group I created this transition document that outlined those items my replacement would need to know to be productive:

Application DBA – Transition Plan

  1. Database Server Management
    1. Disk Space Management
      1. CA Tickets
      2. Database Growth Estimation
    2. Performance Monitoring
  2. Database Build Management
    1. Data Refresh
      1. Redgate
        1. SQL Data Compare Projects
        2. SQL Package Projects
      2. Final Builder Project and Schedule
    2. SQL Auto-builds
      1. Final Builder Project and Schedule
    3. TCW Builds
      1. QA Build Process
      2. Prod Build Process
    4. Metadata Environment
      1. DDL-only Build
  3. Turn Process
    1. Pre-Turn Validation
    2. Post-Turn Validation
    3. Damage Control – Turn Gone Wrong
      1. Discovery
      2. Correction
      3. Cleanup
  4. Database Construction
    1. SQL
      1. “Do No Harm” Scripts
      2. True One-shots
    2. SSIS
      1. Construction
      2. Operation
        1. Database Server
        2. App Server
  5. Control/Meta Data/Source Code Management
    1. SQL
      1. TFS Management
    2. SSIS
      1. Construction
      2. Operation & Management
    3. Configuration Data
      1. ORCA Files
      2. CMD Files
      3. CONFIG Files
    4. Control/Meta Data
  6. Database Consultation
    1. Strategy
      1. Technical Roadmap
    2. Tactics
      1. Database Design
      2. Query Optimization
  7. Environmental Management
    1. General Server Health Monitoring and Management
      1. Architecture Database
        1. dbo.SQLPerfMon – Stores the aggregated historical data from the query cache; captured every hour.
    2. Technical Story Creation
      1. General System Improvement
      2. Database Specific Improvement

Environment Management Team – Transition Plan

  1. New FTP Server Migration
    1. FTPNEWPRODSERVER – Production
      1. Replaces FTPPRODSERVER
      2. DNS – FTPProd
    2. FTPNEWTESTSERVER – Lower Environments
      1. Replaces FTPTESTSERVER
      2. DNS – FTPProof, FTPQA, FTPTest, FTPDev
  2. General Monitoring
    1. Messaging
    2. ISO Listener
    3. Process Tracker
  3. Environment CA Ticket Resolution
    1. Research
    2. Procedural Resolution    
  4. Metavante Management
    1. Password Reset
    2. Outage Management

Needless to say that is quite a bit of information….and this is just the outline. Almost all this information was held in a multitude of documents in the document repository. It was necessary to understand all of this information to properly manage the SQL Server environments. Really, this was the MINIMUM NECESSARY INFORMATION to transfer. I could have dumbed it down, but then I’d be doing a disservice to my fellow associate and not leading them toward perfect service.

And that is the crux of this discussion: Leadership….Anyone at any time has the ability, and responsibility, to lead. And it is when you exhibit leadership that everyone benefits; management, customers, fellow associates and shareholders.

Many lose site that leadership is an exhibited attribute of a person, not the authority of a position. They similarly confuse the action of leading with the act of dictating. This can’t be further from the truth. In the simplest term a leader is someone who is followed by others. So if you are responsible for handing off a system(s) to another person (group, unit, etc.) you are a leader…Act accordingly.

Accountability and the Mystery of the Missing Artifacts

Thursday, June 14th, 2012

It took me a few months after I first arrived to understand the entire IT lexicon at my new company. It took a little longer to understand the necessary artifacts and constructs required for proper project management. These are the necessary items to understand to properly fit into this company’s IT culture. These items produce a common ‘language’ from which communication and action work together to accomplish a set of goals. But what happens when the ‘language’ is missing?

Whether you participate in SDLC or Agile, there are a minimum set of artifacts that needs to be created and used to effectively communicate the project and ensure that it was completely correctly. These artifacts are important for several reasons:

  • Establishment of a baseline for understanding the goals and objectives of the project.
  • Creation of common definitions vital to effective communication between project participants.
  • Outlines what is, and is not, expected of each participant.
  • Provides measurements for success.

There are others of course, but from a project management standpoint having these items covered would go a long way to instituting a can-do environment. And it is can-do environments that consistently build the applications that a company needs to stay competitive and profitable….Which is in everyone interest: Executive, manager, associate, customer and shareholder.

So when artifacts are missing they jeopardize the successful completion of projects necessary for a company to stay competitive and profitable. This is an accountability issue. Even if a well establish standard is in place, if the project participants do not ensure that the proper artifacts are being produced, the project team is not being accountable:

1. (of a person, organization, or institution) Required or expected to justify actions or decisions; responsible.
2. Explicable; understandable

I will suggest that any time the prescribed artifacts are in absentia then some accountability is missing. And when accountability is missing, our path toward competitiveness and profitability will start to suffer. So it is in the interest of each participant to ensure that accountability is maintained. In doing so, you help the project and your fellow associates to achieve the company’s goals.

Techniques that can be used to ensure accountability for artifact creation:

  • Organization Level
    • Implementation of standard processes and auditing functions for project artifacts.
    • Ongoing associate training and engagement.
    • Programs for the team recognition of proper project management processes: Recognize benefit of associate accountability.
    • Remedial training/interventions for projects not following standard processes: Recognize harm of a lack of accountability.
    • Active monitor of projects, from inception to completion.
  • Project Level
    • Effective feedback from the project manager to participants.
    • Maintain effective communication to all project participants and appropriate organizational entities.
    • Participant enrollment and proper delegation of artifact creation.
    • Employ appropriate process and tracking features for selected methodology: Seek out necessary assistance.
  • Peer Level
    • Work within the team dynamic to identify missing artifacts.
    • Volunteer to assist in artifact creation.
    • Provide feedback using positive and enrolling communication.

I’m sure there are quite a few more techniques that we could add; these are but a few ideas to establish and maintain a culture of accountability.

So, what artifacts are missing from your project(s)? What are you doing to ensure accountability? What is that missing accountability costing?

Chalk Talk

Thursday, June 7th, 2012

When I start the process of understanding a system I’m about to automate, I do three things:

  1. I write documentation.
  2. I draw diagrams.
  3. I get other’s feedback.

Not to make this overly simplistic, but that is all that is required to get a detailed understanding of any system you need to automate. The written artifacts become the basis for system understanding. The feedback provides clarity and insight of system idiosyncrasies. Through discussions with team members, owners, and users, I will revise these artifacts many times until I have documents that allow me to fully understand and automate the process.

In a phrase, you have to practice chalk talk. Just as a coach will draw the tactics of a play on a chalkboard, you and your team must sit around the whiteboard and postulate what is possible, what is probable, and what the final product will look like. This usually is not done in a single session, but is a continuous process of research, discovery, and experimentation (even if it is just thought experimentation).

For example, when I took over as the Application DBA for the unit it was apparent that I had no idea what my predecessors did and how they controlled the chaos. We had five environments, not all of which were consistent and may or may not have the latest code base. Each code fragment (SQL object) was migrated separately; it wasn’t always put on the official build list (didn’t make sense to me at all). Each change required another script which in turn caused the same object to be modified in the same build, usually to detrimental effect. I could go on (and on…and on ….and on….).

Our goal was to proceduralize the entire database environment management process, automating as much as we could, and initiate process improvement. When I started initially documenting the loose process they used, I started to formulate the below conceptual automate environments process.

It took multiple iterations and many discussions with my team mates in the Environment Team to reach this point, but it provided a solid picture from which we could plan the automated build framework. We also had detailed discussion with the development groups and management. From there we:

  • Investigated corporate and department policy and procedural issues.
  • Talked to other groups to see how they manage database environments.
  • Researched available tools and started procurement processes when necessary.
  • Initiated experiments to see what worked and what didn’t.

After a period of several weeks, a picture emerged that looks like this…



From this picture we targeted three main items that, when done, would significantly reduce the time/resources necessary and lower the incidence of defects.

  1. Automate SQL Builds
  2. Automate TCW Script Preparation
  3. Automate Data Refreshes

Next, we’ll detail each one of these items and discuss how they were automated and review actual results.

You can’t automate what you can’t understand.

Wednesday, June 6th, 2012

When I first arrived at my current company I was placed into a group of architects that worked on spending accounts. My manager at the time called me into his office: “Hey…Can you be our DBA?” Well, being that I just arrived I couldn’t really say no.

That is when the trouble started! The group already had two DBA’s: They managed the environment and you didn’t ask questions. As I delved into the job, I found a few issues:

  • The DBA’s didn’t use process or procedure: Everything was on the fly.
  • The various environments did not match: Not the data and not the code.
  • Turns were an exercise in terror: You never knew what was going to break, but something would.
  • Environments could be used interchangeably. If they needed to move a production file to a vendor, a QA box would do as well as a production box.
  • Nothing, I MEAN NOTHING, was written down. The DBA’s managed though tribal knowledge.
  • Application metadata was spread everywhere. On occasions it would get loose and a cancellation email from the QA box would be sent to a customer…to great embarrassment.
  • We were the only unit that used both replication and clustered servers in the company. And to top it off, replication was transactional/real-time. I almost felt special. Worst case scenario? Imagine working on a 6 hour snapshot and have it fail on hour 5…During a Production Turn…at 3am! (Yeah…that happened!)

Needless to say, this was not the most advantageous place from which to start. In short order both DBA’s were gone and I was alone. Now I did get a transfer of knowledge, but just enough to scare the heck out of me. And to add gas to the fire we were moving to Agile/Scrum. I had to act and act fast! And the strategy…Automate everything!

Steps to Automating Anything

  1. Understand the Process – Work though in your mind what the process is doing. Talk to owners and users, read available information, research like processes. Understand the whole process: You can’t automate what you can’t understand.
  2. Document the Process – Keep a written record to refer back to during the rest of the process. Information not committed to writing will slowly, but surely, be lost over time. And some automation efforts take quite a bit of time.
  3. Research the Process – Based on the documented process, research and acquire the necessary tools and determine the tactics necessary for automating the process.
  4. Breakdown the Process – Based on the research, break the process into related steps of the process (work units) that can be automated using the acquired tools.
  5. Automate the Process – Take each work unit and with the selected tool/technology, automate it. This becomes an element of the process.
  6. Integrate the Process – As work units are completed, integrate them back into the existing process. In this way you can immediately benefit from the effort.

It’s that easy…in theory. And with a little practice it can be quite easy and have a big payoff. How well does this work in the real world? We’ll discover this in my next automation post.

It’s not useful if it’s not readable!

Wednesday, June 6th, 2012

Revisiting my list of what makes the most effective documentation, we finally arrive at readability. Document readability is a big issue when dealing with any technical documentation. Not because the people don’t know the subject; they do. It’s not like the people aren’t smart; they are. I’ve always thought of it as an issue of skill and practice. It takes years of practice and skill building to be an effective coder, why wouldn’t the same apply to writing effective documentation?

So, what do I mean by readability? What makes a document readable? Again I refer to Ol’ Webster…

  1. read.a.ble/rē’də-bəl/Adjective

    1. Easily read; legible: a readable typeface.

    2. Pleasurable or interesting to read: a readable story.

Documents that are more readable have a higher chance of actually being used, and hence more useful. There are many ways to judge how readable a document is, and there are even formulas that will actually calculate a qualitative measure or readability. I don’t go to that extent, especially with technical documentation, but I definitely keep the espoused concepts in mind.

When I write documentation, I concentrate on these aspects: the Visual, the Written, and the Progression.

Visual Aspects

  • White Space – Don’t clutter up the page so the eye can’t follow what’s going on.
  • Typeface – Does the font look appropriate, locks our eyes to the document and prevents eye-strain?
  • Pictures/Diagrams – Always worth a thousand (or so) words.
  • Lists/Tables – Helps group information so that the brain can easily identify and filter it.

Written Aspects

  • Varied Sentence Structure – Mixed sentence structure forces the user to do a little exercise and concentrate on the subject matter. Otherwise it could be Sleepville for the reader.
  • Define Words/Phrases – Uncommon phrases, abbreviations and jargon can quickly lose the audience. Include the audience by explaining what things mean: Don’t assume the audience has the same insider information or background you do.
  • Step-by-step Procedures – Technical documentation, by its nature, revolves around procedures and processes. Proven, repeatable step-by-step guides can be the most cost effective way to capture corporate knowledge and pass it on. This pays dividends in the long run!

Progression Aspects

  • Generic to Specific Detail– The first few pages of the document should be written for management. And as the document progresses, more and more details is presented. The general progression I like to follow is:

    Executive Summary -> Management Overview -> Architectural Design  -> User Procedures  

  • Easy to Difficult Concepts – Each section of the document, regardless of the purpose, should start with the easy, big-picture concepts and slowly gather more complexity. Jumping right into the meat of the detail could easily leave the audience wondering what is being discussed.

As you write the documentation the organization needs to retain knowledge, a couple of….

Things to Avoid

  • Complicated Phraseology

    “Moving forward, we will leverage our core competencies in emergent adjacencies to generate adaptable business revenues.”

    Man; that’s awfully complicated! Can you imagine a whole document written this way?!?? If I were to put this idea in a readable format it would look something like…

    “We will start searching for opportunities outside our normal business.”

    Basically says the same thing…And I don’t have brain damage.

  • Overly Busy Graphs/Diagrams

     I helped create this mess and can’t tell what the heck it says!?!??!!


    Sometimes less is more…You could easily lose half of the content and still communicate the same ideas.

    Well, it’s obvious that some of the items discussed here need a more detailed treatment, so I will add them to the list of my planned postings. Until then remember:

    “The spoken word is captured by Time; the written word transcends Time.”

“It might be a little disorganized.”

Tuesday, June 5th, 2012

One of my pet peeves with most in house documentation is its organization: There is isn’t any. And organization is vital for documentation to be effective. Without it the reader is left randomly bopping around the content trying to find their needle in the haystack. So, what does it mean to be organized?

  1. or·gan·ized/ˈôrgəˌnīzd/Adjective

    1. Arranged in a systematic way, esp. on a large scale.

    2. Having one’s affairs in order so as to deal with them efficiently.

Although this definition may be accurate, it is not specific enough in dealing with the issue at hand; effective documentation. I associate organized documentation with the following criteria:

  • It has a table of contents and/or index — You can find what you are looking for.
  • It answers the what, why, when, who, and how of system construction and operation — It answers specific questions.
  • It provides background business information — It describes within a business context.
    • Explanation of acronyms,
    • Summary of system interactions,
    • Contact information for major players,
    • History (if any).
  • It provides background technical information: — It describes the technical boundaries.
    • Overview of technical architecture;
    • Details of operating systems, server connections, and file locations.
  • It separates the business aspects from the technical details. – It removes convolution between business processes and their automation.
  • It can be used by all parties involved with the system, regardless of responsibility or background. – It establishes common ground from which to solve problems.

Now these are not absolutes but my own bias. However, I think any document organized in this fashion would be the start of a good effort and provided dividends later. I personally like the following general outline for my documents:

  1. Cover Page
  2. Revision History Page
  3. Table of Contents
  4. Summary Area
  5. Background Information
  6. Business Area
  7. Technical Architecture
  8. Standard Operating Procedures
  9. General Notes
  10. Idiosyncrasies*
  11. Index

* – If you don’t think your system has idiosyncrasies you haven’t delved into it deep enough.

It covers the items from the previous list and it starts with very large concepts and digs in deeper as you get further in. I can scan the table of contents to find the general area I find important or I can search the index for the specific item I want to know about. If I read the whole thing, I should have a pretty general understanding of the business process involved and how it was automated.

Keep in mind that organization is always an on-going event. As the system changes, so does the documentations structure and content. As the system lives, so does its documentation.

Once a document is organized, it may still not be readable….Which is what we’ll cover next.

“Well, it sounds good on paper….”

Monday, June 4th, 2012

I previously outlined a number of items that I feel are required for documentation to be effective. The first on that list was that documentation must be easily accessible. Documentation without accessibility is the same as no documentation at all.

Previous to the digital age, the vendor-provided hardbound manual and ring binder full of three-hole punched paper was what you had to have. They were cumbersome, clumsy, and had a tendency to attract coffee stains. But what is meant by accessible?

  1. ac·ces·si·ble/akˈsesəbəl/Adjective

    1. (of a place) Able to be reached or entered.

    2. (of an object, service, or facility) Able to be easily obtained or used.


How do we make documentation ‘easily obtained’? It may seem to be a no brainer, but I’m always surprised by how much information is NOT accessible. For example, how do you properly fill out an EAPM Peer Review? I’m pretty sure that it is written down somewhere. As an experiment, see how long it takes you to find the actual document. Go ahead, I’ll wait……

The Information Revolution has given way to instantaneous access to searchable information online. Quite frankly, I do not see how anybody got anything done in a reasonable amount of time without the ability to access the latest documentation on a vendor’s API. Heck, Google is the best friend of any tech worker who needs to solve a problem.

However, the search engine approach has a few issues to internal corporate networks:

  1. The information must be visible to the search engine. (I’m pretty sure that Google is not crawling around our internal network.)
  2. Control of sensitive information (Corporate Security).
  3. No internal search engine initiative.

Humana seems to use a few approaches to capture and make information accessible. eRoom is a great approach to consolidate projects, products, and area information in an organization fashion. Also, I’ve seen the rise of wiki-like sites internally (Sharepoint) to disseminate that vital information in the last few years. Some use documents on shared drives. (Talk about old fashioned!) Most business units use a combination of all three of these approaches.

There are some barriers with these approaches:

  1. Some areas have restricted access. This is perfectly acceptable and should be encouraged in some instances due to the sensitive nature of the information. But how do I share techniques across the enterprise?
  2. Not all approaches are searchable from a single point. For a thorough search of information, you would need to try multiple techniques across multiple platforms. An internal search engine initiate would be an overhead expense but could really pay dividends.
  3. Redundant information at multiple points with inconsistent updates. This can cause inaccurate or contradictory information to be propagated…Not an optimal solution. When a single, integrated and searchable platform is promoted a surge of micro-capabilities could explode across the enterprise.

Whichever approach you choose, ensure that your unit has a single point of entry for documentation platforms. That way you can promote a single point of information accessibility to the new associates.

In the next installment we look at information organization: How can I make what I write findable?