In the last few weeks I have been approached by several different UK government projects - all large-scale initiatives intended to reform a major aspect of service delivery. A common theme is integration, either between regional organizations or between disparate types of service provision.

From these discussions, it seems that things have improved somewhat since the early days of what the UK used optimistically to call "eGov". I remember working with UK government organizations a few years ago, and thinking they had been placed in an almost impossible position. Those in the inner circles of central government responsible for "doing something about the Internet" had clearly decided that the safest approach with regard to covering their own backs was to assemble a list of every three-letter acronym that appeared to be currently in vogue, then issue this list to all government departments and agencies as a "recommendation".

As a result, the many individuals in receipt of this list found themselves effectively charged with delivering something of unknown behaviour, but that conformed to at least 25 emerging, overlapping and often inconsistent technologies and standards. Money was being thrown at them, but what they were supposed to do with it was anyone's guess. It was a true Alice in Wonderland situation that could only arise in government circles.

Now people at least have clearly defined goals. However, I suspect that the problems ahead have become harder not easier. At least back then the situation was so obviously ridiculous that no-one could be blamed, whatever they did in response. Now there is the expectation that concrete results will emerge in a controlled fashion, yet the core problems that beset any large-scale integration endeavour have not gone away.

New systems mean new processes, both for doing work and for organizing it. Further, new processes have strategic and tactical dimensions as well as operational ones.

In a government scenario, many if not most such processes make heavy use of humans as participants - there is generally not as much potential for automation as one finds in a commercial setting focused around trade. Hence process analysis and re-engineering must cater for human needs - in particular, the humans involved need to explain what they do now, and see that their explanation is fully recognized in the proposed solution. Further, if the project is to succeed, they need to buy into this solution - which means empowering them to feel a valued part of it.

