Improving the effectiveness of information

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 : 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. 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. Information and Application Architecture: this focusses on identifying

In the previous post I mentioned that creating user-oriented documentation requires an understanding of the audience and its tasks and processes. The trick has always been that it is hard to explain the days or weeks spend on audience and task analysis, while it doesn't deliver a visible contribution to our work from the start. There also isn't a real method or framework - that we can refer to - that demands the activities and deliverables that come with an audience and task analysis. In this a rea we can learn from ICT Architects , especially when it comes to: Usage of a common and widely accepted framework like DYA or TOGAF Development of standard notation methods, like Archimate for creating models of the different architectural layers of a solution Visibility of all activities and models in the end result. Standards versus an Open Framework A fact is that there are standards for documentation, but they are more or less focused on the quality of the end product and not on t

Just like technical writers, ICT Architects face the challenge to describe platforms, systems and solutions from a business point of view. But where there seems to lack a standard for technical writers, ICT Architects have the luxury of having frameworks like TOGAF and notation methods like Archimate to help them do their work. Function-oriented versus user-oriented documentation No doubt that there are still technical writers out there who don't agree with me, but to me it is clear that a user-oriented approach to documentation is the way to go. So if I am talking about making documentation from a business point of view, I am in fact talking about creating a documentation solution that fits the user's needs. Whether or not this is a printed book, a website, embedded on-line help or a combination of all these, doesn't make a difference, as long as the presentation form is chosen from a user's point of view. Where to start? We all know the feeling when we accept a new pr

After working for 2,5 years as Information Advisor and ICT Architect, I had the opportunity to return to the things that I do best: writing, structuring information (modelling) and designing knowledge solutions. Within a few weeks I will start as Knowledge Analyst / Technical Writer at Be Informed in Apeldoorn, the Netherlands. Be Informed and Technical Communication Be Informed is an internationally operating, independent software vendor. I have worked with them from early 2006 until the end of 2008, as an external contractor. The Be Informed business process platform supports administrative processes, that are becoming increasingly knowledge-intensive. The role of technical documentation in this process should not be underestimated. What if we could provide our users with exactly the information they need to perform their task at exactly the right moment. The information could come from various sources (manuals, websites, on-line help) and could involve combinations of software doc