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

Writing effective articles

Image
I am a writer. I have been all my life and I wouldn’t know what to do if I would ever lose this talent. I have been writing about many topics: from welding procedures and high tech greenhouse technology to  software implementations and the use of semantic technology.  Apart from the writing I enjoy digging into these topics and finding out how things really work and what the benefits are of these new technologies or approaches. But is a talent for writing in combination with an interesting topic enough to form the basis for a successful and effective article? Or do we need more? In this series of blog posts I will explore the criteria for a successful article, not necessarily providing you with a fix set of rules but rather focusing on best practices, lessons learned and examples from my own work. On the cover of a magazine One example from my own work. In 2008 I wrote an article called “The Flexible Intranet” about using semantic technology to create smarter Intranet sites...
Read more