Why information architecture needs systems thinking

by

If a factory is torn down but the rationality which produced it is left standing, then that rationality will simply produce another factory. If a revolution destroys a government, but the systematic patterns of thought that produced that government are left intact, then those patterns will repeat themselves … There’s so much talk about the system. And so little understanding.

Source: Robert Pirsig, Zen and the Art of Motorcycle Maintenance, 1974

We who labor at the crossroads of structure and behavior have learned the hard way that content management is far messier than garbage collection and “the system always kicks back.”

Source: Peter Morville, Editorial: The System of Information Architecture (Journal of Information Architecture. Vol. 3, No. 2., 2012) 

Churchman’s interest in computing reaches extensively beyond the metaphor of inquiring systems. He addresses many issues with the state of MIS research of his time, including the tendency of IS researchers to focus on “safe” issues such as “structure of files, retrieval techniques, automatic abstracting, and the like” (Churchman 1968, p.111). He indicates that the majority of such research is not consistent with the systems approach as it focuses on transactions rather than the true goals or benefit of the system. Churchman is also quite visionary as he predicts the ubiquitous role of computers in everyday life. With the ability to “find facts” readily, Churchman predicted that information systems will actually work to reinforce a user’s Weltanschauung (world-view), as the user would screen information based on his Weltanschauung. In order to expand use MIS to expand the user’s view to one that is more holistic, Churchman envisioned a “deadly enemy” proposal for the design of an information system. The main role of this deadly enemy is for the system to propose information results based on assumptions that are opposite of the user’s information request, thereby revealing to the user his fundamental assumptions and at the same time questioning them (Churchman 1968, p. 122-123).

Source: Nicholas Berente, C West Churchman: Champion of the Systems Approach quoting Churchman, C.W. (1968) The Systems Approach, Dell Publishing Co.

See also Kristo Ivanov, The systems approach to design, and inquiring information systems (2001)

We Ought to Know the Difference

by

Is systems thinking really possible? Here’s one reason why it might not be.

One of the concerns of systems thinking is the need to avoid the so-called environmental fallacy – the blunder of ignoring or not understanding the effects of the environment of a system. This is why, when systems thinkers are asked to tackle a concrete situation in detail, they often hesitate, insisting that it is wrong to look at the detail before understanding the context.

The trouble with this is that there is always a larger context, so this hesitation leads to an infinite regress and inability to formulate practical inroads into a complex situation. Many years ago, I read a brilliant essay by J.P. Eberhard called “We Ought to Know the Difference”, which contains a widely quoted example of a doorknob. As I recall, Eberhard’s central question is a practical one – how do we know when to expand the scope of the problem, and how do we know when to stop.

C West Churchman went more deeply into this question. In his book The Systems Approach and its Enemies (1979), he presents an ironic picture of the systems thinker as hero.

If the intellect is to engage in the heroic adventure of securing improvement in the human condition, it cannot rely on “approaches,” like politics and morality, which attempt to tackle problems head-on, within the narrow scope. Attempts to address problems in such a manner simply lead to other problems, to an amplification of difficulty away from real improvement. Thus the key to success in the hero’s attempt seems to be comprehensiveness. Never allow the temptation to be clear, or to use reliable data, or to “come up to the standards of excellence,” divert you from the relevant, even though the relevant may be elusive, weakly supported by data, and requiring loose methods.

Like Eberhard, Churchman seeks to reconcile the heroic stance of the systems thinker with the practical stance of other approaches. But we ought to know the difference.

This is an extract from my eBook on Next Practice Enterprise Architecture. Draft available from LeanPub.

John P. Eberhard, “We Ought to Know the Difference,” Emerging Methods in Environmental Design and Planning, Gary T. Moore, ed. (MIT Press, 1970) pp 364-365

See extract here – The Warning of the Doorknob. The same extract can be found in many places, including Ed Yourdon’s Modern Structured Analysis (first published 1989).

See also

Nicholas Berente, C West Churchman: Champion of the Systems Approach

Jeff Lindsay, Avoiding environmental fallacy with systems thinking (December 2012)

