A NY Times blog post in December 2007 asks "Is Information Overload a $650 Billion Drag on the Economy", describing it as follows:
The information-overload toll is largely a byproduct of workers grappling with the growing tide of e-mail, instant messages, cellphone calls, wikis, blogs and the like.
... while technology investors bemoan the lack of decent solutions:
E-MAIL has become the bane of some people’s professional lives.
The NY Times article goes on to describe the new wave of tech startups that attempt to address the problem by tinkering with your inbox (ClearContext, Xobni, BoxBe, RapidReader, et al), and then dismisses them all by pointing out that:
None of these services really eliminates the problem of e-mail overload because none helps us prepare replies.
Indeed. The true problem here is not the email protocol, or current email clients, both of which serve their purpose reasonably well. The problem is what I call network overload, which refers to the increasing volume of human interaction in the workplace. This interaction manifests itself not only as email, but also as phone calls, conference calls, text messages, instant messages, face-to-face meetings, and in many other ways.
To solve the network overload problem, one must first ascertain its cause. In this case, the root cause is not due to easier communication via technology such as email. Rather, the root cause is the increased amount of collaboration that most people are expected to participate in.
To deal with this, one first needs a means of sorting the wheat from the chaff - distinguishing messages (of any kind) that are part of an ongoing collaborative activity from messages (of any kind) that are simply informational.
Only then is it possible to fix the real problems of email:
TAKE AWAY
The next generation desktop productivity tool cannot possibly be a clever Outlook plug-in that endlessly re-organizes the messages in your inbox, hoping thereby to discover hidden nuggets of gold. This is fiddling while Rome burns! Rather, the next step forward in workplace technology is software based on a robust theory of human interaction: a Human Interaction Management System (HIMS).
A HIMS helps you understand the collaborative work processes (Stories) in which you are engaged, and makes it easier for you to execute your part in these Stories. As the NY Times would say, a HIMS eliminates the problem of e-mail overload by helping you prepare replies.
If you are interested to try out a HIMS, the reference implementation of a HIMS is the free HumanEdj, available now in beta.
]]>Today, encyclopedias, jetliners, operating systems, mutual funds, and many other items are being created by teams numbering in the thousands or even millions. While some leaders fear the heaving growth of these massive online communities, Wikinomics proves this fear is folly. Smart firms can harness collective capability and genius to spur innovation, growth, and success.A brilliant primer on one of the most profound changes of our time, Wikinomics challenges our most deeply-rooted assumptions about business and will prove indispensable to anyone who wants to understand the key forces driving competitiveness in the twenty-first century.
Based on a $9 million research project led by bestselling author Don Tapscott, Wikinomics shows how the masses of people can participate in the economy like never before. They are creating TV news stories, sequencing the human genome, remixing their favorite music, designing software, finding a cure for disease, editing school texts, inventing new cosmetics, and even building motorcycles.
This is hype, of course. Less breathless appraisals of the book than its blurb above point out some of the book's shortcomings:
A review of this book in the Harvard Business Review states "like its title, the book's prose can fall into breathless hype." A review of this book in Choice recommends the book for "general readers and practitioners," but cautions that the authors "present an optimistic overview of successful collaborations and business ventures", "use unique terms (e.g., marketocracy, prosumption, knowledge commons)", should have given "more consideration [to] the darker sides of human motivation as well as groupthink and mass mediocrity", and "primarily draw on their own observations of businesses and trends for the ideas presented."
Nevertheless, it seems clear that blogs, wikis, et al are helping to bring about a fundamental change in the workplace. They accelerate the process started by the Web itself, namely democratizing the publication of information. One could view such technologies as enablers for the Community of Practice idea that has been hovering on the fringes of business life for the last 2 decades.
Further, the widespread use of such powerful communication tools is helping people realize that communication is not the same as collaboration. In fact, many of the people spearheading this recognition are those keenest to promote the existing communication tools. They seek new collaboration tools to go with their wikis and blogs, since they know that for their beloved wikis and blogs to succeed long-term, there must be a way for organizations to manage the explosion of communication that is resulting from large-scale, one-to-many information publication.
Without some form of control applied appropriately at each level of the organizational hierarchy, the "wiki workplace" will simply descend into anarchy.
TAKE AWAY
The authors of Wikinomics are sponsoring the creation by the general public of an "unwritten chapter", via a wiki that will be transformed into a document for publication at key points. This wiki has some interesting ideas. In particular, the vision espoused therein for Enterprise 2.0 offers a compelling vision for the next generation workplace, suggesting that a "People-Oriented Architecture" (POA) is needed to go with today's SOA.
Regular readers of this blog will recognize a similarity between the "Enterprise People Bus" described therein and the knowledge bus concept outlined in some of my previous posts.
There is no doubt that wikis, blogs and the whole panoply of social software tools are changing the workplace. Whether or not this change is for good depends on how fast organizations take up the collaboration tools needed to bring order to the chaos.
]]>Given the ubiquity and importance of relational technology in the workplace, and the array of features offered by open source databases such as MySQL, this may seem a bizarre statement. Yet for many organizations, the primary concern is no longer flexibility or performance, but security:
Many organizations struggle to find a sustainable way to meet global GRC requirements around financial reporting, data security, records retention, risk management, and more.FACT: Industry analysts AMR Research expect organizations to spend nearly $30 billion this year alone, grappling with questions such as:
- How can we stay on top of increasing regulatory demands while controlling cost?
- How can we better manage risk to prevent business and compliance failures?
- How do we achieve better performance while ensuring accountability and integrity?
In my experience, such concerns are becoming more and more important to CIOs. Yet, in this area, there are few offerings, and little indeed that is free and/or open source.
In particular, if you wish to secure data at row level - so that each row has different access permissions, a normal enough requirement in an enterprise environment - options are few. The best approach appears to be an optional Oracle database feature known as Oracle Label Security (aka OLS). Here is how OLS works:
- First, security policies are established to identify how the data needs to be secured by specification of security components for the policies.
- Next, user labels are established that define what row-level security policies are possible for each user.
- For each table that needs to enforce row-level security, a special column called a label column is built and populated.
- During data access, a process called access mediation determines which permissions are required to access the row, and what actions can be performed on the row once it's accessed.
OLS uses three sets of criteria to define both the set of user's permissions to access data in a row as well as the row's accessibility: levels, compartments, and groups.
Levels. As the first security dimension's name implies, a level defines increasing data sensitivity. A typical example includes the standard security levels (Unclassified, Classified, Secret, and Top Secret). Another example for most companies is human resources information. Just about everyone needs to know everyone else's first and last name and e-mail address (i.e. company-wide access). However, only the employee, her supervisor, and the Human Resources department should know salary information about the employee (hopefully!) only the human resources coordinator should know about an employee's participation in a company-sponsored anger-management class.
Compartments. The second security dimension, a compartment defines the areas to which data access is restricted. In other words, compartments can be used to classify data. Typical examples of compartments include functional divisions within a company (Sales, Accounting, Human Resources, Information Technology).
Groups. A group is the third security dimension. It typically defines who is the owner of the data and provides yet another way to classify what type of access is permitted. However, groups have one important difference: They can be used to restrict access to data based on the owning organization's hierarchical structure. Business rules appropriate for group enforcement within a group include geographical areas (localities within states/provinces, and states/provinces within countries) and sales forces (regions that encompass several districts that themselves encompass territories). What's really great about this feature is that OLS allows me to restrict row-level access to specific nodes of the hierarchy. For example, I can grant a sales force's regional manager access to only sales generated within his region's districts; a district manager access to sales generated only within her district's territories; and a salesperson to only the sales generated within his territory.
Security Component Combinations. For each of the label security components, up to 10,000 different values may be established. OLS requires that, at a minimum, one value for the security level must be stored in each label column, even if it indicates unrestricted access is permitted. Note, however, that compartments and groups need not be included in the label column's value. Also, each row and each user can be assigned multiple access permissions for compartments and groups.
Functionality such as OLS should really be part of every database that claims to be enterprise-strength. Perhaps I have missed something, but I cannot see how to achieve equivalent results using (say) DB2, let alone open source alternatives such as MySQL. I believe DB2 has some sort of equivalent to Oracle's Virtual Private Database (VPD - the technology underpinning OLS) in its mainframe edition. But, to my knowledge, that's it, although I have not done proper comparative research in this area.
Further, OLS has been around since 2003, and still has major weaknesses - for instance, support for use of J2EE, since use of OLS via TopLink is currently broken.
TAKE AWAY
I am bemused by the weakness of database offerings with regard to security - especially given the current worldwide focus on combating terrorist threats, the rise of cyber-crime, and the general acknowledgement that the most common threat to organizational security is from insiders.
Your comments are very welcome on this topic! If you have expertise in this area, please share it. I'd be very interested to know your thoughts.
]]>This move, intended to reduce risk, in fact replaced one set of risks (that the requirements could not be implemented as intended) with another set of risks (that the resulting system was not fit for purpose). Hence I have been attempting to de-risk the project by analysing the implications of the move - not only on users of the initially delivered system but also on the project itself at a later date. It is quite possible that, in order to deal with the absence of certain capabilities in the short-term, it may be necessary to introduce design features into the technical architecture that turn out to prevent successful retro-fitting of the missing capabilities later on.
This heart of this work is to analyse the patterns of behaviour that humans will adopt to work with each other via the system. As a result, it has an interesting synergy with a paper I wrote a few weeks ago, for the Requirements Networking Group. Here is the abstract from the paper:
In the end, software applications are only there to support human work. Even a low-level, highly automated software application for (say) car numberplate recognition or payroll calculation is only there to meet the needs of the police officers or HR staff who ultimately set its initial parameters and use its output.Yet most approaches to understanding and modelling human work have a major weakness – they offer reasonable support for capturing H2S interactions (between humans and systems), but are extremely weak when it comes to capturing H2H interactions (between humans and humans). Further, mainstream modelling techniques provide little of the context required to understand what truly goes in knowledge work.
You can find the paper online. You have to join the RNG to access it, but membership is free.
TAKE AWAY
It is really quite startling that issues such as the above are still a problem for software requirements analysis, when you consider how fundamental an engineering task it is.
As another illustration of the immaturity of this aspect of software development, the open source movement is only just waking up to the need for a general requirements management framework (see Open Requirements Management Framework aka ORMF) and an enterprise-oriented application development framework to encompass it (see Open System Engineering Environment aka OSEE). Both these frameworks are only just getting off the ground.
Have you ever noticed how a root cause of software project failure lies in poor requirements engineering? If so, you may like to read the paper referenced above, and check out ORMF/OSEE for yourself.
]]>Their conclusion was that when using my techniques for fault fixing, faults were fixed in approximately half the normal length of time, or in other words, that developers were twice as productive as usual.
TAKE AWAY
Most literature on fault fixing estimates that the average developer spends over 50% of their time fault fixing. So if you are looking to improve the efficiency of your development staff, it must be worth considering techniques that double the productivity of this time.
]]>Budget and resource constraints often mean that, even if too many faults are appearing in a software project, it is not always possible just to add staff. However, even if it is possible, it is often not a good idea.
Adding staff works on the seemingly common sense principle that if 10 developers can fix n faults per week, 20 developers can fix something not too far from 2n faults per week. Software project managers often seem to believe that having more people are working on the job will inevitably lead to an improved delivery rate.
Unfortunately, however, this is not true. In fact, adding staff may well lead to a reduced delivery rate.
Many readers will be familiar with Fred Brooks' seminal book on software project management, The Mythical Man-Month: Essays on Software Engineering. The concept of "The Mythical Man-Month" refers to his principle that "Adding manpower to a late software project makes it later". Brooks says this is because adding people to a project has 2 primary knock-on impacts.
First, the newcomers have to be trained in the skills they need, and familiarized with the project itself. This takes up not only their time but the time of other people - often the people who know most, and who are hence most productive. Induction also takes up other resources of various kinds that can then bottleneck the overall work being done by the project.
Second, the number of communication channels increases dramatically with the number of staff. Brooks' formula is that for n developers, there are n(n - 1) / 2 communication channels within the group. For example, 50 developers implies 50(50 - 1) / 2 = 1225 channels of communication.
This second point is a simplification, of course. Many people would argue that careful management can reduce the number of communication channels. However, from my experience, Brooks' formula is useful whether or not it is exactly correct, in that it indicates the scale of the problem. If you observe any large project from the floor you will see that there is a great deal of human interaction taking place, of all different kinds - not just formal meetings, but emails raising issues, questions asked over the cubicle wall, casual discussions by the coffee machine, and so on. It is very hard indeed to quantify this interaction and even harder to assess its value.
TAKE AWAY
It is possible to add staff to a late-running software development project and gain value. However, it must be done very carefully. To be specific, first you must design the collaborative work processes in which the new staff will engage, using the techniques of Human Interaction Management.
Only by this means can you find out what bang you will get for your buck - what improvement in delivery rate you can expect from purchasing extra staff. In fact, only by this means can you be sure you will actually get an improvement, rather than the deterioriation expected by Brooks.
Further, a moment's thought will show that designing collaborative work processes for new staff is no use unless you have already designed the collaborative work processes for current staff - and ensured that current staff are actually engaging in these processes. Otherwise the structured interactions of the new workers will dissipate into chaos as soon as they start working with people already on the project.
It is possible to improve a late-running project by adding staff, but you can't do it by building a house on sand.
]]>It is important to understand in what ways a large software project is unlike a small one. As I often suggest, one can gain understanding here by comparing software engineering with traditional heavy engineering. For instance, engineers who deal with extremely large and complex systems in fields such as aerospace and the military have always been used to projects that go live with a high number of faults, many of which will remain open throughout the entire lifetime of a system. Fault control in such systems is as much about managing faults as about fixing them.
However, this is not to say that one can take a relaxed attitude towards fault control. There are well-established metrics available for the "defect density" one can expect at each stage of large software projects of certain types in certain fields. These metrics allow software project managers to use the current number of faults, the current fault rate, and the current fix rate to predict where their project will be in the future - and understand whether or not these predictions are worrying.
The situations about which I was asked were worrying. Predictions showed that build deadlines would not be met, and that by a certain point in the future, the number of faults would escalate beyond the managers' ability to control. What should one do in such circumstances?
Taking another leaf out of the military's book, there are 3 approaches that should be used in combination: operational, tactical and strategic. If you prefer, think of these approaches as short-, medium- and long-term. Taken together, they provide a means for even large software projects to become "hyper-productive" - a phenomenon well-recognized in certain small teams, but rarely achieved on the biggest projects.
Operational
One needs to do something in the short-term, not only to stop the situation getting further out of hand, but also to raise morale. Developers do not like to work on failing projects, and once your developers start leaving (or just giving up), you are really in trouble. Even if management somehow conceal the true situation from developers - which is never easy - there is the morale of managers to consider as well.
So in the short-term, it is advisable to set up an emergency room - a lab environment in which some of the best developers can work free from disturbance to knock some of the worst faults on the head as soon as possible. It is often surprising how much progress can be made by reducing the amount of interruption people are subject to. People should not be allowed to enter the emergency room without permission, and if the lab fault fixers need to talk to someone from outside, that person should be brought into the room specially.
A manager should be appointed for the lab, a person who is able to create a team atmosphere as well as maintain a sense of urgency. A key part of the manager's role is to ensure that work is allocated in the most efficient manner possible from hour to hour - sometimes from minute to minute. Everyone should be fully loaded, the whole time, and distractions such as checking email discouraged. The aim is to maintain a sense of flow.
Lab work of this kind is exhausting, so the participants should be rewarded with overtime payments and pampered with free, luxury food and drink. However, the work is also rewarding due to the awareness of visible progress and the team spirit that should be engendered. Further, such a lab is a powerful means of knowledge sharing - after working in the lab, a developer will not only have more system knowledge but may well have acquired new ideas and techniques that will be useful going forward.
Nevertheless, this approach is not intended to be a normal part of the project. If it is necessary to carry it on for more than a month, the participants should change regularly - weekly, for example - to avoid burn-out. Lessons can be learnt by both developers and managers from such a lab, but the emphasis should be on carrying these lessons into regular daily practice rather than on sustaining the lab itself.
Tactical
In the medium-term, there are various means to reduce pressure on a project, with which most project managers are familiar. Deadlines and the content of deliverables can be renegotiated with the client. Workarounds can be developed for areas of fault. End-user expectations can be managed, such as when to expect the introduction of particular aspects of system functionality. Training can be planned so that end-users acquire system knowledge gradually, in order to allow time for the corresponding functionality to be released. Easy-to-use techniques can be developed for end-user fault reporting and control.
When proposing such measures to the client(s), one should take care to present a positive picture. Don't emphasize the trouble the project is in! Rather, explain how your advanced project management techniques have identified potential problem areas well in advance, and prepared a range of compensating solutions. The client(s) should come away from such a meeting feeling glad that you are in charge, not someone who might have let the problems go unnoticed until it was too late.
Strategic
However, it is only fair to admit that, if the project has got to this state, someone has slipped up - even if it was your predecessors. Clearly the scope of the work was misjudged, inadequate development techniques have been used, project management has not been optimal, and so on. So it is necessary to take remedial action to get the project properly back on track in the long-term.
There is a wealth of advice available here, particularly with regard to "Agile" techniques. I recommend Jim Coplien's book Organizational Patterns of Agile Software Development. If you can't face a long read, here are some summaries of "the ten patterns that research has found most strongly correlate to business success": PDF HTML.
One should take the time to understand what Agile project management is all about. Unfortunately, though, Agile techniques work much better with small projects than with large ones. In my experience, agile techniques typically have most success in projects with less than 50 staff, and projects with over 100 staff need something else. So here are some techniques that I have found useful in getting large projects back on track.
TAKE AWAY
It is often tempting to push problems under the carpet when they seem to huge too solve. Large software projects that have gone out of control can seem like a many-headed hydra - as soon as you solve one problem, ten more problems appear. However, there is always a way through the labyrinth.
The key is to be systematic - in particular, divide remedial measures into operational, tactical and strategic.
Further, take care to explain what you are doing to others and get them on board - this is key. Developers as well as managers should understand what is going on and what you are doing about it. A typical but very unhelpful approach to managing crisis situations is to take everything behind closed doors. Resist this temptation! People are surprisingly good-natured, even in times of stress, if they are made to feel a valued part of something - as opposed to being excluded from important discussions.
There is a route to hyper-productivity, and it is not hard. You just have to take it in stages.
]]>A typical factor in people's inability to control their workload is the necessity to use inefficient workplace software, the main culprit being email. Across the board in industry there are major problems resulting from use of email. It is not at all clear when emails should be sent, what they should contain, who should be included, the validity of requesting actions from people, who has committed to do what, the correlation between different email streams, the accuracy of data included, etc. Almost daily, this lack of clarity causes material problems in organizations of every kind.
Problems such as email usage are complex to resolve, relating as they do to process awareness, new approaches to management, new forms of software, and more. Hence solutions for such problems can be expensive to implement in large organizations. How can one justify the expense? In other words, what is the basis of a business case for the introduction of more efficient human collaboration?
It is necessary to find a quantitative means of evaluating the impact. One can list ad nauseam aspects of organizational life that will be improved by rationalizing the way people work together, but the board have a duty to consider the bottom line in any major decisions they make. However swayed they may be personally - e.g., from experience of mobile phone calls at ungodly hours - they will not be acting with due diligence if they approve a programme that has no means to demonstrate Return On Investment (ROI). So it is necessary to find a metric that is applicable to human collaboration.
This is non-trivial, since there is a difference between efficiency and effectiveness.
When measuring the impact of process improvement in mechanistic areas such as transaction handling or manufacturing, the outputs of the process are probably going to remain similar after the changes have been implemented. The aim is simply to produce these outputs quicker and cheaper. In other words, one is aiming for increased efficiency.
The same is not at all true for human collaboration. Free people up by helping them work better, and they will deliver more value to the organization. Once people are not struggling to keep afloat, they can help steer. In other words, improving interaction work delivers increased effectiveness. However, in advance one cannot always predict what form the increase will take. Take sales, for example. One might expect a salesperson who works better to make more sales, but it is quite possible that the actual improvement will be customer relationships that are longer-lasting, something that cannot be measured until enough time has passed.
So what metric should one use when proposing a programme to improve human collaboration in the organization?
TAKE AWAY
The simplest metric for human collaboration is very simple indeed. Work out how much you pay people per hour. Then count how many hours they are spending at work, taking care to include work done out of the office. If your staff start taking less time to do their work, you are getting better value for money.
This applies even if you don't pay people overtime. There is a huge hidden cost to working long hours. Tiredness and stress not only make people miserable, but reduce their contribution to the organization and increase "churn" (the frequency at which staff leave the organization altogether). These negative impacts are at least partially offset by paying people decent overtime - and if you don't pay people overtime directly, you can be sure that your organization is paying the price somehow.
So a first step for a programme to improve interaction work in your organization is to find out how much time in each day people are taking to do their work. Cost this time based on salaries, and aim to reduce the total by a specific amount - say 1 hour per day per person. This effectively gives you a budget for the interaction work improvement programme - spend any less than this in total, and you will have delivered ROI.
Of course, this is using the narrowest of measures - a measure that takes no account of the significant improvements you can expect in effectiveness, which as discussed above will be the main benefit of the programme. However, the aim here is simply to get the programme approved by the board. Once you get going, material impacts of all kinds will become evident. It will be much easier to get approval for your second interaction work improvement programme than for your first!
]]>A case study illustrating use of the knowledge bus will be published in my bptrends.com column "Human Processes" in March. When it appears, I'll link to it from this blog.
The case study can be found here:
Human Processes: Ruling Unruly Rules
"What is the next major step in enterprise IT? Keith Harrison Broninski has a fascinating perspective. He argues convincingly that there will be a shift in emphasis from server-side automation application to client-side human interaction. Read his Column for the details of why he’s convinced this change will occur. "
In particular, dominating the desktop is going to mean something quite different in the 21st century. Whether or not Microsoft remains the leading operating system and office application supplier, the current trend towards commoditization of such products will eventually render Microsoft's presence more akin to that of a company like Cisco. Most people with an interest in IT know roughly what Cisco does, but most ordinary mortals don't think of themselves as Cisco customers.
So who or what will dominate the desktop in the 21st century? The increasing pressures on knowledge worker productivity that I often discuss in this blog means that we are all coming to expect more from workplace IT. In particular, we don't need cleverer tools - office applications, for example, have provided more than enough for most of us for a long time now. What we need is a way to join up the work we do using such tools.
Jim refers to this new layer of technology as the knowledge bus, which I think is an excellent term. It certainly describes very well what I have been trying to achieve with HumanEdj. Here are some key characteristics of a bus:
TAKE AWAY
The latter aspect of a knowledge bus - routing - is in some ways particularly interesting.
Looking forward, it may be that we will see a convergence of Business Rule Management and technology support for knowledge work. If human intervention in rule evaluation is to be controlled properly, it must be viewed as a collaborative business process - what HumanEdj calls a Story. Hence, a precursor to safe use of Business Rules in an enterprise environment is the implementation of techniques and technologies for support of Stories.
Further, the creation and administration of Business Rules in the first place is just as much a candidate for control via Stories as their operational usage. Here again increasing competitive demands will force new levels of complexity in business operations, via extended Business Rule support - but without proper safeguards on the implementation of this support, we will only see more disasters like Black Monday,
20th century technology is not going to go away - if there is one lesson that the IT world should have learnt by now, it is the extraordinary longevity of legacy systems. However, it is certainly not going to be enough to meet the demands of the 21st century. The missing piece is the client-side, desktop-based infrastructure that allows organizations to leverage - safely - the enterprise backbone into which they have already invested so much money and effort. Thinking of this new infrastructure as forming the knowledge bus may be an illuminating way to make sense of what is coming.
]]>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.
]]>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:
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.
]]>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:
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.
]]>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:
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.
]]>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:
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 :-)
]]>