Improving the effectiveness of information

"In engineering , a requirement is a singular documented physical and functional need that a particular product or service must be or perform. It is most commonly used in a formal sense in systems engineering , software engineering , or enterprise engineering . It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system for it to have value and utility to a user." Source: Wikipedia During the Building Business Capabilities conference 2012 in Fort Lauderdale, we are going to develop a working model-driven business application, based on the input provided by the audience. And although this will be in a "lab" situation, we want to stay as close to a real life situation as possible. And then working with requirements is an essential element. Both requirements and the Be Informed modeling artifacts (models, profiles, custom meta models) are aimed at the same goal: allowing the stakeholders of the system to ...

Imagine working at the customer support center of a bank or insurance company, responsible for providing accurate, complete and reliable information to customers. How can you guarantee that the information provided to your customer is enough to prevent possible risks? And, when things have turned out wrong, how can you prove and defend your recommended advice afterwards.  Now imagine you are the manager of the helpdesk: for certain your information needs will be completely different. What you don’t want is another set of manuals, or an additional knowledge base or website:   you want the required information available as precise as possible and at the right moment. There-after you need to be able to reproduce how this information could affect the decisions made by you or your customer. In essence, simple straight through processing. I have made an abstract, titled “Process-driven information: it’s all in the business process design”, for the Building Business Capabilities c...

Yesterday I started working on a new concept for process-driven documentation. The goal is to provide a method that enables us to implement goal- and process-driven documentation during the implementation of new Business Process solutions.With this new concept I want to revive the 'old' Documentation 3.0 idea and implement it in a Business Process context.  Main topics are: How process-driven information can lead to more efficiency, better compliancy and lower risks How documentation of our processes and products can be seen as a product of our processes, modeled by the business itself How a Grow Live approach (instead of Go Live) can help us to continuously improve processes and information I am working on this topic together with Thei Geurts, with whom I worked together on the Documentation 3.0 topic in 2007 and 2008. Some of you might remember our presentations at the STC Conference in Philadelphia or the ISTC Conference in Nottingham, both back in 2008. With this ne...

In the previous posts I have talked about the advantages of having a widely accepted framework for technical communication, just like ICT Architects have. This Technical Communication Framework (TECOF) could be our equivalent for TOGAF. The similarities between Technical Writing and ICT Architecture don't stop at the overview level, we can also learn from the model-driven approach from ICT Architects towards the detail levels of a solution and its context. One of the areas where we can benefit from this approach would in my opinion be the audience and tasks analysis, at the start of a technical communication project. A structured approach to audience and task analysis Archimate is an 'architectural language'. It provides ICT Architects with a vendor-independent set of concepts, including a graphical representation, that helps to create a consistent, integrated model which can be used in for instance TOGAF's views. The business layer in Archimate neatly corresponds...

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...