Book Project: Intro
From IRF Wiki
Contents |
The Dimensions of Technology Success
The patterns identified are introduced.
Understanding the Big Picture: Expanding Contextual Consciousness
- The following players are invovled in most technology solutions:
- Sponsor or funder
- Requirments Gatherer
- Designer
- Implementer
- Operator
- User
- Government Regulator
- Yet when each of these players do their job, they are seldom aware of the larger context, which results in mistakes and contradictions in design and implementation.
- John Verity asks how this applies to users. Dan Woods explains that if systems don't provide users with knowledge of how their work fits into a larger process, they will do it less effectively and make more errors in many cases.
- There appears to be a large payoff for expanding contextual consciousness
- How can it be achieved?
Hub Vs. Edge
In most large organizations a locked-down, tightly-controlled set of central systems store the financial and operational state of the business. This is the hub. Surrounding that hub is the edge: a loosely-organized complex of tools such as email, slide presentations, spreadsheets, shared hard drives, and setups such as blogs and wikis that people use collaboratively to perform work that may or may not end up being captured by the hub.
Almost every modern application of technology has aspects of both hub and edge systems. But the players creating and implementing most applications are frequenly not sufficiently aware of how to categorize funtionality into each domains, resulting in systems either too locked down (the most common error), or those that lack structure. In response to overly locked down applications, users employ available edge tools to create their own end-around solutions, using email, IM, shared spreadsheets, ad hock databases to get their jobs done under the radar of official scrutiny. This do-it-yourself phenomenon is also known as shadow IT.
A variety of architectures (SOA), development techniques (model driven development) and collaborative tools (blogs, wikis, IM) offer ways to bring the hub and edge into harmony.
- What is the nature of the hub and the edge?
- How can one application offer aspects of both the hub and the edge?
- What tools and strategies such as SOA, model-driven development, wikis can help?
- How can the understanding of the hub and the edge inform design and implementation of technology?
Avoiding Overautomation
Most technology and software falls somewhere along a rough spectrum that can defined as follows:
- Infrastructure, such as servers, networks, and other hardware.
- Fundamental software tools such as programming languages
- Platforms and Frameworks for building solutions, such as application servers
- Partial process automation like hub systems, in which a portion of a process is automated and major parts of the process occur outside the scope of the system.
- The part that occurs outside the system is frequently supported by edge tools.
- Total automation, in which the interface between the user and the system becomes invisible and all of the process is automated. Automobiles, video games, weapons systems, and the IPod are examples of such total automation.
Many technology projects fail because the solutions designed are too ambitious in the scope of automation. They try to do too much and become difficult to use.
Agile Development
The past 30 years of software development have shown two things:
- Requirements gathering rarely results in the actual requirements of system. Instead, it results in candidate requirements that may or may not reflect that actual needs of the users being assited or business processes being automated.
- Iterative development, in which requirements are confirmed to be correct through use and then adjusted, results in better solutions.
A set of iterative development methods grouped under the term Agile development methods are based on these premises. The Unified Process, eXtreme Programming, Scrum are examples.
Despite widespread confirmation of the value of Agile methods, many large projects are based on unconfirmed requirements.
- How can the value of Agile methods be understood more widely?
