The Technical Communication Framework (TECOF)

In this third episode of my series about lessons learned as an ICT Architect, I will explore the possibilities of reusing the general ideas behind the TOGAF framework as a starting point for a technical communicators framework.

ICT Architects use frameworks like TOGAF as a detailed method and set of tools for developing an enterprise architecture. Every component in this method delivers a visible addition to the end product.

TOGAF 9 Components
The TOGAF 9 framework for Enterprise Architecture consists of 8 components:
  1. Architecture Vision: this describes in scenarios how the new solution or application will meet the business goals and strategic objectives and address the stakeholder concerns when implemented.
  2. Business Architecture: models that describe how the high-level business requirements (from the Architecture Vision) can be mapped to actors, roles, business functions, business processes and services.
  3. Information and Application Architecture: this focusses on identifying and defining the relevant applications and data.
  4. Technology Architecture: describes the technical infrastructure
  5. Opportunities and Solutions: this concentrates on how the architecture will be implemented
  6. Migration Planning: creating a viable implementation and migration plan.
  7. Implementation Governance: this establishes the connection between the architecture and implementation organization.
  8. Architecture Change Management: monitoring governance requests, new developments and changes in the business environment.
A Framework for Technical Communicators
When looking at the TOGAF Framework for ICT Architecture / Enterprise Architecture I couldn't help but noticing the similarities between documenting an enterprise architecture and writing user documentation. Surely there are differences: the audience, the level of detail in the information, the overall governance. But the framework could be easily modified to serve as a basic framework for technical writing:
  1. Goals and principles: this describes in scenarios how the new product or solution will meet the business goals and strategic objectives and address the stakeholder concerns when implemented.
  2. Actors, roles and processes: models that describe how the goals and principles of the product or solution can be mapped to actors (audiences), roles, functions and tasks.
  3. Functions: this focusses on identifying and defining the relevant components and functions in the product or solution that you are describing.
  4. Technology: describes the technical details of the product or solution.
  5. Solutions and applications: this describes in scenarios how the defined actors (the audiences) can benefit most from the possibilities and features of the product or solution.
  6. Migration: describes the necessary steps to migrate existing data to the new product or solution (if applicable).
  7. Implementation: this describes how the new product or solution can be embedded within an organization or - with consumer products - how the product can be launched successfully.
  8. Change Management: monitoring new developments and changes in the product or solution and implement them in the documentation.
Although I am aware of the fact that this framework will not be 100% useful for every documentation project and for every technical writer, I think it gives us a good starting point for an overall method and set of tools that can help us in our daily work.

TECOF
Every framework needs a name, so I might as well choose one to start with. What about: The Technical Communication Framework (TECOF)? Suggestions for a (better) name are welcome: don't hesitate to use the comment box to drop your suggestions for an alternative name.

It would also be nice to see organizations like STC and/or ISTC adopting this framework and promoting it into their community for further development. To make it a standard framework the development and usage should not be restricted to any society, institute or company.

A structured approach to audience and task analysis
I started this series of blogs with the statement that we - as technical communicators - can learn from ICT Architects. I have already showed the similarities in the framework, now it is time to go into detail. Next time we will look at a structured approach to audience and task analysis.
I will explain how we can use a standard notation method - based on the Archimate standard for ICT Architecture - to describe our audiences and their tasks in terms of actors, roles and processes.

Comments

Post a Comment

Popular posts from this blog

Using the Golden Circle Model in your resume and LinkedIn profile

Image
The last three years I worked as a (senior) business consultant and information architect at software company Be Informed in Apeldoorn, the Netherlands. We worked on an amazing product, a ground breaking model-driven business process platform. And my job was to explain the possibilities of this platform to various audiences. The Be Free program, which I launched in September 2013 was a marketing campaign that targeted on making a wider group of people familiar with the product. The campaign was a great success and I had the feeling that I was really helping people in proving their ideas to their customers and managers. But the interaction was on-line and from a distance, never close enough to really understand their business goals and issues.  The sudden end of my contract with Be Informed, forced me to rethink my professional goals and ambitions. What do I really want? Do I want to be a product marketer, focused on 'pushing' a product? Or do I want to be a business cons
Read more

Improve Product and Brand engagement through smart documentation - A White Paper about the challenge of creating user-centric documentation

Image
For most product manufacturers, delivering adequate documentation is a constant challenge. The increasing complexity of products and the stricter regulations for product documentation often lead to extensive documentation sets with 500+ pages manuals on-line or in print. The question is: how effective is all this documentation? Smart, user-centric documentation Users can be overwhelmed by long, jargon-loaded user manuals, and frustrated by a lack of clear answers. When customers don’t find a solution, blame inevitably falls on the product and the company. Bad documentation - incomplete, unclear, out of date - creates a negative engagement with products and brands. Figure 1. Smarter documentation asks users what they need to know Smart documentation leads users to success and satisfaction. These are the users who share their positive experience with family and friends, and convince them to become customers in turn. Using semantic technology, we can create the smart document
Read more

Laying the foundation for an effective article

Image
In this series of articles you can follow my process in writing a new article on Robotics. In the  first episode  I explained my approach towards writing, the  second article  focussed on setting the goal, choosing an audience and finding the right approach. Now that we have a clear vision on goal, audience and approach, it is time to start setting up the structure. Writing requires a structured approach Writing is all about structuring your thoughts. And although this is a process that most of us do in a more implicit way, it sometimes helps - and is actually best practice - to write down your structure on a very high level. The goal of my article is to change the opinion of the reader towards accepting Robotics as a something that brings value to a business and motivates employees, rather than being limited to reducing FTE. So the structure of my article should be build up around the motives used to build up this case. As I want my article to be short and sharp, I don't
Read more