Updated May 14 2013

We Ought to Know the Difference

by

Is systems thinking really possible? Here’s one reason why it might not be.

One of the concerns of systems thinking is the need to avoid the so-called environmental fallacy – the blunder of ignoring or not understanding the effects of the environment of a system. This is why, when systems thinkers are asked to tackle a concrete situation in detail, they often hesitate, insisting that it is wrong to look at the detail before understanding the context.

The trouble with this is that there is always a larger context, so this hesitation leads to an infinite regress and inability to formulate practical inroads into a complex situation. Many years ago, I read a brilliant essay by J.P. Eberhard called “We Ought to Know the Difference”, which contains a widely quoted example of a doorknob. As I recall, Eberhard’s central question is a practical one – how do we know when to expand the scope of the problem, and how do we know when to stop.

C West Churchman went more deeply into this question. In his book The Systems Approach and its Enemies (1979), he presents an ironic picture of the systems thinker as hero.

If the intellect is to engage in the heroic adventure of securing improvement in the human condition, it cannot rely on “approaches,” like politics and morality, which attempt to tackle problems head-on, within the narrow scope. Attempts to address problems in such a manner simply lead to other problems, to an amplification of difficulty away from real improvement. Thus the key to success in the hero’s attempt seems to be comprehensiveness. Never allow the temptation to be clear, or to use reliable data, or to “come up to the standards of excellence,” divert you from the relevant, even though the relevant may be elusive, weakly supported by data, and requiring loose methods.

Like Eberhard, Churchman seeks to reconcile the heroic stance of the systems thinker with the practical stance of other approaches. But we ought to know the difference.

This is an extract from my eBook on Next Practice Enterprise Architecture. Draft available from LeanPub.

John P. Eberhard, “We Ought to Know the Difference,” Emerging Methods in Environmental Design and Planning, Gary T. Moore, ed. (MIT Press, 1970) pp 364-365

See extract here – The Warning of the Doorknob. The same extract can be found in many places, including Ed Yourdon’s Modern Structured Analysis (first published 1989).

See also

Nicholas Berente, C West Churchman: Champion of the Systems Approach

Jeff Lindsay, Avoiding environmental fallacy with systems thinking (December 2012)

Updated May 14 2013

Mike Walker has Joined Hewlett-Packard

by

Some of you may already know from my LinkedIn profile that I have joined Hewlett-Packard (HP) in the Software Division as an Strategy and Enterprise Architecture Advisor. As I was evaluating HP I didn’t fully appreciate HP’s status in the…

Categories Uncategorized

Assumptions

by

