| 1 | |
There are two types of application being developed today. The first, largely in the hands of the vendor, is the packaged or bespoke application, which consists of a self-contained, installable set of files and executables to achieve a given set of aims. The second, in the hands of the IT departments across the planet, is what we are most interested in here. This is the application constructed from different elements, bought, built and legacy, to meet the needs of the business, to underpin business processes and to manage critical flows of information. This, latter kind of application cannot be considered as a single entity but as the sum of its parts, and the processes involved in its construction are very different from those traditionally associated with application development.In general, software development within an organisation is still perceived as a self-contained activity rather than one part of a bigger set of processes. The result is that methodologies persist, from waterfall and "V" to RAD and DSDM, which are encouraged to take the needs of the business and the architecture into account but which are still treated as though a boundary exists between them and the outside world. Despite the fact that application developers are encouraged to "think outside the box," involving users and operational staff where necessary, such involvement rarely attains its potential due to conflicting pressures. Software development processes are expanding to cover new needs such as Web Site editorial, but they lag behind the accelerating pace of technology. The bottom line is that the paradigm is wrong. Thinking outside the box is wrong, because there is no box - app development is one of a number of activities, rather than the central activity which needs to involve others as it goes along. It goes further than "involving the business", as each organisation is a link in the supply chain of activity and information flows.
| Bloor Research | Jon Collins is a Senior Analyst with Bloor Research. Prior to becoming an analyst, Jon worked in the Industrial, Financial and Government sectors in Britain and France, in a variety of roles including Consultant, IT Architect, IT Manager, Business Analyst and Software Engineer. A key element of Jon's past experience is time he spent as a software development consultant where he trained and mentored developers in development methods, processes for disciplines including Business Process Modelling, Object Oriented Design and Rapid Application Development. Jon also spent time in the definition, implementation and review of corporate IT infrastructures and messaging frameworks, both for major companies and government agencies. Jon's current work includes advising an international Insurance Company on eCommerce issues. |
Critical Success Factors
The context, it would be fair to say, has changed drastically from that of even five years ago, yet it is not being taken into account - applications are being written as though nothing has changes. The context gives us the backdrop, the requirement, the problems which must be solved along the way and, to a large extent, the solutions to these problems.
Secondly, the definition of critical success factors for projects. This
is the domain of the methodology. Did eBay follow a methodology? Probably
not. Should we? At the top end, methodologies can be monolithic, bureaucratic,
largely unusable doctrines whose sole purpose is to wait for obsolescence.
There is clearly a middle ground, in which the needs of understanding and
usefulness are balanced with flexibility, and it is this point we should
strive for.
| Session: Workshop 170 minutes | Level: intermediate |
| Audience: This session is intended for IT-literate managers and developers with some OO knowledge, who are working (or who will be required to work) on eBusiness software development projects for end user organisations. % | Max 30-50 |
| 1 | |