This is the third and final entry in a blog series on writing documents - why the word processor is not the best way to do it, and how to do it better. In the two previous entries, I have:

• Explained the benefits of a more structured approach - an approach in which content is separated cleanly from formatting


• Given an example of such an approach.

In this final post of the series, I will describe a free tool that makes taking this approach just as easy as (if not more than) word processing.

The tool in question, XMLMind XML Editor (XXE), is one of many - there are various lists online, one of the best being provided by the DocBook project's own Wiki. However, I use XXE for 3 reasons:

1. The Standard Edition is free, and this provides enough functionality to write and output DocBook documents


2. With a couple of clicks you can generate output in various forms - HTML for Web browsing, Acrobat (PDF) for download/printing, and various other forms for compatibility with (say) Microsoft Word


3. It is very easy to use, since the interface is "WYSIWYG" - What You See Is What You Get.

What does this last point mean? Simply that using XXE is like using a word processor. Behind the scenes you may be creating XML, but you wouldn't know it - as document author, you write formatted text and see the results on screen just as in any word processor. For example, you can break a document into sections and sub-sections, place text in bold and italic, enter quotations, and so on. There are DocBook features for most common word processing tasks: bibliographies, cross references, footnotes, glossaries, embedded graphics, indexes, tables, and so on. You can even add attributed comments for collaborative working.

There is an XXE tutorial that explains how to write documents using the program, and gives you tips and tricks to speed up your work. I found that 30 minutes invested in this tutorial was enough to get going.

What you won't find anywhere in the tutorial, or in XXE itself, is information on how to specify fonts for pieces of text, customize the layout of pages, change paragraph formatting, etc. This is because, as explained in the previous blog entries, the whole point of using a structured approach is to let you as document author concentrate on content - and forget about document design. Not only are most people who write documents neither interested in nor qualified to design the documents they write, but by far the best approach is to apply preset formats to all your documents - formats that:

• Have been created by professional designers


• Are standardized across your organization and/or for the purpose of the particular document in question


• Not only enable output of the document in different forms but also guarantee stylistic consistency between these forms.

TAKE AWAY

Many of us spend a large proportion of our time entering text into a computer, often to create text documents (as opposed to say, spreadsheets). Typically this is done using a word processor, for example Microsoft Word. This blog series has asked: why?

Even the advanced features of modern word processors can be reproduced using an approach based on simple XML - and there is no need as an author ever to see this XML. You can write a "structured document", in which content is cleanly separated from formatting, without ever seeing a single XML tag - using WYSIWTG tools that have the same kind of interface as a word processor. What's more, such tools are available for free.

And once you start working in this way, the advantages are many and varied. As mentioned in previous blog entries, you can store such written materials in a repository, that is searchable not only on text keywords but according to the internal structure of the documents it contains. You also gain the very useful ability to generate various different forms of output from a single document with little or no effort - both for printing and for Web browsing, for example, or using different fonts, colours and layout.

But perhaps the most useful advantage of all is the ability to standardize on document formatting - both across an organization and for particular types of document - then change these standards at any time, without having ever to touch the documents themselves. To give but one example, we use it for providing software user documentation - and gain not only the ability to generate output both as Eclipse online help and in printable form, but also to change the style of this documentation at any time. For us, using structured documents is a no-brainer - as I suspect it would be for most organizations, if they only took the time to think about it.

An aim of desktop computing must surely be to reduce the amount of effort people have to invest in order to get things done. To me, it seems that taking away the responsibility for messing about with typefaces, line spacing, page layout, and other issues of document design can only be a significant step in this direction. Why not try it?

Posted by keithhb in Office Applications | Permalink | Comments (0)

In the previous posting, I described the disadvantages of using a word processor to create documents, and outlined the advantages of using a more structured approach - an approach in which content is separated cleanly from formatting. In this post, I will give an example of such an approach, and in the next post, I will describe a free tool that makes it just as easy as word processing.

The approach in question is to use a well-established XML dialect called DocBook. Quoting the DocBook Web site:

[DocBook] began in 1991 as a joint project of HaL Computer Systems and O'Reilly. Its popularity grew, and eventually it spawned its own maintainance organization, the Davenport Group. In mid-1998, it became a Technical Committee (TC) of the Organization for the Advancement of Structured Information Standards (OASIS).

DocBook has become the leading way to write structured documents. You create a set of XML files to represent your report, article, book, or whatever - and use XML "stylesheets" to generate from these files a number of finished products. You might require, for example, both a PDF version for printing/download and an HTML version for display using a Web browser. The ability to select any stylesheet for generating output means that on different occasions you can generate each of these end products with different typefaces, layouts, and so on.

Are you put off by the mention of a techie language such as XML? Never fear, as a document author there is no need for you ever to touch the stuff. There are (free) tools available that allow you to write DocBook, and generate all sorts of useful output, without needing even to see the underlying XML code.

TAKE AWAY

Creating a document in which the content (for instance, XML DocBook files) is separated cleanly from the formatting (for instance, as stylesheets) means that you automatically gain various useful advantages. In particular, you can store written materials in a repository, searchable according to the internal structure of the documents it contains. You also gain the very useful ability to generate various different forms of output from a single document with little or no effort - both for printing and for Web browsing, for example, or using different fonts, colours and layout.

DocBook is actually very simple to use - the XML tags are intuitive, with names such as chapter, title, section and so on. However, most people prefer not to write XML by hand. So there are many tools available, some of the best ones being free, which make it as simple to write a DocBook document as a Microsoft Word document. In the next blog post, I will describe one such tool and explain how to use it. If you are starting to see the benefits of changing the way you (and your colleagues) write documents, stay tuned.

Posted by keithhb in Office Applications | Permalink | Comments (0)

Most of us use a word processor, daily - and for many of us, it comes second only to email as a business tool. But is a word processor actually the best way to create written documents?

It is quite extraordinary that in the 21st century the standard way of creating formatted text on computers is essentially unchanged from its roots in 15th century typography. Gutenberg would have had no real difficulty using Microsoft Word. Prior to computerized typesetting, if you wanted bold text in a book, magazine, or newspaper, your printer would achieve it by taking the characters concerned from a bold version of the font and placing them into the appropriate positions on the page. These days, you do it yourself using a word processor - but the principle is exactly the same. You now place characters in bold by choosing the appropriate menu option, or clicking on a toolbar button, but - just as in the old hot metal days - the formatting is attached directly to the text itself.

Why on earth are we still doing things this way? As Charles Goldfarb writes: "Many credit the start of the generic coding movement to a presentation made by William Tunnicliffe, chairman of the Graphic Communications Association (GCA) Composition Committee, during a meeting at the Canadian Government Printing Office in September 1967: his topic -- the separation of information content of documents from their format." The 40-year old "generic coding movement", of which Goldfarb was a founder member, eventually gave rise in 1980 to the standard markup language SGML, which in turn formed the underpinning of HTML and subsequently XML.

In HTML, for instance, one specifies that certain text is a heading by surrounding it with "tags" such as h1 (heading level 1) or h2 (heading level 2), one identifies a list using tags such as ul (bulleted list) or ol (numbered list), and so on. It is then up to the browser that displays the HTML to "render" headings and lists using appropriate fonts and layout. With HTML, the rendering choices are generally built in to the browser itself. With XML, however, there is more flexibility in document formatting - one can identify sections of text as being of any nature whatsoever, then define (by various alternative means) the way in which you would like text of each type to be displayed.

Such an approach to publishing has many advantages over simple typesetting:

• You can do structural searches on the document (rather than just keyword searches)


• It is possible to present the document in outline style


• A document can be formatted in different ways for different purposes


• Documents can be stored and analysed via knowledge management techniques rather than as a stream of bytes


• ... and so on.

It is very hard to explain from a logical standpoint why most people do not write text in this way. Most likely, the reasons are simply commercial - the success of leading word processor products, for example. Yet there are few if any features of document creation that would not be better achieved via separation of content from formatting. And these days there are well-designed, free tools available for the creation and subsequent formatting of structured documents, tools that do not require the user to possess the technical skills of a programmer.