The following passage is drawn from Robert Pirsig’s Zen and the Art of Motorcycle Maintenance. It is a wonderful book, sort of to design and systems thinking what The Goal is to process and stochastics (making it accessable in lay … Continue reading →

Categories Uncategorized

Assumptions

by

The following passage is drawn from Robert Pirsig’s Zen and the Art of Motorcycle Maintenance. It is a wonderful book, sort of to design and systems thinking what The Goal is to process and stochastics (making it accessable in lay manager terms). … Continue reading →

Categories Uncategorized

Black Swans Are More Common Than You Think

by

bg outline

By: Ben Geller, VP Marketing, Troux
describe the image 

The term “Black Swan” was coined by University of Oxford, Saïd Business School professor Nassim Nicholas Taleb to describe high-impact events that are rare and unpredictable but in retrospect seem not so improbable. In the world of IT, black swan projects reap catastrophic effects and even result in a complete corporate meltdown. According to Taleb’s colleagues, Bent Flyvbjerg and Alexander Budzier, “IT projects are now so big, and they touch so many aspects of an organization, that they pose a singular new risk.”1 Flyvbjerg and Budzier go on to state “The CEOs of companies undertaking significant IT projects should be acutely aware of the risks. It will be no surprise if a large, established company fails in the coming years because of an out-of-control IT project. In fact, the data suggest that one or more will.”

They reached this bleak conclusion after conducting the largest global study ever of IT change initiatives. The pair examined 1,471 projects, comparing their budgets and estimated performance benefits with the actual costs and results. The IT change initiatives ran the gamut from enterprise resource planning to management information and customer relationship management systems. Their study sample drew heavily on public agencies (92%) and U.S.-based projects (83%), but they found little difference between them and projects at the government agencies, private companies, and European organizations that made up the rest of their sample.

When the University of Oxford team broke down the projects’ cost overruns, what they found surprised them. The average overrun was 27% — but that figure masked a far more alarming one. Graphing the projects’ budget overruns revealed a “fat tail” — a large number of gigantic overages. Fully one in six of the projects they studied was a black swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%.

Their findings highlighted the true pitfall of IT change initiatives: It’s not that IT projects are particularly prone to high cost overruns on average, as management consultants and academic studies have previously suggested. It’s that an unusually large proportion of IT projects incur massive overages — that is, there are a disproportionate number of Black Swans. By focusing on averages instead of the more damaging outliers, most managers and consultants have been missing the real problem.

According to University of Oxford researchers, any company that is contemplating a large technology project should take a stress test designed to assess its readiness. Leaders should ask themselves two key questions as part of IT black swan management: First, is the company strong enough to absorb the hit if its biggest technology project goes over budget by 400% or more and if only 25% to 50% of the projected benefits are realized? Second, can the company take the hit if 15% of its medium-sized tech projects (not the ones that get all the executive attention but the secondary ones that are often overlooked) exceed cost estimates by 200%? Though these numbers may seem comfortably improbable, their research showed they occur with uncomfortable frequency.

Even if a company passes the stress test, smart managers need to take other steps to avoid IT black swans. They should consider breaking big projects down into ones of limited size, complexity, and duration and make contingency plans to deal with unavoidable risks.

That’s where Enterprise Portfolio Management (EPM) comes in to help. By leveraging EPM techniques, CIOs can take a step back, see the bigger picture and truly understand how IT resources are spread across and utilized by the business. An EPM approach can help CIOs, CFOs and CEOs assess what they have in terms of Applications, Technologies, Information and Projects/Investments. It can then connect these assets back to and support key business capabilities as well as corporate goals and strategies. An EPM effort can show decision-makers what Applications, Technologies, Information and Projects are needed, which are not, and how to safely retire the assets or cancel the projects that do not provide value to the business. This level of visibility equips enterprise leadership with the ability to make well-informed investment and divestment decisions and helps them avoid becoming another example of good IT intentions that turn into an infamous IT Black Swan.

1. Bent Flyvbjerg and Alexander Budzier, “Why Your IT Project May Be Riskier Than You Think”, Harvard Business Review. Vol. 89 (2011), No. 9, pp. 23-25.
 


New Call-to-Action

Categories Uncategorized

Unraveling the Developer Bias in Agile Development Practices

by

There is a contradiction that shows up in many books and articles on agile software development.  .  And I’m going to rant a little on one of them: the “developer” bias in Agile software practices.

Before I begin my rant, I’d like to tell you where it comes from.  I am an Enterprise Architect.  I am also an agilest.  I am a certified Scrummaster (for many years) and have been on many agile projects.  I’ve seen success, and I’ve seen failure.  I know that agile is good, but not good enough to overcome people who are determined to undermine change. 

I am currently engaged on a project to help an organization rewire their business processes.  All of their core processes.  Some of them are in software development… and that is where agile comes in, but some are in other areas (sales, account management, customer service, etc).  I see it all, not just the software engineering bits.

To make this work, we created a set of principles that we use to drive the conversation around transforming the company.  We train people on the principles.  We connect change to the principles.  The principles are developed from the agile mindset but are not the same as the ones traditionally tied to the agile manifesto. 

One is focused heavily on the notion of an empowered team.  As the trainer, I’ve embedded these principles into my head.  Kinda hard not to.  So when I’m reading a book on agile practices, and the author says something that violates one of these principles, it stands out.  Big time.

And hence the rant.  I was reading Mike Cohn’s book on agile stories and I came across a passage that reflects a kind of mindset that does NOT build empowered teams.  And I went off.  The rest of this post is my rant.

—

On one hand, there is a basic expectation that we should empower the team to solve their problems using their skills and training.  On the other hand, there is a bias towards having developers involved in every part of a business process, from sales through requirements to project management and out to delivery and customer service.  The net result: we are empowering developers to perform every role.  No one else is empowered.  They are, in fact, not trusted at all.

At some level, agile practices like XP and Scrum are written, and promoted, by software developers, so it is understandable that these authors believe that software developers are a necessary part of every process.

But they are not. 

So what’s the problem

Organizations intentionally create specific roles and groups of people.  Those roles are defined to take the most advantage of the intrinsic motivations of people when performing their duties.  The things that motivate a person to become a project manager, for example, are rarely the same things that motivate a person to become a software engineer.  Motivation matters. If you are not motivated to excellence, you will not perform with excellence.

While it is fine for an individual person to be able to perform well in a couple of roles, it is absurd to build a system or business process that expects all people in one role to be able to perform another role well.  In specific, it is absurd to build processes where a technologist is required to develop requirements, or manage a project, or plan the delivery of systems.  Those processes can be performed just fine with motivated people who are trained and experienced in those activities.  However, to empower a team, people in these roles must be respected as well. 

Agile software, that so values people over processes and tools, demonstrates an utter lack of respect for the individuals who choose to excel in non-technical roles by asserting the need for developers to be involved in every step of their process.

For example, in XP (and sometimes in Scrum), user stories are described as being developed by a “customer team” that includes developers.  In the book “User Stories Applied,” Mike Cohn describes a process where a series of user roles are developed.  From those roles, the stories will be drawn.  The following is a quote from the book:

To identify user roles, the customer and as many of the developers as possible meet in a room with either a large table or a wall to which they can tape or pin cards.  It’s always ideal to include the whole team for the user role modeling that initiates a project, but not necessary.  As long as a reasonable representation of the developers is present along with the customer, you can have a successful session. — “User Stories Applied” by Mike Cohn

I’m an agilest, and this statement takes my breath away.  Why?  Because the SKILL of developing user roles is a good skill to have, but not a necessary skill for all developers to have.  Yet the author (whom I respect) assumes that the activity cannot be performed successfully without developers in the room!  At the same time, the text assumes that the task can be performed by developers exclusively (no one else is necessary at all).

The time that we spend training developers to be good at creating user stories is time that we are NOT spending training them on concurrent processing, idempotent messaging, and query optimization.  We don’t train business analysts or engagement managers on C# design patterns, so why should we train developers on user role modeling and requirements analysis?  It’s a total lack of understanding of the value of roles, and it is a bias that works against success.

What’s the solution: respect

 

Roles are not boundaries.  In any team, there are roles.  More importantly, as a member of a team, I have to trust my team members to fulfill their roles well.  If they need help, I TRUST THEM TO ASK FOR HELP.  When they do, I am happy to “cross roles” and provide help.  When I provide help, I am doing so from the perspective of a less-skilled resource, and under the supervision of the accountable role.  (e.g. if I “help” a tester, but don’t document a defect according to team standards, how much “help” am I actually providing?)

Roles are empowering.  If my team member does not ask for help, I trust each one to perform his or her role with excellence.  If I don’t trust them, how can they develop the excellence that the company expects?  How can they be recognized and rewarded for excellence if our processes and methods show a lack of trust in their roles to perform well without a developer present? 

Roles demonstrate respect.  As an agilest, I value people over processes.  That means I value the contribution of individual experts on my team to do their work with excellence, and I will show them respect for the work that they do, and the unique value that they contribute.  I will do so by allowing them to do their work without the “supervision and assistance” of a developer.

If they need me, they will ask for me.  Until then, I will get to doing what I do best.  I have a job to do, after all… and it is mine to do well.

Why this matters

Agile software development solves a problem.  The problem is that we are including waste in our processes, and that waste is causing software to be delivered late or with poor quality. 

If we optimize our processes, we can reduce waste. If we include developers in every process, we are not optimizing our processes.  We are, in fact, replacing one kind of waste with another.