Yet the techniques for process mapping have largely not moved on for many years. As has always been the case, requirements modelling techniques are often applied piecemeal, not systematically integrated with development work, and (here's the crunch) suitable more for the design of mostly automated software systems than for the design of systems to support collaborative human activity.

TAKE AWAY

It will be interesting to see to what extent those involved in the current crop of UK government projects take this to heart, and adopt Human Interaction Management principles to structure their requirements analysis and process implementation. Unless they do, the IT press may well be able to enjoy reporting yet another bunch of major IT failures in a few years from now.

Posted by keithhb in Government | Permalink | Comments (0)

When visiting Sun Microsystems last week, I picked up a booklet they are currently giving away: "Being the best @ Email for Dummies", subtitled "Stop the email madness".

The book is actually part of the well-known John Wiley & Sons "... for Dummies" series. What is interesting is that Sun saw fit to sponsor its production, and commission one of their staff to write it.

Sun do offer an email solution. However, there is no advertising for this in their Dummies booklet. The only plug they make for their own products is for their Sustainable Computing initiative, which has no obvious relation to email.

Further, the advice given in the book itself does not necessitate use of Sun software or hardware in any way.

So why have Sun gone to the trouble and expense of producing this book and giving it away free?

TAKE AWAY

I have described in a previous blog post how "If you want efficiency in the 21st century workplace, email is the place to look."

It seems that Sun has got the message. They clearly hope to create the general impression that their company understands the pain felt by everyone currently using email (which is just everyone), and can offer a way forward.

What a shame, then, that their advice doesn't go nearly far enough. Most of the problems we all face with email are hardly touched by the Sun booklet:

• Discussions that fizzle out, fragment among different colleagues, or lose their purpose


• Attachments scattered all over your file system


• No way of ensuring use of a specific version of an attachment, or even of knowing what version your colleagues are using


• Actions that cannot be tracked, or for which you are not sure if anyone has even taken responsibility


• Doing work without knowing what value anyone is getting from it


• Having to spend too much time assembling audit trails for work carried out


• and so on.

Over the next few weeks I will be addressing these problems in this blog, and showing how they can be resolved via a new breed of lightweight software solutions. If you find email frustrating as a workplace tool, stay tuned.

Posted by keithhb in Email | Permalink | Comments (0)

This post is the third and concluding part of my predictions for 2008. In the last 2 posts, I have described how the flood of new technologies in recent years is causing some apprehension among business people. Many remember how hard it was to measure ROI from (for example) ERP - and some remember implementations in which ROI was conspicuous by its absence. How much more complex will it be to measure ROI on BPM+SOA+BRM+CEP+BAM+BI+Mashup+add_your_new_type_of_product_here?

In particular, it is not yet at all clear what is involved in the administration of these new technologies. For more on this, you may be interested to read my latest column on BP Trends, in which I discuss SOA governance from a human perspective.

The crux of the problem is that major software vendors are addressing a technology stack, not a business stack. Recent acquisitions by hard-core technology companies such as Oracle and Sun have reinforced the popular impression that new technologies are aimed squarely at improving core IT operations, not wider business operations. To many business people, technology vendors fail to supply anything that might address their key concerns.

In particular, any disinterested observer of global business must notice immediately that the main thing happening to organizations of all sizes and types is outsourcing. Mom-and-pop-shops are not just outsourcing their book-keeping but also their services, traditionally a core offering of a small organization. Blue-chips are outsourcing their manufacturing, warehousing, logistics, ... you name it. HP has been outsourcing printer design for many years now.

When talking to outsourcing vendors while in India recently, I was struck by the maturity of their business approach. They have come to understand very well what works and what doesn't, and the argument for working with such partners is becoming almost irresistible. So for many business people charged with delivering cost savings and business improvement, a key way forward is Business Process Outsourcing. This means that the main activities required in 2008 are as follows:

1. Process Architecture. Chunk up the organization into a network of co-operating processes - strategic, tactical and operational - and decide which of these should be the current focus.
2. A Wider Vision Of Choreography. Work out the interactions between these processes, and hence which ones can safely be outsourced. What shall we do? What shall our partners do?
3. Total Cost of Ownership. For those processes that are left over - and only those processes that are left over - assess the validity of streamlining them an IT-based implementation. In particular, how can we optimize the IT operations necessary to administer new solutions?

TAKE AWAY

For many people, 2008 will be about process architecture. This is not the same as process mapping. Architecture tells you what processes you have and what the relationships between them are - mapping tells you the steps in a particular process. There are various techniques for process architecture, but the only one based on the realities of networked organizational activity is Riva - though use of Riva does require some care.

The true value of process architecture for many organizations will be that it leads on to a wider vision of process choreography, a vision encompassing a lot more than technical notations such as WS-CDL. In the end, why implement what you don't own? For more details, take a look at the GOOD methodology.

And when you finally decide to implement a process, how do you do it as cheaply as possible? Anyone who has been around a while knows that Total Cost of Ownership depends fundamentally on the ongoing administration costs - and current IT administration frameworks do not go far enough. ITIL tells you what you must do, and COBIT tells you how well you are doing it, but how do you define and implement your processes for IT administration?

Since IT administration is carried out by humans, the missing link here is Human Interaction Management, facilitated by a new breed of lightweight and low-cost tools: the Human Interaction Management System.

2008 may well be the year in which business people start getting true value from technology - by using less of it.

PS: If you would like to hear further explanation of these ideas, I discussed them during a recent ebizQ podcast with Elizabeth Kratz and other writers for this site.

Posted by keithhb in Business Process Management | Permalink | Comments (2)

This is the second in a series of 3 predictions, of ideas that I believe will be publicly accepted by the end of 2008. Last time I discussed how "The new wave of IT solutions is far too complex for most people". This time I'll go into some more detail.

In particular, my second prediction - that people will come to see how "The new wave of IT solutions raises as many problems as it solves" - is based on a phrase that 10 years ago one used to see a lot more than nowadays, namely Total Cost of Ownership (TCO).

The term TCO came into widespread popular usage for IT purposes around the mid-1990s, when Oracle Corporation and Sun Microsystems in particular started propounding the advantages of the "Network Computer" - a true thin client that possessed no hard disk, only an Internet connection. However, it took a long time for the advance of the Web to bring with it software that can support thin client solutions without reducing the user experience unacceptably - AJAX-based applications, for example. Even now, nearly all computing devices still possess a hard disk, and in my view will probably do so for the forseeable future.

So vendors no longer bandy about TCO as much as they did, since they see less mileage to be gained by doing so. Instead, IT customers are starting to take on these concerns. Faced with proposals from vendors, and analysis on sites such as ebizQ, that suggest the modern enterprise needs not just BPM, but BPM+SOA+BRM+CEP+BAM+BI+Mashup+add_your_new_type_of_product_here, organizations are starting to worry very seriously about administrative overheads. Which is not surprising, since:

• These products are new.


• They are complex.


• There are a lot of them.


• Hardly anyone understands how to use them properly.

TAKE AWAY

Part of the reason that corporate decision-makers are deciding to focus on the management aspects of process-orientation (rather than the technology aspects) is due to the rise of Business Process Outsourcing (BPO). Why implement what you may not end up owning?

The outsourcing industry has matured enormously in recent years. Talking to outsourcing vendors while in India recently, I was deeply impressed by their realistic grasp of what works and what doesn't in outsourcing, and how customers can get the best from low-cost commodity labour.

Further, the outsourcing model has spread to the point where it is no longer simply a matter of cost reduction (if it ever was). The rise of "homeshoring" attests to this.

However, the increased interest in outsourcing raises questions of its own. Next time I will address my third prediction - that people will recognize during 2008 how "There are fundamental business problems that need help from IT but that are not addressed at all by the new wave of IT solutions" - and discuss where the market will turn for answers to these questions.

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

Happy New Year. As as traditional at this time of year, I will make a few predictions for the IT landscape in 2008.

Or rather, I will predict some acknowledgements - state some ideas that I believe will be publicly accepted by the end of 2008. These are about what might be called the "new wave of IT": the host of new techniques and technologies that have recently become contenders for a place on the enterprise backbone. SOA and BPMS are obvious candidates for inclusion, along with associated acronyms such as CEP, BRM, mashup, and so on.

So here are the acknowledgements that I believe will happen in 2008:

1. The new wave of IT solutions is far too complex for most people


2. The new wave of IT solutions raises as many problems as it solves


3. There are fundamental business problems that need help from IT but that are not addressed at all by the new wave of IT solutions

Over the next few days I'll take these in turn, starting with:

The new wave of IT solutions is far too complex for most people

If there is a single subtext to the various discussions I have with business people, it is confusion. And this is hardly surprising. Consider BPM, for example, and let's look again at Ismael Ghalimi's original definition of "BPM 2.0" from Feb 2006:

BPM 2.0 is not for non-technical business analysts. Never should have been, never will, and nobody should care.
http://itredux.com/blog/2006/02/01/bpm-20/

Despite this frank admission from a founding figure in the BPM space, and the efforts of certain commentators to explain that BPM is first and foremost a management approach, analysts and vendors continue to present BPM as a set of tools aimed at business users. Presumably this is in the hope that the take-up of such tools will thereby be helped, by broadening the potential market. However, if anything take-up has been harmed by this approach - most business people I talk to are apprehensive about BPM tools, even if they are drawn to BPM as a means of organizational transformation.

Let's face it head-on: BPM tools are simply a new form of programming, and as with any other new form of programming, it is not yet well understood how to use them safely. In particular, mainstream programming aids such as automated testing and static analysis are not even available for BPM tools.

It is no different with SOA, CEP, BRM, mashup, and so on. In the end, these are all techie gadgets, and the first step towards making good use of them is to recognize that.

TAKE AWAY

The SOA analyst firm ZapThink, in their own predictions for 2008, write:

many organizations are still struggling with the business case for SOA, or even worse, have made a wrong turn or reached some kind of impasse with their SOA initiatives
http://www.ebizq.net/news/8772.html

It's hardly surprising. There are new business ideas emerging originally from IT, and resulting new software tools aimed at business users, but the larger incumbent software vendors are still busy trying to sell technologies. As a result, business users are either suspicious or struggling (or both) - and in 2008 we may well see a backlash.

Tune in to the next post for some more home truths about the new wave of IT. Welcome or not, you should consider these ideas before trusting your career, and your organization's livelihood, to the new wave of IT :-)

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