TAKE AWAY

The success of SGML and its descendants is immediately visible to all of us in the increasing prominence of the World Wide Web in everyday life. Yet, for some reason, the vast majority of people still write documents using a word processor, in which text is only structured via an implicit association with the attached formatting - and this is completely unreliable. Few people are consistent in their use even of bold or italic, for example.

More to the point, many word processor documents are stored natively in a format that precludes the simple presentation of the text in alternative forms. Yet this is potentially extremely useful. For example, it would be very valuable if a single document could be displayed either as an article, a slide presentation, a set of Web pages, or a syndicated feed - something that is impossible to achieve via conventional word processing.

In the next postings to this blog I will show how anyone, no matter how technically uninclined, can use simple, free tools to create documents in which content is cleanly separated from formatting. I will also illustrate the immediate business benefit of doing so with examples drawn from daily life.

If you ever write documents (and who doesn't), stay tuned.

Posted by keithhb in Office Applications | Permalink | Comments (1)

This blog has been running a couple of months now, during which I have written about various wide-ranging changes that are in store for enterprise IT over the next few years. Many of these changes are to do with the adoption of new, powerful open source software tools (such as Eclipse) in combination with 21st century management techniques (such as Human Interaction Management).

If you've been following some or all of these writings, you might like to know that our own efforts at Role Modellers are due for release in September this year (here is a preview of the free technology we are building). Recently I have met with people from many different walks of life to discuss these ideas - governments, product/service organizations, consultants, business leaders, academics, investors - and there seems to be general agreement that, yes, we do need what McKinsey call "new technology" for a "new territory" (the globalized, decentralized, Internet-enabled and insanely competitive world that every 21st century organization must somehow deal with).

So we're transitioning from R&D to the next stage - and hiring. Here is the job ad:

Were you at UCLA in the 60s? Xerox PARC in the 70s? Apple in the 80s? Netscape in the 90s? This time, don't miss out.

In South-West England a pioneering startup is building the "framework for 21st century computing technology" (bptrends.com), the software called for by McKinsey to "solve some of the most nagging challenges to the systematic organization of the workforce". We're venture capital backed - and we're hiring NOW.

Our vision is to bring about a healthier, happier, saner, and more productive society by helping people in all walks of life collaborate better with each other. We are looking for friendly, creative software developers with experience of Eclipse EMF and RCP. Join us and you'll get the chance to work with like-minded people, in the working environment everyone dreams of, for a very good salary - plus you'll get a piece of the next Big Internet Play.

Find out more from http://humanedj.com, and if you're interested email your CV to Keith Harrison-Broninski (khb AT rolemodellers DOT com).

--
All the best
Keith
http://keith.harrison-broninski.info

Readers of this blog are very welcome to get in touch.

Posted by keithhb in R&D | Permalink | Comments (0)

This is the sixth and final entry in a blog series on enterprise software development practices. The aim of this series has been to set into context various current movements from a management viewpoint. In particular, I started out by promising to discuss the relationship of application programming (whose state-of-the-art is evolving rapidly at the moment) to other modern approaches (in particular, SOA and BPM), and to show how the use of all 3 approaches can be properly synchronized within the enterprise. What have I covered so far?

I have described the management chaos surrounding all these forms of software development in large organizations (and some organizations that are not so large) - and shown how simple, universal, formal management principles can be applied to sort things out. In particular, this gives you a means not only to integrate the work of diverse teams, but also to ensure that the strategic skills of senior management are leveraged for the business benefit of the organization - even when it comes to IT! In the previous entry, I illustrated this approach by reference to SOA. In this final posting, I will show how BPM and application programming can be brought under the same control.

First, though, why separate BPM and SOA? Many IT writers describe BPM and SOA as part and parcel of the same picture - "your services are there simply for use in your processes". This is true, but it misses a key point. The fundamental aim of SOA is to "decouple" - in plain English, to separate or distinguish - the IT functions offered in an enterprise from the means by which these functions are implemented. In practice, this means that an individual service can be employed without the consuming application or user having any idea how or where is it implemented.

An important implication of this is that the consumer has no idea which particular services are implemented by the same backend system. In fact, even if they do suspect that service PQR is implemented by ERP System XYZ, this may be true one day and false the next, since a primary aim of SOA is to enable the backend flexibility necessary for efficient IT operations. Hence, an ancillary effect of SOA is to prevent service consumers from understanding their IT environment in a holistic way - all they ever see is a disconnected list of individual services, each offering a specific piece of functionality.

It is hard to overstate the importance of this aspect of SOA. To see why it is so important, consider by contrast the nature of BPM and application programming. Both aim at the creation of complete systems - whether such systems are based on processes (like BPM) or on functional needs (like custom applications). Well, yes, of course, you may say - I know what a system is. But do you think about systems in the most useful way? A system is much more than a set of program modules. Here is what Peter Senge, in his seminal book "The Fifth Discipline" (1990, p.68-69), has to say about Systems Thinking:

Systems thinking is a discipline for seeing wholes. It is a framework for seeing interrelationships rather than things, for seeing patterns of change rather than static "snapshots." It is a set of general principles - distilled over the course of the twentieth century, spanning fields as diverse as the physical and social sciences, engineering, and management. It is also a set of specific tools and techniques, originating in two threads: in "feedback" concepts of cybernetics and in "servo-mechanism" engineering theory dating back to the nineteenth century. During the last thirty years, these tools have been applied to understand a wide range of corporate, urban, regional, economic, political, ecological, and even physiological systems. And systems thinking is a sensibility - for the subtle interconnectedness that gives living systems their unique character.

Today, systems thinking is needed more than ever because we are becoming overwhelmed by complexity. Perhaps for the first time in history, humankind has the capacity to create far more information than anyone can absorb, to foster far greater interdependency than anyone can manage, and to accelerate change far faster than anyone's ability to keep pace. Certainly the scale of complexity is without precedent. All around us are examples of "systemic breakdowns" - problems such as global warming, ozone depletion, the international drug trade, and the U.S. trade and budget deficits - problems that have no simple local cause. Similarly, organizations break down, despite individual brilliance and innovative products, because they are unable to pull their diverse functions and talents into a productive whole.

Sound familiar to you? Know of any IT projects that broke down "despite individual brilliance and innovative products", because it was "unable to pull [its] diverse functions and talents into a productive whole"? If you don't, you can't have been around in IT for very long. And you presumably avoid reading the news, in which reports of such failures are constant - frequently not only very costly but also mission-critical for the organizations concerned.

Despite the influence of the many well-known management writers and practitioners such as Senge, Peter Drucker and Charles Handy who have espoused Systems Thinking, and the demonstrable success of organizations that apply its lessons, Systems Thinking has unfortunately not become pervasive in business life - and nowhere is it more sorely needed, or more evidently lacking, than in IT. In particular, anyone working on a BPM project or an application development should apply its lessons.

However, very few do apply such lessons! For example, a recent article in ACM Queue magazine on "Best Practice BPM" recommended that the first step in a new BPM project should be as follows:

To achieve a rich appreciation of the process, it is necessary to model the process at a high level, from a number of different, complementary perspectives. Assessing the business situation using a set of complementary modeling techniques allows people to comprehend the fundamentals of the process better. The ideal techniques for this phase are:

• Flow diagrams to look at the order of activities, using BPMN (Business Process Modeling Notation).


• Role activity diagrams to focus attention on role interactions and the desired behavior of the various actors.


• Object state transition network models to focus on how the things moving through the process change state.


• Capability models to look at the process as sets of reusable business components. A capability may be composed of other capabilities or implemented by a procedure (BPMN-style model).

In other words, don't even attempt to develop an appreciation of the core concerns of Systems Thinking: the high-level structures that underpin business operations and the influences driving these structures. Rather, dive straight down into "the order of activities", "the desired behavior of the various actors", "the things moving through the process" and "sets of reusable business components".

The writer goes on to say:

The emphasis here is on understanding the process, not building models for transformation into code or executable process definitions.

Is it? Sounds just like software design to me. Even the techniques (flow diagrams, state transition diagrams, and so on) are drawn directly from software design.

As with the SOA RedBook from IBM that I criticized in the last posting, it is actually rather unfair to pick on this one article. The methodology it espouses is typical of current BPM practice - as it is typical of application development generally. The approach can be characterized as reductionist rather than holistic - focused on the atomic elements of a system rather than on the operation of the system itself. Why are so many intelligent people, who know about the high failure rate of IT projects, unable to see the wood for the trees?

The reasons for the failure of Systems Thinking to gain traction are complex, but the root cause is simple - the pioneers have typically been more like philosophers, or gurus, than engineers. Drucker, for example, always saw management as a liberal art: "liberal" because it deals with the fundamentals of knowledge, self-knowledge, wisdom, and leadership; "art" because it is also concerned with practice and application. This is all very well, but most practicing managers simply have not found the time, or demonstrated the dedication, to achieve (in Senge's words) "Personal Mastery". What the "manager on the street" wants, and needs, is a simple set of core techniques that they can apply to get their job done - without having to think too hard about it.

Is this an indictment of human nature? Who knows. But we have to work with what we've got.

What is needed in order for ordinary mortals to employ Systems Thinking is a set of simple, formal management principles that:

• Are based on Systems Thinking


• Can be applied to any problem situation.

And this is what the principles of Human Interaction Management (HIM), described in this blog series, provide.

Turning for example to BPM: before starting to develop a set of process specifications, the senior management of an organization should attempt to understand what sort of processes they need. This is a strategic question, to which the answers will be found not in diagramming techniques but in an understanding of how their organization operates - internally, in the context of its target markets, and with respect to its key partners (including particular customers and suppliers). There is no space here for a complete discussion of Systems Thinking. However, to illustrate the difference between such an effort and the sort of effort proposed above for "Best Practice BPM", the output of such an understanding should be a set of structures, connected both by feedback loops of influence and by evolutionary relationships over time. The aim is to model the business as a whole, not to break it down into individual "streams", "chains", "processes", "networks" or "components".

Once such a set of systemic structures has been defined, it is then possible to define targets and measures for the effective performance of these systems. Such targets and measures form the basis of what HIM terms strategic control. As for the SOA example given in the previous posting, these targets and measures can then be passed down to the next level of management - executive control - for definition of outline processes that implement them. Again as for the SOA example given in the previous posting, the subsequent step is for these outline processes to be fleshed out at a yet lower level - via management control, i.e., facilitated and controlled by managers who work as part of corresponding development teams.

As with the SOA example given last time, it is only in this final stage that the details of process or application design are considered. And this is the right place - since both forms of design require an understanding of, facility with, and taste for the sort of diagramming techniques typically recommended for use by board-level executives. Each to their own, and all will not only give their best, but be happy doing so.

TAKE AWAY

The approach described here to managing BPM and application projects provides the much-needed means to integrate process definition and software development directly with the strategic aims of the organization(s) concerned - removing the "strategy disconnect" described previously.

It also avoids the problem with which the discussion above started - that the user of a service is encouraged to think of each service as independent from all other services, the user of a process is encouraged to think of each process as independent from all other processes, and the user of an application is encouraged to think of each application as independent from all other applications.

In fact, it can be argued that the disconnect between high-level strategy and low-level implementation in most organizations is effectively a symptom of lack of Systems Thinking - a problem caused only by the lack of simple, standard techniques with which anyone can apply Systems Thinking. If your IT infrastructure, like most, fails to reflect the stated visions of your organization, this is almost certainly why.

The good news is that there is a solution, it is free, and anyone can apply it easily. Apply the principles of Human Interaction Management - and leverage the power of Systems Thinking to turn your organization into the efficient system that everyone concerned wants it to be.

Posted by keithhb in Business Process Management • Management • Service-Orientated Architecture | Permalink | Comments (0)